How about coming up with a (or another) universal AVR programmer?

Go To Last Post
24 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So, hi guys!

 

I got an AVR Dragon recently and it is real sexy. With it I have successfully unlocked 4 chips which I got their fuse locked. Pretty much the only thing I haven't done is the debugWire, since I'm on a Mac with avrdude.

 

Well, I got to say the hardest part of using the Dragon is wiring. It just takes much time to plug everything according to manual. So I come up with an idea to make yet another open-source programmer and debugger.

 

I'm planning on supporting ISP, JTAG, HVPP, HVSP (for ATtiny13A and such), and maybe even PDI and beyond, DIP-8/14/20/28/40. I also have got two AT89S52 antiques, so it would be a bonus to support it as well.

 

And it looks like something fun! It seems all programming procedures are written in their datasheets.

 

So... is it a good idea or not? Are there already similar open-source solutions? Anyway, I feel good!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It just takes much time to plug everything according to manual. So I come up with an idea to make yet another open-source programmer

A wireless programmer you could use 20 feet from your PC would be nice, new, and useful.  Don't know of any programmers* you can control wirelessly 

 

* a finished programmer unit.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oh I should note that it would be like STK500 with lots of sockets so you can just plug and play, except it would be much cheaper than STK500

 

With a nice PCB, for sure

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

yet another open-source programmer and debugger.

Many of the AVR debugging protocols are NOT "open source", making the debugging part of that both difficult and possibly legally risky.

 

I've always assumed the the STK500 and Dragon had their 'excessive" sets of sockets and jumpers because the AVR hardware was so horribly inconsistent.

It might be possible these days to throw a large-pin-count processor at some of those problems without incurring too much expense, especially if you're willing to sacrifice speed...
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

True, the inconsistency is terrible when considering connections, let alone all different programming protocols.

TBH, I really thought to throw a, like TQFP48 chip in there, with a ZIF socket and call it a day. I was looking at STM32 at that point, realizing I am not familiar with STM32. Then I just kinda decided to do this with an ATmega. At least it's fun! And as an open project, people could just build one on their breadboard and try it out. It is really challenging to allocate all the pins, especially AT89S52 which even required me to throw in another 74HC595.
 

And... do they have lots of protocols? Well I only have used dW... IMO dW looks nice and, there are already a senpai reverse-engineered debugWire and lots of relevant repos on GitHub too. Maybe I could make use of that.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And for those who know, there exists a Chinese programmer named SP200S or somewhat, running on a 8051 with a ZIF socket, with the ability to program a bunch of 8051s and EEPROMs, but not "more modern" AVRs.

 

Well I have to say the ZIF socket is really tempting but, as I think I'm sticking to ATmega16, controlling every single pin just doesn't seem practical.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Within the last month or two there was a thread very like this with someone wanting to make a modern day Dragon/STK500/STK600 like thing. 

 

The conclusion was basically that Arduinos/curiosity/xplained-pro/Xplained-Mini boards these days kind of undermine the $100+ "do all chips" dev board. These days you pick a target like 2560, 328p, 4809, etc then buy the $5.. $15 dev board with that chip and a full programmer/debugger that targets that chip and you can also do full, on chip debugging too for what is effectively a "throw away" price. It's no longer necessary to invest in a one-time, (expensive!), "do everything" board when in the old days you could only afford to buy the programmer / debugger once.

 

Oh and $2 USBAsp's don't help the situation either!

 

The one thing the STK500 (but not Dragon) may have delivered is that it had PC programmable clock and PSU voltage level. (having said that "Curiosity" boards have changeable PSU voltage too)

 

Oh and boards with pinouts that can take "Arduino shields" have a lot going for them too. 

Last Edited: Sun. Dec 19, 2021 - 04:52 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

45gfg9 wrote:

Well, I got to say the hardest part of using the Dragon is wiring. It just takes much time to plug everything according to manual. So I come up with an idea to make yet another open-source programmer and debugger.

 

Really? It's 6 wires if using flying leads. Or just one if you use the header. Exactly what problem are you trying to solve?

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

HVPP can often involve 20+ wires (not that you will probably want to be doing it "in circuit"). I guess just wiring the signals to the Dragon's chip socket can be "challenging" 

 

BTW one way to try and hide such complex wiring is to implement the "routing card" idea that the STK600 had. But look how successful that was (not!). I actually gave my STK600 away to someone but retained my two STK500 which were actually a much more useful (and cheap to operate!) design. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

clawson wrote:

HVPP can often involve 20+ wires (not that you will probably want to be doing it "in circuit"). I guess just wiring the signals to the Dragon's chip socket can be "challenging" 

 

But how many people ever use it? In over 20 years of AVR I've never needed to use it.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I'm with you. I think I only once ever tried HVPP on a couple of 168's I'd lost contact with. I can't remember now but I think I'd maybe just left them stuck in DWEN mode. But on the whole the "cheap solution" to lost chips  that might need HVPP for recovery, is "chuck them in the bin and accept the $1..$2 loss, Learn from the mistake, move on, don't do it again!" 

 

From time to time we see a thread here where someone has wasted a week building some kind of HVPP rescuer at the cost of $20+ when they could simply have discarded the $1" lost" chip and moved on. Unless you are losing handfuls of chips every month I've never really understood the desire to waste your time! 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:
A wireless programmer you could use 20 feet from your PC would be nice, new, and useful.
Olimex's isolated AVR ICSP is one meter short.

avrcandies wrote:
* a finished programmer unit.
Not :

WiFi-Enabled AVR Programmer with Terminal Server from Maverick Embedded Technology on Tindie

uPDI & SPI Programmer using ESP32 | AVR Freaks

MPLAB X remote via a Raspberry Pi 3

 


AVR-ISP500-ISO (Olimex)

 

Remote USB Debugging Plugin Overview - Developer Help

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A wireless programmer you could use 20 feet from your PC would be nice, new, and useful.

Olimex's isolated AVR ICSP is one meter short.

 

 

????  Please show me the link, I'd be very interested in a programmer that uses radio rather than a cable to go across the room (I am NOT interested in a "portable" programmer, I am editing code)

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:

????  Please show me the link, I'd be very interested in a programmer that uses radio rather than a cable to go across the room (I am NOT interested in a "portable" programmer, I am editing code)

 

Any good?

 

https://www.tindie.com/products/...

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A wireless programmer/debugger is coming soon:

Microchip MPLAB ICE4.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

45gfg9 wrote:
I'm planning on supporting ISP, JTAG, HVPP, HVSP (for ATtiny13A and such), and maybe even PDI and beyond, DIP-8/14/20/28/40. I also have got two AT89S52 antiques, so it would be a bonus to support it as well.

 

You forgot the really important support for the current controllers: UPDI.  Basically you don't need anything else because the new AVRs can essentially replace all old ones.

My recommendation is the cheap nEDBG programmer / debugger of the current Curiosity Nano boards.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

GermanFranz wrote:
Basically you don't need anything else because the new AVRs can essentially replace all old ones.
AVRxt : no EBI, no DMA, reduced complexity PMIC

Replacing most AVRe+ by an AVRxt (AVR Dx) :

Migration from the megaAVR® to AVR® Dx Microcontroller Families

 


Instruction Set Summary | AVR® Instruction Set Manual

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:

AVRxt : no EBI, no DMA, reduced complexity PMIC

 

Yes, the old XMegas are not completely out yet.  So let's add PDI to the compulsory program yes

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Any good?

 

https://www.tindie.com/products/...

Thanks!!!  I'm taking a look at that one.  I do wish it had a case like my ARISP MKII ...I do have a 3d printer...could print the mentioned files

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

But on the whole the "cheap solution" to lost chips  that might need HVPP for recovery, is "chuck them in the bin and accept the $1..$2 loss, Learn from the mistake, move on, don't do it again!" 


 

Well, what I'm thinking is that like, RSTDISBL exists for a reason, right? I had made a couple of small projects involving 6 pins. I could have used ATtiny13A but since PB5's not available I had to turn to a 2313. In some cases the idea of using RST as IO really is tempting. Back then if I had had the Dragon, I would no doubt choose 13A. And, as for me, I just can't convince myself throwing away locked chips knowing there exist some approaches to save them.

Also, debug on a standard protocol would be a lot easier than on UART emitting all values everywhere. It can even use GDB, if possible.

 

GermanFranz wrote:

You forgot the really important support for the current controllers: UPDI. 


 

Okay, that could be in the "beyond" part. I own a Nano Every clone with a UPDI pin on it but haven't tested it out.

 

Well, for those like me, there is no need to turn to new chips when I still have some in my hands and they are capable of the task. And for sure old chips will still exist for a long time!

Last Edited: Mon. Dec 20, 2021 - 04:02 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

45gfg9 wrote:
And for sure old chips will still exist for a long time!

 

Agreed, but especially for these old chips there is already a large selection of inexpensive programming and debug tools.

I don't see any need.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Anyone who actually uses RSTDISBL is someone who made a mistake picking the right chip for the application design! The "cheap" solution is to correct the design to a more appropriate chip (ie one with at least one more IO) 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

"Dare to be naïve." - Buckminster Fuller