LAOS Laser

How does this compare to a linux board plus a microcontroller (cortex or even atmega) for the hard real-time stuff? You'd get lots of mature functionality for free that way.

I think what you mean is: can we do the real-time stuff in one loop on the Cortex and have all the other loops on a Linux board? I don't think that would work. I wouldn't want a Linux board to be part of the minimal equipment and there are too many tasks that need real-time interference.

I'm not sure I follow. Real-time comes in many flavors. The only hard real-time requirements I can think of so far is: stepping, homing switches, and laser ON+PWM. Well, for a basic HPC LS3020 anyway. For everything else, even 100 ms responsiveness should be plenty and within reach of the most basic Linux boards.

Example: 1x Carambola (Linux + Wifi + Ethernet + USB), 1x STM32VLDISCOVERY with ARM Cortex M3 (DigiKey 497-10633-ND), together on a board with 2x stepper drivers and some other basic stuff. Plenty of I/O left to avoid the extra I2C Panel. Parts cost well under €50. So perhaps double that for a complete system?

Reducing the functionality of the microcontroller to just RT stepping is a option. However: this does not solve the original question:
having a off-line (most optimally a processor independent) development environment.

Depending on the use case more tasks can be switched between uC and embeddedLinux system (e.g. if WIFI is required, or more advanced user interface)
There still is a strong use case for the uC only (with ethernet or USB) solution.

Is there any progress on this?

Are you perhaps aware that mbed.org support exporting to an offline toolchain?

Eg: http://mbed.org/handbook/Exporting-to-GCC-ARM-Embedded

Yes, the export is a nice way to get all the files out. But the result still needs the "mbed.ar" runtime library, which is not available as open source.

I've been spending the past week exploring all the ARM toolchains out there. This one in particular is nice: https://github.com/adamgreen/gcc4mbed - it has binaries for Windows, Mac, and Linux x86. Adam Green's toolchain used to be based on Code Sourcery, but now seems to be based on the [Linaro](http://www.linaro.org/downloads/) setup, which ends up as arm-none-eabi-gcc, etc.

Next up is an exploration into the different runtime libraries and small RTOS kernels. Lots of stuff out there, I'm trying to make careful choices...

Have you checked out this: http://code.google.com/p/mbed-lib/ ?
Seems to be an open source replacement for libmbed.a (mbed.ar for non-gcc)

Yep. But no activity on that SW for some time, and only a few peripherals implemented (not PWM, Ethernet, no filesystem etc.)

A first solution (for Laos) would already be the ability to compile with GCC4MBED and use the "official" binary mbed.ar library.
The (only) problem at the moment is Ethernet (library support) that we do not yet get working (and some other minor code tweeks).
I am working on it. Let me know if you would like to help.

I have been trying to compile using gcc (arm-eabi-gcc). The error I get at this moment is (and related messages):

undefined reference to `EthernetNetIf::EthernetNetIf'

It seems that I am missing the libEthernetNetIf.a library.

Do you have any clue what is actually wrong, and how to fix it?

See here:

http://mbed.org/users/donatien/code/EthernetNetIf/

also some discussion on the offline use of EthernetIF:

http://mbed.org/forum/bugs-suggestions/topic/3345/?page=1#comment-16957

Thanks. This does give me a usable library (EthernetNetIf.ar).
Now I am a step further, and now got other errors about undefined references.

This may also be required:

http://mbed.org/users/mbed_official/code/EthernetInterface/

Mark: Are you working from the "embedded Arm" exported sourcecode from the online MBED compiler, or the Github version?
jcw had best results using the exported "gcc embedded ARM" file from the project MBED.

you might want to focus on compilation and function without the network code
(just leave out all LaosServer code). If it works with SD printing and USB serial connection, that is already great!

I now was able to compile a bin file. I have no idea if it will work (probably not)

What I did was remove the ethernet code as you suggested. This made everything compile, but left the code probably broken, due to me just commenting out the ethernet code.

Great! Can you post the code somewhere?

You could add some code to laser a file from sd.
Do you have a display? Then you can load a job via the menu.
There is a config flag that disables the bdeletion of jobs at startup.

I will post code when I can.

My laos board is still under construction. First I will make sure the provided firmware/code works.
Also I dont have a way yet to put the code on the display cpu.

I have spent some time preparing the code.

There are two issues to be resolved before I can publish:
- http://redmine.laoslaser.org/boards/3/topics/123
- http://redmine.laoslaser.org/boards/3/topics/124

Please help out if you can.

Earlier tonight, I was also able to pull down the sources from your https://github.com/LaosLaser/Firmware repository and got all of the code to build successfully with gcc4mbed, including the networking code. I don't know if that is any more than what you have completed mark? If it's not, then I can just discard my attempt. Otherwise, I could test it out and issue a pull request once I know that it will basically startup and run without crashing/hanging. To do this, I was wondering if someone could point me to a file that I could send with TFTP to test out my version of the sources. Then I could step through it in the debugger and make sure that everything seems to be running as I expect from my cursory read of the laos firmware sources.

By the way, I also got the mbed RTOS and new networking stack to build and run under gcc4mbed last week so if you are interested in trying that out, I could pull that in and attempt to convert your TFTP server to use it as well.

I guess I should also introduce myself since I am a complete newbie. My name is Adam and I have been playing around with the mbed processor and trying to get it to play well with the GNU tool chain over the last year or so. So while I don't have a laser cutter (yet), I do have quite a bit of experience with the mbed processor, the lwIP networking stack, and utilizing both of those from the GNU toolchain. Let me know if I can be of any help in your cool project!

Great! Does your build still depend on the mbed.ar runtime library? It would be nice if we could end up with a build that is based fully on open source, IMO.

Nah...I am not that ambitious :) It uses the mbed SDK libs/headers pulled down from the mbed site which are as you say, closed source.

But I would think that getting it to compile under GCC is an important step in that direction. You could then pull away from your dependencies on the classes it provides.

He adam, great work! We (jaap, me and now mark) are working on this for some time.
The first problems we encountered where in compiling the networking code.

Other problems include getting it alll working correctly at the same time:
Filesystem, network, I2C and timer interrupts. To test this you need to connect
At least a sd card (better also one of our I2C displays).

Do you have plans to own a laser syetem? (yes they are cool, and even your wive and
Kids can join in the fun.... The holliday season is near....)?

Put a config file on the mbed (see githiub) and send one of the lgc test files (also from github)
Via tftp (binary mode).

Getting the code run with an rtos would be great!
Let me know if you need anything!

With regards,

Peter.

By the way, our first motivation at this time to switch to the offline compiler is
The fact that we want to use git as our main repo and have more people to
contribute to the Sourcecode.

For the networking, I replaced the sources from your tree with a newer, slightly more robust version from http://mbed.org/users/segundo/code/NetServices/ This one isn't precompiled and comes with all of the sources. I did have to make a number of changes to the code to then get it to compile with GCC. I don't know if it works though and I would definitely want to run it and debug out any low hanging issues before throwing it your way. I have gotten it to work in the past so I think it has a chance of working here as well.

I can probably test out the file system, networking, and timers to see if they all work but I don't have access to a I2C display so that isn't something that I can easily test.

A laser system is probably further off in my future.

I already found the config files on github but I didn't find the lgc test files. Can you give me a pointer to the location of one of these samples? Thanks!

The fact that we want to use git as our main repo and have more people to contribute to the Sourcecode.

So I take it that this means having it run with gcc4mbed where it still uses the mbed SDK initially is acceptable?

By the way, do you guys hang out on an IRC chat room?

I don't use IRC.
Email, this place, face-to-face and the occasional skype call.

Btw: in the software/lua/ folder you can find some test files.
In the firmware/config file you can find a suiteable config file.