How to teach hardware-software integration to new developers?

Question

I'm having trouble succesfully teaching integration to trainee that are not from a computer science background.

Basically they have a training of 3 months around C/C++/Python/Software Testing/Electronics and the part where I'm training them: embedded linux.

As you might have already guessed they don't have that much time to consolidate their knowings so when they arrive to my 5 day training on Embedded Linux they don't know much about compilation, Makefile, CPU architecture or even Linux.

The subject I'm giving them is to develop C program that will read an I2C sensor using a real boards and sensors (not raspberry pi, real industrial eval boards). Once the software is developped we are integrating it using Yocto (basically an Embedded Linux distribution generator).

Even given their initial low level, they end up going through the training, it's very hard for them of course but we get there, so it's definitevely in their reach.

The problem I'm facing is that they are not very happy about what they did because of all the suffering that was needed, but I don't really know how to introduce small victory without giving them every thing and keeping them from learning stuff.

Besides the introduction on Linux, Yocto, CPUs, compilation I'm giving the first day, I'm also giving them high level instructions to guide them through their learning and of course my full support during the session.

My high level instructions are more like a plan for example : develop a Hello World, cross compile it, bring it on target (using scp), integrate it using Yocto, plug in the sensor (read the schematic of the board to find the proper GPIO), use i2ctools to detect the sensor on target, read a simple register on the target using C, read the temperature, write a proper userspace application ...

During the session if they are blocked on a problem I'll give them some help and/or proper documentation. Plus of course I walk around the room asking if any one needs help and I ask them questions about what they are currently doing.

So what I'm really wondering is how to make them being satisfy with what they have achieves even if that was hard.

With embedded systems it's true that most of the time you're struggling because you have partial informations, because your system is not standard or even because you're knowledge is not enough for the task at hand, so in the end you are always in the dark until you figured out all your problems and voilà it works you're supposed to be satisfied. How can I help them while they are in the dark and guide them through that final satisfaction that they seems to be completely missing?

How would you guide them so that they are satisfied about their learning without first showing (even partially) the answers? For example I rather have them write the worst buggy piece of code before telling them "may be we should refactor your code with init functions write functions and so on so that we know what piece of it is problematic", instead of directly giving them a template with a structured code and empty function. I think it's a good thing to learn through errors mostly in that kind of context where it's safe to fail.

How do you guys handle that kind of situation ?

Answer 1

Why are you making them reinvent everything? I know that there are people who believe that you learn more powerfully if you generate everything yourself, but I do not believe that research backs that position. The approach of giving absolutely nothing often leads to muddy understandings, and sometimes even to trauma (extreme frustration) that dissuades further exploration.

If you want an excellent breakdown of what is known about how we learn, take a look at How People Learn ii - this no-nonsense volume walks through what we know about learning (meaning what results are solid and thoroughly supported by multiple research studies and multiple researchers over time), as well as compelling ideas that are (at least for now) less supported, and takes pains as well to point out ideas that have been overturned.

We do not learn things deeply on our first brush with a topic. We learn deeply through repeated exposure and by examining simple, known ideas in new light, thereby interconnecting it with other topics and allowing us to boil the essence of an idea into a more abstract form. That's why many teachers arrange their curricula into something of a spiral, where you go over the same material, but more deeply, at each pass.

I would highly recommend scaffolding over multiple activities rather than forcing students to do everything from scratch. With scaffolding, the general process is "I do, we do, you do." So, you begin by demonstrating something, then there are various levels of mixed activities while they work with progressively less support, and finally finishes with the students able to utilize the learning goals independently. This provides more reliable learning, but with comparatively little trauma.

To give deeper understanding, make sure that later activities utilize the skills of the prior activities. That will allow your students to keep revisiting the old ideas in new light, which will help with encoding (through repetition) and abstraction (through exposure in different context or in different ways.)

There are limits to what you can teach in just three days, but you can make sure that a few core ideas are learned well, and that your trainees have a toolkit of less deeply understood techniques that they can use to get by while they continue to learn in the field.

Answer 2

Late answer, but IMO, "real industrial eval boards" that are capable of running Linux sound like overkill if the only goal is to "to develop C program that will read an I2C sensor."

Have you considered using something like NXP's "Freedom" line of eval boards? The big win is the IDE. Last time I used it it was Eclipse-based, and when you opened a new project, you could just select the specific board by model number from a drop-down menu, and it would configure the project for you. You just jump in writing C or C++ code, and then you build the project, program the board, and start it running in a debugger all with a single button press.

The only hardware you need to program the board is a standard USB cable, But to round out the picture, you'll probably want a TTL-level serial port adapter and a terminal emulator for the development PC so that your students can interact with their programs via UART.

Configuring and using the UART is just a matter of a few calls to libraries that come with the IDE. There's probably also library support for reading and writing I2C space. (You might want to either encourage them or discourage them from using that, depending on what you're trying to teach them.)

The IDE was free (last time I used it). Terminal emulator software can be found for free. The boards can be had for less than $20/each (U.S.A., I don't know about where you live), and serial port adapters for about the same price.

---

P.S., Similar products are available from ST Microelectronics.