Looking for thoughts on embedded systems education
in [Embedded]
|
Prev: About Interrupt Problem in RHEL-5
Next: Need help on getting the original source code of eZ430 Chronos
From: Walter Banks on 9 Jun 2010 16:34 address_is(a)invalid.invalid wrote: > Mark Brehob <brehob(a)gmail.com> wrote: > > Hello all, > > I've been teaching embedded systems for quite a few years now and we > > Snip..... 8< > > Nobody seems to have mentioned watchdogs... Indirectly I did with timers. Watchdogs have not been all that useful. As processors get larger code is often now transferred on reset from slow ROM to fast RAM to be executed. The reset times can be very large and other reliability strategies need to be used. Alternatively watchdogs are used to trigger events that stabilizes the system in a some safe mode. The additional application complexity may not be worth it. Regards, Walter.. -- Walter Banks Byte Craft Limited http://www.bytecraft.com
From: John Devereux on 9 Jun 2010 16:38 Paul Keinanen <keinanen(a)sci.fi> writes: > On Wed, 09 Jun 2010 19:21:49 GMT, <address_is(a)invalid.invalid> wrote: > >>Mark Brehob <brehob(a)gmail.com> wrote: >>> Hello all, >>> I've been teaching embedded systems for quite a few years now and we >> >>Snip..... 8< >> >>Nobody seems to have mentioned watchdogs... >> >>Glyn > > Apart from high radiation environments, who needs watchdogs ? Agreed. Starting out, a long time ago before I learned how to do EMC, I used watchdogs all the time. In desperation I even had one system with a free-running 555 connected to the reset pin. They still crashed occasionally, or worse! Now I know how to protect agains ESD and line tranients, I don't bother with watchdogs anymore. And they don't crash. -- John Devereux
From: D Yuniskis on 9 Jun 2010 16:59 Hi John, John Devereux wrote: > Paul Keinanen <keinanen(a)sci.fi> writes: > >> On Wed, 09 Jun 2010 19:21:49 GMT, <address_is(a)invalid.invalid> wrote: >> >>> Nobody seems to have mentioned watchdogs... >>> >> Apart from high radiation environments, who needs watchdogs ? > > Agreed. > > Starting out, a long time ago before I learned how to do EMC, I used > watchdogs all the time. In desperation I even had one system with a > free-running 555 connected to the reset pin. They still crashed > occasionally, or worse! > > Now I know how to protect agains ESD and line tranients, I don't bother > with watchdogs anymore. And they don't crash. As with most things, this depends entirely on the application environment. When designing *gaming* systems, you have to contend with malicious users deliberately *trying* to subvert your system. It is almost impossible to protect a *running* system from these kinds of threats. I have found the opposite tactic to be more effective: *cause* the system to deliberately reset when attacked (not so the code will safely restart but, rather, so the attacker will forfeit any "winnings" he has acrued). Amazing how quickly they stop using this means of subversion. :>
From: -jg on 9 Jun 2010 17:12 On Jun 10, 4:21 am, Mark Brehob <bre...(a)gmail.com> wrote: > On Jun 8, 1:10 pm, Mark Brehob <bre...(a)gmail.com> wrote: > > > > > Hello all, > > I've been teaching embedded systems for quite a few years now and we > > are looking to make some major changes in what we're doing (going from > > one class to two, going from PPC to ARM/ATOM/AVR, etc.) I _think_ > > we've got a pretty good idea about the direction we're going, but I > > thought I'd come here and try to get feedback about what folks in > > industry (and anyone else frankly) think is important and what isn't. > > In general I'd love to hear any thought you all might have, but in > > specific I thought I'd get feedback on how important it is to spend > > time on certain topics. Again, any and all feedback would be > > welcome... > > > * ABI (application binary interface) stuff. Specifically caller/ > > callee registers, dedicated registers, stack management, and the like. > > > * Writing code in assembly. > > ** Specifically handling all the issues associated with interrupts by > > hand (saving all registers used, nested interrupts and saving state > > for that, identifying interrupts sources etc.) > > > * Processor memory bus interfacing. Timing, having I/O devices > > respond to external memory requests etc. > > > * Creating hardware (via FPGA) to do interfacing for either memory bus > > or some other protocol. > > > * I2C/SPI/other simple serial interfaces > > ** Is just learning to use them enough? Should they learn to control > > wires by hand? > > > *USB/firewire or other more complex serial schemes > > > * PCB design. > > ** High speed PCB stuff important? > > > * High-level tool sets? Matlab/Simulink, Android development stuff, > > Arduino? > > **What should they learn? Does it matter which? > > **Is writing low-level modules to work with these tools important? > > > *Writing Linux device drivers? > > Wow, I knew I'd get a lot of feedback, but I didn't expect that much > from so many folks... A lot of you have asked some really good > questions, mostly asking for more context, so I'll provide at least > some of that in one go. > > We've been using a PowerPC/FPGA based system (standard PPC and FPGA > board with a custom interconnect) for about a decade and it's clearly > time to make a change. We teach one pure embedded systems course > which has as pre-reqs a digital logic class, a computer organization > class (very strong coverage but uses a very simplified ISA), and one > and a half programming classes. We also have two specialized embedded > classes (controls and DSP) which are more focused on domain specific > issues (Matlab, making fast filters, computer vision, etc.) > > Our current set-up for our pure embedded systems class is that the > students spend a lot of time in lab designing I/O devices on the FPGA > and writing code that uses those devices on the PPC. The major topics > in lab are: > * Introduction to "real" assembly and byte/word issues (needed due to > the nature of our organization class) > * Memory-mapped I/O from both the hardware and software side > * Memory systems (fairly basic basic) > (The above are all done in assembly on the PPC side after this it's a > mix) > * Using C and assembly together, ABI stuff > * Interrupts (edge/level, saving state, debugging. Nesting and > "synchronous" interrupts (aka faults) vs. asynchronous interrupts (aka > external interrupts) and the whole "why we need interrupts" thing is > really only in the lecture) > *Timers (partly to introduce timers, partly for PWM, partly for more > interrupt practice, partly for on-chip memory-mapped I/O practice) > *A2Ds (basic theory and use) > > The student then do a project of their own choosing in groups which > are usually fairly impressive (say 100 hours/student put into it on > the average). > > We are going to add a new (advanced) class in embedded systems and we > are creating/updating both classes this summer. Honestly we've got a > fairly good plan about where we want to go and have involved a number > folks from industry and academia to get their thoughts. But even so > the net hasn't been cast as wide as it could be so I thought I'd ask > for thoughts about the right directions to go from the net before > things get too solidified (the next couple of weeks). > > Thanks _very_ much to each of you who have taken the time out to > provide such great feedback! I'm going to think through what you all > have said... > > Thanks again, > Mark Given this has a quite high level of pre-requisites and is quite focused, an obvious question, is WHY do you need to change ? Is it that the particular devices, and development boards, are hard to source ? The PowerPC is still actively used, and sourced from Freescale, ST, and Allied ? If you are intending to do a large change, I'd flip the problem on its head, and FIRST look for well designed Development/Project platforms. Doing this, as an example, the ST Primer2 development platform has to appeal to students. http://www.st.com/mcu/contentid-105.html -jg
From: Paul E. Bennett on 9 Jun 2010 18:47
address_is(a)invalid.invalid wrote: > Mark Brehob <brehob(a)gmail.com> wrote: >> Hello all, >> I've been teaching embedded systems for quite a few years now and we > > Snip..... 8< > > Nobody seems to have mentioned watchdogs... Not every system needs one. However, you are right, no one did mention watchdogs. I tend to use a simple pulse-maintained-relay circuit. The relay is energised within a charge-pump circuit. Any single component failure would prevent the relay remaining energised. The processor output you drive this from has to toggle at a steady rate and I tend to make this as a result of regular system sanity checks. Still, the topic is a good one for the OP to add to the list. -- ******************************************************************** Paul E. Bennett...............<email://Paul_E.Bennett(a)topmail.co.uk> Forth based HIDECS Consultancy Mob: +44 (0)7811-639972 Tel: +44 (0)1235-510979 Going Forth Safely ..... EBA. www.electric-boat-association.org.uk.. ******************************************************************** |