New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)

[windoze_killa]

Thats why I chose the 3217. Lots of space for for everything I need. I have pretty much just finished one project, just waiting for Drazzy (at his leisure) to check for an EEPROM problem I am having. After that I can spend some money on a board design.

[grandaspanna]

I'm loving the 1614 as a general purpose part. The SOIC package is easy to manage and two B timers is nice. Wish there was an 812, oh and native USB :-)

[DrAzzy]

You and me both on an 812! And using the 1614 as a general purpose part, they're definitely my go-to now. Did you know they almost made a 3214? Headers for it were in the ATpack, but then got removed this year. I don't suppose you have an idea of which libraries work with megaTinyCore do you? Or more importantly, which ones *don't*. Hit me in the DM's if so, there are some freebies in it for you if you've got a substantial list. ;-) This goes for everyone, by the way. I don't get to work on my own projects anymore so haven't been using libraries much, see....

They also may not be doing an ATtiny422 either! (2-series is coming out, they say around thanksgiving, first datasheet dropped in july, and it shows the whole family - and no 8-pin parts - I'm *thankful* for 2 more months before I have to have the ADC code written; that ADC is another animal, for sure. They also gave us a second USART, which is pretty sweet, though they took away the second ADC (payment for the new ADC :-P) and the TCD (okay, nobody used it anyway - but it sure makes competition tighter for the remaining timers, since you can't offload millis to TCD, which is the default because that thing is a bitch to configure correctly). Besides those big ones, not much has changed other than an extra two CCL LUTs and the ability to make TCBs count on events and cascade input capture if you so desire. Oh, and we get a 32k 14-pin part, and the 32k parts have 3k of ram (not 2k), 32/16k parts get 256 of eeprom, 4/8 get 128b. They can use an external high frequency crystal as clock source, like the Dx series. Sadly the cpu core isn't the Dx one, so it still has the same frequency limits, and the same 16/20 oscillator scheme.

Oh... and they can be fused to use a different pin as reset so you don't need to use HV programming to get hardware reset!

8-pin parts could just be a different datasheet and later release though, because the pinout has to differ more because of the small number of pins... or maybe they don't think it's worth it? There are definitely some things I'd love a dual USART 8-pin part for, though...

It looks to me like they didnt decide they hated external crystals, they just took their sweet time getting a new HF external oscillator peripheral ready (everything announced since this spring has had it - and my god are they announcing a lot of new parts; I suspect they were waiting on the 12-bit ADC enhancement that the Dx series has (though they don't have the crazy one) and/or the crystal peripheral to release a huge refresh of the AVR line).

You'll like the DD-series too (but who doesn't like DDs? *corny laugh track*) they go 14/20/28/32 pins, 16/32/64k flash with 2/4/8k ram and 256b eeprom, ADC on every pin 3 (or 4 on 28/32-pin) pins with MVIO (no ADC on those pins if MVIO is in use, obviously), Dx-style clock generation, we get TCD, and 28/32k parts have a third TCB. Oh, and the 20-pin ones come in soic-20 or VQFN, but not the 3x3mm one that the tinyAVR 20-pin ones come in, which can be massaged into a 20-pin DIP outline - those are coming to my shop for the 1616 in october btw - but the 28 pin ones will be in DIP package too, so who cares?). Oh, and dedicated reset pin, but both reset and UPDI can be fused to GPIO, though one of them is input only like usual on Dx? Can't be certain about that. Product brief is out, but that's it, so who knows when we will see it, probably 2021.

[windoze_killa]

Hey DrAzzy,

Would you be able to give an indication of when you might be able to look at the EEPROM problem in the 3217? I know you are flat out.

[grandaspanna]

You'll like the DD-series too (but who doesn't like DDs? *corny laugh track*) they go 14/20/28/32 pins, 16/32/64k flash with 2/4/8k ram and 256b eeprom, ADC on every pin 3 (or 4 on 28/32-pin) pins with MVIO (no ADC on those pins if MVIO is in use, obviously), Dx-style clock generation, we get TCD, and 28/32k parts have a third TCB. Oh, and the 20-pin ones come in soic-20 or VQFN, but not the 3x3mm one that the tinyAVR 20-pin ones come in, which can be massaged into a 20-pin DIP outline - those are coming to my shop for the 1616 in october btw - but the 28 pin ones will be in DIP package too, so who cares?). Oh, and dedicated reset pin, but both reset and UPDI can be fused to GPIO, though one of them is input only like usual on Dx? Can't be certain about that. Product brief is out, but that's it, so who knows when we will see it, probably 2021.

A 32-bit virtual TCB, did I understand that right??? Is that going to be on the AVRxxDD14? My use cases are generally very basic and currently all digital, but lazily settled to use two TCB instances for a project. Want to capture pulse width and frequency, but the pulses are relatively short compared to the frequency, so frequency timer was rolling over if I wanted good resolution for pulse width. Also used an external 20MHz clock for better accuracy which sounds like it won't be necessary. Don't know if it's entirely new, but I may find a use for the native ZCD...

[DrAzzy]

Yeah, you can do it on DA, DB, and future DD, tinyAVR 2-series - and probably the EA series too.

In fact, you could snag one of AVR DA-series breakout boards from Tindie, download DxCore, write the code this weekend and be running it next week when my board arrived (assuming you're in the US). Oh hey, funny, it looks like that just so happens to be my store selling them, what an odd coincidence...

Hell, you can even crank the clock on those bad boys up to 32 MHz for even more accuracy (of course in flagrant violation of the manufacturer specifications - but hey, they're the ones that left the clock control register allowing you to set the internal oscillator to 32 MHz when the part was rated for 24...) It's only fair, considering all the errata we have to deal with!

And yeah, you set the high timer to clock on event, set an event channel generator to the low timer OVF, and set the high timer to use that as event source, and set the cascade bit in one of them, then configure the low timer for input capture normally. The cascade bit (I forget which one you set it on) makes the hardware ensure that they don't miss an overflow or anything, then in your CAPT ISR, you read out both timers, combine the values, and proceed normally.... time an event up to 178.9 seconds to an accuracy of 24ths of a second, or with overclocking, something up to 134.2 seconds long to an accuracy of 32nds of a second.

Of course the giant caveat here is that you actually need to use a DB-series, or an external oscillator, in order to not get thrown off by the accuracy of the internal oscillator... I foolishly didn't think to put external oscillator pads on my breakout boards). With external watch crystal for autotune, the internal oscillator is only within 0.4%.... (you're limited by the granularity of the tuning). That saaaaid.... Imagine you didn't autotune (in this approach, autotune is poison, because it could change the cal between your own calibration and the measurement of interest), and used the watch crystal driven PIT to generate events, and timed them with input capture. Now you know from basic math how many clocks the TCB input capture *should* have measured if the clock was perfect, and you just measured the actual number of clocks - there's your correction factor! Obviously a bit of care is needed with the math (you're basically multiplying a uint32 by a uint32 (so you need to store it in a long long), and then dividing it by another uint32 - I wonder how many clocks an AVR would take to do that calculation? the multiplication isn't the problem, but dividing a 64-bit number by a 32-bit one, heh, you almost feel bad for the poor ALU) So yeah - just buy one of my boards, download DxCore and start playing around. I would also *love* to hear about your experiences with it and code samples relating to the 32-bit input capture!

There's no input capture library (yet) to my knowledge; but that's okay IMO, because there never was for the classic AVRs either!

[grandaspanna]

Ok, officially drooling, so I've ordered two of the DA boards. Given overseas postage, I got plenty of time to muse on what to do with them :-)

[windoze_killa]

I have just installed the 2.1.3. I now get this error when compiling.

Arduino: 1.8.13 (Linux), Board: "ATtiny3217/1617/1607/817/807/417, ATtiny3217, 20 MHz, 1.8V (5 MHz or less), Disabled, Disabled, EEPROM retained, Enabled (default timer), Closer to 5v"





Error resolving FQBN: getting

Error compiling for board ATtiny3217/1617/1607/817/807/417.


This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.

[pert]

I have just installed the 2.1.3. I now get this error when compiling.

Please do this:

• (In the Arduino IDE) click File > Preferences
• Check the box next to "Show verbose output during: > compilation
• Click "OK"
• Sketch > Verify/Compile
• After the compilation fails you'll see a button on the right side of the orange bar "Copy error messages". Click that button.
• In a forum reply here, click on the reply field.
• Click the </> button on the forum toolbar. This will add the forum's code tags markup to your reply.
• Press "Ctrl + V". This will paste the compilation output between the code tags.
• Move the cursor outside of the code tags before you add any additional text to your reply.

If the length of the output exceeds the forum's 9000 character limit, save it in a .txt file and post it here as an attachment. If you click the "Reply" button you'll see the "Attachments and other options" link that will allow you to make the attachment.

[windoze_killa]

That is the verbose output.

[pert]

OK. I have tried compiling for the same board, with the same custom board option as far as I can tell, and I don't get any error. This "Error resolving FQBN: getting" error is certainly strange. FQBN is the machine-readable identifier for an Arduino board and for your board selection should look something like this:

Code: [Select]

megaTinyCore:megaavr:atxy7:chip=3217,clock=20internal,bodvoltage=1v8,bodmode=disabled,eesave=enable,millis=enabled,resetpin=UPDI,startuptime=8,uartvoltage=5v,serialevent=no

So my recommendation is to uninstall and then reinstall megaTinyCore:

• Tools > Board > Boards Manager
• Wait for the updates to finish.
• From the list of boards platforms, select "megaTinyCore by Spence Konde".
• Click the "Remove" button.
• Wait for the removal to finish.
• Click the "Install" button.
• Wait for the installation to finish.
• Click the "Close" button.
• Try compiling again.

Hopefully that will magically fix whatever the issue is.

[windoze_killa]

If I regress and install 2.0.5 it compiles ok.

[pert]

What happens if update back to 2.1.3 again?

[windoze_killa]

It fails again. I have tried all the usual stuff. Rebooted too.

[pert]

Please post the verbose output from compiling the File > New sketch with megaTinyCore 2.0.5.

Maybe that will give us a clue.