Hi Friends!

Briefly: considering ways of uploading code to microcontroller (particularly some Atmel's AtMega - same as used for Arduino) from the smartphone.

In details:

Programming MCUs (e.g. uploading firmware into their ROM) usually happens via
some proprietary interface (using SPI in case of AVR), or UART, or JTAG. This generally involves dedicated software on the side of computer and some hardware (USB to UART or dedicated "serial programmer").

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.

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!

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.

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

rodion_gork@mail.ru (RodionGork) wrote:

> Hi Friends!
>
> Briefly: considering ways of uploading code to microcontroller
> (particularly some Atmel's AtMega - same as used for Arduino) from the
> smartphone.
>
> In details:
>
> Programming MCUs (e.g. uploading firmware into their ROM) usually
> happens via some proprietary interface (using SPI in case of AVR), or
> UART, or JTAG. This generally involves dedicated software on the side of
> computer and some hardware (USB to UART or dedicated "serial
> programmer").
>
> 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.
>
> 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!
>
> 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.
>
> - 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.

+1. I hope you get a good reponse. A worthy project for your students, and
the solution could be used around the world!

--
MRM

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!

On 2024-03-27, RodionGork <rodion_gork@mail.ru> wrote:
> Hi Friends!
>
> Briefly: considering ways of uploading code to microcontroller (particularly some Atmel's AtMega - same as used for Arduino) from the smartphone.

If your smartphone has USB, just plug a AVR programmer in.

> In details:
> Programming MCUs (e.g. uploading firmware into their ROM) usually happens via
> some proprietary interface (using SPI in case of AVR), or UART, or
> JTAG. This generally involves dedicated software on the side of
> computer and some hardware (USB to UART or dedicated "serial
> programmer").

FX "arvdude", (which is FOSS)

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

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

do they still make smartphones with 3.5mm jacks?

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

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

Have you considered using USB? (hmm maybe not, do iphones have USB a
USB host on their Lightning connector? only 4 pins... maybe not, but
phones with USB-C or (or micro etc) should ba able to connect to a
USBASP or similar by using the right plug adaptor.

Or bluetooth perhaps, prototyping modules with BTLE enabled processors
on them are only a few bucks - write some code, add a connector and a
power supply.

--
Jasen.
🇺🇦 Слава Україні

On 27/03/2024 05:10, RodionGork wrote:
> Hi Friends!
>
> Briefly: considering ways of uploading code to microcontroller
> (particularly some Atmel's AtMega - same as used for Arduino) from the
> smartphone.

<snip>

> - 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).

Maybe play a suitable (uncompressed?) video with bits encoded as frames?
Don't ask me how, just a thought.

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

--
Cheers
Clive

On 27/03/2024 11:08, Clive Arthur wrote:
> On 27/03/2024 05:10, RodionGork wrote:
>> Hi Friends!
>>
>> Briefly: considering ways of uploading code to microcontroller
>> (particularly some Atmel's AtMega - same as used for Arduino) from the
>> smartphone.
>
> <snip>
>
>> - 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).
>
> Maybe play a suitable (uncompressed?) video with bits encoded as frames?
> Don't ask me how, just a thought.

MJPEG?

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

--
Cheers
Clive

RodionGork <rodion_gork@mail.ru> wrote:
> Hi Friends!
>
> Briefly: considering ways of uploading code to microcontroller
> (particularly some Atmel's AtMega - same as used for Arduino) from the smartphone.
>
> In details:
>
> Programming MCUs (e.g. uploading firmware into their ROM) usually happens via
> some proprietary interface (using SPI in case of AVR), or UART, or JTAG.
> This generally involves dedicated software on the side of computer and
> some hardware (USB to UART or dedicated "serial programmer").
>
> 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.
>
> 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!
>
> 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.
>
> - 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.
>

Keep your audio interface but plug it into a Bluetooth audio receiver (or
cannibilze an old Bluetooth headphone and connect your audio interface to
where the earpiece was). Then students can connect audio via Bluetooth.

--
piglet

On 27/03/2024 11:08, Clive Arthur wrote:
> On 27/03/2024 05:10, RodionGork wrote:
>> Hi Friends!
>>
>> Briefly: considering ways of uploading code to microcontroller
>> (particularly some Atmel's AtMega - same as used for Arduino) from the
>> smartphone.
>
> <snip>
>
>> - 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).
>
> Maybe play a suitable (uncompressed?) video with bits encoded as frames?
> Don't ask me how, just a thought.
>
>> 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.
>

With, for example, an MJPEG file playing, you could have say a grid of
3x4 or more squares, each with a different file encoded. Select your
file simply by placing your phototransistor in the appropriate square.

Also, using an RGB phototransistor (if there is such a thing, if not
three phototransistors with filters) could triple the data rate.

--
Cheers
Clive

On 27/03/2024 05:10, RodionGork wrote:
> Hi Friends!
>
> Briefly: considering ways of uploading code to microcontroller
> (particularly some Atmel's AtMega - same as used for Arduino) from the
> smartphone.
>
> In details:
>
> Programming MCUs (e.g. uploading firmware into their ROM) usually
> happens via
> some proprietary interface (using SPI in case of AVR), or UART, or JTAG.
> This generally involves dedicated software on the side of computer and
> some hardware (USB to UART or dedicated "serial programmer").
>
> 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.
>
> 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!
>
> So now I'm looking for further, alternative approaches. For example:

How about canibalising a cheap bluetooth earbud or pairing the phone by
Bluetooth for audio with some other cheap and nasty peripheral. Plenty
of not quite supported any more "smart" speakers knocking around.

--
Martin Brown

piglet wrote:
> RodionGork wrote:
>> Hi Friends!
>>
>> Briefly: considering ways of uploading code to microcontroller
>> (particularly some Atmel's AtMega - same as used for Arduino) from the smartphone.
>>
>> In details:
>>
>> Programming MCUs (e.g. uploading firmware into their ROM) usually happens via
>> some proprietary interface (using SPI in case of AVR), or UART, or JTAG.
>> This generally involves dedicated software on the side of computer and
>> some hardware (USB to UART or dedicated "serial programmer").
>>
>> 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.
>>
>> 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!
>>
>> 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.
>>
>> - 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.
>>
>
> Keep your audio interface but plug it into a Bluetooth audio receiver (or
> cannibilze an old Bluetooth headphone and connect your audio interface to
> where the earpiece was). Then students can connect audio via Bluetooth.

Beings Bluetooth uses a packet-based protocol you need an MCU to receive
packets, no?

It's easy to use a HC-05 Bluetooth Module:
<https://arduinogetstarted.com/tutorials/arduino-bluetooth>

It's harder to DIY:
<https://hackaday.io/project/184542-i-made-my-own-audio-bluetooth-module>

Danke,

--
Don, KB7RPU, https://www.qsl.net/kb7rpu
There was a young lady named Bright Whose speed was far faster than light;
She set out one day In a relative way And returned on the previous night.

On Wed, 27 Mar 2024 05:10:12 +0000, rodion_gork@mail.ru (RodionGork)
wrote:

>Hi Friends!
>
>Briefly: considering ways of uploading code to microcontroller (particularly some Atmel's AtMega - same as used for Arduino) from the smartphone.
>
>In details:
>
>Programming MCUs (e.g. uploading firmware into their ROM) usually happens via
>some proprietary interface (using SPI in case of AVR), or UART, or JTAG. This generally involves dedicated software on the side of computer and some hardware (USB to UART or dedicated "serial programmer").
>
>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.
>
>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!
>
>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.
>
>- 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.

Maybe they could upload the code to a web site, and you could have
hardware in the student lab that loads the target machines.

Coding on a phone sounds nasty.

Hi Friends! First of all thanks for all those replies. These are my first steps in usenet and I hardly expected such quick and multiple-sided discussion. Seems like some suggestions complement each other so I'll answer in the order of encountering them in replies.

> A worthy project for your students, and the solution could be used around the world!

Thanks for your kind words. Actually it already can be used but probably I need to add more documentation/video, particularly about hardware setup. "Coding / beeping" page is here (you may click "compile" and then "burn" just for fun):

https://rodiongork.github.io/avr-mic-loader/

Setup may look as easy as here:

https://i.imgur.com/j6N3aNe.png

> Presumably, you want this to be an interface that each student can "take
home"

Yep (some of them already took it home and did some coding in "unsupervised" mode), moreover it would be fine to have interface which is easily and cheaply reproducible.

> some control over the MCU-end of the system. Is this an
OTC "module"?

I'm not sure what is OTC module. AVR microcontrollers were picked as those with probably simplest assembly language, particularly these are bare ATMega8L chips in DIP-28. Initially kids plugged them into breadboard, added battery, couple buttons and LED - and audio-connector of course - and voila (see image linked above). That was not very stable so we invested 2-3 lessons in building hand-made PCBs.

> Look into the "Kansas City Standard"

Thanks, I glanced over but need to dive more into details. It also reminded me of approach used with ZX spectrum, need to check how exactly it worked...

> I would assume you really would like a bidirectional link.

Well, this would be an improvement though more wiring is needed and audio port with mic input. Shall search for more info how 4-contact jack is implemented on various smartphones... Though if uploading could be made more stable even with one-way link, I'll stick to it for simplicity...

> If every phone supports a microSD card

Surprising idea! never came to my mind, though I think there is no API to directly control SD card pins and with 8-bit MCU bootloader it is probably not possible to accomodate for complicated code handling SD card IO... And yep, these are perhaps more rare than audio jacks

> The USB charging/data port would be another obvious candidate

Unless I'm mistaken it works only with phones which have USB "on the go" variety, e.g. can work as USB-host?

> A BT interface on your MCU module

We actually did use this previously (HC-05 or something alike), just with somewhat different firmware (also created by me) allowing an interactive BASIC on Arduino or STM32. Here is a lousy video:

https://www.youtube.com/watch?v=q9JcWGs_VaI

However setting 15+ cheap bluetooth devices with shaky power supply - they were not working fine
and it was sometimes painful experience. I admit I haven't thought of them for uploading though
it will make straightorward flow. Perhaps shall switch to it if "audio" channel couldn't be
improved after all, thanks :)

> You can also hack the NFC interface

Here I'm a bit out of sync with technology - does all modern smartphones include NFC? And I think receiver needs a chip like 531 or 522 and some stuff around so it feels bit too complicated for school level...

> The (camera) "flash" LED might be easy to drive

Very curious idea I completely missed, also not sure about throughput but need to go and check first. Also it suggests using camera itself as a feedback... very interesting!

> you could paint a barcode image on the phones screen

Ha-ha! that is also something I completely missed. I can easily program "running barcode" in an HTML page with javascript/canvas... Not sure if it will work better than blinking display, but
it looks much more comprehensive to user... and seems more versatile (even up to printing barcode on a paper) - will think more about this, thanks!

> Maybe play a suitable (uncompressed?) video with bits encoded as frames?
Don't ask me how, just a thought.

That may be working, right. Not necessarily video, it is possible to programmatically blink an area of screen etc...

> Keep your audio interface but plug it into a Bluetooth audio receiver

Interesting, never thought of this approach - shall investigate it further, thanks.

> Maybe they could upload the code to a web site, and you could have
hardware in the student lab that loads the target machines

funny, but you described exactly approach we used year ago - they uploaded code to my server, then rushed to the single laptop at the center which had USB programmer attached - and here entered pin-code by which small script fetched the compiled HEX-file from the server and uploaded it. It was just not very convenient when there are many people and few (or single) computer. But it was the most stable setup probably, that's true.

> Coding on a phone sounds nasty.

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 :)

On 3/26/24 10:10 PM, RodionGork wrote:
> Hi Friends!
>
....
>
> 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.

There are converters from USB/Lighting to 3.5mm audio jack available for
both iPhone and Android phones. That will allow you to use your existing
solution.

For example:
https://www.amazon.com/s?k=android+to+headphone+adapter&crid=1BB6G61LWQS2X&sprefix=android+to+headphone+adapter%2Caps%2C151&ref=nb_sb_noss_1

https://www.amazon.com/s?k=ios+to+headphone+adapter&crid=NUHO55L01ZGZ&sprefix=ios+to+headphone+adapter%2Caps%2C155&ref=nb_sb_noss_2

kw

On 3/27/2024 12:22 PM, RodionGork wrote:
>> some control over the MCU-end of the system.  Is this an
>> OTC "module"?
>
> I'm not sure what is OTC module.

Over The Counter. I.e., buying some preexisting module (like an
arduino) instead of designing something WITH an AtMega on it.
In the former, you have some other things that extend the
bare MCU, often that is the limit on what one would want to do
with the hardware. In the latter, you are likely making your
own module and are free to add whatever additional circuitry
you desire (within size, price, etc. constraints).

> AVR microcontrollers were picked as those with
> probably simplest assembly language, particularly these are bare ATMega8L chips
> in DIP-28. Initially kids plugged them into breadboard, added battery, couple
> buttons and LED - and audio-connector of course - and voila (see image linked

Ah, OK. So, you were neither buying a prebuilt "module" nor
building one of your own. You have more flexibility in that
the students can add whatever they need to the MCU. But,
you don't want to burden them with a lot of peripheral
circuitry because that's more work, wiring, likelihood of
mistakes, etc.

> above). That was not very stable so we invested 2-3 lessons in building
> hand-made PCBs.

Then, you COULD add some small amount of "cheap" circuitry to
meet your goal!

>> Look into the "Kansas City Standard"
>
> Thanks, I glanced over but need to dive more into details. It also reminded me
> of approach used with ZX spectrum, need to check how exactly it worked...
>
>> I would assume you really would like a bidirectional link.
>
> Well, this would be an improvement though more wiring is needed and audio port
> with mic input. Shall search for more info how 4-contact jack is implemented on
> various smartphones... Though if uploading could be made more stable even with
> one-way link, I'll stick to it for simplicity...

Baseband audio is relatively easy in terms of hardware. If hardwired,
then even the detection algorithms could be simple.

>> If every phone supports a microSD card
>
> Surprising idea! never came to my mind, though I think there is no API to
> directly control SD card pins and with 8-bit MCU bootloader it is probably not
> possible to accomodate for complicated code handling SD card IO... And yep,
> these are perhaps more rare than audio jacks

You store the "compiled" code in a file in a particular place
on the card while in the phone. Then, bit-bang the interface to
pull the file off the card into the MCU.

>> The USB charging/data port would be another obvious candidate
>
> Unless I'm mistaken it works only with phones which have USB "on the go"
> variety, e.g. can work as USB-host?

That's the most versatile. But, you may also be able to abuse the
signals and bit-bang an interface. (I don't know what the phone
API exposes as far as direct control over the i/f)

>> A BT interface on your MCU module
>
> We actually did use this previously (HC-05 or something alike), just with
> somewhat different firmware (also created by me) allowing an interactive BASIC
> on Arduino or STM32. Here is a lousy video:
>
> https://www.youtube.com/watch?v=q9JcWGs_VaI
>
> However setting 15+ cheap bluetooth devices with shaky power supply - they were
> not working fine
> and it was sometimes painful experience. I admit I haven't thought of them for
> uploading though
> it will make straightorward flow. Perhaps shall switch to it if "audio" channel
> couldn't be
> improved after all, thanks :)
>
>> You can also hack the NFC interface
>
> Here I'm a bit out of sync with technology - does all modern smartphones
> include NFC? And I think receiver needs a chip like 531 or 522 and some stuff
> around so it feels bit too complicated for school level...

NFC would really only work for delivering data *to* the phone.
(sorry, I was lumping all the ideas together without qualifying
their respective abilities). It's advantage was that it was contactless.
So, any wired interface OUT of the phone could be paired with that
wireless interface back IN.

>> The (camera) "flash" LED might be easy to drive
>
> Very curious idea I completely missed, also not sure about throughput but need
> to go and check first. Also it suggests using camera itself as a feedback...
> very interesting!
>
>> you could paint a barcode image on the phones screen
>
> Ha-ha! that is also something I completely missed. I can easily program
> "running barcode" in an HTML page with javascript/canvas... Not sure if it will
> work better than blinking display, but

The advantage is that you can distribute "preprinted programs"
by photocopying onto paper. A photoreflective sensor could
scan paper images. Or, the students' phones could take photos
of the pages and "process" them internally.

Note that a barcode can be "folded", regardless of whether it
is scanned by hand or electronically -- scan column one, move
an inch to the right and scan column number two, move...

For longer programs (data blocks), print multiple pages/screens.

> it looks much more comprehensive to user... and seems more versatile (even up
> to printing barcode on a paper) - will think more about this, thanks!

If you transfer the code photographically, there are different
constraints than if you expect the user to manually "scan" it.
Take these into consideration when designing the code's
geometry as it may allow for some simple hackery (e.g., if
a '1' bar/space is twice the width of a '0' bar/space).
Think about distortions introduced by camera held skewed...

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...]

RodionGork wrote:

<snip>

>> A BT interface on your MCU module
>
> We actually did use this previously (HC-05 or something alike), just with some
> what different firmware (also created by me) allowing an interactive BASIC on
> Arduino or STM32. Here is a lousy video:
>
> https://www.youtube.com/watch?v=q9JcWGs_VaI
>
> However setting 15+ cheap bluetooth devices with shaky power supply - they were not working fine
> and it was sometimes painful experience. I admit I haven't thought of them for uploading though
> it will make straightorward flow. Perhaps shall switch to it if "audio" channel couldn't be
> improved after all, thanks :)

The batteries shown in your video look like two 1.5 VDC used in the USA.
If so they provide, at best, 3 VDC. You may need more oomph.

I power my Blue Pills and Black Pills with USB 5 VDC and let the built
in LDO regulator drop it down to 3.3 VDC.

Danke,

--
Don, KB7RPU, https://www.qsl.net/kb7rpu
There was a young lady named Bright Whose speed was far faster than light;
She set out one day In a relative way And returned on the previous night.

On Wed, 27 Mar 2024 19:22:44 +0000, rodion_gork@mail.ru (RodionGork)
wrote:

>Hi Friends! First of all thanks for all those replies. These are my first steps in usenet and I hardly expected such quick and multiple-sided discussion. Seems like some suggestions complement each other so I'll answer in the order of encountering them in replies.
>
>> A worthy project for your students, and the solution could be used around the world!
>
>Thanks for your kind words. Actually it already can be used but probably I need to add more documentation/video, particularly about hardware setup. "Coding / beeping" page is here (you may click "compile" and then "burn" just for fun):
>
>https://rodiongork.github.io/avr-mic-loader/
>
>Setup may look as easy as here:
>
>https://i.imgur.com/j6N3aNe.png
>
>
>> Presumably, you want this to be an interface that each student can "take
>home"
>
>Yep (some of them already took it home and did some coding in "unsupervised" mode), moreover it would be fine to have interface which is easily and cheaply reproducible.
>
>> some control over the MCU-end of the system. Is this an
>OTC "module"?
>
>I'm not sure what is OTC module. AVR microcontrollers were picked as those with probably simplest assembly language, particularly these are bare ATMega8L chips in DIP-28. Initially kids plugged them into breadboard, added battery, couple buttons and LED - and audio-connector of course - and voila (see image linked above). That was not very stable so we invested 2-3 lessons in building hand-made PCBs.
>
>> Look into the "Kansas City Standard"
>
>Thanks, I glanced over but need to dive more into details. It also reminded me of approach used with ZX spectrum, need to check how exactly it worked...
>
>> I would assume you really would like a bidirectional link.
>
>Well, this would be an improvement though more wiring is needed and audio port with mic input. Shall search for more info how 4-contact jack is implemented on various smartphones... Though if uploading could be made more stable even with one-way link, I'll stick to it for simplicity...
>
>> If every phone supports a microSD card
>
>Surprising idea! never came to my mind, though I think there is no API to directly control SD card pins and with 8-bit MCU bootloader it is probably not possible to accomodate for complicated code handling SD card IO... And yep, these are perhaps more rare than audio jacks
>
>> The USB charging/data port would be another obvious candidate
>
>Unless I'm mistaken it works only with phones which have USB "on the go" variety, e.g. can work as USB-host?
>
>> A BT interface on your MCU module
>
>We actually did use this previously (HC-05 or something alike), just with somewhat different firmware (also created by me) allowing an interactive BASIC on Arduino or STM32. Here is a lousy video:
>
>https://www.youtube.com/watch?v=q9JcWGs_VaI
>
>However setting 15+ cheap bluetooth devices with shaky power supply - they were not working fine
>and it was sometimes painful experience. I admit I haven't thought of them for uploading though
>it will make straightorward flow. Perhaps shall switch to it if "audio" channel couldn't be
>improved after all, thanks :)
>
>> You can also hack the NFC interface
>
>Here I'm a bit out of sync with technology - does all modern smartphones include NFC? And I think receiver needs a chip like 531 or 522 and some stuff around so it feels bit too complicated for school level...
>
>> The (camera) "flash" LED might be easy to drive
>
>Very curious idea I completely missed, also not sure about throughput but need to go and check first. Also it suggests using camera itself as a feedback... very interesting!
>
>> you could paint a barcode image on the phones screen
>
>Ha-ha! that is also something I completely missed. I can easily program "running barcode" in an HTML page with javascript/canvas... Not sure if it will work better than blinking display, but
>it looks much more comprehensive to user... and seems more versatile (even up to printing barcode on a paper) - will think more about this, thanks!
>
>> Maybe play a suitable (uncompressed?) video with bits encoded as frames?
>Don't ask me how, just a thought.
>
>That may be working, right. Not necessarily video, it is possible to programmatically blink an area of screen etc...
>
>> Keep your audio interface but plug it into a Bluetooth audio receiver
>
>Interesting, never thought of this approach - shall investigate it further, thanks.
>
>> Maybe they could upload the code to a web site, and you could have
>hardware in the student lab that loads the target machines
>
>funny, but you described exactly approach we used year ago - they uploaded code to my server, then rushed to the single laptop at the center which had USB programmer attached - and here entered pin-code by which small script fetched the compiled HEX-file from the server and uploaded it. It was just not very convenient when there are many people and few (or single) computer. But it was the most stable setup probably, that's true.
>
>> Coding on a phone sounds nasty.
>
>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 :)

Dogfood it. Start a class project to develop a universal phone-to-Jtag
gadget. Then sell it to finance your classes.