BeagleBoard Labs/Training from Free Electrons

If you are new to Linux or embedded Linux, this might be a great place for you to get started, now with directions specific to the BeagleBoard:
http://free-electrons.com/blog/beagle-labs/

Lots of great info there going all the way from building code from sources, through, booting the board, and on to running a web server on it over the USB OTG port and applying real-time kernel patches.

I'm not sure if the actual lab sources are shared publicly or not, but the slideware is.

The Free Electrons Beagle materials are really good. If you are a
beginner to embedded Linux I suggest going through there materials.
I've been working my way through all their labs (http://free-
electrons.com/doc/training/beagle/labs.pdf) and doing so has plugged
many holes in my understanding.

Their lab sources are available, though many of the labs show how to
build form the sources online.

I'm planning on teaching a 32-bit embedded processor class based on
the Beagle next spring. I plan to adapt the labs from Free Electrons
and use the Embedded Linux Primer by Chris Haliana (http://

%22,+by+Christopher+Hallinan&ei=Qsg4S4_4M5PAM4DdmbQB&cd=1) as a text.
Between the two my students should be well prepared for the embedded
world.

However, I've hit one snag so far. They show how to build a kernel
from "git clone git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux
omap2.6.git" using initramfs. Unfortunately I haven't gotten it to
boot all the way. I'll save the details for another post.

Are there any others out there using the Free Electrons materials?

--Mark

Mark A. Yoder wrote:

Are there any others out there using the Free Electrons materials?
  
I have skimmed them, and found them very useful for beginners. But the
students and clients I teach need much deeper device driver and kernel
porting training, which is where the Free Electrons materials come up
short. So I teach from my own materials. That's not a slight on the FE
materials, at all, as I think they are a pretty nice introduction to
embedded Linux.

I think it would be both very challenging and ill-advised to try to give
detailed treatment in a free, online setting to the more advanced topics
that I teach. For one thing, the subject matter is itself very
volatile. For another, it requires about 10x the presentation length
that you find with the more introductory topics. Keeping everything
up-to-date is a very full-time job, and I've found that the serious
students are willing to help offset that expense.

b.g.

Mark, thanks for mentioning the materials. I was unaware of them.

Linebreaks in URL's is not a good plan. Here is a better version that
can be used to directly click on it:
http://free-electrons.com/doc/training/beagle/labs.pdf

Source for the pdf is also available (navigate one level up).

I've also added the link to the beagleboard wiki page

FM.

Frans:
   Thanks for patching up the URL.

I changed the wiki to point a level higher. It's a better starting
point for a newbie.

--Mark

Your site says there aren't any spots available in your training
courses. Do you do them all freelance style or do you work with an
agency/school?

I don't want to discourage those posting URLs on the list (unless, of
course, it's forbidden) -- it's at least useful to myself.

I am most impressed with the online resources that exist, including
the site mentioned in this thread. I realize that the more detailed
information is more tiresome to update and I think that's why TLDP's
HOWTOs went out of style in favor of wikis. Nevertheless, the
archived HOWTOs, books, etc. allow a person to get the detailed
snapshot and fill in the updated material using mailing lists (like
this one), source documentation, white papers, conferences, and so
forth. SLLUG is using audio recordings now without transcription for
a way of diffusing detailed information quickly and easily. You also
see a number of universities posting entire lecture series on YouTube.

I really wish there were more sophisticated HOWTO and lecture-like
presentations on YouTube regarding the BeagleBoard. I'm surprised
there aren't as it seems that there are a large number of
free/sponsored trainings that are going on. Maybe I'm just missing
them?

Yup, I'm targeting beginners. I'm aiming at a graduate level, however
I'm only requiring some OS experience (not necessarily Linux) and some
C programming. The rest I'll have to teach. There is a lot to choose
from and I'm not sure what to squeeze into a 10 week course.

Good point about volatility and the cost of keeping everything up-to-
date. It isn't easy to separate the old, out of date sites from the
new correct ones.

What sort of background do you want your students/clients to have?
Your answer may give me some direction as to what to put in my course.

--Mark

Jackman wrote:

Your site says there aren't any spots available in your training
courses. Do you do them all freelance style or do you work with an
agency/school?
  
I do them all freelance, and haven't gotten around to planning for 2010
yet. I'm a bit behind, to say the least!

I don't want to discourage those posting URLs on the list (unless, of
course, it's forbidden) -- it's at least useful to myself.
  
Not sure what you are saying here. Are you offended by my shameless
self-promotion? I actually considered not participating in this
discussion at all because I feared I might do exactly that.

I am most impressed with the online resources that exist, including
the site mentioned in this thread. I realize that the more detailed
information is more tiresome to update and I think that's why TLDP's
HOWTOs went out of style in favor of wikis. Nevertheless, the
archived HOWTOs, books, etc. allow a person to get the detailed
snapshot and fill in the updated material using mailing lists (like
this one), source documentation, white papers, conferences, and so
forth. SLLUG is using audio recordings now without transcription for
a way of diffusing detailed information quickly and easily. You also
see a number of universities posting entire lecture series on YouTube.
  
The general problem with all of those approaches are that to really
understand the Linux kernel, you have to work through it methodically
and in detail. You can get by with basic skills if you want to confine
your capabilities to relatively simple drivers that follow existing
design patterns--- and wiki-level treatment can handle that. But that
limitation becomes a really serious impediment once you start working
with real hardware trying to solve real problems--- especially hardware
with real sensors and actuators.

Case in point, I was recently tasked with writing an ADC driver with a
SPI-like (but non-conforming) interface. And to make it even more
interesting, I had to stream the incoming values directly to userspace
so they could do a bunch of signal processing and accumulate very large
datasets. Anything but a zero-copy solution would have distracted the
CPU for too long.

There's no existing model to follow for such an objective, at least not
one that I have encountered. But since I'm well-grounded in all the
necessary fundamentals like SPI controllers, ADCs, GPIO, kernel threads
and copying data to userspace, it was just a matter of stitching them
all together in code and then waiting for the hardware to arrive.

There were a few minor hiccups when the boards did finally show up, but
despite it being the most sophisticated driver I have ever done in terms
of distinct functional elements, it was also among the easiest to get
out the door. I think the key to my success in this case was because I
had previously beaten to death all of my misunderstandings about all the
fundamental topics I needed to know to bring the platform to life. You
don't get that understanding by just browsing lots of code, you have to
learn things a step at a time and in the right order--- and you also
have to learn how to properly apply what you are learning.

This need for a methodical approach is the same as what's required for
learning mathematics, science, and a lot of other subjects. And trying
to do that successfully in an online format is a bit of a specialty in
itself--- witness all the online sites that try and generally fail to be
really good, comprehensive learning sources for subjects that we already
know how to teach in non-online ways. The experts who can do that
aren't experts in Linux drivers, and there don't appear to be many
people around with the combination of skills that are necessary. I'd
like to say I'm among those who DO have the skills, but I'll leave the
final judgment to those who visit my website when I deploy it sometime
in 2010. That's all I'm going to say about that. :slight_smile:

I really wish there were more sophisticated HOWTO and lecture-like
presentations on YouTube regarding the BeagleBoard. I'm surprised
there aren't as it seems that there are a large number of
free/sponsored trainings that are going on. Maybe I'm just missing
them?
  
Some of the free/sponsored trainings artificially limit the
opportunities for redistribution via copyrights, so that they can offer
those as a for-fee service. Others don't capture the live presentations
in formats that lend themselves to online redistribution. And still
others just.... don't.

Myself, I can't sign up for putting together a series of free online
presentations on a subject as important as the one we're talking about.
The effort I could afford to apply towards it without serious funding
would result in something that was basically worth what you'd pay for
it. It's just too hard to do right on a gratis basis. But sadly,
people get hurt or worse when they encounter systems developed by people
who haven't been well-trained. It just isn't worth the risk. Bad
training is worse than no training, because bad training makes you think
you are prepared for situations that you just aren't.

I recently had a client who was nearly killed due to a stupid system and
software design error. (The error wasn't mine, I was brought in to
figure out what happened and prevent it happening again). We've got to
start taking this stuff more seriously than we are, and one way to
address that problem is by getting properly trained in how to do this
stuff. Such training is expensive, because it isn't easy to produce.
But it's still cheaper than living without it. At least, I'm pretty
sure that's how my client and his family feel.

</soapbox>

b.g.

Mark A. Yoder wrote:

Yup, I'm targeting beginners. I'm aiming at a graduate level, however
I'm only requiring some OS experience (not necessarily Linux) and some
C programming. The rest I'll have to teach. There is a lot to choose
from and I'm not sure what to squeeze into a 10 week course.
  
I can tell you this from my own experience (I also teach three online
classes through UC San Diego on embedded programming topics) that you
must set your expectations low. The reason is that the online delivery
systems like pre-recorded lectures with audio and video still don't
convey the information as efficiently as doing it in-person. It takes
me 18 weeks to teach all of the peripherals in an Atmel ATtiny44, for
example. There are probably explanations for that which I simply don't
understand because I'm not a psychologist. But some days, I wish I was...

On top of that, you have to lay foundations on subjects like debouncing
and flash/eeprom programming. And even some basic electronics, if you
are going to have students wiring up even the most primitive circuits on
their own. All that detail work costs time, either in your
presentations or in student frustration and under-productivity.

Good point about volatility and the cost of keeping everything up-to-
date. It isn't easy to separate the old, out of date sites from the
new correct ones.
  
My rule of thumb is that they're all old until they demonstrate
otherwise. :slight_smile:

What sort of background do you want your students/clients to have?
Your answer may give me some direction as to what to put in my course.
  
I require C programming experience, a strong motivation to know the
material, and no aversions to letting the magic smoke out of anything.
The latter two seem to actually discourage more prospective students
than the need for C.

I did have one class recently where about half the students preferred to
program in Python, rather than C. We still did the kernel-side
programming in C, of course, but they did all their user programs in
Python. I know next to nothing about Python, so there was no point in
trying to change my presentations even if I had been able to anticipate
the situation. I just went with it once I discovered what was going on
(it was a face-to-face class, meeting over four days).

As it turned out, that class went farther than any of my other ones
because they were more productive with the user programs than I was!
But the fact that my materials weren't obsoleted by their language
choice told me that what I was teaching (advanced Linux device drivers,
with applications) sort of "transcended" programming languages--- which
was a very gratifying conclusion. Means I must have been doing
something right, I guess.

That might have been the only thing I was doing right. We smoked about
$1500 of my hardware that week. :slight_smile:

b.g.

The greatest problem I've faced for most of my life is that technical
resources just aren't available. I grew up in a small town, worked in
a small town, and went to school in a small town. Public libraries
rarely carry computer literature (mostly because it's high volatile).
Small towns don't usually attract extroverted engineers, but rather
retired ones that just want to be left alone. High schools don't
offer any specialized courses in small populations and community
colleges usually can't afford to, either.

The luckiest break I had was a retired physicist/EE and an EE business
owner who were both in Central Oregon because of the hobbyist flying
opportunities there. Through them, I was allowed to learn about radio
(mostly tube radios) and the Apple II. Apple IIe computers are like
old VWs -- they're always around and there's always one nobody wants.
:slight_smile: Being able to use what I could find from university web sites, my
mentors, and the physical platform (the Apple and a PC), I was able to
develop a number of skills which landed me jobs.

To name a few:
Business/Government Network Installation (mostly by sub-contract)
Electronics Assembly (mostly testing and soldering)
Systems Supervisor (current job; MS-DOS knowledge was a prerequisite)
Programming Tutor (at a local community college)
Small Business Website Administrator
POS Systems Installation

None of those jobs, including my current job, permit me to make the
big bucks, but at least it's more than minimum wage. The point is,
even if my education isn't ideal, there was no other way I could have
obtained it, even if I wanted to pay for it.

My remark about discouraging people was an attempt to say (politely),
"DON'T STOP!" :slight_smile:

Even now I'm finding myself getting a better education from my
'extracurricular activities' than from school. I live in SLC now, but
the local university seems to been highly corporate-ized, meaning lots
of cash in exchange for poor instruction, few resources, and
unrealistic demands. I find myself memorizing random details for
exams rather than learning anything even remotely practical. My only
motivation to finish my degree is so that I can check off one more
requirement on job postings.

Right now I'm heading up a software migration project to the Linux
environment, I'm starting a company in Peru, and I'm running a
political action site (yet unannounced), but it's all based on a skill
set which was acquired through mailing lists, books, IRC, work
experience, mentors, and hobbies.

In the end, I'm trying to encourage people to be actively involved in
community education. What is done to document and to instruct really
is appreciated. When I'm just not getting what I need or want from
universities, I'm looking more than ever to community hosted
instruction. I'm certain I'm not the only one.

So what should be covered in a 32-bit embedded course? We already
teach an 8-bit embedded class using PIC processors. It's a good
course, but about all we are able to do is read switches and turn on
LEDs. The Beagle can do so much more.

I'm working in a traditional collage classroom. I have forty 50
minute periods that can be either lectures or labs. The students will
have had some programming experience (python and C) and will have had
an OS course.

I'm thinking of handing them a BeagleBoard with the SD card already
initialized with Angstrom and spend the first lab getting the USB hub
and monitor set up so the can play with streaming video, etc. right
out of the box.

The next lecture will start with the OMAP 3530 reference manual and
the question "What happens when the OMAP comes out of reset?" Start
at the beginning and build up all that had to happen to run Angstrom.
I'd like to have a week on programming the DSP side of the OMAP, but I
don't know that I'll have time.

What topics do you have in your embedded classes? Are there changes
you would make it if were face-to-face rather than online? Could I
get access to your online material to see what you've done with them?

--Mark

I'm really glad you decided to enter the discussion! I've found the
topic quite thought provoking.

I'm not involved in teaching, but as a consultant I often encounter
clients whose issues are the result of a lack of training. I've never
thought about it from this angle before, so I really appreciate your
insights.

Yikes - $1500 of hardware smoked! Was there a common thread to the carnage?

Steve

Steve Sakoman wrote:

I'm not involved in teaching, but as a consultant I often encounter
clients whose issues are the result of a lack of training. I've never
thought about it from this angle before, so I really appreciate your
insights.
  
<shameless>

Well, next time you identify a training need, call me! :slight_smile: :slight_smile:

</shameless>

Yikes - $1500 of hardware smoked! Was there a common thread to the carnage?
  
Yes. Dry, cold winter combined with active students, fabric chairs, and
bare circuit boards where the standoffs aren't grounded (it was a COTS
board, not my own this time). So touching them before touching the rest
of the board, which is my usual habit, does no good.

Also, don't assume that students can jumper together various circuit
boards properly with discrete wires, even when given clear directions
and told to "let me check them over before you plug anything in".
Murphy rules in such situations, which is why I'm very, VERY particular
about the boards I work with--- and I often design my own to make sure
things are almost self-assembling. But not so self-assembling that the
students can't adapt them for other ideas. I have to do a thorough
failure-modes-and-effects analysis, because anything that can go wrong,
will go wrong.

Why not dispense with the jumper-it-together concept, and just spin a
single board to do everything? Because then the students can't explore
alternative exercises during class. The way I teach, I need hardware
that's reconfigurable--- but not TOO reconfigurable.

The damage in that particular class was somewhat higher than usual, but
I count on blowing up some stuff each time I run a session. Students
learn even more from their failures than they do from their successes,
and they're much more adventurous when they know that it isn't the end
of the world to lose a little magic blue smoke. And that's when they
really start impressing me! Exciting, but terrifying at the same time. :slight_smile:

b.g.

Mark A. Yoder wrote:

So what should be covered in a 32-bit embedded course?

Everything. :slight_smile:

  We already
teach an 8-bit embedded class using PIC processors. It's a good
course, but about all we are able to do is read switches and turn on
LEDs. The Beagle can do so much more.
  
Yes it can, but that capability isn't worth much if you can't help the
student see the motivation behind all that capability AND properly equip
them to take advantage of all that cool stuff.

My online class at UCSD is 18-ish weeks long, and the student kit
consists of two ATtiny44 chips, a solderless breadboard, half a dozen
LEDs and resistors, two pushbuttons, two potentiometers, and an 8-bit
shift register. We cover every peripheral in the chip, both by lecture
and lab exercise. First in assembly language, then in C. We do a bit
more than blink LEDs and read pushbuttons and potentiometers, but even
that by itself can provide lots of educational opportunities. My
students give me very high marks for satisfaction with the class, but
also complain that we try to cover almost too much material in the time
available.

I'm working in a traditional collage classroom. I have forty 50
minute periods that can be either lectures or labs. The students will
have had some programming experience (python and C) and will have had
an OS course.

I'm thinking of handing them a BeagleBoard with the SD card already
initialized with Angstrom and spend the first lab getting the USB hub
and monitor set up so the can play with streaming video, etc. right
out of the box.
  
That's a good idea. It has the added benefit of teaching them how to
take it apart and put it back together, i.e. when they get back home.

The next lecture will start with the OMAP 3530 reference manual and
the question "What happens when the OMAP comes out of reset?" Start
at the beginning and build up all that had to happen to run Angstrom.
  
I don't think I would start with this. It doesn't convey anything
that's of immediate practical use. Would be good information to have at
the end, however, when students are skilled enough to consider tweaks to
u-boot scripts, creating their own system daemons, etc.

I'd like to have a week on programming the DSP side of the OMAP, but I
don't know that I'll have time.
  
I wouldn't do it at the expense of anything else. Ideally, you'd have
another 10-50 weeks so that you could really dive into it and teach it
properly. The ARM-plus-DSP design is a key component of cell phones,
media players and other important applications. But it's potentially a
complex subject area, no point in approaching it at all if you can't
really deal with it well.

What topics do you have in your embedded classes?

We start with using software polling to blink the LED and vary its
intensity, and use a pushbutton to change the blink rate and/or
brightness. Then we cover debouncing, to explain why the button doesn't
always behave the way you expect.

At that point the student is pretty frustrated with what it takes to
babysit the LED and the pushbutton at the same time, so we introduce the
timer/counter so they can hand the blinking and brightness off to
hardware. Then the frustration comes because they keep stomping on
their timer/counter configuration bits or they get out of sync with the
LED, because they don't know how to synchronize their updates with the
hardware. So we introduce interrupts. And so on.

It was somewhat challenging to come up with a hardware setup that was
pretty idiot-proof. But that was incredibly easy compared to getting
the scope-and-sequence of each lecture right, so that when you came into
the (virtual) classroom each week you were motivated by a problem
created the previous week. Getting that right is essential, otherwise
the student starts asking "why are we learning this today?".

Are there changes you would make it if were face-to-face rather than online?

The only change I would make in my own materials is that if we were
face-to-face, I would have a very long-term project that we started on
the first day of class, and worked on a bit each week in parallel with
the curriculum. Something very ambitious, like an automated Christmas
light display, or something. The final-term assignment would be to
finish that project off.

In the online setting, it seems more difficult to carry things over from
week to week because you don't have an easy way to say "ok, let's set
this aside for a few minutes and discuss where we're at on the X
project". At least, when I tried it didn't work out so well.

Could I get access to your online material to see what you've done with them?
  
No, it's locked up inside of a Blackboard system that UCSD controls.
I'd never use that specific system again, given a choice. But they're
the Microsoft of the online education world, unfortunately.

But we can discuss it off-list, if you like.

b.g.

Jackman wrote:

None of those jobs, including my current job, permit me to make the
big bucks, but at least it's more than minimum wage. The point is,
even if my education isn't ideal, there was no other way I could have
obtained it, even if I wanted to pay for it.
  
Sure. But even today there aren't very many good opportunities to learn
embedded systems, at least by my definition of what constitutes "good".
The stuff just isn't being taught very well, because it's hard enough to
DO let alone teach that it's beyond what a lot of instructors are
willing and/or able to deliver. So we cope by teaching ourselves, which
is far from ideal but better than nothing.

If you've got a Beagleboard and a desire to use it for more than a media
player, you're already on the right track!

My remark about discouraging people was an attempt to say (politely),
"DON'T STOP!" :slight_smile:
  
Ok! :slight_smile:

Even now I'm finding myself getting a better education from my
'extracurricular activities' than from school. I live in SLC now, but
the local university seems to been highly corporate-ized, meaning lots
of cash in exchange for poor instruction, few resources, and
unrealistic demands. I find myself memorizing random details for
exams rather than learning anything even remotely practical. My only
motivation to finish my degree is so that I can check off one more
requirement on job postings.
  
Yep. All those things serve a useful purpose, just sometimes it might
be hard to identify what that purpose might be. :slight_smile:

I'll give you my opinion on why the situation is what it is, at least
for embedded systems at the university level. First off, instructors
don't want to spend a lot of time updating their presentation
materials--- they want to bang them out once, and then re-use them over
and over. That's just not possible for embedded stuff beyond a certain
level.

Second, instructors and their egos hate to say that something works in a
certain way, and then be proven otherwise before class is over and you
can confront them on it. Anytime there's hardware in the room, that
hardware has the potential to not work even if the instructor says it
should. If he says "now, watch the LED blink!" and there's no blink,
the instructor's ego and credibility take a hit.

A lot of instructors aren't qualified to teach what they're teaching.
If you stay within the strict confines of their materials then
everything is fine; but if you wander off into stuff that naturally
follows from that, everything falls apart because their depth of
knowledge isn't any deeper than the paper that they're presenting from.
Programmable hardware naturally tends to lead you off the beaten path,
e.g. "ok, now what happens if I double the value in this control
register?", and when you get there the instructor is forced to say, "I
don't know"--- and then their ego and credibility take yet another hit.

Finally, just because you know a subject well doesn't mean you can teach
it well. Great engineers don't necessarily make great engineering teachers.

Now, I'm really generalizing here. There are some very good teachers
out there. Just not enough of them.

Right now I'm heading up a software migration project to the Linux
environment, I'm starting a company in Peru, and I'm running a
political action site (yet unannounced), but it's all based on a skill
set which was acquired through mailing lists, books, IRC, work
experience, mentors, and hobbies.
  
Wow! You seem quite busy.

In the end, I'm trying to encourage people to be actively involved in
community education. What is done to document and to instruct really
is appreciated. When I'm just not getting what I need or want from
universities, I'm looking more than ever to community hosted
instruction. I'm certain I'm not the only one.
  
Certainly. Just recognize that there are limits to what you can achieve
with a budget of $0.

b.g.

Mark A. Yoder wrote:

So what should be covered in a 32-bit embedded course?

Everything. :slight_smile:

  We already
teach an 8-bit embedded class using PIC processors. It's a good
course, but about all we are able to do is read switches and turn on
LEDs. The Beagle can do so much more.
  
Yes it can, but that capability isn't worth much if you can't help the
student see the motivation behind all that capability AND properly equip
them to take advantage of all that cool stuff.

My online class at UCSD is 18-ish weeks long, and the student kit
consists of two ATtiny44 chips, a solderless breadboard, half a dozen
LEDs and resistors, two pushbuttons, two potentiometers, and an 8-bit
shift register. We cover every peripheral in the chip, both by lecture
and lab exercise. First in assembly language, then in C. We do a bit
more than blink LEDs and read pushbuttons and potentiometers, but even
that by itself can provide lots of educational opportunities. My
students give me very high marks for satisfaction with the class, but
also complain that we try to cover almost too much material in the time
available.

I'm working in a traditional collage classroom. I have forty 50
minute periods that can be either lectures or labs. The students will
have had some programming experience (python and C) and will have had
an OS course.

I'm thinking of handing them a BeagleBoard with the SD card already
initialized with Angstrom and spend the first lab getting the USB hub
and monitor set up so the can play with streaming video, etc. right
out of the box.
  
That's a good idea. It has the added benefit of teaching them how to
take it apart and put it back together, i.e. when they get back home.

The next lecture will start with the OMAP 3530 reference manual and
the question "What happens when the OMAP comes out of reset?" Start
at the beginning and build up all that had to happen to run Angstrom.
  
I don't think I would start with this. It doesn't convey anything
that's of immediate practical use. Would be good information to have at
the end, however, when students are skilled enough to consider tweaks to
u-boot scripts, creating their own system daemons, etc.

I'd like to have a week on programming the DSP side of the OMAP, but I
don't know that I'll have time.
  
I wouldn't do it at the expense of anything else. Ideally, you'd have
another 10-50 weeks so that you could really dive into it and teach it
properly. The ARM-plus-DSP design is a key component of cell phones,
media players and other important applications. But it's potentially a
complex subject area, no point in approaching it at all if you can't
really deal with it well.

What topics do you have in your embedded classes?

We start with using software polling to blink the LED and vary its
intensity, and use a pushbutton to change the blink rate and/or
brightness. Then we cover debouncing, to explain why the button doesn't
always behave the way you expect.

At that point the student is pretty frustrated with what it takes to
babysit the LED and the pushbutton at the same time, so we introduce the
timer/counter so they can hand the blinking and brightness off to
hardware. Then the frustration comes because they keep stomping on
their timer/counter configuration bits or they get out of sync with the
LED, because they don't know how to synchronize their updates with the
hardware. So we introduce interrupts. And so on.

It was somewhat challenging to come up with a hardware setup that was
pretty idiot-proof. But that was incredibly easy compared to getting
the scope-and-sequence of each lecture right, so that when you came into
the (virtual) classroom each week you were motivated by a problem
created the previous week. Getting that right is essential, otherwise
the student starts asking "why are we learning this today?".

Are there changes you would make it if were face-to-face rather than online?

The only change I would make in my own materials is that if we were
face-to-face, I would have a very long-term project that we started on
the first day of class, and worked on a bit each week in parallel with
the curriculum. Something very ambitious, like an automated Christmas
light display, or something. The final-term assignment would be to
finish that project off.

In the online setting, it seems more difficult to carry things over from
week to week because you don't have an easy way to say "ok, let's set
this aside for a few minutes and discuss where we're at on the X
project". At least, when I tried it didn't work out so well.

Could I get access to your online material to see what you've done with them?
  
No, it's locked up inside of a Blackboard system that UCSD controls.
I'd never use that specific system again, given a choice. But they're
the Microsoft of the online education world, unfortunately.

But we can discuss it off-list, if you like.

b.g.

I'm working in a traditional collage classroom. I have forty 50
minute periods that can be either lectures or labs. The students will
have had some programming experience (python and C) and will have had
an OS course.

I am in exactly the same situation, and am going mad trying to
understand the Beagle, so if you make such a course, could you link to
your materials? I'm sure it would be a very useful tool for beginners
and students who are trying to self-learn

Yes I'll post all my course materials .... once they are ready.

I think I'll use: http://elinux.org/User:Yoder as a pointer to
everything. However right now it's only a place holder.

Are there others working on college-level courses based on the Beagle?

--Mark

I am an adjunct teaching an evening course in Embedded Device Drivers using Linux for the Comp Eng Tech dept at the University of New Hampshire. The course is taught to students who do not have prior Embedded experience but are strong programmers and understand Linux.
I am using Chris Hallinan’s Embedded Linux Primer; Linux Device Drivers 3 and the Embedded Linux slides from the Free Electrons website.

After verifying board operation I plan on having the students follow a normal board bring up cycle (create an image; install it on an SD card and test it). Then they will recompile various drivers and observe the outcome. We’ll remotely debug the board and use it as a basis to study the aspects of Embedded Linux and Device Driver Development.

The students have a semester project (that I will review the subject matter at MidTerm) involving functionality modifications with the Beagleboard.

The first time I taught this course I did not have HW and all the work was done with the Linux Kernel in the student’s own laptops. Needless to say the debug examples were limited.

-DC-

My Beagle course is up and running. Materials are at: http://elinux.org/index.php?title=Category:ECE597.

–Mark