Looking for a list of DIP AVRs

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

I'm currently developing a sort of AVR development board, with capabilities similar to (and exceeding) those of the STK500 (it's gonna have debugWire functionality).  It is specifically for 8-bit AVR's in DIP packaging that make use if the ISP programming interface, in all of the varieties that there are (DIP-8, DIP-14, DIP-20, DIP-28, DIP-40).  Note that this excludes chips that use UPDI, so no ATmega4809 or AVR DA and DB families.

 

I would like it to be 100% compatible with any chip in this category, but for some reason I just can't find any good list of all such chips.  The attached table was exported from Microchip's part selector (and then I did some sorting, and removed columns I didn't need for easier reference).  I searched for all 8-bit AVR MCUs, and searched for "DIP" with the packages column enabled.  It has all of the current models that fit this category, but there are some missing.  The only one I know it's missing the ATtiny22, and, to be fair, this is an EOL product from 20 years ago, but I suspect there are more.

 

Does anybody know where I could go about getting a complete list, or failing that, where I could look up all of the releases going back to forever and construct a list myself?

 

And to those of you who will point out that it is a wholly foolish endeavour (not to mention a enormous waste of time) to try and make it compatible with all of these outdated and no-longer-produced chips, I completely agree with you 100%.  But I'm a perfectionist in some ways, and I want to try anyway.  Also, 1. It's my time to waste, and 2. You're wasting your time writing a very good and completely valid argument telling me not to waste my time, as I just don't care.  I'm doing something I'll probably regret later, and I know it.  Ok?  Ok.

Attachment(s): 

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


Well I was going to suggest Microchip's parametric selection tool but given that it never actually works perhaps I won't. However I would try a large distributor like Digikey, Arrow, RS or similar that also do parametric selection then just filter on PDIP.

 

Something like this...

 

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

ERR_NAME_INVALID wrote:
it's gonna have debugWire functionality

 

Your Excell table is interesting. Why, there is not DebugWire mark associated with any chip?

Do you mean "it's gonna have ISP and DebugWire functionality"?

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

I guess a limitation of both manufacturer & distributor parametric searches is that they'll only show "current" models.

 

There are probably many variants which are no longer manufactured in DIP,  but once were and are still to be found for sale in various corners of the interwebs, and hiding in people's drawers ...

 

eg,

ERR_NAME_INVALID wrote:
ATtiny22, and, to be fair, this is an EOL product from 20 years ago, but I suspect there are more.

 

Rather than try to make the base board compatible with everything, might it not be easier to have a single, common socket on the baseboard, and adaptors for specific chips ... ?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Mon. Nov 22, 2021 - 11:37 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

From memory,  STK500 caters for all the DIP8, DIP20, DIP28, DIP40 chips.   If you want to use DIP14 chips,  make an adapter to fit on the EXPAND0 header.

 

If you want to make "your own" STK500,   just copy all of the design files.   And "add" a DIP14 socket.

 

I occasionally dig out my old STK500 board.   Normally for its adjustable VCC.

But life is much easier with an XMINI, XPRO or Curiosity board.   You get Serial comms and debugging with a single USB cable.   The Curiosity even gives programmable VCC too.

 

David.

Last Edited: Mon. Nov 22, 2021 - 11:28 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
If you want to make "your own" STK500,   just copy all of the design files 

Good one!

 

I guess a trawl through the revision history of STK500 might reveal a list of all the devices it has supported - and their packages ... ?

 

The Curiosity even gives programmable VCC

Interesting - is that all Curiosities, or just certain models ?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Every Curiosity.

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

ERR_NAME_INVALID wrote:
STK500 (it's gonna have debugWire functionality) ...

DIP-40

JTAG; an example :

PCB-AVR1284-3U | Atmel DIP40 AVR DevBoard | BusBoard Prototype Systems

 

P.S.

re your handle, one's name is absolutely valid.

 

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

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

clawson wrote:
distributor
microchipDIRECT, products, 8-bit MCU, lower left for 8-bit AVR, rightmost column, PDIP

Microchip Technology Inc. | World's Largest Inventory of Microchip Products

 

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

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

Are you gonna use ZIF sockets?  That would be rather nice!   Instead of RS232 control, use a USB comm.  This is your big chance for the hall of fame, if you make it usb powered.

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

Will you be developing a board that will be used by primarily one AVR device type, but be initially configurable to all AVR DIP types, or a board where the individual CPU chip will be inserted and removed often?

 

The first would be like a single-application PCB, but not limited to a specific AVR, only to a package type (DIP).  This would be worthwhile developing for times such as the present when availability of specific AVR devices can be a problem.  The user would select an AVR and then set jumpers and/or solder bridges to configure its pin-out to the application's circuitry.

 

The second type would be like an old-fashioned EPROM/EEPROM IC programmer.  Here a Zero-Insertion-Force (ZIF "flip handle") socket would handle all the AVR pin-configurations by using the Input/Output pins of the master driver CPU as power/ground pins for the AVR device-under-test.

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

ERR_NAME_INVALID wrote:

Note that this excludes chips that use UPDI, so no ATmega4809 or AVR DA and DB families.

 

Ruling out the best current and future AVRs is not a good decision. Especially since they offer attractive DIP types.

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

I wound up writing a textwall, sorry about that.  There's a lot of stuff I wanted to say about my project, and I wound up saying it all.  This is a big project with a lot of features, and I just couldn't distill down all of the things I wanted to cover, as I wanted to explain all of what I'm planning.

 

 

 

 

 

 

I was not expecting so many questions.  I'll do my best to answer all of them, and give a more general description of what I envision.

 

 

My inspiration to begin working on this project was that every AVR development system I could find was ridiculously expensive.  I'm 16, and I don't have all that much money, and I enjoy working with AVRs for projects.  I've always sort of wanted one of the better, fancier dev systems/programmers, but I didn't have the money, and the convenience of just being able to plug in USB power to my Arduino UNO and have it go (as opposed to having to breadboard an AVR up to an ISP) was enough at the time.

 

 

But I eventually wanted more.  More than that, I wanted to make something better.  I wanted to make something as featureful as one of the commercial systems, but open-source, easy to build, and inexpensive.  Something that the community could freely view the plans and code for, so that it could be open for improvements, suggestions, and to be learned from.  Something that would be easy to build in one's spare time with bog-standard equipment as well, so no SMT parts.  Something that would be cheap enough for the basement hobbyist to buy without needing to get a loan.  Something that was different: by the community, for the community.

 

 

Now to what I'm currently thinking of building.  Its main purpose will be to be a development board similar to the STK500, i.e. something that you have an AVR chip in for long periods of time that you are actively experimenting with.  I will also make it so that you can add a ZIF socket, and use it to program a bunch of chips quickly.  It will support ISP, High-voltage serial/parallel programming, debugWire, possibly UPDI (more on that later), and connecting external programmers.

 

 

This will all be done with an on-board ATmega328P (or a bigger AVR if needed), with an SPI RAM chip.  You will communicate with it via a TTL serial header, although I may swap this for a a USB-B port and an FTDI chip (or alternative) if it's not too expensive, just to have it nice and integrated and reduce the need for external tools.

 

 

As to exactly how you communicate with the programmer AVR, there will be multiple ways.  You will be able to use it via a CLI interface interactively over serial.  This will allow you access to the debugWire interface, and batch programming modes (in addition to the ISP, UPDI (if I add it), and high-voltage modes).  The other way is to put it in emulation mode, and it will behave as if it was a programmer, working over serial.  This would make it directly compatible with avrdude and possibly other things, maybe even Microchip Studio.  Perhaps I could implement the STK500 protocol, as this would easily bring in compatibility for the high-voltage mode.  If I add UPDI, I would obviously need to implement a protocol for a programmer that supports UPDI.

 

 

You can power the board via USB, from the FTDI header or the ISP header, or via external 15-20VDC to a barrel jack.  You only need to power it via the barrel jack if you intend to use high-voltage programming (although, this can support more current capacity than USB, if you need it).  I'm not going to include any boost converters to make high-voltage programming possible with USB power, as they're kind of expensive and would drive up the cost, and I don't think high-voltage programming is used very often anyway (this is speculation and conjecture on my part, please tell me if I'm wrong).

 

 

There's going to be one socket for each type of DIP AVR.  I think that's all I'll need, because (from what I've seen) there seems to be one configurations of pins per DIP size (ignoring the UPDI based chips).  Perhaps there are older parts that have different pin assignments, but I haven't seen any yet.  Please let me know if you know of any examples.

 

 

All of the port pins will be bussed together from all of the sockets, and will be brought out to female headers (kind of like an arduino) for easy breadboarding.  There'll also be another set of pads right next to them, where you can mount male pin headers, should you be inclined.  I'm currently debating whether or not to also include 2x5 pin headers for the ports like on the original STK500, as I don't know if they'd be useful or not.  We'll see, I guess.

 

 

There will be six (or maybe more) 2x5 pin headers on the board, and these will be for selecting what kind of DIP AVR you're working with.  Each AVR has extra pin functions (XTAL, TTL serial, SPI, reset, AREF, etc.) on different port pins (not to mention that some AVRs have dedicated pins for some of these, and some do not).  All of these signals will run from the respective peripherals to a 2x5 header (the "master"), and there will be one 2x5 pin header per DIP socket that will connect those signals to the correct pins, when you install a 10-pin IDC ribbon cable between the "master" and the appropriate one for the socket you're using.  In less confusing english: You install a ribbon cable to select the socket you're using.

 

 

I haven't quite worked out how connecting the proper pins for the high-voltage programming will work yet, or indeed if I'll need to use a bigger AVR with more I/O to do the job, but I'll figure it out.  I just haven't looked into the protocol yet.

 

 

Should the user choose to install a ZIF socket in one of the DIP socket positions, you can use it to program lots of chips very quickly.  There will be an external DIP-8 SPI 128k SRAM chip connected to the programmer AVR, and I plan to use it to store the flash and EEPROM data, so that you can load everything once and put in a new chip, press go, and get a chip with all of the flash, EEPROM, fuse, and lock bits set just how you want.  Repeat to get as many programmed chips as you need.

 

 

Somebody brought up the point that:

Ruling out the best current and future AVRs is not a good decision.

I agree with that, but I don't know if I can integrate support for these chips into my design.  First, I'd need to implement UPDI.  It seems like it's a fairly complex protocol, so I'll look into it so see if I could manage it.  Second, I'd need more sockets to accommodate the different arrangement of pins.  I think I can do it, but I dunno.  I'll look into it.  If I do wind up putting in support for UPDI based chips, I'll add a connection for an external UPDI programmer.

 

 

 

If there is interest in my project, I can post updates here as I work on it.  Also, if you made it this far, you deserve a cookie :)

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

It's great to see someone with loads of energy and enthusiasm working intensely on their project with both passion and determination.  You will go far with that attitude!  However, from you description, I wonder---how is this proposal significantly different/better than a std STK500? Certainly, the STK500 is already DIP-oriented, for onboard work.  It also has the ISP connector for external chip programming.  Have you already worked with the STK500?  If not, maybe give one a try so you can keep thinking of ways to make it look like old news. With your interest and energy, there are certainly a wide variety of project to tackle.

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

Thanks for the compliment!  I tend to be overly intense in working on my projects.  As in, finding a new super ridiculously complex project to work on, and then doing that to the exclusion of literally anything else for about a week before backing off.  I'm still in that first phase, and I'm on thanksgiving break which isn't me doing me any favors.  Usually I'd have homework etc. to keep my project obsession at bay XD

 

Also, I find it interesting that you raise that point.  I think I've done plenty to make the STK500 look like a dinosaur.  I will be completely supporting everything the STK500 can do, and batch chip programming and debugWire and possibly UPDI and a lot more chips that the STK500 can and it's gonna be a LOT cheaper and it's gonna be completely open source and you don't have to find some way to get an RS-232 connection.  I honestly can't think of much else to add to that list, although I'd love to hear your ideas.  Part of the point of this project (at least to me) is to get community input, and have it be something for the community.

 

Also, when I was talking about an external programmer port, I was talking about having an external programmer (AVR dragon, Atmel ICE, etc.) plug into the board and program chips on the board.  I was going to have a connector for an external ISP-type programmer, and if I add support for UPDI based stuff, a port for that as well.  I guess I could also add outputs for these, or maybe just wire it so that the ports are bi-directional.

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

Suggest throwing in a PLCC-44 socket somewhere.  I use a lot of mega8535s.  They make ZIF sockets for them too.  I don't think any current (modern) AVRs use PLCC, though.  S.

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

ERR_NAME_INVALID wrote:
every AVR development system I could find was ridiculously expensive

really?

 

Microchip Studio is free, and the Curiosity and Xplained boards are around $10 - which is going to be less (probably significantly less) than the cost of the parts alone.

 

As already noted, these boards come complete with a debugger, ISP, serial port, etc.

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The Xplained boards from Microchip are pretty cool, and are definitely an amazing option if you want to evaluate the capabilities of an AVR before going all-in and buying the necessary equipment to really work with them, but they don't really fit the bill of what I was talking about.  In that quote I was referring to standalone programmers (Atmel ICE, AVR Dragon, etc.), and development boards (STK500, STK600, etc.) which are mostly upwards of $100, the exception being the AVR dragon, which I think retailed for about $55 (but those aren't made anymore, and from what I've read, they had the tendency to just stop working for no reason).

 

The software side of things was never in question, as you can do just about anything with just FOSS like avr-gcc (/w avr-binutils and avr-libc) and avrdude, and of course Microchip Studio is free.

 

Also, my goal is not to compete with that market (doing so would be foolish, those things are extremely cost-optimized).  I want to provide an alternative to the nice integrated development boards like the STK500 and 600, because those really are prohibitively expensive.  The STK500 is about $130 (and that's without any of the addons, and it hasn't seen any updates since 2008), and the STK600 is a whopping $300!

 

Suggest throwing in a PLCC-44 socket somewhere

I'm limiting built-in sockets to DIP flavors to keep the cost down (and prevent the physical dimensions of the PCB from approaching ur mom territory; it's supposed to sit on your desktop, not be your desktop lol), but there's no reason I couldn't add an expansion connector and design expansion boards with ZIF sockets for different flavors of SMT AVR.  I was sort of planning that, actually.  Also, I think having it be an expansion is fine as I don't think all that many people dabble in surface-mount soldering wizardry (I sure don't).

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

ERR_NAME_INVALID wrote:
The Xplained boards from Microchip are pretty cool, and are definitely an amazing option if you want to evaluate the capabilities of an AVR before going all-in and buying the necessary equipment to really work with them

You really don't need any further equipment.

 

And it's not hard to adapt the on-board debugger to work with an external target:

https://www.avrfreaks.net/forum/low-cost-debugger-xplained-kits

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am impressed too. When I was 16, I had completely different things on my mind.

But I also know that it is much easier

ERR_NAME_INVALID wrote:
writing a textwall

to tell your wishes and plans than to actually come up with a finished product.

 

I don't want to judge here whether there is still a great need for an AVR development board for older controllers.

In any case, one should consider the wide range of simple & cheap development tools available today.

In order to experiment with an AVR, besides the peripherals to be controlled, you usually don't need much

more than a power supply and a programming connection.

 

But anyway, it is sure to be a nice entry-level project.

 

Personally, I'm only interested in the current UPDI AVR types. 

These can easily replace all old types and offer even more possibilities.

A cheap programming tool is missing here.

 

If it would still work wirelessly and come along as a small additional chip with antenna

that I could add to all my wireless smart home components for remote programming,

I would promise to buy at least 10 of them from you wink

 

Last Edited: Tue. Nov 23, 2021 - 08:37 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I see your point about the super old chips not really being a big priority, and I somewhat agree.  I just kind of want it to everything under the sun and be "The Perfect Machine" (props to you if you know that that's a reference to).  Also, after looking into it, UPDI seems not too hard to implement, so I plan on making that a feature for sure.

 

And could you elaborate on what kinds of UPDI AVR you like to use?  What models, package types, etc?

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

ERR_NAME_INVALID wrote:

"The Perfect Machine"

 

doesn't exist. That would be asking too much.

 

ERR_NAME_INVALID wrote:

UPDI seems not too hard to implement

 

I am not sure if it is so. Most of the time it's more complicated than you initially think.

But I haven't had time to deal with it myself.

 

ERR_NAME_INVALID wrote:

what kinds of UPDI AVR you like to use?  What models, package types, etc?

 

My favorite controller right now is an AVR128DB28.

That’s everything you need in a practical, slim DIP housing.

For other, more space-saving projects, I like to design my own PCBs for SMD types.

 

 

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

I was mainly worried about the physical standard being difficult, but it's pretty simple.  Programming the logical side with all of the instructions doesn't seem too hard either.  The UPDI standard is listed in section 30 of the ATmega4808/4809 datasheet, it you're so inclined.

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

I wonder if we should have a show of hands here as to the last time anyone used their STK500s. In it's day the thing was phenomenal and I guess the programmable PSU and the programmable clock still are a bit. But these days if you want to prototype with some AVR you just get an Arduino or Xplained or Curiosity with it on and play there. The Atmel boards usually have a debugger for just a few bucks. So like the Butterfly (and STK200 before it) and so many AVR boards that were the go-to, must-have things, like STK500, have kind of had their day.

 

(Actually I remember when Atmel sent me the first issued STK600 (might have been for 50000 posts?) I was so excited thinking "finally an STK500 with a debugger (it does say "JTAG" on the box) but then the sense of total disappointment when I found it was JTAG programming but not JTAG debugging - I gave it away to a fellow Freak soon after. That was the window of opportunity for a "better than STK500" but it was missed). 

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


clawson wrote:
things, like STK500, have kind of had their day.

Indeed.

 

And that's not just  Atmel  Microchip; that's industry-wide - just about every manufacturer now has low-cost dev boards with built-in debugger.

 

Personally, I far prefer a simple, single-purpose dev board than something which tries to be all-singing, all-dancing, all-things-to-all-men, everything-including-the-kitchen-sink, "universal", blah blah ...

 

I find that such things have so many options & goodies that they just get in the way - and take ages to figure out exactly what everything does, how it's connected, and how to use it ...

 

just my 2p

 

 

(with a claw from Gimli)

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm sorry, I know we weren't supposed to be getting into a discussion about the potential utility - or otherwise - of the project.

 

however, it does seem that  the OP really hasn't understood the current state-of-the-art in dev boards, etc (eg, #17) - so that might actually have a bearing ... ?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Wed. Nov 24, 2021 - 10:28 AM