views:

711

answers:

4

As a kind of opposite to this question: "Is low-level embedded systems programming hard for software developers" I would like to ask for advice on moving from the low level embedded systems to programming for more advanced systems with OS, especially embedded Linux.

I have mostly worked with small microcontroller hardware and software, but now doing software only. My education also consists of hardware and embedded things mainly. I haven't had many programming courses and don't know much about software design or OO coding.

Now I have a big project in my hands that is going to be done in embedded Linux. I have major problems with designing things and keeping things manageable because I haven't really needed to do that before. Also making use of multitasking and blocking calls instead of running "parallel" task from main function is like another world.

What kind of experiences do you have on moving from low-level programming to bigger systems with OS (Linux)? What was hard and how did you solve it? What kind of mindset is needed?

Would it be worthwhile to learn C++ from zero or continue using plain C?

+7  A: 

The main problems with using the Linux kernel to replace microcontroller systems is driving the devices you are interfacing with. For this you may have to write drivers. I would say stick with C as the language because you are going to want to keep the user-space as clean as possible. Look into the uclibc library for a leaner C standard library.

http://www.uclibc.org/

You may also find busybox useful. This provides many userspace utilities as a single binary.

http://www.busybox.net/

Then it is simply a matter of booting from some storage to a live system and running some controlling logic through init that interfaces with your hardware. If need be you can access the live system and run the busybox utilities. Really, the only difference is that the userspace is much leaner than in a normal distribution and you will be working 'closer' to the kernel in terms of objectives.

Also look into realtime linux.

http://www.realtimelinuxfoundation.org/

If you need some formal promise of task completion. I suspect the hardest bit will be booting/persistent storage and interfacing with your hardware if it is exotic. If you are unfamiliar with Linux booting then

http://www.cromwell-intl.com/unix/linux-boot.html

Might help.

In short, if you have not developed at a deep level for Linux, built your own distro, or have kernel experience then you might find the programming hard-going.

http://www.linuxdevices.com/ Might also help

Good Luck

Aiden Bell
I have a working hardware, at least for now. And besides, I've been trying the code mostly on the pc. So the actual coding is the biggest problem at the moment, but I might need these later. Thanks.
Purple Tentacle
No worries! Good luck with it all.
Aiden Bell
+1  A: 

In order to work with Unix/Linux you should get into the Unix philosophy: http://www.faqs.org/docs/artu/ch01s06.html

I consider the whole book a quite interesting read: http://www.faqs.org/docs/artu/index.html

Here you can find a free Linux distro for embedded targets plus bootloader to get you started: http://www.denx.de/wiki/DULG/WebHome

robert.berger
Seems like a good read. Thanks.
Purple Tentacle
+2  A: 

I was in a very similar predicament not too long ago. I bought and read Embedded Linux Primer and it was a very helpful way to make the mental-transition to a high level OS (from a microcontroller perspective).

If you have the "time to 'take your time'," you could obviously make the transition. But if you need to get up to speed quickly, you may want to strongly consider getting a technical mentor to help guide you.

Nate
+1  A: 

You also may find it useful to work your way into Linux by starting out with ucLinux. It's basically Linux on a microcontroller. You could get a feel for the kernel without the virtual memory aspect of it as transition. See if ucLinux supports a microcontroller that you are already familiar with and see how the kernel interacts with that architecture.

I agree that the Embedded Linux Primer book is great for getting your brain wrapped around embedded Linux. You're better off sticking with C for now. C++ can wait, and it's more useful for applications, not driver code.

When you're comfortable with how ucLinux operates, then you could start out with a normal Linux kernel on a microprocessor architecture such as ARM that has an MMU and virtual memory.

Just my two cents!

DoxaLogos