Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Don Y <blockedofcourse@foo.invalid>
Newsgroups: sci.electronics.design
Subject: Re: Microcontroller (AVR) programming from smartphone
Date: Wed, 27 Mar 2024 21:33:52 -0700
Organization: A noiseless patient Spider
Lines: 129
Message-ID: <uu2rvq$3c84h$2@dont-email.me>
References: <f3de3f8fc37a3347899d8d66b21c48e6@www.novabbs.com>
 <uu0dmp$2m89h$2@dont-email.me>
 <2aadd9a482e08f1b41bf0b923fef2a85@www.novabbs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 28 Mar 2024 04:34:04 +0100 (CET)
Injection-Info: dont-email.me; posting-host="46ff8eb4a4dc90175a8a45bab40b9df6";
	logging-data="3547281"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19daDHxAfHvN6XF7GUzR5sL"
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Cancel-Lock: sha1:OBgZvCqq2CcngZ33uBcMpaq+2M8=
In-Reply-To: <2aadd9a482e08f1b41bf0b923fef2a85@www.novabbs.com>
Content-Language: en-US
Bytes: 6923

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