Low Cost SBC Dev Kits for Embedded App Training? 26
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? (Score:5, Informative)
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 (Score:1)
Desktop PC? (Score:3, Insightful)
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? (Score:2)
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? (Score:2)
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 (Score:1)
Re:Desktop PC? (Score:2)
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 (Score:1)
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 (Score:2, Interesting)
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? (Score:3, Insightful)
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 (Score:1)
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 (Score:2)
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.