avrdude-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #61624] [Feature request] Serial/UART UPDI programmers


From: Dawid Buchwald
Subject: [bug #61624] [Feature request] Serial/UART UPDI programmers
Date: Mon, 13 Dec 2021 16:21:29 -0500 (EST)
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.93 Safari/537.36

Follow-up Comment #22, bug #61624 (project avrdude):

> I only own tiny1-series chips, so I tested on ATtiny416 and ATtiny817.

Thanks for confirmation. I will get myself the other types as well then.

> Probably a noob question, but does there exist an NVM 1 family?

Not a noob question, it's really confusing. According to sources of pymcuprog
there are actually three families: 0 (tiny), 2 (AVR Dx) and 3 (AVR EA). Family
1 has never been mentioned there.

That being said I think there are no NVM 3 chips in the wild.

I have also looked into the fuses business, and quite frankly, with my utter
lack of knowledge about AVRDUDE source code (I volunteered to join the project
like a week ago, for the sole reason of porting pymcuprog code to C) it would
be way too risky. 

See, the whole efuse/hfuse/lfuse/fuse model should be probably refactored, but
we are talking about changing SIGNIFICANT part of the existing codebase
affecting dozen different programmers. Without proper release model (parallel
development of stable and refactored version) and considerable testing effort
I wouldn't touch it.

That being said, there is an issue of safemode option. I don't want to pretend
I fully understand what it does, but it seems to help to prevent accidental
bricking of your chip with accidental fuse change. It supports the
[e/l/h/-]fuse model and I don't think I could safely extend it to support the
fuse0-8 model of new AVR chips. Sure it would be nice to have it, but I think
it goes way beyond the intended SerialUPDI driver implementation. Thing is
that it should work regardless of programmer used and I don't think it works
for any new chips at all.

So yeah, for now I will focus on refactoring my code, improving error handling
and supporting missing memory types (user row, lock) and possibly DTR/RTS
support. Other things will have to wait to be prioritised.

    _______________________________________________________

Reply to this item at:

  <https://savannah.nongnu.org/bugs/?61624>

_______________________________________________
  Message sent via Savannah
  https://savannah.nongnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]