Re: Microcontroller (AVR) programming from smartphone

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.
<shrug>  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!