Part 1 in a series on embedded development explains the purpose of the project and outlines hardware options.
An Introduction to Embedded Linux Development, Part 1
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Pointless. Wait for at least 2 more Parts before bothering to post it again…
It seems to me that embedded development with linux is just about how to set up a linux and how to cross compile and nothing else, roughly.
Therefore, it is only like (or will be like) cross developing from arch A to arch B. Or is there anything special in embedded development for application programmers these days, when the OS handles all the details anyway?
There are a number of issues that pop up in embedded development that don’t in regular programming.
One: Embedded development is often done on units with limited features/resources. Take the writer’s choice of a Motorola ColdFire and uClinux. This means no MMU (Memory Management Unit). Coding for CPU’s without MMU’s tends to require more attention to memory fragmentation issues.
Two: Embedded systems tend to run unattended for long periods of time. So you better use crash/hang detection techniques and hardware resources such as watchdog timer, and you better make sure when the device does crash that it can recover gracefully. (Ever see a bank terminal crash?) Oh. Remember to watch out for those memory fragmentation issues.
Three: Many embedded systems have real-time constraints. Systems can be either hard real-time (i.e. If the device doesn’t perform some action once every 100 microseconds, then the device has failed) or soft real-time (e.g. video display, where a dropped frame here or there won’t cause any problems).
Four: In order to take advantage of the wonderful features of a lot of these devices, you often have to write your own drivers. It could be a feature that the vendor just didn’t get around to writing drivers for or a bit of hardware you made just for the application.
On the more extreme end are the devices that can’t handle linux (say, 1KB of data memory and 5KB of code space) and applications that are so bandwidth limited that interrupts need not apply (like a device that needs to make a sample once every 10 microseconds, something you generally can’t use an interrupt on a PC for). But of course, then we’re straying away from the subject of the article.
To Dennis C.:
Thanks for the short decription but I was asking about embedded development __with Linux__. I am aware of the things you told, indeed. But it seems to me that where linux can be applied as an embedded OS there is no much low level thing to care about for application (user space, not kernel space) programmers.