Path: ...!news.mixmin.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 Date: Tue, 26 Mar 2024 23:17:53 -0700 Organization: A noiseless patient Spider Lines: 92 Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Wed, 27 Mar 2024 06:18:02 +0100 (CET) Injection-Info: dont-email.me; posting-host="8f21412ebf5b907dea5c38aa239c3f50"; logging-data="2826545"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/hujSE0nBj+TXFT2/1F4Lb" User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Cancel-Lock: sha1:g9b6+XBq9/RJFCZWF3Nf+HWHx8E= Content-Language: en-US In-Reply-To: Bytes: 5631 On 3/26/2024 10:10 PM, RodionGork wrote: > Suppose we want to be able to write simple code using mobile phone - situation > I met with my class of 15+ students with no dedicated lab having 15+ computers. Presumably, you want this to be an interface that each student can "take home"; not one that is only accessible in a "lab"? You obviously have some control over the MCU-end of the system. Is this an OTC "module"? (if so, which) Or, something that you have created (or are about to create)? I.e., what hardware resources do you have on that module? > I tried creating a small system containing two parts: First - html web-page > with a textarea to write assembly code, built-in AVRA assembly compiler (just > compiled to javascript) - and some JS code which can "beep" the bits of the > hex-file containing firmware (via audio). Second - bootloader for target MCU > which uses ADC pin to "listen" to those beeps via direct wire connected to 3.5 > mm audio jack plugged into smartphone - and "burn" incoming data into flash > memory. > > This works (if you are curious to try, it could be found in my github page by > same username) - however there is a sudden issue: almost half of students use > mobile phones without 3.5mm jack - as nowadays it is the era of wireless > headphones already, I missed the fact! Yes. Welcome to the wireless future! :< > So now I'm looking for further, alternative approaches. For example: > > - attaching microphone to ADC pin instead of wired connector; code should be > beeped out via built-in speaker of the smartphone (it would be a bit noisy > class, of course) - I actually tried, but was not yet able to come up with > signal recognition algorithm of good enough quality. Look into the "Kansas City Standard". It was a commonly used approach for storing (and retrieving) data on audio cassettes in the early hobbyist days. > - blinking data with display and catching it with photo-transistor attached to > ADC or digital pin, haven't tried for it seems like bitrate would be very low > (even though we generally need to upload firmware of few dozens bytes). > > Thus I'm open to any ideas / hints / articles on improving either of these two > approaches - or perhaps something completely different which I may have missed. I would assume you really would like a bidirectional link. This would allow the phone to also act as a "user I/O" device -- to display output from the MCU as well as provide input to the programs running there. [The audio interface would have allowed this] If every phone supports a microSD card, you could use that as a transfer medium. But, I am unsure how durable those connectors within the phone are going to be as this sort of media isn't often inserted/removed in normal phone use. The USB charging/data port would be another obvious candidate (though I am not sure what Apple products support). Even without a USB controller in the MCU, you could possibly "hack" the interface to support a low speed, out-of-band channel. A BT interface on your MCU module (they can be purchased with such things in place) would be an easy bridge medium. You can also hack the NFC interface for a reasonably high bandwidth channel (but, I don't know if all phones -- of every vintage -- have NFC capabilities). A DIY NFC i/f can be pretty cheap (esp if you already have an MCU available); a few passives, a rectifier and wire for an antenna. The (camera) "flash" LED might be easy to drive. But, again, I am not sure how much "action" that is intended to see on a phone -- you could end up taking the equivalent of thousands of photos in a few seconds with such a (ab)use. The camera on the phone could act as the counterpart for receiving data from the MCU. If your "programs" are always relative short ("tokenized"), you could paint a barcode image on the phones screen and have the user "swipe" the MCU module (with a fixed photodiode mounted) to capture the light/dark transitions. (You can likely limit the performance requirements for this interface by insisting that users swipe at a reasonably slow rate instead of having to tolerate a wide range of possibilities). Flashing an LED into the phones camera could act as the MCU output capability. It all depends on what you have (or will accommodate) on the MCU side and how capable you are of supporting a crude hardware i/f. Good luck!