On 3/27/2024 12:22 PM, RodionGork wrote:
I agree. But coding without anything is even worse. These are "facultative" classes of electronics happening once per week and we can't pretend on supplying ourselves with suitable auditorium with desktop computers or fetching dozen-or-two spare laptops :)
With your additional comments lending a better vision of your environment
and potential goals, let me share how we are addressing a similar issue,
here, to see if it might be something that you can exploit with YOUR
resources and goals.
We have access to a LOT of surplus laptops (thousands, annually -- the US
is a wasteful society). So, one of our goals is to find uses for them
instead of just processing them for "reclaimable/recyclable materials".
Another goal is to provide laptops to underprivileged kids who might not,
otherwise, have access to a "computer" that they can use (for homework,
play, etc.).
A third goal is to teach them a skill that is increasingly becoming a
necessity in their education and daily life; programming.
This is a multiyear program to address kids of differing ages and
experience WITHIN THE PUBLIC SCHOOL SYSTEM. So, a 10 year old kid could
take the "beginner's" version of the program in one year, then a
more "intermediate" version in the next year and an "advanced" version
in still another year. Each version has an increasingly detailed
curriculum that exposes more and more "real world" issues to the student.
To that end, we are modifying some laptops (one per student) to turn
them into "teaching appliances". This limits what they can be used
for -- which cuts down their "theft" value as well as reduces the number
of ways they can be "broken" (malware, misconfiguration, etc.).
[This is to reduce the effort required by staff to maintain something
that the student NEEDS to participate in our program. As administrative
costs increase, programs become less "available" to students]
The appliance gives the student a means of writing "code" with a comfortable,
familiar interface -- a keyboard and display. A simple editor makes it
easy to modify those programs, cut-and-paste portions from other (previously
written) programs, etc. A simple filesystem lets them store older "exercises"
as well as alternate versions of each exercise as they explore programming
strategies and options.
The appliance also hosts an "emulator" (simulator) that allows the students
to "run" their code on this virtual computer, examine the internals of that
computer as it is executing, single-step, breakpoints, etc.
To add interest to the course, they aren't tasked with writing meaningless
programs ("Today we will write a program to generate the Fibonnacci
sequence..."). Instead, they write programs that drive mechanisms and
respond to sensors.
These mechanisms and sensors are emulated, as well. So, we can have a
furnace controlled by a thermostat operating in the presence of a heat
sink (cold winter wind) and task them with writing the program to
control that furnace. They can run their code and see how it handles
the stated problem.
Bugs in their programs have no real world consequences; the pipes won't
freeze if their algorithm fails to maintain an adequate temperature. Nor
will the pets and plants die if they fail to cycle the heat OFF when the
area has reached that "livable" state.
[The problems get more sophisticated as the students progress further
into the curriculum with "advanced" students having to deal with more
significant challenges and more "annoying details" that are characteristic
of the real world (e.g., what if the furnace doesn't APPEAR to be generating
heat? how do we detect that? how do we know if the furnace is at fault
or the temperature sensor or the actuator OR THE MAGNITUDE OF THE HEAT
SINK??)]
The details of the emulated system also evolve, over time, to expose
more of a "real" computer to the students. For example, initially, the
verbs and predicates that the student uses may be "IsCold?", "ApplyHeat"
where the details of each of those are buried as "needless", initially
(what, exactly, defines "cold"? how, specifically, do you turn on the
furnace?). Later, more familiar constructs are used:
if (temperature < MINIMUM_FOR_COMFORT) ...
In this way, we encourage the students to think about the problem BEFORE
thinking about the minutiae of programming language syntax.
Even such crude problems and crude constructs can be used to expose
different coding styles and consequences to the student. Note the
difference between (pseudocode):
do {
if (temperature < MINIMUM) {
furnace(ON);
} else {
furnace(OFF);
}
} while (FOREVER);
and
do {
if (temperature < MINIMUM) {
furnace(ON);
while (temperature < MINIMUM) {
//
}
furnace(OFF);
}
}
As writing code is such a trivial issue, we add more interest by actually
allowing the students to install *their* code in a real, physical model
by installing their thumbdrive ("SneakerNet") in that model and watching
as a real controller (previously EMULATED in their appliances) controls a
real furnace based on a real sensed temperature.
[Because they have been able to simulate this on their "learning appliances",
we don't waste a lot of time with this *single* (unshareable) resource.
Yet, they can see the real consequences of their code instead of some
imaginary, contrived example.]
Additionally, they spend time (as a group) actually building (assembling)
these mechanisms so they get a feel for what practical issues can arise that
make the theoretical solution fail. E.g., what if the power is off? Or, a
connector is unplugged? Or, a wire breaks? Or, the sun is shining on the
thermostat through a nearby window? Or...
The intent, here, is to get them to think beyond the obvious and anticipate
how their "perfect" algorithm can fail in a real world scenario. So, we
can then teach them how to recognize these situations in their code and
defend against them. (e.g., if the temperature sensor fails indicating
COLD, their algorithm would gleefully keep the heat running continuously!
How can they guard against that possibility? Likewise, if it fails indicating
HOT, their algorithm will NEVER call for heat -- with a different set of
consequences)
[IME, this is what makes most "programmers" ineffective at their jobs.
I suspect most folks who have written UART drivers/ISRs dutifully note
the parity and overrun error flags; but, how many people actually have
thought about what to DO with them?? (why did you write code to
notice them if you aren't going to make use of that information? Oops!)]
Finally, on completion of the course (no "grades" issued), the student
surrenders his "teaching appliance" -- so we can use it for the next group
of students -- and is given a "real" laptop. What he chooses to do with
this is entirely up to him (including SELLING it!).
As I don't know where your emphasis is intended, I can't speak to whether
or not this is a suitable approach. Here, anything involved with the
public school system has many additional (legal) requirements so you
tend to want to set the bar high -- do a LOT to make the effort worthwhile.
(e.g., the actual "teachers" have to undergo criminal background checks,
fingerprinting, etc. before they can interact with the students. The
facility has to carry liability insurance in case a student is injured
on the premises -- even if just sitting in a classroom listening to a
teacher speak. there are "costs" to interfacing with the "establishment"
and "turf" issues, etc.).
But, you might be able to do something similar in phones instead of relying
on "real hardware" PER STUDENT. In our case, the "real hardware" (furnace,
etc.) is not the sort of thing you could send home with each student. So,
we design the curriculum to SHARE that hardware. But, allow the
students to use "virtual" hardware that mimics the operation of the
physical hardware.
[Watching their programs actually DOING things -- moving mechanisms, lighting
lights, reacting to the environment, etc. is very engaging. Compare that
to watching the generation of 0, 1, 1, 2, 3, 5, 8...]
Microcontroller (AVR) programming from smartphone
Re: Microcontroller (AVR) programming from smartphone
