Prev: About Interrupt Problem in RHEL-5
Next: Need help on getting the original source code of eZ430 Chronos
From: Nial Stewart on 9 Jun 2010 08:34 > * PCB design. > ** High speed PCB stuff important? It's probably important to give them enough information so they understand what causes problems and when they might encounter them when doing a design. And let them know where they can get more details if required. Nial.
From: Mark Brehob on 9 Jun 2010 12:21 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
From: address_is on 9 Jun 2010 15:21 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
From: Jon Kirwan on 9 Jun 2010 15:31 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 Or reset ciruits, since you bring that up. Jon
From: Paul Keinanen on 9 Jun 2010 16:09
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 ? |