<p>Late answer, but IMO, &quot;real industrial eval boards&quot; that are capable of running Linux sound like overkill if the only goal is to &quot;to develop C program that will read an I2C sensor.&quot;</p>
<p>Have you considered using something like NXP's &quot;Freedom&quot; 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.</p>
<p>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.</p>
<p>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.)</p>
<p>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>
<hr />
<p>P.S., Similar products are available from ST Microelectronics.</p>

CC BY-SA 4.0
2023-10-02T15:24:40.797Z
Those are MCUs, and one of the client specifically wants embedded Linux boards, that's unfortunately two very different worlds.
But your point is interesting too, as I should probably reduce the scope first and then give them an overview of the overall system (ie embedded Linux, makefiles and so on).
YCN-
CC BY-SA 4.0
2023-09-26T22:01:25.660Z
2023-09-26T22:01:25.660Z
Solomon Slow
<p>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.</p>
<p>If you want an excellent breakdown of what is known about how we learn, take a look at <a href="https://nap.nationalacademies.org/catalog/24783/how-people-learn-ii-learners-contexts-and-cultures" rel="nofollow noreferrer">How People Learn ii</a> - 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.</p>
<p>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.</p>
<p>I would highly recommend scaffolding over multiple activities rather than forcing students to do everything from scratch.  With scaffolding, the general process is &quot;I do, we do, you do.&quot;  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.</p>
<p>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.)</p>
<p>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.</p>

CC BY-SA 4.0
2023-08-14T12:19:37.950Z
I guess that's part of the answer indeed, while talking to a friend that followed such training, he told me that I should probably make them learn the other way around : start high level for instance a simple C program, and give them some script wrapping the toolchain around, and then go deeper and deeper. I'll be taking your advices and his and making it all over again. Because they probably xill feel better all through the learning process and we would be able to stop the training anywhere, plus they will be able to take something home without it hearting too much.
YCN-
CC BY-SA 4.0
2023-08-22T15:43:08.053Z
@YCN- I realized that I left out important components, so I made some significant edits to the end. I hope your next training goes much better!
Ben I.
CC BY-SA 4.0
2023-08-08T19:14:22.663Z
2023-08-23T20:49:30.153Z
2023-08-23T20:49:30.153Z
Ben I.
<p>I'm having trouble succesfully teaching integration to trainee that are not from a computer science background.</p>
<p>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.</p>
<p>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.</p>
<p>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).</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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 ...</p>
<p>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.</p>
<p>So what I'm really wondering is how to make them being satisfy with what they have achieves even if that was hard.</p>
<p>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?</p>
<p>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 &quot;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&quot;, 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.</p>
<p>How do you guys handle that kind of situation ?</p>

CC BY-SA 4.0
2023-08-27T21:35:24.410Z
What do you mean by `integration`?, I assume not calculus.
ctrl-alt-delor
CC BY-SA 4.0
2023-08-30T07:36:46.073Z
Indeed, basically integration is when you get other people software and hardware and bring it to a target while maintaining a coherent system. Meaning that you have to handle dependencies, packages conflict, versions, OS particulatities and so on.
The developpment aspect of that work is mostly to read specifications and datasheets and to write code that respects both the OS and the device (or piece of software) that you are integrating.
YCN-
CC BY-SA 4.0
2023-08-30T10:35:49.893Z
How does that differ from deployment?
ctrl-alt-delor
CC BY-SA 4.0
2023-08-31T12:09:19.343Z
For instance when you assemble different hardware peripherals (such as sensors, GPU, memories and so on) or take a piece of software and adapt it to the specificities of your systems that's called integration. Deployement is more taking your software to a specific target in production.
For instance integration can be taking a software and preparing the deployement using different packaging methods: deb, rpm, wheel archive, docker, lxc... It can also be adapting your software to an architecture (x86, ARM, PowerPC...) or a build system (Yocto/Buildroot) or even an OS.
YCN-
<programming><student-motivation><compiling><industry-training><linux>
How to teach hardware-software integration to new developers?
# How to teach hardware-software integration to new developers?

(Asked by: username_0 on 2023-08-08)

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 ?

**Tags:** programming, student-motivation, compiling, industry-training, linux

> **Comments:**
> **username_1**: What do you mean by `integration`?, I assume not calculus.  
> **username_0**: Indeed, basically integration is when you get other people software and hardware and bring it to a target while maintaining a coherent system. Meaning that you have to handle dependencies, packages conflict, versions, OS particulatities and so on. The developpment aspect of that work is mostly to read specifications and datasheets and to write code that respects both the OS and the device (or piece of software) that you are integrating.  
> **username_1**: How does that differ from deployment?  
> **username_0**: For instance when you assemble different hardware peripherals (such as sensors, GPU, memories and so on) or take a piece of software and adapt it to the specificities of your systems that's called integration. Deployement is more taking your software to a specific target in production. For instance integration can be taking a software and preparing the deployement using different packaging methods: deb, rpm, wheel archive, docker, lxc... It can also be adapting your software to an architecture (x86, ARM, PowerPC...) or a build system (Yocto/Buildroot) or even an OS.  

---

## 2 answers

### Answer by username_3 on 2023-08-08. Score: 6 | Accepted answer

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](https://nap.nationalacademies.org/catalog/24783/how-people-learn-ii-learners-contexts-and-cultures) - 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.

> **Comments:**
> **username_0**: I guess that's part of the answer indeed, while talking to a friend that followed such training, he told me that I should probably make them learn the other way around : start high level for instance a simple C program, and give them some script wrapping the toolchain around, and then go deeper and deeper. I'll be taking your advices and his and making it all over again. Because they probably xill feel better all through the learning process and we would be able to stop the training anywhere, plus they will be able to take something home without it hearting too much.  
> **username_3**: @username_0 I realized that I left out important components, so I made some significant edits to the end. I hope your next training goes much better!  

---

### Answer by username_2 on 2023-09-26. Score: 1

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.

> **Comments:**
> **username_0**: Those are MCUs, and one of the client specifically wants embedded Linux boards, that's unfortunately two very different worlds. But your point is interesting too, as I should probably reduce the scope first and then give them an overview of the overall system (ie embedded Linux, makefiles and so on).  

---

