Low Cost SBC Dev Kits for Embedded App Training?

SmilingMonk writes "The company I work for is looking to train engineers fresh out of school on embedded software development. It seems to be specialized enough field of interest that it might be helpful for some people to 'get their feet wet' developing embedded solutions on in-expensive SBC ^? s before they are handed off to the product lines. A low cost ($400) full featured solution we recently stumbled across is the eCOG1 Development Environment. Yes, we've been to LinuxDevices, but feel compelled to ask which similarly featured low priced SBCs others have used that we could have our trainees develop embedded Linux applications on?"

Comments

How about one that combines GNU training?

[bgat]

[shameless plug]

I'm an embedded development and training consultant. I have a tutorial on my website that features the ARM Evaluator 7T board (about $250) and a complete procedure for building the arm-elf GNU toolchain and debugging a simple "hello, world!" program.

I have both onsite and public training courses available, and I'm working on an elearning site as we speak. I'm also available for just plain old embedded development tasks. See my resume.

The ARM7TDMI chip that the Evaluator 7T uses doesn't have as many peripherals as the eCog chip you mention, but it is a true 32-bit chip with a GNU-supported instruction set and debugging environment. Hard to beat that!
[/shameless plug]

HTH,

Desktop PC?

[d2ksla]

Have you thought about using a regular desktop PC?

You could teach people how to set up a minimal Linux system using their own kernel, busybox etc. As far as embedded hardware goes, I'm sure the parallel port can be one good way of introducing device drivers on several levels. It is fairly simple to understand and program.

Re:Desktop PC?

[bgat]

A desktop PC is a decent place to start, but it simply can't duplicate all the concerns present in an embedded development environment.

For example, it's relatively straightforward to build a native GNU compiler, but much more difficult to build a cross-compiler (one that produces applications for a different architecture than the one the compiler ran on). Unless your embedded system is based on a PC, you will *have* to master the concept of cross compiling before you can get very far.

Also, PCs are pretty limited in the different types of peripheral hardware available, and the ways by which you control them. Writing a Linux interrupt handler is not all that much different from writing a Linux application--- at least by comparison to writing an interrupt handler for a bare-metal embedded setup.

So yes, a PC isn't a bad place to start. But don't stay there long.

Re:Desktop PC?

[d2ksla]

Hey Bill, I enjoyed your lectures at ESC/SF02 :-)

I'm not sure I agree that setting up a GCC for cross-compilation belongs in an introductory embedded course (which is what the poster was looking for). I can do it, but most embedded developers use cross-compilers the company bought or the in-house guru set up. Some link map editing should be enough.

Also, an x86 PC can still be used for bare-bones development using uC/OS-II or RTEMS if that is desireable after the Linux part of the course is over. The uC-OS-II kernel is particularly suited for a course since it comes with a pretty good textbook explaining every little detail about its' real-time kernel.

But if you absolutely have to have non-x86 experience many CPU/DSP companies have low-cost ($100-$200) evaluation boards for their chips that often include a C compiler. uC-OS supports a number of different CPU's.

Re:Desktop PC?

[funky womble]

The Soekris boxes might be good. They're Elan-based (486) single-board computers (not PC/104). They come with 8-bit general purpose I/O, compactflash, RS232, PCI, miniPCI, ethernet, hardware watchdog, and some have PC card support. Console is directed over the RS232 port. Take a look at the mailing list archives for examples of what people are doing with them.

Not directly relevant to learning a Linux based system, but maybe an interesting training tool: old home computers! Some of the Commodore computers (for example C64, VIC20, Plus4) have general-purpose I/O 'user ports'.

TI DSPs

[den_erpel]

We are giving a seminar to a number of engineering students with the same goal and have put a lot of material online.

More information should become online on DSPInfoExchange, but as with most companies, promises, promises, promises... If you are interested, you can always contact me for the rest.

If you have a look at the Texas Instruments website and look for DSP Fest or Developer's Conference, you'll find a lot of relevant material. They promised to release linux tools a couple of weeks ago on the tidevcon 2002 (not the full blown gfx interface, but rather gdb like) for the 'C6000 line. Let's hope they deliver :)

Re:Hello?

[bgat]

Engineers fresh out of school can't handle this simple task on their own?

Nope. And I for one don't have a problem with that.

It's just a hobby for me now, but I can still slay 99% of the 'engineers' out there.

That's exactly the trouble I'm frequently called in to clean up after.

An engineering degree is mostly about training you how to think. You aren't going to learn how to write fault-tolerant code, how to harden a system to survive in an industrial environment, or anything else that's so application and domain specific. Five years just isn't long enough. And with no real practical experience to go along with them, even if you *could* train an undergraduate in those skills, you'd still be wasting your time.

The field of embedded systems is *huge*. It requires continuous effort to stay trained in the latest state of the art as it applies to solving real problems. I'll take a trainable, fresh graduate who realizes he's an idiot, over a garage hacker who thinks that since he can make a few LEDs light up on his Basic STAMP, he's ready to design a diesel engine controller.

I realize that these are sweeping generalizations on my part, ymmv.

Re:Intrinsyc Cerf Cube

[bgat]

I've got a cerfcube here, it's pretty nice. Their GNU toolchain setup process is kinda brain-dead, but their Linux port isn't too bad. I've heard they're moving to Familiar for their Linux setup, but I haven't taken a look lately to see what progress they've made.

Still, it *is* a StrongARM-powered device. Man, that's one buggy chip! If it didn't have Chipzilla and Micro$oft pushing it so hard, that silicon would have been made into bathroom mirrors a long time ago. Gaaak!

But yea, if you're wanting to get a quick start with embedded Linux, a 'Cube isn't a bad way to go.