First of all I just joined this group so let me salute all members !!
I have a request and I would be happy is someone could help.
You all probably know that embedded systems are more and more considered as hot topics to be though at universities. I will be in charge of managing a complete course for graduate students on embedded system with a focus on software engineering and operating systems for embedded platforms.
Since having only a theoretical course is quite a boring activity : ) I am looking for the best platform students can experiment and play with (doing labs, projects and so on)
Obviously, free and open source platforms are privileged since this is an education purpose in a university that cannot afford paying money for licences; or even managing a complex relation with an industrial partner with some 'discounts' on licences.
So if anyone has a suggestion I would be happy to know about it. At the end of the process, I'll send a table summarising all the suggestions so other people/teachers could benefit from it.
Opinions on this vary wildly but I started out with PICs and I think it was a good way to start. Development kits are in abundance but all each student really needs is a breadboard, a 16F84, a 20MHz crystal and a few LEDs/switch. Oh, and a 5V supply of course. MPLAB is free and allows development in assembler. Developing in C will require the purchase of compilers.
Programming the devices can be done in a few ways but will require purchasing equipment. Or write a serial bootloader and flash the devices once and use serial comms for programming them thereafter. Cheaper but harder.
Whilst I've not worked with them myself then I believe AVRs are also of this sort of thing and that their development tools are free (even in C).
I agree with Chris about this and would put teaching about RTOSs (or certainly any practical teaching using them) well down the list of things to experiment with. Getting the hang of interrupts and using ADCs and serial communication is far more useful I would say, and also makes for some fun experiments. A model weigh-bridge relaying its data back to a PC is far more fun and interesting than watching an RTOS light LEDs in different tasks.
Moreover, working with an RTOS throws up a barrier to progress, at least initially. For small tasks it is easier to dispense with the RTOS and just write code. You'll find things getting unwieldy the more different things you ask the processor to do, until at around the 3 - 6 'task' point you find that you can justify the overhead of using an RTOS by the ease of adding more tasks.
--
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" gives you just what it says.
See details at http://www.wescottdesign.com/actfes/actfes.html
Hi, I can recommend FlashForth and PIC18Fxxxx processors. See
formatting link
It is a target resident interactive Forth environment which you can access via terminal emulator on the PC. It has an interpreter, compiler, assembler and a multitasker. You can interactively read and write all PIC registers and memories and incrementally develop your software. Once you have flashed the kernel into the chip, it is writeprotected and you do not need any programmer to develop your code.
FlashForth is free with a GNU license and Microchip is happy to send you free samples of the chips. Of course you have to build boards yourself then or buy some boards. There are large offerings of PIC prototyping boards.
At risk of inflaming the Church of Forth I would venture that C would be more useful to a student, particularly because they are likely to be learning it it other modules. If there were a FlashC version which is a friendly and useful as FlashForth sounds then it could well be an ideal solution.
The best thing about AVR and IAR is the easy start. You can have a working program in 10 minutes without any prior knowledge. However AVR is not so good as the production part. Being an AVR fan myself, I have to admit that.
Why paying so much attention to RTOS or non-RTOS question? A RTOS is just another library to use. It is also a style of programming which can be handy for some cases.
For the expert -- yes. For the student, there's a pretty big learning curve to using an RTOS effectively. Getting all of your 'i's dotted and 't's crossed can be confusing the first time around, which can get in the way of the (hopefully) real point of the exercise, which is getting a headless, limited-resource processor to do something useful.
But you are probably correct that it's getting too much print in this particular thread.
--
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" gives you just what it says.
See details at http://www.wescottdesign.com/actfes/actfes.html
You live dangerously. But there is no FlashC, is there ?
I agree that Forth is not very hot on a students resume. But it is an amazingly illustrative environment to work in. And since it comes with the source code you can actually figure out what is happening. Learn to think, instead of learn to IDE :-)
Is rarely used in industry. .... Forth is a damned good language but it is going to be little use to students on a course where they want to get jobs afterwards.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ chris@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Not that I'm aware of, but it would be nice if there was. I did know of a serial bootloader a colleague of mine wrote but it didn't come with all the friendly development tools and pretty much just allowed an MPLAB generated hex file to find its way into a PIC.
It is on my list of things to have a play with if I ever find any spare time. For a blue-sky project I might think about it but everything I do here has to be backwards compatible with existing systems.
Having the source code is not always a good idea. You want to teach programming not have the students hacking in to the environment. They are usually too easily distracted anyway.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ chris@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
The AND was just fine - FOSS is a commonly used term to avoid the confusion that comes with the 'free' ambiguity. Apparently he's looking for something that is free and open - software released under FSF approved licenses qualifies for this job.
You are of course right that using free software doesn't mean zero cost. The learning curve of free toolchains can be steeper than that of closed commercial offerings, but I think this argument is invalid in this context. The setup can be prepared, tested and documented in advance, allowing the students to concentrate on using the tools for a specific assignment.
If this was an engineering company looking for a platform to build a product on, bound by tight timings, and with no prior experience with the available tools, a commercial product might be appropriate, but this situation is different.
When teaching "embedded system with a focus on software engineering and operating systems for embedded platforms.", having the complete source to all parts available (the open part) AND being able to talk (write, publish, criticice, ...) about its implementation (the free part) is certainly a good thing (tm).
With ARM being the architecture I know best this is what I would recommend. The architecture scales from low-end synthesizable cores for use in FPGAs (Cortex-M1 being the smallest I know about) up to multi core systems with large amounts of memory.
There's a wide variety of development boards available for moderate prices. The devboards from the chip manufacturers tend to be rather pricey, but other companies produce suitable boards as well.
The software side can be covered completely using free software. Eclipse is becoming a defacto standard (opinions on it may differ, but it certainly is one of the most ambitious projects), and the GNU toolchain is available for a multitude of targets, of course including ARM. Debugging has been a weak point, but (shameless plug) the OpenOCD now offers JTAG debugging (and programming) for ARM7/ARM9, Cortex-M3 and XScale based targets. The necessary hardware can be built for little money (Wiggler clones, FT2232 based USB solutions) or bought for a little more money (FT2232 based USB solutions, several other commercial offers).
Available operating systems are for example FreeRTOS, eCos, BSD variants and the ubiquitous Linux. Again, with Linux being the system I know best this is what I would recommend. There are platforms with support for many peripherals readily available in the mainline kernel, others require vendor supplied patches, until they eventually find their way into the kernel. If you're going the route of using Linux on an ARM9 system, using something that's well maintained is an important aspect, if you want to benefit from the community keeping your platform supported by current tools. The Atmel ARM9 Chips (AT91RM9200, AT91SAM926x) are a good example with lots of support in the mainline kernel. Marvell PXA27x (formerly Intel) is also well supported, but since Marvell acquired the PXA business the situation apparently got worse, with Marvell being unwilling to offer even product briefs without signing an NDA. The code in the kernel is of course still there, and the original documents from Intel are still available (with some searching, and not from Intel itself). The carme project from the Berner FH (carme.bfh.ch) builds upon a PXA270 module, and is targeted for educational use. Cirrus CS-EP93xx support is available both from the manufacturer (code quality there probably isn't the best, at least for Linux standards) and in the mainline kernel (with fewer peripherals supported). Samsung S3C24xx is well supported as well, and is being used in the OpenMoko project (probably many more projects) that aims to create a completely (except for the GSM chip) open mobile phone platform, so community support for these chips is rather strong.
If you're looking for something smaller, FreeRTOS (or no OS at all) on an ARM7 might be a viable choice. Microcontrollers from Atmel (AT91SAM7), NXP (LPC2000) and ST Micro (STR7x) are in wide use, with cheap development boards and lots of examples available.
The idea was not to let the students rewrite the compiler.
In embedded programming you also want to teach how the software interacts with the hardware. So if you have the low level source, you can see how to program to interact with a piece of HW. Of course you can use assembly for that also, but as soon as you take in C and closed libraries you loose the clarity.
And with Forth you can interact with the HW from the command line, and easily grasp what is happening.
After that it is easy to learn C and the IDE of whatever one is using. (I have been on too many courses where 75 % of the time is spent presenting the IDE buttons).
Another thing you want to teach is debugging. Debuggers for embedded usually cost money per seat. With Forth you can at least print out traces and test your code one small piece at a time. Much of your time is usually spent debugging anyway.
Anyway this was just one alternative for the list.
Knowing quite a few people who learned to programme using Forth and then went to the other camps afterwards I do not consider Forth to be any sort of blockade to getting a job. Considering that there is a Forth in every Sun Workstation and in many PowerPC's not to mention in a wide range of industrial devices (just well hidden from the normal user) I would consider it a useful language to know. Then I know you would expect me to say that anyway.
--
********************************************************************
Paul E. Bennett ....................
Forth based HIDECS Consultancy .....
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.