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?"

How about one that combines GNU training?

[bgat]

[shameless plug]

I'm an embedded development and training consultant. I have a tutorial [billgatliff.com] on my website [billgatliff.com] that features the ARM Evaluator 7T [arm.com] 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 [billgatliff.com].

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,

LinuxDevices

[GreyWolf3000]

I don't think LinuxDevices can be beat for anything relating to embedded Linux development. Great to learn on too!

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.

cross is a must, soft first target second

[push_bp]

Chose the software first (dev and debug tools), then the target. I'm not sure that setting up a cross-dev chain is a must, but learning to *use* some is mandatory. In the gcc chain, at least the binbutils part, there are tools like objcopy or objdump that you may not heard of if you stay with PC/PC. Embedding is cross-compiling. It's not just the same: different object format, static vs dynamic link, endianeness, different library... and then there's the upload to target and debug step. cross/remote-debugging is special: is slows down your code-compile-debug cycle, you may not have the full debuger capability your used to, you may have to write some debuger script to put your target in a known step first. Will you debug via serial with a ROM-monitor of a kind, via ethernet, with BDM, will you use an ICE... So do use a cross-compiler, and do use a remote debuger. You don't have a real contact with embedding as long as you stay PCPC104. PC104 is an industrial reality, but you asked about "learning", not doing actual projects. be assure that someone trained on a cross environment will be at ease in a PCPC setup. Considering the target, wich was your question ine the first place: two criteria comes to mind. - supported by gcc - not Intel x86 architecture (see above: cross!) One of gcc main point is the broad range of CPU family it supports. Just say "32 bit" and gcc is there. So time spent on gcc can be recycled on other CPU. BTW I build my first cross-gcc chain using the excellent (even if at the time these were only draft) documentation from Bill. I now I use the RPM from OAR/RTEMS http://www.oarcorp.com They are available for PC host towards most target CPU, binutils+gcc+newlib. At least Motorola 68000, PowerPC, Hitachi SH, of course Intel x86, ARM I think, MIPS maybe + others?

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'.

Coldfire Based Embedded SBC's

[NoAGuru]

Cybertec http://www.cybertec.com.au have a product that is based on open-source software that looks like it would fit your requirements.

Processor = Coldfire 5272
Compiler Tools = gnu (linux or windoze hosted)
RTOS = RTEMS (The best RTOS in the world! http://www.rtems.com)

The cost listed on the web site is $ 525 AUD
(i.e. about $260 US).

I have not used the product but I the company is very active is supporting Coldfire and RTEMS.

Best regards
Paul

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 [kuleuven.ac.be].

More information should become online on DSPInfoExchange [ti.com], 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 [ti.com] 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.

Intrinsyc Cerf Cube

[trailerparkcassanova]

Check this out:
http://www.intrinsyc.com/products/cerfcube

Although developing applications for a embedded system does not an embedded developer make. An embedded developer should be able to bring up a brain-dead board/system from scratch. They need to know about init'ing the board; CPU (cache, interrupts, etc), memctlr/memory, peripherals, using FLASH (reading, updating, running code from or copying into RAM), updating NVRAM on the fly, handling interrupts, debugging without an ICE or debugger, etc. Do they need a FLASH file system? They need to know how to get information from a schematic and/or a datasheet. These are just off the top of my head. There's a lot of gotchas that embedded application developers never deal with. So training on a SBC/box/whatever that already has an O/S ported and running doesn't teach much embedded development. The dirty work is already done for you.

Someone mentioned pick the tools first. Well that never happens when you develop systems that are to be produced in volume where cost is the main consideration.

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 [handhelds.org] 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.