Prev: About Interrupt Problem in RHEL-5
Next: Need help on getting the original source code of eZ430 Chronos
From: Mark Brehob on 8 Jun 2010 13:10
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?
From: linnix on 8 Jun 2010 16:29
Two of my comments:

> * PCB design.
> ** High speed PCB stuff important?

Not really, low speed and low cost PCBs are more important to me and
my customers.

> *Writing Linux device drivers?

Not really, but portings tools/applications are necessary.

For example, I am right in the middle of GNU hell right now.

In my case, older version of GCC works for older chip. However, new
chips need new GCC. So, new M4, MPFR, GMP, LLC, AM, AC and GCC
upgrade hell.


From: Paul E. Bennett on 8 Jun 2010 16:29
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...
>
> * 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?

It all depends on the topics in your curriculum I suppose and I think I
would write the curricula for embedded systems teaching slightly different
to most.

It is all very well teaching students about the basic architectures of
embedded systems and definitely give them an appreciation of machine coding
and assembler. Once they have that under their belt then I would look at the
other aspects of decent embedded systems design, including the design
management aspects (not many courses seem to cover that well enough). Topics
such as re-entrant code design, interrupt service routine design with simple
fault-finding and performance monitoring techniques (ban the use of a logic
analyser as a fault-finding tool). I wouldn't cover operating systems in
particular but would certainly cover some of the functions operating systems
would include.

I think I would introduce them to the notion of system modelling, task
analysis and function point analysis, exploring the risk elements posed by
systems and how to architect to reduce those risks, and insist that they
ensure the security and survivability of their project work (probably would
question whether or not to deliberately put a spanner in the spokes for that
bit but you would definitely get to know who had backed up properly and had
decent information and code management in place ... I know, it sounds
cruel).

I would definitely cover communication systems and protocols as a segment
and make one of the projects a "with comms" one.

--
********************************************************************
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..
********************************************************************

From: Jon Kirwan on 8 Jun 2010 18:01
On Tue, 8 Jun 2010 10:10:25 -0700 (PDT), Mark Brehob wrote:

> 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.)

Just as a guiding thought, designing embedded systems
teaching seems to require some ability at predicting both the
needs of students to come as well as industry directions. So
what do you see there? (There are some core values, I think,
and you've mentioned some good ones below. But suggesting
additions to your list would be easier if there were some
idea what you see as student need and industry direction.)

> I _think_ we've got a pretty good idea about the direction
> we're going,

So can you talk about that, then?

>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.)

These two go hand in hand, I think. Should be taught either
in the same class or nearby in time. I'd add "computer
architecture" generally, here, as well.

And maybe, if you can consider fitting it in, floating point
formats and some discussion about numerical methods and
possible pitfalls using FP in numerical applications.

>* 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.

Interrupts, level vs edge triggered, etc. come immediately to
mind when talking about interfacing. Also, various bus
concepts such as ISA (incident) and PCI (reflection) and
direct memory access methods all flood in. Some of this is
still meaningful at the very small instrument level, some
only comes in with very complex systems (PCI, for example.)

And once some of the more complex systems are involved, you
can start talking about memory queues and read-around-write.

Hmm. Read-around-write can occur even in a very simple
system sporting an I2C EEROM device, now that I think about
it. If the writes to the EEROM can be buffered and operate
in the background (timer-driven or in a concurrent process)
and where a read that takes place before one of the writes
can complete is allowed pick up the queue value or else must
somehow wait for the write to complete... either way, it
poses some interesting problems to think on. Synchronous vs
asynchronous reads and writes...

>* I2C/SPI/other simple serial interfaces

Including multi-master and then the few undefined states that
can occur there?

>** Is just learning to use them enough? Should they learn to control
>wires by hand?

You know your limitations better than I do. If I were
thinking about embedded systems classes, I'd probably want
them to be a 'total immersion' thing -- 15 hours a day with
the students captive on some big ship in the ocean where they
cannot escape. ;) And there are few things better at
teaching that putting hands onto actual situations and real
results to help drive home the concepts and theories being
discussed. Theory and result go hand-in-hand, I think.

>*USB/firewire or other more complex serial schemes

Once sufficiently into multi-master I2C, I think USB will be
a logical extension if you can afford the time there. I'm
not sure about how you would consider dividing time between
host and slave, though. Your 'market' determines that as
well as whether or not you cover it at all.

I encounter USB more than I'd like, though. Sometimes, the
solution is to just "buy" a USB-RS232 solution and write the
traditional serial port code to get by. Total Phase's
Aardvark and so on comes to mind here. Other times, that
isn't acceptable and more knowledge helps. I don't know
where the future is going, here, though. I'm mostly just
following along and dealing with what sits in front of me.
You need to anticipate, I think.

>* PCB design.
>** High speed PCB stuff important?

Not in my general experience. Except PCI, with serpentine
clock lines and skews, mostly because "it's so abundant."

>* High-level tool sets? Matlab/Simulink, Android development stuff,
>Arduino?

Not in my experience. But it is admittedly narrow.

>**What should they learn?

How to find information when they need it, how to interpret
what information they find, .... okay, basically how to
_imagine_ as well as how to perform when told exactly what to
do, because there will be times when imagination is what is
needed.

Actually, encouraging imagination is something that can be
done as part of the above technologies. For example, before
teaching them about multi-master in I2C (if you do that, at
all) and before even letting them know about it, take a break
and pose the problem to them for their own imagination. Ask
them about how they might 'modify' the single master I2C in
order to achieve a usable multi-master situation. Let them
work in teams on the problem and then present their ideas
shortly later to the class. Let them deal with objections,
too. It would be a great segue into multi-master, but it
would also be a lost opportunity for the students to develop
their own imagination skills if you just rolled on
immediately into the established multi-master solution
without giving them the opportunity to think for themselves
here.

This should underlie much of the teaching -- don't miss your
opportunities to encourage imagination. I think this means
breaking students into groups, in many cases, too.

And this gets back to why I'd would prefer to have ALL of
their attention, all day and into the evening, for a
concentrated situation.

At some point, not necessarily at first though, I think it
would be very good to actually have the teams compete with
each other, some of the time, and be given specific
challenges with boundary conditions spelled out but also
where they are completely free to come up with a solution, so
long as those written boundaries are accounted for, and then
given very short time scales to come up with a solution.

>Does it matter which?

That's a question for you, not me.

>**Is writing low-level modules to work with these tools important?
>
>*Writing Linux device drivers?

I haven't ever done an embedded Linux thing. But there are
some devices out there that use it. However, I suspect the
businesses (I'm ignorant, so have no idea) playing in that
game probably have their own specific ways of training new
hires and unless you are willing to become a vassal of one or
more of them, I'm not sure you can focus on that.

Best of luck and let me know where this might be taught.

Jon
From: linnix on 8 Jun 2010 18:23

> >*USB/firewire or other more complex serial schemes
>
> Once sufficiently into multi-master I2C, I think USB will be
> a logical extension if you can afford the time there.  

That's exactly my problem. The latest USB enabled chip needs the
latest GCC tools chains. Updating tools are very time consuming.

>
> I encounter USB more than I'd like, though.  Sometimes, the
> solution is to just "buy" a USB-RS232 solution and write the
> traditional serial port code to get by.  

USB-RS232 is too limited in device control. For integrated USB
micros, I use libusb very often.

> >*Writing Linux device drivers?
>
> I haven't ever done an embedded Linux thing.  But there are
> some devices out there that use it.  However, I suspect the
> businesses (I'm ignorant, so have no idea) playing in that
> game probably have their own specific ways of training new
> hires and unless you are willing to become a vassal of one or
> more of them, I'm not sure you can focus on that.

I don't need to write Linux driver too often. I have to use tools and
other people's works. Not just Linux, but public software in general.

I would give the student an A (or even a check) if he/she can upgrade/
update to the latest GCC 4.4 or 4.5 using GCC 3.4.



 |  Next  |  Last
Pages: 1 2 3 4 5 6
Prev: About Interrupt Problem in RHEL-5
Next: Need help on getting the original source code of eZ430 Chronos