tinyAVR 2-series

[a7hybnj2]

They are here! I just ordered a tube of 10 1624's and 1626's 14 and 20 pin respectively.

Let me know if there is anything I can test on my end.

I got them from Mouser.

[SpenceKonde]

Woah! Crazy. Well, I don't have anything written for them - I've been adjusting docs, but there's no code or anything, lol... they're gonna need new variant files, new boards.txt entries.... new bootloader configs too I guess, though I bet the old binaries will work for USART0, just not USART1. Logic needs to be ported to them... I don't know when I'll even be able to have working core ready for them... I was hoping they'd keep getting delayed some more.

…

On Wed, Feb 3, 2021 at 9:23 PM a7hybnj2 ***@***.***> wrote: They are here! I just ordered a tube of 10 1624's and 1626's 14 and 20 pin respectively. Let me know if there is anything I can test on my end. I got them from Mouser. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#309>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABTXEW6I2YOLYOIVZ2G2TDDS5IAIZANCNFSM4XB6Z47A> .

--

____________ Spence Konde Azzy’S Electronics New products! Check them out at tindie.com/stores/DrAzzy GitHub: github.com/SpenceKonde ATTinyCore <https://github.com/SpenceKonde/ATTinyCore>: Arduino support for all pre-2016 tinyAVR with >2k flash! megaTinyCore <https://github.com/SpenceKonde/megaTinyCore>: Arduino support for all post-2016 tinyAVR parts! DxCore <https://github.com/SpenceKonde/DxCore>: Arduino support for the AVR Dx-series parts, the latest and greatest from Microchip! Contact: [email protected]

[a7hybnj2]

Haha awesome. The full series isn't released but the 162x are out.

Most of that stuff sounds way beyond me. I will will play with them once they arrive and if I do anything useful I'll let you know.

If you need a tester for anything let me know.

[SpenceKonde]

Also... goddamn, thanks for the tip about mouser vs digikey. Digikey is slipping! While Mouser? Mouser is shipping...
Not only does mouser have the new parts that digikey doesn't, their prices on the whole Microchip product line are better! I do hope they change their mind about the VQFN's being non-stock though.

The 1627 is listed as coming in the microscopic VQFN (3x3mm- same as the attiny841's small version and the 1616 (but not the 3216!) . Think we'll get the ultra small package for the 32k parts this time around? I hope so - you can put them on a breakout board that fits into a DIP socket : without wasting any pin positions (the 4x4mm like the 24-pin tinyAVRs) you lose the two middle pin positions to the chip. -P We're gonna be waiting a while I'm afraid for the 32k parts - they haven't even released the ATPack for them yet (I'm definitely a bit worried that they'll end up deciding they'd cannibalize sales of the high end AVR DD line, and cut it off at 16k (though I may be being too negative.

I'm pretty sure that all the tinyAVRs with more than 8 pins of a given flash size and series (0 vs 1) were the same die (and the 2 and 4k parts are the same die too, I think. They shipped a whole bunch of 402's with the wrong signature way back, and someone else here claims to have a 414 that insists that it's a 416, recently acquired. I think they. I always wonder what mechanism is used to do that sigrow writing, whether etching with laser is involved (maybe only for some parts), or if you need to contact part of the chip that's not exposed after the package goes on.... or maybe there's just some magic KEY value you can use via UPDI that will just let you write to the SIGROW! They have that "KEY" to enable chip erase, and another to enable the write userrow while locked, plus the one for NVMPROG - and they're 64-bit keys. Wouldn't be hard for them to have extra ones , and brute forcing a 64-bit keyspace with a non-trivial verification time wouldn't be practical...

[freemovers]

You probably mean the ATtiny3226 will be the 3x3. The ATtiny1627 is 16k and 4x4.

…

On Feb 7, 2021, at 7:00 PM, Spence Konde (aka Dr. Azzy) ***@***.***> wrote:  Also... goddamn, thanks for the tip about mouser vs digikey. Digikey is slipping! While Mouser? Mouser is shipping... Not only does mouser have the new parts that digikey doesn't, their prices on the whole Microchip product line are better! I do hope they change their mind about the VQFN's being non-stock though. The 1627 is listed as coming in the microscopic VQFN (3x3mm- same as the attiny841's small version and the 1616 (but not the 3216!) . Think we'll get the ultra small package for the 32k parts this time around? I hope so - you can put them on a breakout board that fits into a DIP socket : without wasting any pin positions (the 4x4mm like the 24-pin tinyAVRs) you lose the two middle pin positions to the chip. -P — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[gcormier]

Got my 1624 from Microchip direct but also noticed Mouser has stock too.

I asked Digikey, they were useless, said to ask Microchip. Asked Microchip, they were confused and said to ask the vendor. Disappointing indeed.

Put it on a test board, fired up atmel studio and looks good via atmel ice. Haven't dared to try avrdude, and I guess we're a way out from support for the 2 series.

[a7hybnj2]

@gcormier I think you could copy the 1614 from avrdude and just change the IDs. I will be getting my chips sometime this week and will see how far I can get. Really I'll be waiting on Spence because the reason I am drawn to the 1626 over 1616 is the 2nd hardware uart...

[gcormier]

Yup I chose 1624 because of 2 Serial.

Now, using the second serial (Serial1) has proven problematic compiling for 1614.

[SpenceKonde]

github 'master' branch now hasI sketched in support (board defs made from 1-series with regex's, #ifdefs made less inclined to block compiles instead of spewing warnings, and tone got the new name for the clksel bitfield group codes).

I know all analog related stuff is broken, but please go determine what else is.

[SpenceKonde]

clock source for millis timekeeping needs to be TCA0, TCB0, or TCB1

[gcormier]

Just pulled master branch - Not seeing the 2 series

[SpenceKonde]

They're under the 0/1-series definitions with the same number of pins

[SpenceKonde]

Amended the boards.txt to make it more obvious where to look

[SpenceKonde]

boards.txt also clarifies which timer options work are expected to work

[gcormier]

Flashed and some basic stuff works - need to whip out the scope or logic probes to see if Serial is broken, or, if it's the LIN bus with an issue. (Arduino IDE to compile, Microship to flash UPDI - can't seem to get ATMEL-ICE visible in Arduino IDE. I use neither regularly, typically use PlatformIO.)

[SpenceKonde]

Converting to a discussion topic :-)

[SpenceKonde]

See also: #317

[t-moe]

According to the datasheet of the new series (e.g. 1627) the fuse RSTPINCFG has a default value of "GPIO". This means that the UPDI pin can only be used, using a High-voltage programmer.

However, I noticed that in practice the chips have the Fuse configured to "UPDI" when coming off the factory. Can anybody confirm/deny this? Have you been able to flash your tiny's without using a high-voltage programmer? (e.g. atmel-ice?)

(I've built myself a DIY-HV-UPDI-Programmer before I found out, that the fuses actually seem to be setup to GPIO...)

[a7hybnj2]

@t-moe I have successfully programmed one without a HV programmer. I never pulled the default values since I assumed they would have been the same as the previous series 1 chips which again I never actually looked but worked with updi just fine. I do see the section on RSTPINCFG but I don't see where it lists the 'default'.

I still think I will make a HV programmer because would be good to have anyway. Thanks for the link.

[t-moe]

I think I have found the answer myself:

The datasheet says the default of RSTPINCFG is GPIO

But the errata says that the default is UPDI.

Takeaway: You only need to build an HV-programmer when you want to use the pin as GPIO.

[SpenceKonde]

Huh, I swear I replied to this yesterday.

It is implausible that Microchip would ever ship a part in that configuration. This is AVR-land - HV programming is weird and exotic Most of their programmers don't support it at all, including the ones commonly used internally by Microchip. If the Microchip engineers couldn't program their engineering samples, at all, even Microchip would notice.. (apparently the curiosity nano is used internally, if I parse what was said in the context of pymcuprog behavior correctly). Also note that support for HV programmers with the official tooling has always been flaky (IIRC when tinyAVR 0/1 came out, for a longm the microchip IDEs had problems using it, offficial; HVUPDI programmers were difficult to obtain etc. I would be less surprised for a chip to ship on which HV programming didn't work at all as opposed to one where HV was needed vfor nbasic functionality.

That p[art didn't even register in my brrain, I soldered em down and started programming them :-P

[grandaspanna]

I'm no expert, but both 0xD4 and 0xF6 yield '01' for the RSTPINCFG configuration. The datasheet error seems to be in the row that shows the default bit values. The errata actually doesn't address this, but instead the greyed fields that are reserved. I'm saying this out aloud mostly to test my understanding :-)

[SpenceKonde]

And in summary, this section of the datasheet wasn't checked for technical accuracy by anyone with a clue.