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: Phil on 8 Jun 2010 19:05 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 Hi Mark, I teach a pair of embedded systems courses. I believe in both covering the underlying fundamentals (especially interrupts and memory bus interfacing), but also in covering higher level design approaches. To me whether you pick SPI or USB or I2C isn't as important is that they get exposure to something that smells like a serial port. Rather than make a big long post I'll direct you to the courses I teach. The home pages have a lecture-by-lecture list of exactly what we are teaching. Tastes can reasonably very quite a bit, but in my case the content is informed by a number of years in industry before I switched to teaching. Junior-level course: http://www.ece.cmu.edu/~ece348 (gives specific section references in a course text) Senior/MS level course: http://www.ece.cmu.edu/~ece649 (includes slides on-line) Cheers, -- Phil Phil Koopman -- koopman(a)cmu.edu -- http://www.ece.cmu.edu/~koopman Author of: Better Embedded System Software, Drumnadrochit Press 2010
From: D Yuniskis on 8 Jun 2010 20:07 Hi Mark, Mark Brehob 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... From the littany of topics that follows, it looks like you are trying (perhaps) to cover too much. And, probably at a level (complexity) that many won't experience "in industry" (there are a lot of *small* embedded systems to which many of the issues below would never apply). Are you wanting to address hardware or software? or both? I would concentrate on what makes an embedded system *different* from a "desktop" system. Most of these issues are obvious -- once you *think* about them. For example: USER INTERFACE Embedded systems tend to have different user interfaces than the traditional "monitor/keyboard/mouse". Thinking about how you *reliably* communicate with a user (who and *what* is your user??) requires an entirely different mindset than the "let's pop up a dialog box and ask him a question..." approach. You may be confined to a simple keypad with a 7 segment display. Or, maybe a couple of buttons and an indicator light! :-/ Or, you may have hundreds of buttons, levers, knobs, etc. *AND*, in most cases, *all* you have are those buttons, knobs, indicators, etc. -- i.e., *you* have to interface directly to them (instead of "receiving scan codes from a keyboard"). You also have to consider how you can convey "errors" (on your part *or* the user's) to the user with these particular mechanisms. And, how the user can remedy those errors without resorting to aboriginal rain dances, etc. FIELD INTERFACE Embedded systems usually interface to other physical devices that aren't common in a desktop environment. In addition to "real" switches, you might have to monitor temperatures, pressures, rates, etc. I.e., *you* have to acquire data instead of expecting the user to "type in a value". So, you need to be conversant in various measurement techniques, understand sources of error, unit conversion factors, etc. You may need to interface to mechanism and understand how they behave, physically. So, for example, you can't expect a motor to be "up to speed" instantly after you have applied power to it. Often, you have to implement control loops. So, you need to understand classic control theory so you can recognize the issues that are important in controlling a mechanism or process -- and the techniques that you can use to overcome the issues that *will* arise ("Gee, the mechanism overshot it's intended stopping point...") COMMUNICATIONS Rather than focus on the mechanics of particular communication technologies, think about the *content* of exchanges over those media. What do you want to say? How can you be assured that the other party understands the intent of your message (e.g., in the presence of noise)? How can you be sure *you* understand what is being "said" to you? (ECC's, CRC's, protocol design, etc.). How can you be sure the other party is "still there"?? RELIABILITY Embedded systems are often throwaway, commodity items (e.g., mice). But, other times, they are expensive, one-of-a-kind devices. Or, are part of much larger *systems* (which can be large, expensive, etc.). Many times, they can have direct or indirect health and safety issues (e.g., the ABS on your vehicle; or the control system that meters insulin into a diabetic). The consequences of "bugs" can be *considerable* -- in terms of lives and treasure. And, the cost of repairing a bug can be astronomical -- many times more than the cost of the product *or* the development effort itself! (I'll be amused if Toyota "discovers" a bug in their engine control system... "oops!") [Testing is a whole course in itself] You can't just shrug/curse and give the three finger salute. So, you have to be able to think about what *can* go wrong. Even the things that you think *can't*! And, how they will affect the performance of your code and product. (e.g., what happens if you *can't* write to the FLASH??) COST / PERFORMANCE Many embedded systems are not produced in the huge volumes that are common with desktop machines. (though some are produced in even *bigger* volumes!). So, things that seem inexpensive in the desktop world can be prohibitively expensive in the embedded world. (e.g., you can buy a 17" LCD monitor in QTY 1 for about the same price as a 3" QVGA *display* -- which still needs electronics to drive it! -- in the same quantity) Most embedded systems have fixed resource complements. You can't just "add more memory" or "a bigger disk". And, being cost constrained, you can't overspecify your resource requirements to "play it safe". So, you have to learn how to come up with *good* estimates given some "nebulous" design goal (from the folks in marketing). And, how to use tools to refine those estimates before you have to commit to them. Sorry, the list goes on but I haven't the time to try to enumerate all of the issues. My point is, to avoid the petty technology issues. Those are easy to pick up. Instead, focus on the philosophical/environmental aspects of embedded system designs. Otherwise, you're just creating more "coders" without the skills to know *what* and *how* they should "code". HTH, --don
From: Mark Borgerson on 9 Jun 2010 01:20 In article <01e9e399-d752-48c4-b9b4-8f2796daf7a8 @q12g2000yqj.googlegroups.com>, brehob(a)gmail.com says... > 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? > Since I taught a course like this in the mid 80's, small processors have added DMA interfaces for serial peripherals. DMA is very useful for some things and should be discussed. TIMERS TIMERS TIMERS (and how the can be used for PWM) Mark Borgerson
From: Stargazer on 9 Jun 2010 04:51 On Jun 8, 8: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.) What you are doing seems extremely important, because embedded systems despite being widely developed and used, desperately lack good education. Below I'll try to back up my comments with real problems that I saw in many projects in different companies (and of different scale!) > 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. This is rarely really interesting, unless you write your own operating system or at least generic task switcher. Most embedded systems either include an OS already or follow single-task + interrupts design. > * 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.) Writing in assembly is rarely needed at all, but it is extremely useful for understanding and "feeling" the architecture. This isn't covered well in academia, so this is a great step for programmers to get in touch with at least one architecture. Moreover, it is enough for your student to get into one particular architecture in order to know how to approach a different one later. Regarding interrupts - there are some common issues that have to be covered: * edge or level triggered interrupts * shared / daisy chained interrupts * automatic acknowledgement by hardware (part of bus interface) or explicit software acknowledge needed (device will keep interrupting until ack'ed) * interrupt controller design: masking, priorities, in-service/EOI etc. You may use one of standard IC chips or design your own simple, but it has to exist on the test system so that students can play with it and feel what happens "here" and "then" > * Processor memory bus interfacing. Timing, having I/O devices > respond to external memory requests etc. Very important. Also to describe some common mistakes, like the one that I once had to figure out in software and docs. Spansion NOR flash was connected to 440EP PPC via one of chip selects, and its "ready" signal was connected to the CPU's peripheral polling leg... the problem was that when polling the CPU's peripheral controller allowed the device to be "not ready" for *max.* ~3 ms, while flash chip was not ready for *at least* 300-400 ms when erasing block... so the system panic()'ed with "machine check" by design! :-) Funnily, the older (and smaller) AMD NOR flash, while otherwise compatible, didn't cause "machine check exception". The reason was... that older flash chip just didn't have a "ready" leg. > * Creating hardware (via FPGA) to do interfacing for either memory bus > or some other protocol. I think that you need to separate pure hardware and pure software issues and decide what side your class will be. It can't be both. Embedded engineers are either electrical engineers with "some knowledge in software", or software engineers with "some knowledge in hardware". Hw people will not find anything new in the topic, andsw people will never need it. May be they should be two different courses - "embedded for EE" and "embedded for SW". > * I2C/SPI/other simple serial interfaces > ** Is just learning to use them enough? Should they learn to control > wires by hand? Yes, in many systems it is necessary to bit-bang, so such control should be taught. May be also JTAG software control should be there (as it is common to use for flash programming). > *USB/firewire or other more complex serial schemes USB is complex enough to be subject of a separate course. But I would suggest covering some standard UART design and communication in details. This will also make for a good communication intro. > * PCB design. > ** High speed PCB stuff important? IMO, this is subject to the same saparation between hw and sw. > * 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? I never even participated in a project in which somebody used them. But that's more of side-note and "no comment" from my side. Watch for how many responses will substantially discuss them. > *Writing Linux device drivers? A good idea. The students need to write something working from scratch, and Linux drivers are a good choice due to OS source availability, good informational coverage and extreme popularity in embedded projects nowadays. I would also suggest customizing Linux BSP for the platform, so that people get the feeling of a "live" system's needs. I would also suggest covering several topics that nearly any embedded will need: * debugging (serial interface, JTAG, software emulators etc.). Use of LEDs for debugging in bootstrap / system-critical code * communications - generic Ethernet rings design and TCP/IP stack, application-level protocols availability etc. * upgrades, version management, configuration interface etc. (flash / persistent storage interfacing). Use filesystem or design own simplified management? * evaluation of software availability (OS available? or too "thick" for the design? TCP/IP stack available? bootstrap / CPU example assembly code available? etc.) * risks estimation. This is never covered realistically. Most failed embedded projects do so not because the design was not workable, but because different vendors provide extremely bad support (see "software availability"), are not willing to fix bugs or even cooperate in diagnosing (they are more interested in "shutting" you so that nobody else will know) and bluntly false claims about their projects (they would easily lie to you that something works when it doesn't, only to generate sales). Overall amazingly bad quality of "dedicated" embedded software. Silent recognition of this fact has led to Linux taking over embedded OS field, despite that it is not RT and was never even designed to be a dedicated embedded system. Several well-known companies are now promoting their custom embedded Linux distros even ahead of their own core products. Good luck! Daniel
From: Walter Banks on 9 Jun 2010 07:54
Mark Brehob wrote: > * 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.) Combine event driven programming with interrupts focus on the objectives and no the detail of the solutions. For example an event happens interrupts current execution context must be saved. Run to completion probably doesn't need context to be saved. > * 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 Communication principles. Add LINbus and possibly CAN to the list LINbus is showing up in many of our customer applications. > * PCB design. > ** High speed PCB stuff important? > > * High-level tool sets? Matlab/Simulink, Android development stuff, > Arduino? Arduino has some distinct teaching advantages by providing some quick systems experience. It has the ability to show the big picture without overwhelming implementation details. > > **What should they learn? Does it matter which? > **Is writing low-level modules to work with these tools important? > > *Writing Linux device drivers? Hosted vs non hosted embedded systems. My own list of important topics includes. Reliability. (Also mentioned in Don Yuniskis list which has several good ideas) Principles of reliability. Start with basic reliability math and terminology work towards applying the principles. misra has some good ideas on this Timers, Timers Timers Core of many non hosted embedded systems. Event scheduling, PWM (PWM tone generation followed by DTMF with a PWM makes good lab) Multiprocessor applications. Interprocessor protocols. Load sharing. Considerations to logically dividing the application. Heterogeneous and homogeneous systems. Interprocessor calls shared variables. Possibly use IEC 61131, IEC61499 as references. Multiprocessor solutions have been here for 20+ years and needs to be formally covered. Software issues Fixed point math. One tight lecture lecture of principles of fractional math basic operations and conversions. Trading precision for dynamic range. Been there taught that. Regards, Walter.. -- Walter Banks Byte Craft Limited http://www.bytecraft.com |