Adding support for UPDI-over-UART programmers

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Adding support for UPDI-over-UART programmers

Paul "LeoNerd" Evans
There are several easy hacks to talk UPDI over any standard UART
device. These started with some advice from `pyupdi`[1] about how to
just use a 4k7 resistor on the TX line of any USB-UART bridge to turn
the thing into a half-duplex onewire. I now make and sell two separate
products on my Tindie store[2,3] for doing this and I also link to my
Device::AVR::UPDI CPAN module[4] containing another implementation of
this.

I figure now's about the time for avrdude itself to have an
implementation too, so the standard AVR code-uploading tool can do it.

I'm imagining for example:

  $ avrdude -c updi-uart -P /dev/ttyUSB0 -p attiny814 ...

Would anyone like to have a go at this, based on these two examples? Or
failing that, give me a hand-hold at how to add new programmer support
so I can do it?

Thanks,


[1]: https://github.com/mraardvark/pyupdi
[2]: https://www.tindie.com/products/leonerd/avr-updi-programming-cable/
[3]: https://www.tindie.com/products/leonerd/avr-updi-programmer-with-12v/
[4]: https://metacpan.org/pod/release/PEVANS/Device-AVR-UPDI-0.03/bin/avr-updi

--
Paul "LeoNerd" Evans

[hidden email]      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/

attachment0 (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Adding support for UPDI-over-UART programmers

Paul "LeoNerd" Evans
On Wed, 25 Mar 2020 16:31:16 +0000
"Paul \"LeoNerd\" Evans" <[hidden email]> wrote:

> Would anyone like to have a go at this, based on these two examples?
> Or failing that, give me a hand-hold at how to add new programmer
> support so I can do it?

Anyone any update on this?

I'm just looking for a small amount of handholding, to get me started
on the process. I basically have some questions mostly about how to add
some new programmer type to the codebase.

I am *totally* guessing here I'd go something like

 $ git clone SOMEWHERE
 $ cd avrdude
 $ cp some-example.c prog_updi-uart.c
 $ $EDITOR some_main.c
    # add in a link to the new programmer type somehow
 $ $EDITOR prog_updi-uart.c
    # actually implement my code here

Is that a reasonable description? Can anyone help me fill in the
details so I can give you a new programmer type, please?

Thanks,

--
Paul "LeoNerd" Evans

[hidden email]      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/

attachment0 (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Adding support for UPDI-over-UART programmers

Joerg Wunsch
As Paul "LeoNerd" Evans wrote:

> I am *totally* guessing here I'd go something like
>
>  $ git clone SOMEWHERE
>  $ cd avrdude
>  $ cp some-example.c prog_updi-uart.c
>  $ $EDITOR some_main.c
>     # add in a link to the new programmer type somehow
>  $ $EDITOR prog_updi-uart.c
>     # actually implement my code here

Unfortunately, I'm afraid nothing like that is readily available.

You could try looking up one of the more simple drivers (i.e.  *not*
those for stk500v2 or jtagice etc.) as a reasonable template.

In general, each programmer is described by a table of method it
implements, usually located towards the end of the programmer
implementation.

pgm_new() in pgm.c mentions all programmer fields, among them, these
are marked "mandatory":

  /*
   * mandatory functions - these are called without checking to see
   * whether they are assigned or not
   */
  pgm->initialize     = pgm_default_2;
  pgm->display        = pgm_default_6;
  pgm->enable         = pgm_default_4;
  pgm->disable        = pgm_default_4;
  pgm->powerup        = pgm_default_powerup_powerdown;
  pgm->powerdown      = pgm_default_powerup_powerdown;
  pgm->program_enable = pgm_default_2;
  pgm->chip_erase     = pgm_default_2;
  pgm->open           = pgm_default_open;
  pgm->close          = pgm_default_4;
  pgm->read_byte      = pgm_default_3;
  pgm->write_byte     = pgm_default_5;

Finally, your programmer needs to be added to programmer_types[]
in pgm_types.c.

That's it. :-)

OK, life is probably more difficult, but I hope it gets you an initial
idea. Just ask here for more if you're stuck.

Btw., I'm surprised UPDI is looking that simple as you described it.
--
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)

Reply | Threaded
Open this post in threaded view
|

Re: Adding support for UPDI-over-UART programmers

Paul "LeoNerd" Evans
On Thu, 23 Apr 2020 21:57:39 +0200
Joerg Wunsch <[hidden email]> wrote:

> Btw., I'm surprised UPDI is looking that simple as you described it.

I believe it was designed that way on purpose. You can read/write it
just with a resistor to turn a regular async serial port into a
half-duplex single wire bus. There's really not much to it.


How does source control work there then? Do I just grab latest tarball
from savannah (looks like 6.3 from 16-Feb-2016), or is there some other
source control system in effect somewhere?

--
Paul "LeoNerd" Evans

[hidden email]      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/