Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Don Y Newsgroups: sci.electronics.design Subject: Re: Microcontroller (AVR) programming from smartphone (long; whiners stay away) Date: Thu, 28 Mar 2024 00:12:44 -0700 Organization: A noiseless patient Spider Lines: 167 Message-ID: References: <2aadd9a482e08f1b41bf0b923fef2a85@www.novabbs.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Thu, 28 Mar 2024 07:12:54 +0100 (CET) Injection-Info: dont-email.me; posting-host="46ff8eb4a4dc90175a8a45bab40b9df6"; logging-data="3611658"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+xjLfnLLcx6TA0/pteaVyL" User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Cancel-Lock: sha1:GRqv5Poq6gsJHA8sjIE2Auxix44= In-Reply-To: <2aadd9a482e08f1b41bf0b923fef2a85@www.novabbs.com> Content-Language: en-US Bytes: 9693 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...]