Slashdot Mirror
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?"
[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,
b.g.
I don't think LinuxDevices can be beat for anything relating to embedded Linux development. Great to learn on too!
Slashdot: Where people pretend to be twice as smart as they really are by behaving like children.
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.
Freevo - Linux Multimedia Jukebox
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
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
Genius doesn't work on an assembly line basis. You can't simply say, "Today I will be brilliant."
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?
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.
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.
b.g.