UDPI direct from pi gpio.

[Yardie-]

Hi I would like to embed a Tiny in a PI hat I am designing and would like to program it directly from the PI.
I don't think Arduino/avrdude could handle this as it expects to talk over USB I think.
Has anyone got any ideas as how I could do this.
It seems totally do able I just can't think how.

[SpenceKonde]

If it has a UART that can talk to the tinyAVR, serialUPDI (included with the core, as a python script, based on microchip's pymcuprog, >20x performance improvement vs the Microchip version, since as they admitted, they didn't make any attempt to optimize performance. I've seen the stock microchip code upload at like 100-200 bytes/second, due to a combination of poorly chosen defaults and USB latency, the 1/2-16 ms polling period that has to elapse for a round trip of information to get sent to the target and for the response that it sent to become visible to the computer - to reduce the processing burden on the PC, they delay checking USB devices, but on default options, there's a round trip for every 2 bytes written to the flash. It can be lowered to every page of flash requiring like half a dozen round trips on tinyAVR, and slightly less per 512b on Dx-series using the tricks I do in SerialUPDI, and the FT232 and similar parts default to a usb latency timer of like 16ms, but can easily be set to 1 ms if you know about that). But yeah, serialupdi I think would be the thing to try. UPDI is an autobaud, half duplex single wire serial port that runs with 2 stop bits and parity enabled. That's all it is, so the modification to make an ordinary serial adapter speak it is trivial. Most of us use programmers made from standard serial adapters by adding a single diode or resistor.

[Yardie-]

Yeah I just wanted to come out the Pi serial pins and talk direct to the attiny.
So how I understand it I can just use serialupdi and send the data direct over the tx of the Pi.
Have I got that right.

I made a serial adapter but I want to skip the USB part as the Pi already has a UART bus.
I haven't used Arduino in a while and would like to work with the tinies again.
I'll check out serailupdi
Thanks Spence.

[SpenceKonde]

You need a diode (small/signal diode, and it must be a schottky) or a 4.7k resistor between Tx and Rx. UPDI line goes to Rx. (this is how you make a normal full duplex 2 wire serial into a half duplex single wire one - that trick has been discussed in app notes for classic AVRs and modern ones, in the latter case just as a point of comparison - their UARTs can do that without any external components; The UPDI interface looks suspiciously like the stock UART, with the configuration forced into 8E2 + ODME and LBME, autobaud enabled, in front of
a supervisor section of the chip, which sets WFB - much more visible on the Dx-series, where it writes every word as you send it, and since it writes with the response signature disabled; during that 80us write, the CPU is halted - but the UART is not, and the receive is doublebuffered, just like a normal UART, so if the UART baud rate is too high, it fails not on the second word, but some number of words in. Just the USB latency from sending the page to the serial port in chunks instead of as one giant blob makes the difference).

And now that I type that - you may find that you need to enable the write delay option. You usually do not have to with a USB-serial adapter (and it destroys performance), as the time it takes to transmit the following 2 words plus the USB latency is enough for a page write. On linux machines, depending on the adapter, occasionally you do (you never need to when writing to Dx unless the baud rate is way too high, but you sometimes do on tinyAVR). Windows serial performance is a bit worse, so anything that is slow enough the chip can understand is also slow enough for the page write to complete before enough data from subsequent commands has gotten to the device to overflow it's buffer.

But the on-board UART from the pi could be much faster. The symptom of this failure would be for it to have sent 1 page, and then fail, and when you dump the contents of the flash, you find that exactly one page has been written.

[Yardie-]

Excellent thanks again I will make a Pi to 3216 (I still have heaps of those) breakout PCB and add BAT54 Schottky barrier diode across RX and TX to the 3216 UPDI pin and see how it goes. It will be really cool to have a programmable true real time peripheral connected to a PI. The possibilities are endless.
Thanks again Spence. This is quite exciting really.

[Yardie-]

So just to see I've got it right.
You use Arduino to create the image then use serailupdi to upload that image direct to the tiny.

Obvouisly I haven't had a chance to look into serailupdi so if the answer is there then don't bother answering me (and sorry for being so lazy).

Thanks for the tip about the board rate it shouldn't be too hard to set that in the PI anyway even hacking out a bitbanged version shouldn't be that hard

Actually after just a bit of searching this looks interesting https://github.com/adrianomarto/soft_uart
it creates a soft serial device that maybe Arduino could even talk directly to (but that might be a bit of a stretch) as it's doesn't natively send out Serial. But it should make the hookup for serialupdi a lot easier. But as I said I still don't fully understand the work flow here.
I will bang out a PCB and give it a go.

Thanks again Spence.

[SpenceKonde]

I think the idea of using a soft serial on the pi (assuming it doesn't have a second hardware one) to communicate with the 3216. Even better if you could rig up some way to switch the TX and RX pins from being on the diode or resistor going to the UPDI line, and a pair of normal pins. That would be an analog multiplexer IC, I think, and they're hardly expensive. Might cost you some speed and force you to slow down the baud rate if you weren't careful with the specs of the analog muxer. But that's probably a problem for the future.

Docs for it are here (there's an explanation for why the file is called that on the page)
https://github.com/SpenceKonde/AVR-Guidance/blob/master/UPDI/jtag2updi.md

And yeah, make the image on Arduino, and you can do an upload (likely on a different computer) with verbose upload enabled (actually you don't need anything connected to do this). Just enable verbose upload, scroll up until you see the command invoking python to run prog.py. That's SerialUPDI, and you can use the arguments sent by the IDE as a template.

[Yardie-]

Yes I was thinking of just a jumper for the diode connection connect it and the diode is connected and works as jtag. However to lose two pins on the Pi but gain 18 real time GPIO pins is a pretty good trade-off.
Also the speed is not really that much of an issue only an annoyance really.
Especially with the chip shortage you could have a reprogramable IC for PWM ADC and normal digital IO all mixed onto the same chip talking back to the Pi as say an I2C slave. Or even using 5 wires (3v3, gnd, sda, scl, jtag) to an external breakout PCB.
I'm sort of surprised it hasn't been tried before (but it probably has somewhere).
I'll build it all and let you know how I go in a month or two.

IMHO the only real issue here is getting the Arduino framework to talk to directly to a serial device (with the correct settings) rather than over a USB one.
It has been a while since I played with either a Pi Arduino or a atTiny so I will have to relearn lots of stuff but it is much further up my list of priorities now.

[Yardie-]

And yes only the Pi4 has more than 1 hardware serial.

[SpenceKonde]

Arduino can totally talk to programmers that aren't USB. When the core author creates the platform.txt file which is where programmer upload recipes go (it's a crude format where anything enclosed in curly braces if it's been defined as a value, is replaced with that value). There's a tools submenu where you select a COM port. That com port is used for serial monitor. Additionally it is accessible from recipes defined in platform.txt (eg for upload, bootload and programming) as {serial.port}.

Unless the upload parameters are defined in boards.txt to tell it what to do in order to upload, it will shrug it's shoulders and use the currently selected programmer. In programmers.txt, there are he definitions. Even "upload" when defined in that way it could mean over serial, but that's just because that's very common.

Examples

serialupdi57k.name=SerialUPDI - SLOW: 57600 baud
serialupdi57k.protocol=uart
serialupdi57k.program.extra_params=-u {serial.port} -b 57600
serialupdi57k.program.protocol=uart
serialupdi57k.program.tool=serialupdi
serialupdi57k.bootloader.tool=serialupdi

jtag2updi.name=jtag2updi
jtag2updi.communication=serial
jtag2updi.protocol=jtag2updi
jtag2updi.program.protocol=jtag2updi
jtag2updi.program.tool=avrdude
jtag2updi.program.extra_params=-P{serial.port} -b{program.speed}
jtag2updi.program.speed=115200

nedbg.name=Curiosity Nano (nEDBG, debug chip: ATSAMD21E18)
nedbg.communication=usb
nedbg.protocol=curiosity_updi
nedbg.program.protocol=curiosity_updi
nedbg.program.tool=avrdude
nedbg.program.extra_params=-Pusb

Those are things that get substituted into the recipe.

In those controllers are serial-based programmers and 1 USB based one.

As you can see, the USB one passes a parameter specifying use of USB (if it was using some hypothetical tool that would only upload through native USB devices then it probably wouldn't have that parameter at all, since you don't have to tell something what it already knows

The Arduino framework has NOT A CLUE whether a serial adapter is connected via USB, or whether it's native to your hardware, or whether it's created by some clever virtual driver that's actually piping the data in and out of an IP connection or is a PCI card that contains alien technology allowing superluminal communication by coupling to the fabric of space time. If the driver presents it as a serial port, that's all arduino knows. . If it gets a COM port or tty number assigned (and there is an OS API to request that list) those all look alike, and that's what Arduino puts into the tools -> port menu. The OS hides from applications the exact nature of the serial port, because it shouldn't matter to the application. A serial port whose driver correctly implements standard interfaces should honor anything that works on a serial port, in terms of opening and closing connections, sending and receiving data, setting and reading modem control pins and so on.

[Yardie-]

Actually as the Pi already supports hardware serial and the device is already configured as ttyS0 I will start with the simplest solution and add the diode (as per instructions) to the default Serial RX and TX then simply set the device as such in the prog.py arguments. If that works it will basically solve my issue as I can just use jumpers to program the tiny then set the pi back to normal serial mode.
KISS
The rest is just fruit on top really.

[Yardie-]

Learning more all the time here's a useful link if anyone else is interested
https://docs.bitscope.com/pi-serial/
and this
https://www.raspberrypi.com/documentation/computers/configuration.html#configuring-uarts

search in the page for uart here https://github.com/raspberrypi/linux/tree/rpi-4.1.y/arch/arm/boot/dts/overlays
to see what overlays to enable and disable.
So far as long as you disable bluetooth a Pi Zero W has two enablable uarts.
So this is clearly the simplest solution.

[Yardie-]

Wow thanks Spence. That sounds easier than I ever imagined.
Next week I'll dig up my Pi and some old 3216 PCBs and give it a go.
Thank you very much.