Arduino Forum

Using Arduino => Microcontrollers => Topic started by: DrAzzy on Jun 25, 2019, 07:49 am

Title: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: DrAzzy on Jun 25, 2019, 07:49 am
https://github.com/SpenceKonde/megaTinyCore (https://github.com/SpenceKonde/megaTinyCore)
Download the core or sync github repo into your (sketchbook)/hardware folder: https://github.com/SpenceKonde/megaTinyCore/archive/v1.0.0_manual.zip.zip (https://github.com/SpenceKonde/megaTinyCore/archive/v1.0.0_manual.zip.zip)

The new megaAVR 1-series and 0-series ATtiny parts bring exciting new features to the ATtiny family. However, until now there has been no support for these parts on the Arduino IDE. This core provides Arduino IDE support for these new parts. This is the initial release, and we expect issues to come up, however, basic functionality is there, with support for the entire ATtiny 1-series and 0-series product line. Please alert us to any issues you encounter with the core.

These parts cannot be programmed via ISP - only via UPDI. An Arduino can be easily made into a UPDI programmer, see: https://github.com/SpenceKonde/megaTinyCore/blob/master/MakeUPDIProgrammer.md (https://github.com/SpenceKonde/megaTinyCore/blob/master/MakeUPDIProgrammer.md)

Some of the exciting features:
Flash up to 32k, SRAM up to 2k. 5 to 21 usable I/O pins. Runs from internal oscillator, with sufficient accuracy for UART (no crystal support) - core supports 20MHz, 16MHz, 10MHz, 8MHz, 5MHz, 4MHz and 1MHz. Up to 8 PWM pins, hardware UART, SPI, and I2C peripherals, on-chip DAC (core support coming soon), and more.

See the README (https://github.com/SpenceKonde/megaTinyCore) and part specific pages for more information, and the relevant datasheet for much more detail.

Supported parts:

24-pin (21 I/O pins)
3217, 1617, 817, 1607, 807
20-pin (17 I/O pins)
3216,1616, 816, 416, 1606, 806, 406
14-pin (11 I/O pins)
1614, 814, 414, 214, 804, 404, 204
8-pin (5 I/O pins)
412,212,402,202

This core requires the Arduino Official megaAVR board package to be installed (the one with Uno WiFi Rev. 2). This is the version for board manager installation.

Try it out, kick the tires, find the bugs we missed, and create github issues and/or post in this thread. Be sure to read the readme, which lists several known issues
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: BJHenry on Jun 25, 2019, 08:01 am
I saw this maybe a week ago, I've enjoyed watching more and more being added to it. I'm super excited that it is out in public now. Well done.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: DrAzzy on Jun 26, 2019, 06:47 am
It is now available through board manager as well! Same json file as ATTinyCore (see signature)
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: DrAzzy on Jul 09, 2019, 05:03 pm
Exciting news - Version 1.0.1 now available on board manager and for manual installation.

DAC support is now in.

A working Servo library is included (see caveats in documentation)

Timekeeping bugs in 1.0.0 are now fixed (a bug in micros() caused the millis timer to lose counts in 1.0.0).

Many improvements to documentation.

Breakout/development boards are expected to be available in my Tindie store before the end of the month (the designs are already in the hands of my manufacturing partner).

Please try it out and let me know how it works out for you all! These are some really awesome parts, and I hope that more Arduino people will start playing with them. For those of us who are thinking of releasing a product based on Arduino-programmed-AVR's, the megaAVR attiny's are particularly well suited because of their low prices compared to comparable classic AVR parts - even in quantities of 1, the bare parts are available from digikey et. al. for around $1 for the top parts in these product lines!
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: DrAzzy on Jul 26, 2019, 08:06 am
1.0.2 is now available!

Board manager and manual installs. Board manager no longer requires the official megaAVR board package, too (manual installs do require it, though).

This is mostly a bugfix release; you should install it if you've been playing with this - it fixes a few issues on specific parts, but most notably problems with analogRead() on pins numbered higher than 11.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: G2Li on Aug 06, 2019, 05:58 pm
Hi,

I am trying to program my attiny1617 with arduino uno, I have my uno connected via usb and attiny1617 in PCB connected the resistor and capacitor via dupont wires as mentioned above. I have selected 'arduino as jtag2updi' in 'Programmer option'.

 However when I click upload my sketch comes up with:

avrdude: jtagmkII_initialize(): Cannot locate "flash" and "boot" memories in description


Please help me, any ideas and solutions. Thanks

Lili


Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: DrAzzy on Aug 07, 2019, 12:57 am
Have you uploaded the jtag2updi sketch to your Uno, and then connected cap between Rst and Gnd?


avrdude: jtagmkII_initialize(): Cannot locate "flash" and "boot" memories in description

always shows up, and seems to be a spurious message - it may be something that *could* be fixed by changes to avrdude.conf, but because programming works, I haven't undertaken to fix it.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: DrAzzy on Aug 07, 2019, 01:36 am
Also, 1.0.3 is now released - this fixes serial on the 412/402/212/202 parts, and also adds the "tinyNeoPixel" and "tinyNeoPixel_Static" libraries that implement support for WS2812 ("NeoPixels") on megaTinyCore. See the full documentation here https://github.com/SpenceKonde/megaTinyCore/blob/master/megaavr/extras/tinyNeoPixel.md (https://github.com/SpenceKonde/megaTinyCore/blob/master/megaavr/extras/tinyNeoPixel.md)
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: G2Li on Aug 07, 2019, 11:43 am
It works !!!! 
I tested a  digital pin, I got an output signal form my attiny.  but the information avrdude: jtagmkII_initialize(): Cannot locate "flash" and "boot" memories in description always shows up.

Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: hansibull on Aug 07, 2019, 03:06 pm
Thanks for doing all this. The fact that you've supporting 25 new ATtinys is just incredible!

Do you think you'll be able to merge your changes to the NeoPixel library into the main Adafruit repo?
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: DrAzzy on Aug 07, 2019, 06:50 pm
Thanks for doing all this. The fact that you've supporting 25 new ATtinys is just incredible!

Do you think you'll be able to merge your changes to the NeoPixel library into the main Adafruit repo?
They would require a bit of modification, since the version that I include is tightly integrated with the core (plan is to include analogous version in ATTinyCore as well), in order to minimize flash usage at speeds below 16MHz. May do this in the future, but it is a low priority, and I have many high priority tasks in my queue.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: gaufowl on Sep 04, 2019, 12:45 am
I have a question regarding the instructions in your README. I am currently working on a computer that I have to do manual installs on. I have no internet access, but I can get files transferred to the computer. Your README states that the Arduino megaAVR board package must be installed using board manager. I have already successfully manually installed megaTinyCore (I believe). Can I just follow the same process with the megaAVR, or is there something special that the board manager does that I will be unable to do through the manual method? I am working with the 3216, if that matters at all. Apologies if this is a trivial question, I'm inexperienced with micro-controllers.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: DrAzzy on Sep 04, 2019, 02:51 am
A board manager installation will ALSO install the required 7.3.0 version of avr-gcc.

I do not know how to do this manually in a way that the IDE will correctly use.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: DrAzzy on Sep 04, 2019, 08:09 am
1.0.5 is out, with a few board manager fixes (actually, it's been out for a while).

I discovered something amazing last night!

Because the flash is memory mapped on these parts, YOU NO LONGER HAVE TO MANUALLY DECLARE THINGS PROGMEM NOR USE pgm_read_byte_near().

Anything declared const is not copied to the RAM, yet can be accessed in the same ways as any other variable (except of course that it can't be changed, but that's the case with anything declared const). This includes string literals, so the F() macro is not needed either.

Major win.

I also played around with pin interrupts without using attachInterrupt and wrote a little documentation page: https://github.com/SpenceKonde/megaTinyCore/blob/master/megaavr/extras/PinInterrupts.md (https://github.com/SpenceKonde/megaTinyCore/blob/master/megaavr/extras/PinInterrupts.md)
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: Kattiny1616 on Sep 20, 2019, 08:44 am
Hey DrAzzy, thank you so much for your help!

I am currently using the attiny1616 and I am trying to read data from the Bosch BMI160, using the Emotibit library (https://github.com/EmotiBit/BMI160-Arduino ). I wanted to ask you if that even works this way or do I have to read and write to the BMI160 through Wire.h. If I just try to use the library as is I get this error message:

Code: [Select]
C:\Users\keyan\Documents\Arduino\libraries\EmotiBit_BMI160\BMI160Gen.cpp: In member function 'int BMI160GenClass::i2c_xfer(uint8_t*, unsigned int, unsigned int)':

C:\Users\keyan\Documents\Arduino\libraries\EmotiBit_BMI160\BMI160Gen.cpp:120:38: error: call of overloaded 'requestFrom(int&, unsigned int&)' is ambiguous

     Wire.requestFrom(i2c_addr, rx_cnt);

                                      ^

In file included from C:\Users\keyan\Documents\Arduino\libraries\EmotiBit_BMI160\BMI160Gen.cpp:3:0:

C:\Users\keyan\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\1.0.5\libraries\Wire\src/Wire.h:63:13: note: candidate: virtual uint8_t TwoWire::requestFrom(uint8_t, size_t)

     uint8_t requestFrom(uint8_t, size_t);

             ^~~~~~~~~~~

C:\Users\keyan\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\1.0.5\libraries\Wire\src/Wire.h:65:13: note: candidate: uint8_t TwoWire::requestFrom(int, int)

     uint8_t requestFrom(int, int);

             ^~~~~~~~~~~

exit status 1
Error compiling for board ATtiny3216/1616/1606/816/806/416/406.


I would really appreciate your help!
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: DrAzzy on Sep 21, 2019, 05:31 pm
Will investigate. Wont be able to this weekend as I am out of town and didnt think I would be looking at any i2c devices, so didnt bring any.

Does that library work if you try to compile for the Uno WiFi Rev. 2 (from the official arduino megaavr board package)?
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: Kattiny1616 on Sep 22, 2019, 12:08 am
Hey Drazzy, thank you for your reply.

I will test the Uno Wifi Rev1 tomorrow and then report to you. I worked on the wire.h code the whole day and will continue tomorrow.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: DrAzzy on Sep 22, 2019, 01:08 am
Not the Uno Wifi Rev. 1 - that is not a megaavr board.

Uno Wifi Rev. 2 or Nano Every are megaavr boards. If you can check whether the same issue occurs there that would help me out. I suspect the same issue will happen there, since we just ganked the Wire library from that, and the peripherals are the same.

If the issue does NOT reproduce there, it would be helpful if you could post:
Code that reproduces the issue
Locations that you get any libraries not included with the core/IDE for it (so I can get the same libraries installed and test with those).
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: Kattiny1616 on Sep 22, 2019, 10:58 am
I tested the boards out.

First, I used the "Arduino Uno Wifi" board and the code was uploaded to the Arduino Uno with no issues.

Second, I used the "Arduino Uno Wifi Rev2" and I got the same issue as posted in my first post.

Third, I used the "Arduino Nano Every" and the same issue and in "Arduino Uno Wifi Rev 2" occurred.

This is the code to read out the BMI160 through i2c:

Code: [Select]
#include "BMI160Gen.h"

const int i2c_addr = 0x68;

int gx, gy, gz;// raw gyro values
float gForceX, gForceY, gForceZ; //tatsächliche g-Kräfte
int ax, ay, az; //Beschleunigungsrohdaten
float rotX, rotY, rotZ; //Rotation


void setup() {
  Serial.begin(115200);
  BMI160.begin(BMI160GenClass::I2C_MODE, i2c_addr);
  BMI160.setAccelerometerRange(2); //setzen der Range für den Beschleunigungssensor. Erlaubte Werte: 2, 4, 8, 16
  BMI160.setAccelRate(6);
  BMI160.setGyroRange(125);  // setzen der Range für den Gyro. Erlaubte Werte: 125, 250, 500, 1000, 2000
  BMI160.setGyroRate(6);
}


void loop() {
  // put your main code here, to run repeatedly:
  BMI160.readGyro(gx, gy, gz);
  BMI160.readAccelerometer(ax, ay, az);

  gForceX = (ax / 16384.0);
  gForceY = (ay / 16384.0);
  gForceZ = (az / 16384.0);

  rotX = gx / 262.4;
  rotY = gy / 262.4;
  rotZ = gz / 262.4;
 
  Serial.println(String(gForceX) + ";" + String(gForceY) + ";" + String(gForceZ) + ";" + String(rotX) + ";" + String(rotY) + ";" + String(rotZ)) ;
}
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: DrAzzy on Sep 22, 2019, 09:14 pm
Where do we get "BMI160Gen.h"?
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: Kattiny1616 on Sep 22, 2019, 09:30 pm
Hi DrAzzy, I am using the Emotibit library (https://github.com/EmotiBit/BMI160-Arduino). You have to import all the files into your Arduino library.

I wrote a code that manually writes and reads all the necessary registers of the BMI160 through the Wire.h library. My first few lines of code seem to work just fine, still if I could use the EmotiBit library that would ease my work dramatically.

If you want, I could post my code here.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: DrAzzy on Sep 22, 2019, 11:40 pm
This minimal example demonstrates the issue.

Code: [Select]
#include <Wire.h>
void setup() {
}
void loop() {
   unsigned int rx_cnt=10;
   Wire.requestFrom(0x20, rx_cnt);
}


Further investigation has revealed the cause of the issue - from Wire.h

Classic AVR:
Code: [Select]
    uint8_t requestFrom(uint8_t, uint8_t);
    uint8_t requestFrom(uint8_t, uint8_t, uint8_t);
    uint8_t requestFrom(int, int);
    uint8_t requestFrom(int, int, int);


megaavr:
Code: [Select]
    uint8_t requestFrom(uint8_t, size_t);
    uint8_t requestFrom(uint8_t, size_t, bool);
    uint8_t requestFrom(int, int);
    uint8_t requestFrom(int, int, int);



In both cases, these are all aliases of of the second one.

The problem arises when requestFrom() is called with an int as the first argument, and an unsigned int as the second one. This is done in the BMI160 library from EmotiBit

What happens?

size_t is an unsigned int.

So the compiler is looking for the best match for requestFrom(int, unsigned int) - but it can't choose between requestFrom(uint8_t,size_t) (which is the same as requestFrom(uint8_t,unsigned int) )
and
requestFrom(int,int)

In both cases one variable would need it's type converted - so it doesn't know which to choose.

In the case of classic avr, this is not ambiguous, because the choices are requestFrom(uint8_t,uint8_t), and requestFrom(int,int) - so the second one gets chosen, as it requires changing the type of only one of the arguments.

The newly standardized arduino API (used for megaavr, but not for classic avr) specifies for hardwareI2C the signature shall have size_t for the second argument (annoying, as it wastes memory, and the buffer length on existing arduino boards is short enough that a uint8_t would work)

I adjusted the signatures for all the variants of requestFrom to specify size_t as the type for the second argument. Fix is in github now, and will be in 1.0.6

Thanks for reporting this issue.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: Kattiny1616 on Sep 23, 2019, 12:27 am
Wow, thank you so much for your help and for the information!

How long does it take until the Arduino Board manager gets the update?

Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: DrAzzy on Sep 23, 2019, 06:23 pm
New versions show up in board manager when I do a release (well, within ~24 hours - I depend on Per to update the board manager json, and then I push the new board manager json to my website). Releases are generally done when the list of changes in the dev version looks big enough to justify it (based on magnitude of changes and severity of bugs fixed).

Thanks to the work of westfw, we're getting optiboot bootloaders soon (he said a few days on Sunday). I'm planning to do a release immediately before merging his bootloader changes (which will need some tire-kicking and documentation before I let them loose on the world), so I would say probably within the week.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: Kattiny1616 on Sep 24, 2019, 09:06 am
I just read through some documentation of the optiboot loader. Sounds pretty good. It should be compatible with the attiny1616, I saw that it is compatible with a lot of MegaAVR chips.

I'm so glad that there is such a great community around these chipsets. I am just starting to learn about them!
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: DrAzzy on Sep 24, 2019, 04:37 pm
I will be doing 1.0.6 release today. 1.0.6 with that fix will be avail in board manager within a day or so.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: DrAzzy on Oct 14, 2019, 10:12 am
Some exciting "coming soon" news from the land of megaTinyCore:
* Coming very soon: 1.1.0 release with SERIAL BOOTLOADER SUPPORT (optiboot) - this will also support disabling reset so it can be programmed like a normal (ex, Pro Mini) arduino, with autoreset, as well as an option to leave the UPDI/RST pin as UPDI (power-cycle the board to enter bootloader and upload w/in 8 seconds). I've been testing this out and it works great.

* 1.1.0 will also correct the sketch size output when using const variables (which unlike classic AVRs are stored in flash without being copied to RAM without using the PROGMEM keyword, and can be accessed without any special functions). The functionality isn't new, but previously the sketch size reported did not include these const's.

* Coming soon, new and slightly improved versions of the breakout boards in my Tindie store - this corrects the bad silkscreen. The 14 and 20 pin boards have an added breakaway mounting tab with 2 holes in it. The 24-pin boards have 2 mounting holes nearer the middle of the board (adding the tabs would have pushed the board past a key size limit and nearly doubled production cost). The 8 pin boards do not have mounting holes (this would have increased production cost ~50% due to increased board area). All of the new Rev. A boards will also have the autoreset enable solder bridge disconnected by default so I can bootload optiboot boards in place. Expect discounted versions of the 14, 20, and 24-pin bare breakout boards.

* Assembled boards pre-loaded with optiboot and UPDI pin set to work as reset will be available soon.

Less exciting news on megaTinyCore - I thought I'd released 1.0.6 for board manager 3 weeks ago (I mean, I did) - but I failed to add it to the board manager json file. I apologize for the inconvenience here; still working on getting it added (as I need per's help to generate that file)

Get excited!
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: BJHenry on Oct 14, 2019, 02:23 pm
Just so you don't feel like you're shouting into the void: I haven't had a chance to play around with this chips yet but I'm very excited to, and have been watching the development of this core with great interest.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: Kattiny1616 on Oct 14, 2019, 03:21 pm
Hey DrAzzy, that's pretty amazing!!! We are currently developing our hardware with the attiny1616 and you are a huge help! I'm actually really excited for your updates :)
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: Kattiny1616 on Oct 17, 2019, 10:38 am
Hello again, I have a small obstacle to overcome here and would appreciate your help.

I am using the attiny1616 to read data from a flex sensor and an IMU, low-pass filter the data and send it through bluetooth to my phone. I need at least 200 Hz but at the moment i only reach 140Hz and I don't see a way to minimize my code anymore to increase the transfer rate.

Question: is the attiny able to read, process and send data that fast? 
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: DrAzzy on Oct 23, 2019, 07:13 am
1.0.6 is now *actually* available. So much for getting 1.0.6 out way ahead of 1.1.0 so people didn't have to wait for fixes to the 1.0.6-fixed bugs while I got the bootloader stuff set up.

1.1.0 is essentially ready for release at this point. I have assembled 3216-based breakout boards with the autoreset circuit, bootloaded them with UPDI fused as reset, connected the solder pads to enable autoreset, and verified that you can program them over serial with the autoreset just like a normal part, and have them jump to app on POR rather than bootloader. And I can take a part without autoreset circuit, and load a different optiboot binary (with 8 second timeout and that runs on POR) and upload over serial by powercycling it, and still reprogram it freely over UPDI.

@kattiny1616 - Since I don't know the details of what you're doing, I couldn't say, but 200Hz doesn't sound crazy (though again, if you're doing tons of math, maybe?)

How are you talking to the bluetooth? Is it just a bluetooth serial module? If so, are you using it at a high enough baud rate to accommodate the data you want to send at 200Hz? This would be an easy gotcha, so thought I'd mention it.

Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: DrAzzy on Oct 26, 2019, 10:02 am
Okay, 1.0.6 release *actually* works now.

1.1.0 will also be getting the Logic library for working with the new CCL peripherals (Configurable Custom Logic)
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: robjordan on Nov 07, 2019, 04:40 pm
Would it be ok to post here with a newbie question about bringing up an Attiny1614 for the first time? I'm struggling and could really use some help with understanding what is and isn't working.

I bought a few 1614s and a clone Arduino nano (I'm more experienced with ESP8266 and ESP32, so I know the Arduino IDE but actually haven't used Arduino hardware before). After a bit of a struggle I am able to load sketches reliably on the nano. It came with the 'old' bootloader, so I have to select that non-default option, and has a ch341 USB controller, which I understand is different from the genuine arduino). I have it directly connected to PC via mini-USB cable. I've run the IDE on both Linux and Windows 10. I've got the jtag2updi installed.

I soldered the 1614 onto a breakout board, it and the nano are on a breadboard, and I've triple-checked connections between Nano and the 1614 breakout legs:
Nano 5V -> 1614 Vcc
Nano GND -> 1614 GND
Nano D6 via 4.7k resistor to 1614 UPDI

I've got a 10uF electrolytic between Gnd (-) and RST (+) on the Nano.
I've got a 100nF ceramic across Vcc and GND on the 1614.

If I understand the sequence correctly, the next step is to set the board type to Attiny1614... and Burn Bootloader. After some healthy-looking output, and the 'Cannot locate "flash" and "boot"' (which I understand to be normal) I get the following error:

Code: [Select]
avrdude: jtagmkII_reset(): timeout/error communicating with programmer (status -1)
avrdude: initialization failed, rc=-1
         Double check connections and try again, or use -F to override
         this check.

avrdude: jtagmkII_close(): timeout/error communicating with programmer (status -1)
avrdude: jtagmkII_close(): timeout/error communicating with programmer (status -1)

avrdude done.  Thank you.

Error while burning bootloader.


I've cut the avrdude command and run it from the command line with "-v -v" appended to get more detail, and I'm attaching that debug output.

I'm a bit lost on what (if any) communication is actually happening between the Nano and the 1614. Is the 1614 responding to anything, or is it completely unresponsive? What other debugging tips do you have. I know the answer is always 'check the wiring' and I'm happy to believe I've got something wrong but I'm a bit stumped right now.

Thanks very much in advance.
Rob
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: DrAzzy on Nov 08, 2019, 04:00 am
I've had another report of this issue. I am currently investigating and will let you know if I am able to reproduce it.

Can you let me know what OS this is an issue on?
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: robjordan on Nov 08, 2019, 11:24 am
I've had another report of this issue. I am currently investigating and will let you know if I am able to reproduce it.

Can you let me know what OS this is an issue on?
Assuming you are responding my post #32, I see this same behaviour on Windows 10 and Linux Mint.

Thanks
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: robjordan on Nov 08, 2019, 03:28 pm
I've done a bit more investigation using https://github.com/mraardvark/pyupdi. It's a bit easier for me to diagnose, because the recommended wiring setup loops Tx back to Rx and checks for commands echoed back. I can see now that the UPDI pin on the attiny1614 is remaining high during attempted serial transmissions, thus interfering with the echo of commands. I've checked for shorts between pins on the breakout board and there are none apparent to me. Maybe I've borked the chip... perhaps I'll try a second.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: DrAzzy on Nov 08, 2019, 05:00 pm
Interesting. It's not reproducing for me with manual install on attiny1614 on windows. Maybe there's an issue with the toolsDependencies pulling in a bad version of avrdude?
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: DrAzzy on Nov 10, 2019, 12:25 am
I'm not able to reproduce this issue with either manual or board manager installation.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: DrAzzy on Nov 14, 2019, 10:30 am
megaTinyCore 1.1.0 released!

The moment we have all been waiting for it here - Optiboot support on megaTinyCore. Optiboot is supported on all parts, as a normal serial bootloader. It can be uploaded with the UPDI pin still set to reset (in this case, you unplug and replug to start bootloader), or with the UPDI pin set to work as reset so the standard autoreset circuit can be used. Warning: In the latter case, you can no longer program the chip via UPDI, including to return it to it's original state - an HV programmer is needed. Be sure you know what you're getting into when you load the UPDI-pin-as-reset version of the bootloader. Note also the version you get with UPDI as reset does NOT run after power on reset, only external and software reset, and only for 1 second. Ie, like a normal pro mini or similar.

This release also introduces some other new features:
* U(S)ART pin selection from the tools menu for parts other than the 8-pin ones
* The Logic library for interfacing with the built-in configurable custom logic (CCL) units. Fixing the examples so they work on tiny parts was deferred to 1.1.1.
* Enhanced pinout diagrams and documentation
* Fix mEDBG on ATtiny416 Xplained Nano
* Fix EESAVE option, which was backwards
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: DrAzzy on Nov 18, 2019, 07:46 pm
1.1.2 is coming out tonight to fix a few issues reported within the past two days (since the 1.1.1 release) - in 1.1.0, compilation for all parts in board manager was broken (but not in manual install version). In 1.1.1, compilation for 24-pin parts was broken due to a typo introduced in 1.1.1.

Edit: 1.1.2 is now out for both board manager and manual installation.
Edit2: board manager json was briefly broken. It is fixed now.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: BR87 on Dec 02, 2019, 04:39 pm
hello, I find the subject very interesting, I tried to install  " jtag2updi " in an Arduino nano but I have an error message

C:\Users\CARPEN~1\AppData\Local\Temp\ccrQPW5r.ltrans0.ltrans.o: In function `main':

C:\Program Files\Arduino\hardware\arduino\avr\cores\arduino/main.cpp:43: undefined reference to `setup'

C:\Program Files\Arduino\hardware\arduino\avr\cores\arduino/main.cpp:46: undefined reference to `loop'

collect2.exe: error: ld returned 1 exit status


why?

1.1.2   installed

IDE arduino 1.8.10


thanks
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: pert on Dec 02, 2019, 05:19 pm
Unless you define your own main function (which I don't recommend), every sketch must contain a setup() and a loop() function. If you don't need any code in the function, you must still define it, but you can leave it empty.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: DrAzzy on Dec 02, 2019, 07:21 pm
I think you probably didnt follow the instructions for jtag2updi?

It's a weird sketch - it is a classical c program with a dummy sketch as a shim so it can be built on arduino. See the readme.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: BR87 on Dec 02, 2019, 11:57 pm
Ok ,I had not done this step   "Just copy all the files inside "source" to a new directory called "jtag2updi" inside your sketch main directory."

thanks


Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: BR87 on Dec 11, 2019, 10:31 pm
Hello, I'm having fun with my new attiny , I have a question, I use this chip to drive a motor with the PWM (attiny3216 PWM PC0 / 10), but the frequency is too low, I wanted to know if it was possible to change this frequency ?

thanks
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: DrAzzy on Dec 11, 2019, 10:55 pm
Hello, I'm having fun with my new attiny , I have a question, I use this chip to drive a motor with the PWM (attiny3216 PWM PC0 / 10), but the frequency is too low, I wanted to know if it was possible to change this frequency ?

thanks
Yes, it's possible - those pins are controlled by the Type D timer. The actual process of working with this timer is rather annoying - many of the registers change protected, and require the timer to be stopped to change them, so you have to briefly stop the timer, and use the PROTECTED_WRITE() macro to write to some of the registers. It's very possible - and you might find some of the other features of timer d useful for motor control. But the price is that you'll need to study the relevant section of the datasheet; the Timer D on the 1-series parts is probably the most complicated peripheral I've seen on an AVR. Just figuring out how to get normal PWM out of it was a battle for me. Good luck - it will be a challenge, but it is definitely possible. As always in the case of embedded peripherals, with great power comes great complexity.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: hansibull on Dec 12, 2019, 08:02 am
Not sure if it would help you in this case, but here's how analogWriteFrequency() is implemented on the megaAVR-0's (https://github.com/MCUdude/MegaCoreX/blob/fc1bea759b46474bc5d2108d8249b9f41ef3a68b/megaavr/cores/coreX-corefiles/wiring_analog.c#L206-L233). Just bear in mind that these do not have a type D timer, but rather type A.

It would be a nice feature to have in megaTinyCore too if you guys can figure out how to do it. A base PWM frequency of about 1 kHz is pretty much useless for anything else than driving LEDs.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: BR87 on Dec 12, 2019, 09:09 am
thanks, for your answers, in a more general question is it possible to change the PWM frequency of timer A or B? if you have any idea how to do it, my skills are not up to what I want to do with this new attiny!

thanks
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: DrAzzy on Dec 12, 2019, 02:01 pm
The issue with timer A is that on megaTinyCore, we use that for millis too, so adjusting timer A frequency is problematic (the tinies have one, sometimes two timer B's, so we cant use the timer B for millis because then we couldn't use tone). Iirc there was some other issue with changing the prescaler on the timers, I think the type B timers don't have a separate prescaler ftm the type A timer?

I think using the type D timer is probably the right route, I'll just be an adventure reconfiguring it. It's got all sorts of features intended to make controlling motors easier like programmable dead time generator and stuff
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: DrAzzy on Jan 24, 2020, 09:36 pm
megaTinyCore 1.1.5 now available

This adds the ability to use the RTC timer as the clock source for millis() timekeeping. This doesn't provide micros(), but on the upside, it can be used to keep millis() updated in standby sleep (which is nearly as power efficient as power down - mfg. spec 0.7uA) and all of the other timers can be "taken over" for other uses. Note that using standby sleep in this way requires small modifications to how you put the chip to sleep to ensure that the millis timer interrupt does not wake the chip up, there is information on this in the README which will be expanded in a future update.
This also fixes the option to disable millis entirely which was broken by a typo in 1.1.3, and provides some further improvements to flash usage and expands the part-specific documentation.
Available via board manager, or for manual installation from https://github.com/SpenceKonde/megaTinyCore/releases/tag/1.1.5_manual

I have also neglected to announce 1.1.4 - this expanded the millis/micros menu to allow you to pick which of the timers on the chip is used for millis/micros, as well as significant improvements in flash usage, particularly for the Wire library. Of course, some of these have tradeoffs. As of 1.1.5 the timer options for millis/micros are:
Default (TCA0 on 20 and 24 pin parts, TDC0 on smaller ones that have TDC0)
Disabled
TCA0
TCD0 (1-series only, takes out the two extra PWM pins on the 20 and 24 pin parts, hence why it's not default there)
TCB0 (takes out Tone, and on everything except 1-series with 16k of flash or more (hence the second timer), servo as well)
TCB1 (only present on 1-series parts with 16k of flash or more)
RTC (no micros, only millis)
RTC with external 32.768khz crystal (no micros, not available for 8-pin parts, requires UART to be moved to alternate pins; not recommended)

If you want to do something that requires taking over a timer, this gives you the freedom to move millis/micros timekeeping to a different timer. TCD0 is particularly appealing on the 1-series parts, because it has a separate prescaler, whereas TCBn uses TCA0's prescaler settings.



One minor bug in 1.1.5 - the option for RTC with external watch crystal is not supported on 8-pin chips, but the core still shows the menu option. Do not use this setting on 8-pin parts. This option will be removed from the menus in 1.1.6.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: Kattiny1616 on Jan 31, 2020, 07:31 pm
Hi guys

we are using an Attiny1616 together with an RN4871 BLE chip to send the data. The Board Attiny1616 is part of the Arduino IDE, thus I thought I ask my questions here.

We have a few sensors connected to the attiny1616, like a flex sensor and an IMU. We want to send the gathered data as fast as possible through the RN4871 to our phone.

We connected the hardware serial pins of the attiny1616 and RN4871.

The problem that we run into is that data packages sent from the RN4871 arrive cut off on our phone. (we test the packages with a BLE Scanner). The data is not only cut off but we also lose some of the data. If we set a delay into our code then the sending works.

What is the best way to make sure that the RN4871 sent all the data in the buffer before accepting the next data package from the attny1616?

If some kind of code is requested, I will happily provide something. At the moment, I don't see the need for a code, since it is a fundamental question.

Thanks all!


Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: pert on Jan 31, 2020, 07:37 pm
Kattiny1616 has created a dedicated topic for their question:
https://forum.arduino.cc/index.php?topic=662095 (https://forum.arduino.cc/index.php?topic=662095)
To avoid wasted time due to duplicate efforts, let's confine the discussion on this subject to the dedicated topic.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: Kattiny1616 on Jan 31, 2020, 11:33 pm
Sure! Thanks already.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: DrAzzy on Feb 01, 2020, 09:12 pm
The uart on the megaavr parts seems to behave badly for the first few hundred milliseconds after it is enabled. I have not been able to figure out why.  Could this be related to your issue?
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: pert on Feb 01, 2020, 09:30 pm
There was a problem like that on the Uno WiFi Rev2, which I reported here:
https://github.com/arduino/ArduinoCore-megaavr/issues/37 (https://github.com/arduino/ArduinoCore-megaavr/issues/37)
and was fixed by the patch linked from that issue.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: pjeran on Mar 08, 2020, 06:48 pm
First DrAzzy - thanks for the development of these uCs!

Crazy to see how much functionality is packed into such a low cost processor.

I have a question about the RTC - I am trying to count how many button presses there are in a 5 second interval using the lowest amount of power possible.

I have set up an interrupt using the RTC to give me an interrupt every 1 seconds and only processes the information when I have seen 5 occurrences.

I have another interrupt set to trigger when a button press is sensed, however, I am dealing with bounce.  Within the ISR I was trying to see if there had been X milliseconds between button presses, but it does not appear that millis increments when asleep even though I am using the RTC.

Did I misunderstand that millis would update even when asleep if I was using the RTC?

Thanks,

Paul


Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: DrAzzy on Mar 08, 2020, 11:07 pm
If you are using the RTC as millis timer source (tools -> micros/millis -> RTC), millis() will keep count while sleeping (or it should! Is it not? What sleep mode are you using? I think there is one that turns off everything regardless, and another one that leaves on selected peripherals, like the RTC. I have not done much testing with sleep on these yet, so I don't have a definite answer... It is possible that I missed something.

Were you using the periodic interrupt timer part of the RTC, not the RTC part of the RTC? (if you used the RTC part, that would break the millis on RTC functionality) Be aware that if RTC is set as millis timer source, it will configure the RTC clock source and prescaler; be sure you don't change that, and that the interval you chose for the PIT interrupt is correct for that prescaler.

Your overall setup seems rather strange, and I'm confused about what you're trying to do...
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: pjeran on Mar 09, 2020, 05:10 am
thanks for the help, new to this part and some of the new functionality

I am using the RTC as the milis source.  I grabbed the code from your github - Using the Real Time Counter (RTC) as the start for my code.  My understanding is that it uses the interrupt timer part of the RTC.

I changed the sleep mode to set_sleep_mode(SLEEP_MODE_STANDBY) to keep peripherals like the RTC going.

My project is that I have an anemometer with a switch that triggers once a revolution.  Instead of leaving the uC on continuously, I wanted to put the uC to sleep and use a pin interrupt on the switch to count the milliseconds between triggers to calculate the wind speed.  In addition I wanted to take a running 5 second average of the wind speeds using the interrupt from the RTC to count seconds for assisting in calculating the average.

I am continuing to do some tests to dig deeper and any suggestions are welcome.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: DrAzzy on Mar 09, 2020, 05:39 am
Definitely keep me posted on this - as I said, I have barely worked with sleep/power save on these parts (generally, I don't do much low power stuff - most of my projects would be classified as home automation).

IIRC I leave the prescaler at 1 when using RTC for millis, so that should be fine.

Some of the first things I would recommend:

First, don't use any sleep, just do some sanity checks - read out the registers after you set them and make sure it's not refusing to let you change them because the RTC is running (I don't think the RTC does this - some peripherals on the megaavrs do - TCD in particular - but I don't think the RTC is one of them).

Then, make the PIT ISR toggle a pin (eg, PORTA.OUTTGL=2; or whatever pin you want - making sure you've set that pin as OUTPUT), and with an LED and resistor on the pin, make sure it blinks the LED.

Then, see if everything else works without getting sleep involved - are both interrupts working together, is the speed being counted, etc.

Make sure millis() isn't actually busted with RTC as millis source, too - I know it worked in my quick tests, but that feature isn't even in a release yet; there could totally be bugs with it.

Finally, add sleep (leave the blinky toggle in place - it's a good debugging aid) and see if that breaks it.

One other thing to be very aware of when using RTC as millis and sleep - I know I mention this, but is very easy to forget: the millis interrupt will wake the part every so often to increment millis. You need to make sure the rest of your code is smart enough to go back to sleep when this happens (same with your other interrupts, but I suspect you are keenly aware of that much)
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: grandaspanna on Mar 17, 2020, 11:45 am
I need some help migrating some code from an attiny85 to a attiny1616 (target may change, but I think it's generic to the 1-series parts).

I want to setup an ISR every millisecond. Currently, I do this for the attiny85:

OCR0A = 0xAF;           
TIMSK |= _BV(OCIE0A);


and then:

SIGNAL(TIMER0_COMPA_vect)
{
  current_millis = millis();
  f1light.Update(current_millis);
 
}


How do I do the equivalent with the megaTinyCore?



Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: DrAzzy on Mar 20, 2020, 04:19 am
megaTinyCore 1.1.6 is now available!
This is a pretty exciting release, especially for the many people who have asked about reconfiguring the type A timer, TCA0, to generate specialized PWM. Unlike the classic AVRs, where each timer can select prescaling independently, the type B timers on megaAVR can only use either 1, 2, or what TCA0 is using. Previously (being based on official core) those timers were set to use the TCA0 clock, prescaled by 64. So even if you set a TCB to be the millis timekeeping source, you still couldn't change the TCA0 prescaler to generate different output frequencies. Similarly, frequencies generated by tone() would be wrong. Both of these dependencies have been removed in 1.1.6. The included Servo library, however, still doesn't work if the TCA0 prescaler was changed in 1.1.6, but it has already been fixed for 1.1.7.

To celebrate the newfound usability of TCA0 we now have a guide on doing this sort of thing, with several examples:
https://github.com/SpenceKonde/megaTinyCore/blob/master/megaavr/extras/TakingOverTCA0.md (https://github.com/SpenceKonde/megaTinyCore/blob/master/megaavr/extras/TakingOverTCA0.md)

As a result of these changes, tone() can also generate frequencies much lower than were previously possible. Servo and tone() will preferentially use TCB1 and TCB0, respectively, on parts with both (1-series parts with 16k or 32k of flash), unless their preferred one is used for millis. Thus, Servo and tone can coexist on those parts, or one or the other can be used if you set millis to use one of the type B timers.

When using Optiboot, you can now choose choose to set the UPDI pin as an I/O pin - like setting it to act as reset, this prevents further UPDI programming, If this is done, the bootloader image used will run for 8 seconds after power is applied (and after a software reset), like when Optiboot is used with that pin set as UPDI.

The long-broken Logic library, a wrapper around the CCL peripherals, is now properly supported. The documentation has been corrected to point out caveats that apply to the ATtiny parts. Additionally the examples have been expanded to describe the behavior as relates to the ATtiny parts as well, including examples of how to use the Event System (EVCTRL) to work around the fact that IN0 for CCL0 is on PA0 which is the UPDI/RESET pin which is normally not usable due to it's use in either programming (either via UPDI or to reset into bootloader).

There are also some other lesser bug fixes:
* Serial will no longer output gibberish if data is sent just after Serial.begin().
* The issues with disabling the DAC via the menu for 14-pin and 20-pin parts have been fixed.
* pulseIn() now honors the timeout value when no pulse is detected (previously in all versions, including official AVR boards,, this expired in 11/16ths of the specified time, though pulse times were correct).
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: DrAzzy on Mar 20, 2020, 06:04 am
I need some help migrating some code from an attiny85 to a attiny1616 (target may change, but I think it's generic to the 1-series parts).

I want to setup an ISR every millisecond. Currently, I do this for the attiny85:

OCR0A = 0xAF;           
TIMSK |= _BV(OCIE0A);


and then:

SIGNAL(TIMER0_COMPA_vect)
{
  current_millis = millis();
  f1light.Update(current_millis);
 
}


How do I do the equivalent with the megaTinyCore?


Okay, so several things come to my mind - I would appreciate answers to as many as possible so I can help out further if it's an x-y problem....

1. What are you doing with that data? ie, what does f1light.Update() do with it? That seems pretty crazy.

2. That is a very strange approach (and it's also off from 1ms, too - it's 1.024ms, assuming it's running at 16MHz - and millis() compensates for that - so sometimes the values it reads will by 2ms ahead of the last one) - Was that value picked arbitrarily to be in the middle of the millis cycle?

3. Assuming it really does make sense to have an interrupt running every ms, and you don't need PWM from timer0.... On the T85, with my ATTinyCore with millis disabled from the submenu:

Declare globally:
Code: [Select]

volatile unsigned long current_millis=0;


In setup:
Code: [Select]

TCCR0A=(1<<WGM01)|(1<<WGM00); //No PWM channels turned on
TCCR0B=(1<<WGM02)|(1<<CS01)|(1<<CS02);
//prescaler 64, fast PWM with OCR0A as TOP
OCR0A=249; //Overflow every 250 counts, for 1 overflow per 1ms....
TIMSK=1<<TOIE; //enable interrupt


And the ISR:

Code: [Select]

ISR(TIMER0_OVF_vect) { //will error if millis not disabled. ISR() same as SIGNAL()
current_millis++;
f1light.Update(current_millis); //whatever this does?!
}
[code]

But anyway, that was just a more reasonable approach at first glance compared to what you did...
All that said, assuming the goal is conceptually sound....

On a megaavr tiny:

Similarly, suggest disabling millis, megaTinyCore also has menu for that...

Assuming you kill builtin millis and use your own declare globally:
[code]
volatile unsigned long current_millis=0;




In Setup:
Code: [Select]


//TCB0.CTRLA=0; //no prescale, disable.
//TCB0.CTRLB=0; //uhh... yup, periodic interrupt mode is all zeros in cntmode, and none of the others apply.
//Commented out because on my core, assuming megaTinyCore 1.1.6+ with millis disabled or not using a TCB, these registers aren't touched by initialization.

TCB0.CCMP=(F_CPU/1000)-1; // (20000 for 20MHz, 16000 for 16MHz)
TCB0.INTCTRL=TCB_CAPT_bm;
TCB0.CTRLA=TCB_ENABLE_bm;



And the ISR:
Code: [Select]

ISR(TCB0_INT_vect) {
current_millis++;
f1light.Update(current_millis); //whatever this does?!
TCB0.INTFLAGS= TCB_CAPT_bm; //I almost forgot, super important - megaavrs don't clear interrupt flags for you!
}


Actually, hm - I just realized a way to make my core's millis timing better when using a TCB basically do that for TCB0... okay, maybe posting this giant thread WAS worth it!






Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: DrAzzy on Mar 20, 2020, 08:53 am
megaTinyCore 1.1.7 is now available!

This fixes a bug with RTC as millis source introduced in 1.1.6, as well as fixing the broken behavior with tone not moving to TCB1 if that exists on the part and TCB0 is used for millis. It also brings the fix for Servo, so that it can be used even if your sketch changes the TCA0 prescaler.

In the process I made TCB as millis source more efficient - the ISR and calls to millis are lightning fast now, and micros is faster too.

I swear, these ifdefs will be the death of me...
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: DrAzzy on Mar 21, 2020, 01:43 am
And again...

megaTinyCore 1.1.8 is released and available for board manager. It fixes a critical issue that prevented use of TCA0 as timing source.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: grandaspanna on Mar 21, 2020, 01:11 pm
Thanks so much for the consideration!

1. What are you doing with that data? ie, what does f1light.Update() do with it? That seems pretty crazy.
The scenario is basically a blinking LED (isn't it always?). Based on the duty cycle of an inbound PWM, which I'm measuring with interrupts, I vary the duty cycle of an output pin, in single-digit Hz range. The input value changes the on/off values from say 950/50 through to 100/150 (in milliseconds). The method in the above checks to see how much time has passed in the current state and then flips it when elapsed. Pinpoint timing is not required +/- several milliseconds would be fine for the output. The input timing is a little more crucial, where a PWM pulse is between 1000 and 2000 microseconds.

I'm intending on running the chip at 10 MHz with the internal oscillator @ 5V. The current attiny85 circuit runs fine at 8MHz.

Quote
2. That is a very strange approach (and it's also off from 1ms, too - it's 1.024ms, assuming it's running at 16MHz - and millis() compensates for that - so sometimes the values it reads will by 2ms ahead of the last one) - Was that value picked arbitrarily to be in the middle of the millis cycle?
The value was randomly lifted from some other code to run the routine once per ms cycle, or so I've understood it. As per above, the scenario is decorative, so precision timing is not crucial.

Quote
3. Assuming it really does make sense to have an interrupt running every ms, and you don't need PWM from timer0.... On the T85, with my ATTinyCore with millis disabled from the submenu:
I don't really need the routine to run every ms really, and I think from your example, I could use the B timer to trip every 10-20 ms with probably no noticeable difference in function. I don't need PWM support directly, but I am using interrupts to track an incoming PWM signal (switching the interrupt between rising and falling edges).

Quote
Code: [Select]


//TCB0.CTRLA=0; //no prescale, disable.
//TCB0.CTRLB=0; //uhh... yup, periodic interrupt mode is all zeros in cntmode, and none of the others apply.
//Commented out because on my core, assuming megaTinyCore 1.1.6+ with millis disabled or not using a TCB, these registers aren't touched by initialization.

TCB0.CCMP=(F_CPU/1000)-1; // (20000 for 20MHz, 16000 for 16MHz)
TCB0.INTCTRL=TCB_CAPT_bm;
TCB0.CTRLA=TCB_ENABLE_bm;


I think I understand TCB0 isn't otherwise used unless I use <servo>. Is that correct? Is millis still working normally in TCBA?

If that's the case, I think the periodic interrupt on TCB0 should do the trick. Is there a default pre-scale for TCB0, or is it safer to explicitly assign one? (oops, I think your example covers that).

For no real reason, here's a picture of the AT85 board (lower) and the 1616 board (upper). The 1616 will allow for easier programming and the additional I/O opens up some possibilities. The newer board has a dual mosfet with separate outputs as pads on the bottom.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: grandaspanna on Mar 25, 2020, 03:47 am
Again, thanks for the pointers. I have some code that seems to suit my purpose so far.

Here is my baseline. In setup():

TCB0.CTRLB=0; // periodic interrupt mode
TCB0.CCMP = 50000; // 100Hz for a 10MHz clock, based on the DIV2 below
TCB0.INTCTRL=TCB_CAPT_bm;
TCB0.CTRLA= TCB_CLKSEL_CLKDIV2_gc | TCB_ENABLE_bm;


And the ISR:

ISR(TCB0_INT_vect) {
  //current_millis++;
  if(led_status)
    digitalWrite(PIN_PA4,HIGH);
  else
    digitalWrite(PIN_PA4,LOW);
   
  if(millis() - last_time > target){
    led_status = !led_status;
    last_time = millis();
  }
  TCB0.INTFLAGS= TCB_CAPT_bm; //clear interrupt flag
}


Anything bad about this approach?
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: concon on Mar 27, 2020, 04:36 pm
Attiny1614 in 1 Mhz., I want to run in i2c at 100kHz, but it seems impossible, it Is there a way?
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: pjeran on Mar 28, 2020, 05:11 am
Update on the RTC and millis updating when in standby.

I can confirm that millis does update while sleeping, I was having an issue with a very noisy switch that my normal 15mS debounce was not addressing.

Thanks again for the core.

Paul
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: DrAzzy on Apr 03, 2020, 04:12 am
megaTinyCore 1.1.9 released - big millis/micros fixes!

This change brings a huge number of enhancements and fixes relating to the millis timekeeping functions. Previously, at 20/10/5 MHz, micros() was wrong with TCA0 or TCD0 as millis source (it would undercount, and then jump forward when the interrupt fired), and there was a slow drift on all timekeeping when TCD0 was used. Both were due to integer-math that had not been caught previously. These have been fixed. The timer settings used have been changed for some of the slower clock speeds to improve various parameters on those configurations. Performance of micros() has been slightly improved (mostly back to what it was before the above changes) and micros() now returns the closest time to when it was called possible.

The changes to timer configurations are summarized here in google sheets: https://docs.google.com/spreadsheets/d/1W6XAChKxozjN87hF34xwsb6TCKHA1KMztx8wL_UbLmk/edit?usp=sharing (https://docs.google.com/spreadsheets/d/1W6XAChKxozjN87hF34xwsb6TCKHA1KMztx8wL_UbLmk/edit?usp=sharing)

There is now a document included with the core that describes the timers on these parts and how they are used by the core: https://github.com/SpenceKonde/megaTinyCore/blob/master/megaavr/extras/PWMandTimers.md (https://github.com/SpenceKonde/megaTinyCore/blob/master/megaavr/extras/PWMandTimers.md)

This update also brings a few unrelated changes.

The EEPROM library has been enhanced to allow writing to the "user row", an extra page of flash that these parts have.

When the Servo library was modified to not depend on the TCA0 prescaling, the "trim" duration used to correct for the time taken to call digitalWrite() was not changed to be consistent with this (as an aside, it was also wrong to begin with). The Servo library also now does not use the prescale of 2 when run at 10MHz or less, which should make the output ever-so-slightly smoother with slower clock speeds.

The Wire library can now take up to three arguments when used in slave mode; the first is, as always, the slave address, the second is a bool; if true, it will also react to general call messages, and the third is put into the TWI0.SADDRMSK register, which can either act as a second address, or mask off specified bits of the address allowing it to respond to any address that matches the unmasked bits (like how some AT24-series EEPROMs use some of the device address bits as the high bits of the memory address). These new arguments are optional.

Finally, the programmer included on the Xplained Pro demo boards is now supported.

Next up is getting a bit more of an understanding of sleep and adding the planned megaTinySleep library
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: DrAzzy on Apr 03, 2020, 04:17 am
Attiny1614 in 1 Mhz., I want to run in i2c at 100kHz, but it seems impossible, it Is there a way?

As far as I can tell it should work? I haven't played with I2C enough to comment on that - certainly not under unusual operating conditions like 1MHz system clock (why do so many people want to do things at the minimum supported clock rate?! I have never understood this...). The datasheet doesn't specify a minimum system clock for a given TWI SCL clock, but there certainly must be one.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: DrAzzy on Apr 11, 2020, 06:11 pm
Want free ATtiny breakout boards?

Orders for a new rev. of the megaavr ATtiny breakout boards is going out before the end of the month. If you have suggestions for improvements I should make in the Rev. B, let me know! If I use your suggestion, you will get FREE copies of the new board! Or, if you prefer, twice as many free copies of the existing version.

These are the boards (disclosure: Obviously, these are items from my own store)
8-pin megaavr tiny breakout board (https://www.tindie.com/products/drazzy/attiny412similar-breakout-board-bare-board/)
14-pin megaavr tiny breakout board (https://www.tindie.com/products/drazzy/attiny1614similar-breakout-board-bare-board/)
20-pin megaavr tiny breakout board (https://www.tindie.com/products/drazzy/attiny3216similar-breakout-board-bare-board/)
24-pin megaavr tiny breakout board (https://www.tindie.com/products/drazzy/attiny3217similar-breakout-board-bare-board/)

(number of free boards depends on how insightful and valuable your suggestion is)
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: dlloyd on Apr 11, 2020, 06:41 pm
Awesome! I'll place an order for the 8-pin version ASAP!
I do have a $0.00 suggestion...replace R1 (4.7K) with something lower (i.e. 2.2K).
Regards,
dl
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: Paul_N on Apr 13, 2020, 09:55 pm
Hi Dr Azzy --

Thanks for creating the megaTinyCore and for making these boards available.

I have one suggestion to offer for your next board rev.

Please consider inserting a set of solder bridge pads in the path between the output of the 1117 regulator and the VCC net, to provide a means to isolate the regulator output from the miocrocontroller, just like the isolation pads you have in your reset circuit that allows UPDI/RST to be isolated from D2 anode net when the solder bridge is removed.

Thank you,


Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: DrAzzy on Apr 15, 2020, 01:06 am
Awesome! I'll place an order for the 8-pin version ASAP!
I do have a $0.00 suggestion...replace R1 (4.7K) with something lower (i.e. 2.2K).
Regards,
dl
Thanks - I'm looking into this. I thought I was copying some official guidance when I picked 4.7K, but I can't find any official source now that I'm looking - and it looks like most people are using much smaller resistors, too. Do you have any thoughts on what the lowest value I could safely use would be?

I've got some ideas that could capitalize on this to improve the experience with optiboot/autoreset - I'm hoping it will be possible to make the autoreset circuit combined with ersatz reset and the fact that the UPDI pin has been found to work as a basic input when still set as UPDI to reset the chip into optiboot...

Planning to get your order shipped out today (or what I assume is your order) - thanks for the order!

Regarding it being a $0.00 change, I'd say it's worth something, considering the potential impact. As it happens, I also now have your mailing address anyway >.>


Hi Dr Azzy --

Thanks for creating the megaTinyCore and for making these boards available.

I have one suggestion to offer for your next board rev.

Please consider inserting a set of solder bridge pads in the path between the output of the 1117 regulator and the VCC net, to provide a means to isolate the regulator output from the miocrocontroller, just like the isolation pads you have in your reset circuit that allows UPDI/RST to be isolated from D2 anode net when the solder bridge is removed.

Thank you,

Thanks for the suggestion. I'm a bit unclear on what your objective is here, can you clarify?

The current jumper is between the RST/UPDI pin, and the autoreset circuit. The former is connected directly to the UPDI/RST pin on the header on the long edge of the board, and to the 3-pin UPDI header through the excessively-high-value resistor mentioned above; the latter is the part with the diode, pullup, and capacitor to DTR.

So disconnecting the current RST_EN solder bridge should do the trick if you just want to make sure that the diode is not connected between the UPDI pin and Vcc.

Or am I misunderstanding something?

One other thing to note - If the cap between DTR and UPDI is connected, you need the diode there, because otherwise when DTR is released, the brief high voltage pulse on the UPDI pin could be mistaken for the pulse to start HV programming mode (some of the tinyAVR 0-series and 1-series parts require the KEY to be sent shortl after the HV pulse, others, it seems do not)
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: dlloyd on Apr 15, 2020, 06:55 am
Quote
Thanks - I'm looking into this. I thought I was copying some official guidance when I picked 4.7K, but I can't find any official source now that I'm looking - and it looks like most people are using much smaller resistors, too. Do you have any thoughts on what the lowest value I could safely use would be?
I've been using 1K without any issues on a breadboard with 6" leads. Mainly, with the HV programmer, the 1K and diode is mainly to protect the Nano's pin. Lots of information with series terminating SPI signals. One reference I read used 330 ohm series resistance with SPI @ 4MHz.

Quote
I've got some ideas that could capitalize on this to improve the experience with optiboot/autoreset - I'm hoping it will be possible to make the autoreset circuit combined with ersatz reset and the fact that the UPDI pin has been found to work as a basic input when still set as UPDI to reset the chip into optiboot...
I've tested the Attiny1604 with ersatz reset on PB0 connected to the onboard DTR reset circuit and it worked great. Right now I'm just using the UPDI as reset because of the quick startup (about 4.5ms) when powered up. Luckily, this falls within the 8.8ms I/O protection enable, allowing me to experiment with some new ideas.

Quote
...(some of the tinyAVR 0-series and 1-series parts require the KEY to be sent shortl after the HV pulse, others, it seems do not)
Oh, If you have one of these, I'd love to do some tests with it!
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: DrAzzy on Apr 15, 2020, 10:38 pm
I've been using 1K without any issues on a breadboard with 6" leads. Mainly, with the HV programmer, the 1K and diode is mainly to protect the Nano's pin. Lots of information with series terminating SPI signals. One reference I read used 330 ohm series resistance with SPI @ 4MHz.
I've tested the Attiny1604 with ersatz reset on PB0 connected to the onboard DTR reset circuit and it worked great. Right now I'm just using the UPDI as reset because of the quick startup (about 4.5ms) when powered up. Luckily, this falls within the 8.8ms I/O protection enable, allowing me to experiment with some new ideas.
Oh, If you have one of these, I'd love to do some tests with it!
8.8ms protection enable???

I am pretty sure I do have such a part (I have almost the entire tinyAVR 0-series and 1-series product line), but I have no idea which parts have it!
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: dlloyd on Apr 15, 2020, 11:22 pm
Quote
8.8ms protection enable???
Yes (from the Attiny1606 datasheet) ...

30.3.2.4 Output Enable Timer Protection for GPIO Configuration When the RESET Pin Configuration (RSTPINCFG) bits in FUSE.SYSCFG0 are 0x0, the RESET pin is configured as GPIO. To avoid the potential conflict between the GPIO actively driving the output and a12V UPDI enable sequence initiation, a timer protection is disabling the output enable for a minimum time of 8.8 ms after each System Reset.

Quote
I am pretty sure I do have such a part (I have almost the entire tinyAVR 0-series and 1-series product line), but I have no idea which parts have it!
Ah, no problem.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: DrAzzy on Apr 17, 2020, 06:33 am
2.0.1 is released!

In pursuit of the goal of eliminating unnecessary tools submenus (which presented problems for sketch maintenance, because submenu settings are not saved with the sketch), the tinyNeoPixel library is no longer a menu option, instead, there are three copies of the library, one for each port - I realize this will break existing sketches (was intended for 2.0.0), but having the sketch require specific submenu options also broke sketches.

Now the only tools submenus are for things that are used to control fuses (which require burn bootloader to set), the clock speed (which in theory is supposed to, but in reality only requires burn bootloader to switch between 16MHz derived clocks and 20MHz derived ones)), and the millis/micros timer, which has to be a submenu because it controls which ISR is defined for millis timekeeping.

Additionally, several bugs relating to the analog references and the DAC introduced by 2.0.0 and 1.1.10 were turned up in testing - this is now fixed. Note also that the EXTERNAL reference option is not present on as many parts as I thought it was - I only know for certain that it's on the "good" 1-series tinies, but existing documentation and header files are unclear about whether it might be present on other chips - so there is also an EXTERNAL_EXPERIMENTAL analogReference() option, available on all parts that don't have , which will try to set the appropriate bits, whether or not the header file says it's there,

Finally, inconsistencies in treatment of the EESAVE fuse for Optiboot boards was fixed - now it is not enabled for these board definitions (previously some had it, and some didn't). Thus, burn bootloader will always clear the EEPROM (and as always, optiboot uploads won't touch the EEPROM - though note that the version of Optiboot included with the core does support EEPROM writes (though the IDE does not have this functionality)
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: Paul_N on Apr 20, 2020, 09:57 am
My suggestion was intended to provide a means of isolating the regulator from the microcontroller, for those cases when the microcontroller might be powered by two AA cells.  This would be similar to what Arduino did with the Pro Mini.  See Arduino Pro Mini schematic excerpt below

(http://ad7i.net/images/pro-mini-power-isolation.jpg)

I realize that one could simply not assemble the regulator on the board in order to avoid the regulator for battery powered situations.   But I often repurpose prototyping boards several times over their life, so a simple means to isolate the regulator from the VCC net is something that I would find useful.

Best wishes,

Paul
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: DrAzzy on Apr 20, 2020, 05:56 pm
Got it, that makes sense. I'll add two more jumpers - one to isolate the regulator/power supply circuit, and one to isolate Vcc on the FTDI connector. Heck, probably should add same for the UPDI connection, too.

(when I'm running on battery, I assemble the boards in what I sell as the "no regulator" version, where I put a jumbo SMD resistor between Vin and Vout on the regulator outline, no input cap (output cap serves as board-scale decoupling), but with the PTC fuse present so a short in downstream circuit won't short the battery, which in turn would either damage the battery holder (for AA's - if they're fresh, shorted AA's will generate enough heat between the battery itself and the connection between the wires and springs that contact the board to melt the plastic on the battery holder), or start a fire (for LiPo batteries, if the protection circiit that the cheap chinese manufacturer swears up and down is present actually isn't)).

Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: DrAzzy on May 03, 2020, 02:58 pm
megaTinyCore 2.0.2 released!

This fixes a few 2.0.x related bugs, fixes tinyNeoPixel compatibility issues with WS2812 (as opposed to SK6812 clones, which were more tolerant of it's incorrect timing) at 16MHz and higher. The same thing that caused that issue (ST indirect completes in 1 cycle, not 2), also allowed the ugly hackjob to get rid of the menu implemented in 2.0.1, and now there's one version of each of the libraries for all ports, with no submenu!
Wire library issues (excessively sized buffer and compile errors on 20-pin 0-series parts) fixed; also coding defensively around the way we plan for pinswaps being an option - now it always makes sure the swap exists before proceeding under the assumption that it is. Also, since 2.0.0 (or maybe earlier), the alt and default pins were backwards on 20-pin parts.
The macros that were used to identify part families were wrong for a bunch of parts
Finally - analogReadResolution() which was planned for 2.0.0 but forgotten about is now in - it has two valid options, 8 and 10. 2.1.0 will add options 11, 12, and 13 which will use oversampling and decimation (with appropriate warning from the app note on when this is applicable, and the downsides of this) by using the accumulator function)
Last but not least (er, well, I guess actually least, because it also isn't in yet). this week expect 2.0.3 which will pull in improved toolchain version to fix the R_AVR_13_PCREL errors when out of space....


Yeah, I like the idea of the jumpers. I recently found some jumper outlines that I really like - the next version is going to have a *lot* of tiny little jumpers for people who are interested in doing weird stuff with the board (and it's going to be the same across all the modern AVR breakouts I make - and I am going to have full set)... My current list (not all boards will have all of these, due to space/sanity):

All jumper names are preliminary, suggestions wanted - I think

Jumpers relating to Power Supply
REG: normally closed. Cut to disconnect regulator output from rest of circuit entirely
VUP: normally closed. Cut to isolate Vcc from Vcc pin of UPDI header(s)
VSER: normally closed. Cut to isolate Vcc from Vcc pin of FTDI header.

Relating to Reset:
RST_EN (reset enable or disable)  - on tinies, this disconnects the whole reset circuit from the pin, on others, this only disconnects DTR from the cap - for the below:
RST_CAP (not for tinies) - if RST_EN cut, jump this to tie the side of the cap normally on DTR to gnd?
DTR_IO (not for tinies)- if RST_EN cut, jump this to tie DTR to an I/O pin
ERZ_RST (on tinies) - if RST_EN not bridged, this could connect another pin for "ersatz reset"

Others:
CTGN - connected by default, connects the "CTS" pin of serial header to ground.
CTXD - if CTGN cut, bridge this to connect "CTS" pin to an I/O pin (specifically, UART0's XDIR pin - so you could use that header for RS485 if you wanted to)

Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: dlloyd on May 03, 2020, 03:55 pm
Quote
Others:
CTGN - connected by default, connects the "CTS" pin of serial header to ground.
CTXD - if CTGN cut, bridge this to connect "CTS" pin to an I/O pin (specifically, UART0's XDIR pin - so you could use that header for RS485 if you wanted to)
I like how you're making the normally redundant "CTS" pin useful - awesome! Could you add one more use for this pin? ... a jumper to connect "CTS" pin to PA0 to to allow UPDI programming and serial monitor (https://forum.arduino.cc/index.php?topic=669577.msg4570056#msg4570056) all in one 6-pin connection.


Edit: ...to allow a "plug-n-play" connection scheme like this:
(https://i.imgur.com/Rxl5qJo.png)
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: DrAzzy on May 05, 2020, 12:34 am
Aaah - hmm - the catch with that is it doesn't work well on a tiny, because if using DTR for autoreset, UPDI doesn't work (I haven't been able to make UPDI work with an autoreset circuit on UPDI pin, even if the pin isnt enabled for autoreset, just electrically connected. Have been trying to work out a way to pull that off (but working on another project as top priority now)

Though, for megaAVR 0-series and my other project, it will make a lot of sense (we basically end up with two variants on the 6-pins serial/programming header - 1x6 FTDI-inspired, and the 2x3 (there's the microchip pinout, and the mcudude one with extra pins)...

How many connectors will the new boards that have plenty of space (for the megaAVR 0-series parts) going to support by now? 3? plus cut+jump at designated points to support at least 3 variations on one of them...

That's the great thing about standards - there are so many to choose from! (I don't like proliferating them - and I'm already guilty of this via the 3-pin UPDI header, though I can't say I regret it, since the 6-pin one with 3 pins unused is unnecessarily bulky for the small ATtiny boards.

As an aside, I made the decision to bite the bullet and design my own CH340G adapter and try to get a batch produced in China - hoping they will end up being cheap enough that I won't lose money offering them as the addons, but am not happy with how any of the ones you can buy easily do the voltage switching, most don't break out all the modem control pins - and I'd add a few other jumpers on them too, most notably a "direct" connection (bypassing the usual ~1k resistor) for the TX pin, and ones to disable the RX led so it doesn't lead the pin at all. (and yes, I just had to do things like this last night for what I would argue was a really simple use case - I wanted to monitor the serial data that avrdude sent to my nano with jtag2updi on it - but serial wouldn't even work with just a scope probe on it without making that connection more forceful)
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: dlloyd on May 05, 2020, 04:28 am
Right now I'm using a connection scheme similar to this on a breadboard without any programming or reset issues. Quite anxious to get the prototype PCBs soon so I can test the switching of RX/TX from programmer to target (and back) automatically and complete the firmware and documentation. For the HV programmer (on the breadboard), I'm using your ATtiny1604 breakout board with a 1606 board as the target. I've programmed the 1604 with a revised version of jtag2updi from ElTangas. It doesn't matter what configuration the target's PA0 is set to, because the programmer automatically sends a HV pulse sequence on power-up to ensure UPDI mode until the next POR. As a result, no DTR signal or reset pin is needed on the target as far as burning the bootloader or uploading sketches is concerned. After programming, I'll be monitoring the DTR status to determine if the serial monitor is open or closed to auto-switch the TX/RX signals.

EDIT: Just did a re-read ... yeah, any load connected to the UPDI pin (auto-reset or other) needs to be disconnected prior to programming.

Oh, If your scope's probes have a X10 switch, try this as it will load the circuit far less than X1.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: DrAzzy on May 07, 2020, 07:11 am
Interesting! So the HV programming stuff is working well?

As it happens I've been up to my armpits in jtag2updi code recently making it support the "new" NVM peripheral, which behaves very differently from the old one...
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: dlloyd on May 07, 2020, 02:11 pm
Quote
Interesting! So the HV programming stuff is working well?
For the Nano HV Programmer and the devices I have on hand, yes (since mid March).

One thing I'd like to add later is improved capability with programming in the field (in-circuit), where it would be ideal to send the HV pulse automatically just after power-up. Might need to use some hardware circuit solution with the atmega328 (Nano), but I've tested this to work when using a tinyAVR as a programmer because it "boots-up" very quickly (5ms).

I have to say that when I started working with the tinyAVRs a few months back, I had the fear of messing with the UPDI pin and getting locked out, but that seems like a distant memory now.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: gabenix on May 08, 2020, 04:40 pm
The new megaAVR 1-series and 0-series ATtiny parts bring exciting new features to the ATtiny family. However, until now there has been no support for these parts on the Arduino IDE. This core provides Arduino IDE support for these new parts. This is the initial release, and we expect issues to come up, however, basic functionality is there, with support for the entire ATtiny 1-series and 0-series product line. Please alert us to any issues you encounter with the core.
Hey DrAzzy, thanks for all your hard work supporting these boards! It's a great service!

I'm using the Attiny412 and I'd like to use the DAC on PA6. I've read where you have stated that there is DAC support, however analogWrite() has no effect or output so I'm assuming the DAC is not already initialized in the IDE board setup? How can I access the DAC in Arduino IDE?

Thanks for so much for your help!

From the Datasheet:



31.3.1 Initialization
To operate the DAC, the following steps are required:
•   Select the DAC reference voltage in the Voltage Reference (VREF) peripheral by writing the DAC and AC Reference Selection bits (DAC0REFSEL) in the Control A register of the Voltage Reference(VREF.CTRLA).
•   The conversion range is between GND and the selected reference voltage.
•   Configure the further usage of the DAC output:-  Configure an internal peripheral (e.g. AC, ADC) to use the DAC output. See the accordingperipheral's documentation.-  Enable the output to a pin by writing a '1' to the Output Enable bit (OUTEN) in the Control Aregister (DAC.CTRLA). This requires configuration of the Port peripheral.
•   Write an initial digital value to the Data register (DAC.DATA).
•   Enable the DAC by writing a '1' to the ENABLE bit in the Control A register (DAC.CTRLA).




Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: gabenix on May 08, 2020, 07:46 pm
Just a bit more information to followup on my post above:

I'm using the most recent version of the megaTinyCore - at least as of 48 hours ago. I can provide the version number when I get home tonight.

I did find this on your Tindie page for the 412: DAC output (just do analogWrite() on the DAC pin - voltage is between 0V and the DAC reference voltage set in the tools menu; this voltage must be less than Vcc).

However analogWrite is not producing any output on PA6 (Pin 0 in IDE). All other pins work as expected and PA6 does work functionally for serial data.

I did not notice any setting for DAC reference voltage in Tools menu, I will check again later. If I had not set it in Tools, does it default to a setting? The chip is operating at 5V so even if defaulting to the highest reference it should still work.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: gabenix on May 08, 2020, 11:59 pm
One quick update...

I just got home and re-tested. The DAC is functioning, that's good news, however the voltage output range is 0.0 to 0.625V. I didn't notice this output last night because the voltage out was much lower than I was expecting/looking for.

So the reference voltage must be set, however I have no setting for that in the "Tools" menu as the documentation states. Am I missing it? I adjusted the BOD voltage setting to see if that may affect it however it did not produce any change for the DAC output levels.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: DrAzzy on May 09, 2020, 01:55 am
One quick update...

I just got home and re-tested. The DAC is functioning, that's good news, however the voltage output range is 0.0 to 0.625V. I didn't notice this output last night because the voltage out was much lower than I was expecting/looking for.

So the reference voltage must be set, however I have no setting for that in the "Tools" menu as the documentation states. Am I missing it? I adjusted the BOD voltage setting to see if that may affect it however it did not produce any change for the DAC output levels.
Since 2.0.0, you use DACReference() to set the DAC reference voltage - it can be set to any of:

INTERNAL0V55
INTERNAL1V1
INTERNAL2V5
INTERNAL4V34
INTERNAL1V5

Let me know where in the documentation I missed updateing the method of setting DAC voltage reference. I removed all the stuff from those menus that could be done in the code because, in practice,  sucked to have to keep a record of what settings each sketch needed, and very easy to end up with bugs because those settings are saved globally and reset when you switch boards, rather than on a per-sketch basis.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: gabenix on May 09, 2020, 09:40 pm
Hey, thanks! That works perfectly. I have since discovered this info on the root Master branch of your megaTinyCore GitHub so it's published there. I had ended up at the megaTinyCore/megaavr/extras/ATtiny_x12.md page which has much less information on it (my fault for not tracing back).

The page that does need updating is the Tindie here --> https://www.tindie.com/products/drazzy/attiny412402-dev-board-arduino-compatible/

Thanks again for responding, great work!
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: windoze_killa on May 19, 2020, 10:56 am
Just have to throw this out there.

Most of this thread has flown way over my head but these chips have I2C pins. Why can't they be programmed through these?
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: grandaspanna on May 19, 2020, 11:11 am
Most of this thread has flown way over my head but these chips have I2C pins. Why can't they be programmed through these?
The simple answer is that the chips aren't designed for that.

I'm a hobbyist and have been playing with the attiny1614 and attinty1616 parts and am loving the UPDI programming, which means only three wires (Vcc, GND & signal) from the programmer to the circuit. Many of my designs are meant to be small, so the space that an ICSP header takes up is significant. In some cases, I only need to add a single pad for the UPDI connection and can program the chips easily. I'm naive, but I haven't yet seen the need for a bootloader and been embarrassed to ask :-)

I'm using an Arduino Nano as the programmer, which is dirt cheap and has been very reliable so far.

My next step is experimenting with an external crystal oscillator as the clock - I have one use case that needs better than 1% accuracy.

These chips have some really cool features. I'd love to see a USB-equipped one.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: westfw on May 20, 2020, 01:17 am
Quote
I haven't yet seen the need for a bootloader
Single (cheap) connection for both program loading and serial comm with the host...
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: DrAzzy on May 20, 2020, 04:51 am
The main advantage of programming through a bootloader is that you don't need an additional microcontroller running jtag2updi or similar between the computer and target (which of course also entails a USB-serial adapter chip, either on the board of that microcontroller - if it's say a nano - or on a separate board - if it's, say, a pro mini) - you just need the USB-serial adapter.

In practice, I usually don't use the bootloader on these; the nuisance of the reset pin is enough to make it less appealing. What I usually end up doing, instead, is having the serial port connected and the output piped to a terminal program, and then program via UPDI - has the added advantage of the programming process not breaking the serial connection (though this also makes clear the fact that jtag2updi seems to reset the part after programming multiple times - which, despite my farting around with jtag2updi for like two weeks, I still haven't fixed....)

Just have to throw this out there.

Most of this thread has flown way over my head but these chips have I2C pins. Why can't they be programmed through these?
For the same reason that an atmega328p can't be programmed over the I2C pins.

The chip, out of the box, only supports one means of programming - for the classic AVRs, that was ISP (SPI pins, using Reset like chip select), for the modern AVRs it's UPDI. Any other method of programming is achieved via a bootloader.

People often want to program over serial, so bootloaders (well, really only one bootloader these days, WestFW's Optiboot) get written to support programming via serial (UART).

There is much less interest in programming via I2C, so bootloaders that do this don't get written (there's also some awkwardness about timing - as you'd need to reset into bootloader, since the flash protection prohibits code executing from non-bootloader sections of the code from rewriting the flash, but resetting the part immediately before starting an I2C transaction is tricky. Probably the way to do it would be to have the device generally configured as I2C slave, and then listen for a specific command that starts the programming routine, and react to that by doing a software reset to run bootloader)... besides, even if you did this, there isn't a convenient way to make a computer do I2C, nor is there a standard for this...
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: windoze_killa on May 21, 2020, 01:07 am
I have had a bit of a look at the data sheet but not sure if I am reading it right. Can the UPDI pin also be used as an analog in? If so it would be the perfect chip. I was trying to get away with only 3 pins + VCC in my design.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: westfw on May 21, 2020, 02:59 am
Quote
Can the UPDI pin also be used as an analog in?
It looks that way to me...  typically AIN0.
I don't yet have a programmer that does the HV UPDI handshake, so I haven't had the guts to reprogram the pin to anything other than the default UPDI function.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: windoze_killa on May 21, 2020, 03:18 am
I am about the design a board for a micro and the 3216/17 seems to be the way to go. Small and has the program memory I need. At least I think thats what I need. When I compile my program for the 2560 it says it takes 14K and I still have a few things to add. The board has to be small and will have a 1.3" OLED display on top. In total I wil have 4 wires coming out, GND, VCC, Analog in and a switched O/P.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: windoze_killa on May 26, 2020, 05:13 am
Hi again. Just before I go butchering my UNO with caps and resistors I would like to make sure I have the process correct.

Being the first time programming a clean chip I want to make sure I get it right. I load the UNO with the programming sketch. Connect it to my custom board using VCC, GND and UPDI and load the optiboot bootloader. Then I do the same with my program sketch.

I think I saw somewhere that the bootloader when you switch on or reset waits for 8 seconds for data on the UPDI pin before running the loaded program. Is this correct? If so, can you shorten that or remove it totally once I have the program in a state I finally like.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: grandaspanna on May 26, 2020, 06:05 am
I'm throwing this here, I *think* it's right, but happy to have my knowledge tested/corrected.



Now, you choose "burn bootloader". This doesn't install the bootloader (unless you chose one in step 1 above), but sets the fuses consistent with your settings.

After this, you can simply load your programs via the jtag2updi programmer.

Been working a treat for me so far. I have a little test bed 1614 on a SOIC breakout and it's been awesome. Got some PCBs arriving tomorrow for a new project that will use some of the timing functions for pulse width and frequency.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: windoze_killa on May 26, 2020, 07:33 am
Thank you for the info. Whats the difference between a plain bootloader and the optiboot?
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: grandaspanna on May 26, 2020, 07:35 am
Thank you for the info. Whats the difference between a plain bootloader and the optiboot?
Maybe poor phrasing on my part. It means no bootloader.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: windoze_killa on May 26, 2020, 07:40 am
So how does the main program run? I thought the idea of a bootloader was to start the main program.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: westfw on May 26, 2020, 08:01 am
Quote
So how does the main program run? I thought the idea of a bootloader was to start the main program.
The main function of the booloader is to LOAD the main program.  This can also be done using a "device programmer", which used to be an expensive and hard-to-obtain bit of hardware.  These days, the Arduino Nano Every and the Arduino Uno WiFi 2 include a device programmer as part of the boards, and you can also easily load software on any Arduino AVR board that will make IT behave like a programmer.
If you use a programmer, the device will start the user sketch immediate upon reset or powerup, by hardware magic.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: windoze_killa on May 26, 2020, 08:10 am
I am obviously missing something here. Once you disconnect the "device programmer" from the chip (talking stand alone custom board)will it still run the main program without a boot loader?
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: grandaspanna on May 26, 2020, 10:07 am
I am obviously missing something here. Once you disconnect the "device programmer" from the chip (talking stand alone custom board)will it still run the main program without a boot loader?
Yes. It works really well and is simple.

The bootloader is simply an optional program that can be used to load a program into memory over the serial interface.

When the device powers up, it runs whatever program is at the start address.

If you don't have a bootloader, it just runs your code straight away.

If you do have a bootloader, it will do some things to see whether or not you're trying to load a new program. Bootloaders have various strategies for working that out. If it decides you're not looking to invoke its services, it jumps to your program.

Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: windoze_killa on May 26, 2020, 10:58 am
Excellent. Thank you.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: BJHenry on May 27, 2020, 03:13 am
Regarding the JTAG2UPDI programmer, are we likely to see a version that runs on the ATMega32U4 so that we can use something like a Micro/Pro Micro?
Also, I don't know if you've seen but there is more information on the tinyAVR-2 series up on the Microchip website now, including this family overview (http://ww1.microchip.com/downloads/en/DeviceDoc/tinyAVR2-Family-Product-Brief-ATtiny162x-DS40002203A.pdf).
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: DrAzzy on May 28, 2020, 04:49 am
Very nice! Looks like they'll be around soon!

analogRead() will take some work, but probably not much, since we will just be using in single-ended mode. One odd thing I saw was that they may not support native 10-bit analog readings - just 8 or 12... but we can work around that easily enough...

The rest of the stuff, I think, will "just work"...

Joy to the world on the second USART! That's the one thing that really held back the tinyAVR 0/1-series...

I'm not going to touch the 32u4 issue - that looks like mondo work and I don't want to spend any more time on that damned jtag2updi.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: Paul_N on May 28, 2020, 06:12 am
Hi Dr Azzy --

In your May 5th post in this thread you mentioned that you were making some CH340G based USB to Serial adapters.  Is there a reason you choose the CH340G over the Silicon Labs CP2102N?  Maybe it was cost or available packages?  I see that Mouser has the PC2102N at $1.33 in singles but the only package available is the QFN28.  Not the easiest thing to hand solder.

The reason I ask is because the windows 10 driver for the CH340G does not appear to honor XON-XOFF flow control (but the CH340G does pass the ^s and ^q without interference).  I know from a project I'm doing that the CP210x set of drivers from Silicon Labs *does* honor XON-XOFF flow control.  Also the drivers are royalty free.

Thank you,

Paul_N
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: westfw on May 28, 2020, 07:19 am
Quote
the windows 10 driver for the CH340G does not appear to honor XON-XOFF flow control
I don't see any indications in the CH340 *chip* datasheet that it has any support for XON/XOFF flow control.  Just "hardware flow control."
I guess you lose some functions when you pay 1/5 the price :-(
(I suppose that you could try to support Xon/Xoff in the windows driver, but that seems very "distant" considering that a single USB message might contain 64 bytes of data...)
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: windoze_killa on Jun 09, 2020, 01:42 am
Just a quick question.

If i program a 3217 and set the protection fuse can it be reprogrammed with a new revision of code?
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: DrAzzy on Jun 10, 2020, 05:44 am
I chose the CH340G because the part is cheaper than dirt, dead easy to solder, physically and electrically very resilient, and I have a great deal of experience using them (modifying boards based on them, have designed multiple boards, etc).

Just a quick question.

If i program a 3217 and set the protection fuse can it be reprogrammed with a new revision of code?
Yes, assuming you are using UPDI programming. The "chip erase" operation clears the lockbits as well as the flash.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: windoze_killa on Jun 10, 2020, 08:59 am
Excellent. Thankyou.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: DrAzzy on Jul 25, 2020, 07:26 am
Yikes - realized I forgot to post about version 2.0.4/5 here!

megaTinyCore v2.0.4 released 7/8/2020 (with 2.0.5 less than 24 hours later)

The biggest change here is the switch to new and improved compiler toolchain. This fixes a few odd errors, most notably the 'relocation truncated to fit: R_AVR_13_PCREL against symbol tablejump2' error shown when a sketch was too large on a part that used RJMP (ie, 8k or less of flash). This also includes a bugfix for eeprom.h (this is the builtin <avr/eeprom.h> one, not EEPROM.h) where the eeprom_is_busy() macro it provided would throw a compile error on these parts because it referred to registers that don't exist here. We have also updated the datasheets to the latest versions. The header files and datasheets contained another big surprise - a bunch of the BOD settings were removed! According to Microchip ATpack release notes, these were "unqualified" BOD settings. Now, only 1.8, 2.7 and 4.3 are "official" - these correspond to 5 MHz, 10 MHz and 20 MHz guaranteed operating speeds. Accordingly, the menu was updated to list the official ones and the speeds they are guaranteed for; the "unqualified" ones (which seemed to work for me!) were marked as such. They are not guaranteed to work, and may vanish in future silicon revisions.
This version also introduced improved naming of exported binaries and assembler listings - the name now includes everything that could effect the .hex output. As part of this initiative, it was discovered that the attempt to delete merged hex files could result in failure to export compiled binary on some linux platforms (#201) because such merged hex files were not created for non-optiboot board definitions (and never got deleted on optiboot ones, by design).
And some other assorted fixes:

Significant documentation improvements, including a page listing errata and table of which applies to what parts... as there are unfortunately a lot of errata in some of these parts!
Improve backwards compatibility of Wire.h (#203)
Fix strange bug in EEPROM.h that was somehow missed (note that there is still #200 which I don't know how to fix)
Possibly fix #189 (timing glitches when TCA0 used as millis timing source)
Fix problem with millis not being entirely disabled when set to be disabled.
Ever so slightly improve baud rate accuracy, reduce space taken by Serial.begin() by a few bytes.
Fix compile error from Tone() on parts without a second type B timer (ie, everything not a 1614, 3216, 1616, 3217, or 1617) when TCB0 was selected as a millis source. (part of #189)
Correct bug in micros() timekeeping when TCA0 is used as millis() timing source (introduced in 1.1.9 - after the exhausive testing for these sorts of issues) (#189)
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: DrAzzy on Jul 25, 2020, 07:57 am
Oh - also - I decided against making a super-serial-adapter using the CH340G...

Because I found a much better part! It's the Holtek HT42B534 USB UART adapter.

It has some compelling advantages over the CH340G:
* 0.25% clock accuracy without a crystal (the non-crystal CH340 adapter's oscillator is mediocre at best)
* Dedicated pin for an activity LED - so it doesn't load down RX just to light an LED.
* Has true VDDIO pin, which works from 1.8~VDD (ie, 5v or whatever the adapter is running at - as many of us know, some the hard way, many USB "phone charger" type supplies actually give 5.3v).
* Hardware RTS/CTS flow control

On the CH340G, it's not explicitly stated that you can switch the voltage supplied to the part from 3.3 to 5v while it's live. It happens to work (the trick is, you have external 3.3v regulator tied to the 3v3 pin, rather than relying on the on-chip regulator to get it from the 5v line. that way you can switch the voltage on that pin to change what voltage the I/O is running at, without putting a glitch on the 3.3v pin that actually runs the electronics).

The Holtek chip gives you a dedicated VDDIO pin that you have to connect a voltage to - and that voltage is what a "high" that the board tries to output is.

I'm going to have a *three* position switch (I just got them in, they're adorable!). I've seen designs where people put the full current of a USB adapter through that sort of switch, but as I call my design the ultimate serial adapter, halfassing it like that isn't exactly an option. So tje common on switch will be ground, and the 1P3T switch will just decide which of the three P-channel MOSFETs iomn. First one will connect VBUS to Vcc, second will connect the 3.3v one, and the third will keep both off them off (there will be a third FET and outline on back for an optional second regulator to be installed (or they can add their own) - but by default, you'd use that setting to use "whatever logic level whatever it's plugged into is" Particularly handy for devices in low power applications where the device is running straight off a LiPo at ~3.8v,

For the activity lights, the LED pin will drive one LED, and I'll run a second one from the TX light, using a bicolor LED - between the two of them, it will be kinda like you had a real RX light, but without the load on RX pin.

There will be a 2-position switch to choose if that sixth pin is DTR or RTS (some tools use DTR for reset, some use RTS, and some just brute force and try both to reset the chip, while the hardware flow control wants RTS.

And then TX and RX will both have 1k series resistor to the 6-pin header which can be bypasses with a solder bridge jumper on the back (I have done this to multiple adapters - sometimes you desperately need one or both of them to be tied *diretly* to the serial adapter,

So that's the plan. Obviously, all the modem control pins, as well as all the voltages, will be broken out (I'm imagining 6p on one of the narrow ends, miniusb on the other, and the 6 modem pins. VBus, VDDIO, and  ground on one long side, switches on the other.

Oh, and (hopefully) obviously, the switch that controls the transistor gates will also control the power LED, setting it to either 5v (white, just like my 5v boards), green (just like my 3v3 boards), orange (for external or third regulator). I have most of the parts, though I still haven't laid out the board. If they work as well as I hope, I'll probably have a few hundred made to sell.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: westfw on Jul 25, 2020, 09:33 am
Quote
the non-crystal CH340 adapter's oscillator is mediocre at best
How can you tell?  Doesn't it have to be "very close" for USB to work at all?
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: DrAzzy on Jul 26, 2020, 07:21 am
How can you tell?  Doesn't it have to be "very close" for USB to work at all?

I am referring to baud rate generation.

From the datasheet, "the baud rate error of CH340G/CH340T/CH340R UART transmission is less than 0.3%, less than 1% for CH340C/CH340E/CH340B"

The latter three are the models without external crystal. That implies that they've got *at least* 0.7% or so inaccuracy in their timebase (which I think is close enough for USB, based on VUSB working with just tuned internal) But the Holtek chip specs 0.25%...
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: trimarco232 on Aug 24, 2020, 04:29 pm
Hi,
I didn't read everything, nor understand all of it, so 3 questions ; sorry and thanks for answering !

1) CH340 : the easiest to solder is CH330N (CH340N) : can it be used for auto-reset, since it has no DTR, but only RTS ?

2) auto-reset : is there a way to use it at PA0, while PA0 is configurated as UPDI ? ; ie. in UPDI mode, PA0 works as PIO too, thus can generate an interrupt that resets the chip by software … so one can use the bootloader in auto-reset mode, while UPDI can still be used (if needed), and there is no need to HV it (le beurre et l'argent du beurre)

3) the yet remaining issue concerning parts like AtTiny1616 is the rich set of silicon bugs … : do the libraries take care of that, do they make differences between infected and non infected parts ?
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: DrAzzy on Aug 24, 2020, 09:25 pm
1. Yes, avrdude manipulates both DTR and RTS such that either can be used to do autoreset (

2. It may be possible to set an interrupt on that pin al-la-ersatz reset even if it is set to UPDI. It is on my list of things to test, but it is 20-30 action items down the list so I have no ETA of when I will have information here, it is not getting closer to the top as urgent things of higher priority are coming up faster than I can check things off. I am way WAY behind on everything right now.

3. I have a section in the core documentation where I list the errata and characterize the size of the impact on users of the core, with a sentence or two describing the impact on users of the core for every issue and what measures, if any, are taken to correct for it in the core. The vast majority of these issues will only be relevant if you are implementing functionality which is not exposed by the Arduino core or included libraries.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: terje1055 on Aug 28, 2020, 01:07 pm
I am trying to compile this example code for SD card datalogger, but get the error message below when I choose ATTiny3217. It works if I choose, for example, Arduino Uno...

Any help appreciated. Thanks.

Arduino 1.8.13
MegaTinyCore 2.0.5


Code: [Select]
/*
  SD card datalogger

  This example shows how to log data from three analog sensors
  to an SD card using the SD library.

  The circuit:
   analog sensors on analog ins 0, 1, and 2
   SD card attached to SPI bus as follows:
 ** MOSI - pin 11
 ** MISO - pin 12
 ** CLK - pin 13
 ** CS - pin 4 (for MKRZero SD: SDCARD_SS_PIN)

  created  24 Nov 2010
  modified 9 Apr 2012
  by Tom Igoe

  This example code is in the public domain.

*/

#include <SPI.h>
#include <SD.h>

const int chipSelect = 4;

void setup() {
  // Open serial communications and wait for port to open:
  Serial.begin(9600);
  while (!Serial) {
    ; // wait for serial port to connect. Needed for native USB port only
  }


  Serial.print("Initializing SD card...");

  // see if the card is present and can be initialized:
  if (!SD.begin(chipSelect)) {
    Serial.println("Card failed, or not present");
    // don't do anything more:
    while (1);
  }
  Serial.println("card initialized.");
}

void loop() {
  // make a string for assembling the data to log:
  String dataString = "";

  // read three sensors and append to the string:
  for (int analogPin = 0; analogPin < 3; analogPin++) {
    int sensor = analogRead(analogPin);
    dataString += String(sensor);
    if (analogPin < 2) {
      dataString += ",";
    }
  }

  // open the file. note that only one file can be open at a time,
  // so you have to close this one before opening another.
  File dataFile = SD.open("datalog.txt", FILE_WRITE);

  // if the file is available, write to it:
  if (dataFile) {
    dataFile.println(dataString);
    dataFile.close();
    // print to the serial port too:
    Serial.println(dataString);
  }
  // if the file isn't open, pop up an error:
  else {
    Serial.println("error opening datalog.txt");
  }
}



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


Code: [Select]
Arduino: 1.8.13 (Windows 10), Board: "ATtiny3217/1617/1607/817/807/417, ATtiny3217, 20 MHz, 4.2V (20 MHZ or less), Disabled, Disabled, EEPROM retained, Enabled (default timer), Closer to 5v"


In file included from C:\Program Files (x86)\Arduino\libraries\SD\src/utility/Sd2Card.h:26:0,

                 from C:\Program Files (x86)\Arduino\libraries\SD\src/utility/SdFat.h:29,

                 from C:\Program Files (x86)\Arduino\libraries\SD\src/SD.h:20,

                 from C:\Program Files (x86)\Arduino\libraries\SD\examples\Datalogger\Datalogger.ino:24:

C:\Program Files (x86)\Arduino\libraries\SD\src/utility/Sd2PinMap.h:438:5: error: 'DDRD' was not declared in this scope

   {&DDRD, &PIND, &PORTD, 0},  // D0  0

     ^~~~

C:\Program Files (x86)\Arduino\libraries\SD\src/utility/Sd2PinMap.h:438:5: note: suggested alternative: 'VDD'

   {&DDRD, &PIND, &PORTD, 0},  // D0  0

     ^~~~

     VDD

C:\Program Files (x86)\Arduino\libraries\SD\src/utility/Sd2PinMap.h:438:12: error: 'PIND' was not declared in this scope

   {&DDRD, &PIND, &PORTD, 0},  // D0  0

            ^~~~





.
.
.
.








In file included from C:\Users\tea\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.0.5\cores\arduino/UART.h:28:0,

                 from C:\Users\tea\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.0.5\cores\arduino/Arduino.h:314,

                 from sketch\Datalogger.ino.cpp:1:

C:\Users\tea\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.0.5\variants\txy7/pins_arduino.h:77:79: error: 'PIN_MOSI_SCK' was not declared in this scope

 #define MOSI ((uint8_t) (PORTMUX.CTRLB&PORTMUX_SPI0_bm?PIN_SPI_MOSI_PINSWAP_1:PIN_MOSI_SCK))

                                                                               ^

C:\Program Files (x86)\Arduino\libraries\SD\src/utility/Sd2Card.h:79:35: note: in expansion of macro 'MOSI'

     uint8_t const  SPI_MOSI_PIN = MOSI;

                                   ^~~~

C:\Users\tea\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.0.5\variants\txy7/pins_arduino.h:77:79: note: suggested alternative: 'PIN_SPI_SCK'

 #define MOSI ((uint8_t) (PORTMUX.CTRLB&PORTMUX_SPI0_bm?PIN_SPI_MOSI_PINSWAP_1:PIN_MOSI_SCK))

                                                                               ^

C:\Program Files (x86)\Arduino\libraries\SD\src/utility/Sd2Card.h:79:35: note: in expansion of macro 'MOSI'

     uint8_t const  SPI_MOSI_PIN = MOSI;

                                   ^~~~

C:\Users\tea\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.0.5\variants\txy7/pins_arduino.h:78:79: error: 'PIN_MISO_SCK' was not declared in this scope

 #define MISO ((uint8_t) (PORTMUX.CTRLB&PORTMUX_SPI0_bm?PIN_SPI_MISO_PINSWAP_1:PIN_MISO_SCK))

                                                                               ^

C:\Program Files (x86)\Arduino\libraries\SD\src/utility/Sd2Card.h:81:35: note: in expansion of macro 'MISO'

     uint8_t const  SPI_MISO_PIN = MISO;

                                   ^~~~

C:\Users\tea\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.0.5\variants\txy7/pins_arduino.h:78:79: note: suggested alternative: 'PIN_SPI_SCK'

 #define MISO ((uint8_t) (PORTMUX.CTRLB&PORTMUX_SPI0_bm?PIN_SPI_MISO_PINSWAP_1:PIN_MISO_SCK))

                                                                               ^

C:\Program Files (x86)\Arduino\libraries\SD\src/utility/Sd2Card.h:81:35: note: in expansion of macro 'MISO'

     uint8_t const  SPI_MISO_PIN = MISO;

                                   ^~~~

exit status 1

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











Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: CrossRoads on Aug 28, 2020, 01:28 pm
Code: [Select]
C:\Program Files (x86)\Arduino\libraries\SD\src/utility/Sd2PinMap.h:438:5: error: 'DDRD' was not declared in this scope
   {&DDRD, &PIND, &PORTD, 0},  // D0  0
     ^~~~


That indicates the code is trying to access Port D.
The 3217 only has Port A, with bits 0 to 7,
Port B with bits, with bits 0 to 7, and
Port C with bits 0 to 5.

The 20 pin SOIC has a few less bits:
Port A, with bits 0 to 7,
Port B with bits, with bits 0 to 5, and
Port C with bits 0 to 3.


Code: [Select]

C:\Users\tea\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.0.5\variants\txy7/pins_arduino.h:77:79: error: 'PIN_MOSI_SCK' was not declared in this scope

 #define MOSI ((uint8_t) (PORTMUX.CTRLB&PORTMUX_SPI0_bm?PIN_SPI_MOSI_PINSWAP_1:PIN_MOSI_SCK))

                                                                              ^


MOSI can be on PA1 or PC2. Maybe this is setting it to be on a different pin?
I am not sure if PORTMUX.CTRLB means it is trying to use a PORTB pin.
Same with the SCK and MISO errors.



Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: dlloyd on Aug 28, 2020, 09:48 pm
Looks like your SD card datalogger library was written for the ATmega328P ... the ATiny3217 has different registers.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: windoze_killa on Aug 30, 2020, 01:45 am
Hi All,

Not sure what I have done wrong but I am getting the following error.

avrdude: jtagmkII_getsync(): sign-on command: status -1

It keeps repeating itself trying to upload my sketch. It compiles ok.

I have installed jtag2updi on a nano and set the tinycore to a 3217. AmI missing something else?
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: windoze_killa on Aug 30, 2020, 05:41 am
Update. Seems to be working sort of.

Now I have this error message.




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, RTC w/w32khz xtal (no micros), Closer to 5v"

Sketch uses 21382 bytes (65%) of program storage space. Maximum is 32768 bytes.
Global variables use 150 bytes (7%) of dynamic memory, leaving 1898 bytes for local variables. Maximum is 2048 bytes.
/home/jason/snap/arduino/41/.arduino15/packages/arduino/tools/avrdude/6.3.0-arduino17/bin/avrdude -C/home/jason/snap/arduino/41/.arduino15/packages/megaTinyCore/hardware/megaavr/2.0.5/avrdude.conf -v -pattiny3217 -cjtag2updi -P/dev/ttyUSB1 -Uflash:w:/tmp/arduino_build_356461/PI_GPI_ATRE_OLED_TNR_NANO.ino.hex:i

avrdude: Version 6.3-20190619
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "/home/jason/snap/arduino/41/.arduino15/packages/megaTinyCore/hardware/megaavr/2.0.5/avrdude.conf"
         User configuration file is "/home/jason/snap/arduino/41/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : /dev/ttyUSB1
         Using Programmer              : jtag2updi
avrdude: jtagmkII_getsync(): sign-on command: status -1
JTAG ICE mkII sign-on message:
Communications protocol version: 1
M_MCU:
  boot-loader FW version:        1
  firmware version:              6.00
  hardware version:              1
S_MCU:
  boot-loader FW version:        1
  firmware version:              6.00
  hardware version:              1
Serial number:                   00:00:00:00:00:00
Device ID:                       JTAGICE mkII
         AVR Part                      : ATtiny3217
         Chip Erase delay              : 0 us
         PAGEL                         : P00
         BS2                           : P00
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 0
         StabDelay                     : 0
         CmdexeDelay                   : 0
         SyncLoops                     : 0
         ByteDelay                     : 0
         PollIndex                     : 0
         PollValue                     : 0x00
         Memory Detail                 :

                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00
           prodsig        0     0     0    0 no         61   61      0     0     0 0x00 0x00
           fuses          0     0     0    0 no          9    0      0     0     0 0x00 0x00
           fuse0          0     0     0    0 no          1    0      0     0     0 0x00 0x00
           fuse1          0     0     0    0 no          1    0      0     0     0 0x00 0x00
           fuse2          0     0     0    0 no          1    0      0     0     0 0x00 0x00
           fuse4          0     0     0    0 no          1    0      0     0     0 0x00 0x00
           fuse5          0     0     0    0 no          1    0      0     0     0 0x00 0x00
           fuse6          0     0     0    0 no          1    0      0     0     0 0x00 0x00
           fuse7          0     0     0    0 no          1    0      0     0     0 0x00 0x00
           fuse8          0     0     0    0 no          1    0      0     0     0 0x00 0x00
           lock           0     0     0    0 no          1    0      0     0     0 0x00 0x00
           data           0     0     0    0 no          0    0      0     0     0 0x00 0x00
           usersig        0     0     0    0 no         32   32      0     0     0 0x00 0x00
           flash          0     0     0    0 no      32768  128      0     0     0 0x00 0x00
           eeprom         0     0     0    0 no        256   64      0     0     0 0x00 0x00

         Programmer Type : JTAGMKII_PDI
         Description     : JTAGv2 to UPDI bridge
         M_MCU hardware version: 1
         M_MCU firmware version: 6.00
         S_MCU hardware version: 1
         S_MCU firmware version: 6.00
         Serial number:          00:00:00:00:00:00
         Vtarget         : 5.0 V

avrdude: jtagmkII_initialize(): Cannot locate "flash" and "boot" memories in description
avrdude: AVR device initialized and ready to accept instructions

Reading | avrdude: jtagmkII_program_enable(): timeout/error communicating with programmer (status -1)
avr_read(): error reading address 0x0000
    read operation not supported for memory "signature"
avrdude: error reading signature data for part "ATtiny3217", rc=-2
avrdude: error reading signature data, rc=-2
avrdude: jtagmkII_close(): timeout/error communicating with programmer (status -1)
avrdude: jtagmkII_close(): timeout/error communicating with programmer (status -1)

avrdude done.  Thank you.

the selected serial port
 does not exist or your board is not connected


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




Any Ideas?
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: windoze_killa on Aug 30, 2020, 05:55 am
Yet  another update.

Brain failure.

copper to air ratio problem.

Forgot to install a vital 0 ohm resistor of the board. Uploads fine.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: pert on Aug 30, 2020, 06:10 am
Well, if you're going to suffer from a bad copper:air, too low is always better than too high!
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: windoze_killa on Aug 30, 2020, 09:41 am
Ok. New problem.

As some may be aware I have been trying to make a gear indicator for my motorbike.

Obviously because I am using a tiny3217 I have to program it using UPDI and it is now working.

The problem is the display does start working until I have reached 3V on the UPDI pin (also A0) and yes I need to use this pin. Is there something I should be doing to enable this pin as an analog in pin after programming?
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: windoze_killa on Aug 30, 2020, 10:06 am
Well, if you're going to suffer from a bad copper:air, too low is always better than too high!
Also know as a carbon based failure somewhere between the chair and the workbench.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: windoze_killa on Aug 30, 2020, 10:13 am
Another post for Drazzy.

I know you probably had a very good reason for doing it but not paying attention caused me some dramas using on of your break out boards.

The numbering along the sides of the board don't correlate to the pins on the chip. Would have saved some trouble if they did.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: grandaspanna on Sep 21, 2020, 01:13 am
Has anyone found an OLED library that works with the attiny412? At a minimum, I'd like to display text (numbers only will do). Most recently I've tried SH1106lib, but getting errors. The first is if I enabled HW i2c, it says the 412 doesn't have it. If I disabled HW i2c, I'm getting "impossible constraint in i2c_read" which is part of the SoftwareI2C library.

I have a plan B to switch to a larger package, but would be nice to know :-)
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: windoze_killa on Sep 21, 2020, 01:21 am
What display are you using? I am using an SSD1306 with a tiny3217 and it works fine.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: grandaspanna on Sep 21, 2020, 02:13 am
It's a generic 128x32 i2c module. I've had it happily working with u8x8 and u8g2 with an attiny1614, but the code/memory footprint is too big for the 4k of the 412.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: windoze_killa on Sep 21, 2020, 02:43 am
What about modifying the library and remove any characters you don't need.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: grandaspanna on Sep 21, 2020, 03:13 am
With the u8x8 library and no fonts at all, the code is still too big at close to 5k.

I'd rather switch to a part with a bit more code space than hack standard libraries too much. The difference in cost is small for my volumes.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: windoze_killa on Sep 21, 2020, 03:18 am
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.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: grandaspanna on Sep 21, 2020, 03:28 am
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 :-)
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: DrAzzy on Sep 23, 2020, 01:20 pm
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.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: windoze_killa on Sep 24, 2020, 12:55 am
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.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: grandaspanna on Sep 24, 2020, 01:39 am
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...
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: DrAzzy on Sep 24, 2020, 09:21 am
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 (https://www.tindie.com/products/21007/), download DxCore, (https://github.com/SpenceKonde/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!
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: grandaspanna on Sep 24, 2020, 11:39 am
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 :-)
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: windoze_killa on Oct 17, 2020, 06:41 am
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.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: pert on Oct 17, 2020, 07:38 am
I have just installed the 2.1.3. I now get this error when compiling.
Please do this:


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.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: windoze_killa on Oct 17, 2020, 09:36 am
That is the verbose output.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: pert on Oct 17, 2020, 09:59 am
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:

Hopefully that will magically fix whatever the issue is.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: windoze_killa on Oct 17, 2020, 10:10 am
If I regress and install 2.0.5 it compiles ok.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: pert on Oct 17, 2020, 10:12 am
What happens if update back to 2.1.3 again?
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: windoze_killa on Oct 17, 2020, 10:36 am
It fails again. I have tried all the usual stuff. Rebooted too.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: pert on Oct 17, 2020, 10:04 pm
Please post the verbose output from compiling the File > New sketch with megaTinyCore 2.0.5.

Maybe that will give us a clue.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: windoze_killa on Oct 18, 2020, 03:48 am
I was wrong. it was only set to verbose for upload. Here is the verbose for compile.

Code: [Select]

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"











/snap/arduino/41/arduino-builder -dump-prefs -logger=machine -hardware /snap/arduino/41/hardware -hardware /home/jason/snap/arduino/41/.arduino15/packages -hardware /home/jason/snap/arduino/current/Arduino/hardware -tools /snap/arduino/41/tools-builder -tools /snap/arduino/41/hardware/tools/avr -tools /home/jason/snap/arduino/41/.arduino15/packages -built-in-libraries /snap/arduino/41/libraries -libraries /home/jason/snap/arduino/current/Arduino/libraries -fqbn=megaTinyCore:megaavr:atxy7:chip=3217,clock=20,bodvoltage=1v8,bodmodeactive=disabled,bodmodesleep=disabled,eesave=enable,millis=enabled,uartvoltage=5v -ide-version=10813 -build-path /tmp/arduino_build_178766 -warnings=none -build-cache /tmp/arduino_cache_16426 -prefs=build.warn_data_percentage=75 -verbose /home/jason/snap/arduino/current/Arduino/PI_GPI_ATRE_OLED_TNR_3217/PI_GPI_ATRE_OLED_TNR_3217.ino

Error resolving FQBN: getting

Error compiling for board ATtiny3217/1617/1607/817/807/417.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: windoze_killa on Oct 18, 2020, 04:03 am
Here is the compile output for version 2.0.5.

Attached as a file as it seems to be huge for somereason.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: pert on Oct 18, 2020, 05:40 am
I was wrong. it was only set to verbose for upload. Here is the verbose for compile.
OK, that output might have provided a clue. I can now see your FQBN:
Code: [Select]
-fqbn=megaTinyCore:megaavr:atxy7:chip=3217,clock=20,bodvoltage=1v8,bodmodeactive=disabled,bodmodesleep=disabled,eesave=enable,millis=enabled,uartvoltage=5v

The strange thing is this is the FQBN that would be generated by using megaTinyCore 2.0.5.

For example, here you can see that 2.0.5 has a "20" option for the clock menu:
https://github.com/SpenceKonde/megaTinyCore/blob/2.0.5/boards.txt#L55 (https://github.com/SpenceKonde/megaTinyCore/blob/2.0.5/boards.txt#L55)
Code: [Select]
atxy7.menu.clock.20.build.speed=20
but 2.1.3 has no option of that name. The equivalent is "20internal":
https://github.com/SpenceKonde/megaTinyCore/blob/2.1.3/boards.txt#L60 (https://github.com/SpenceKonde/megaTinyCore/blob/2.1.3/boards.txt#L60)
Code: [Select]
atxy7.menu.clock.20internal=20 MHz Internal
So it's impossible to get "clock=20" in your FQBN when using megaTinyCore 2.1.3

Same for the "bodmodeactive" and "bodmodesleep" menus. Your FQBN is also missing the new "resetpin", "startuptime", and "serialevent" menu options.

So my advice is to try a fresh install. Delete everything under the /home/jason/snap/arduino/41/.arduino15 folder except for preferences.txt, then reinstall megaTinyCore 2.1.3. Note that .arduino15 is a hidden folder, so if you have your file browser configured to not show hidden files and folders then you won't see it. You can also get to it by clicking the link the the Arduino IDE's File > Preferences menu.

I was a bit suspicious of your snap installation of the Arduino IDE as the culprit, since the unspecified modifications made by random community members in order to get the IDE into the package manager repository are somtimes the cause of confusing bugs that don't occur when using the official Arduino IDE. However, I just installed the snap package and still wasn't able to reproduce the error you're getting.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: windoze_killa on Oct 18, 2020, 11:24 am
So what an FBQN.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: pert on Oct 18, 2020, 11:41 am
FQBN stands for "fully qualified board name".

If you were telling a human which board configuration to use, you might say something like:
Quote
In the Arduino IDE, select "ATtiny3217/1617/1607/817/807/417" from the Arduino IDE's Tools > Board > megaTinyCore menu.
Now make sure you have "ATtiny3217" selected from the Tools > Chip menu.
Also, make sure you have "20 MHz Internal" selected from the Tools > Clock (change 20/10/5 int<->other=burn bootloader) menu.
...and so on.

But that's not how it's done when you're communicating with a computer. We need a way to specify the exact board configuration in a machine readable format. That is the FQBN.

People who only use the Arduino IDE's GUI can usually remain blissfully unaware of FQBN. But once you start using command line tools, you must use it because there are no longer nice menus for you to use to point and click your way to a board configuration.

Your FQBN:
Code: [Select]
megaTinyCore:megaavr:atxy7:chip=3217,clock=20,bodvoltage=1v8,bodmodeactive=disabled,bodmodesleep=disabled,eesave=enable,millis=enabled,uartvoltage=5v
The "megaTinyCore" is the vendor name.
The "megaavr" is the architecture.
The "atxy7" is the board ID (https://arduino.github.io/arduino-cli/latest/platform-specification/#boardstxt).
After that come the custom board options you find in the additional Tools menus that appear after you have selected a megaTinyCore board from the Tools > Board menu. You can learn more about those here:
https://arduino.github.io/arduino-cli/latest/platform-specification/#custom-board-options (https://arduino.github.io/arduino-cli/latest/platform-specification/#custom-board-options)
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: windoze_killa on Oct 19, 2020, 02:52 am
Followed your instructions but now get this error.

File attached.



Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: pert on Oct 19, 2020, 03:15 am
The error from windoze_killa's 2.1.3 output.txt:
Code: [Select]
In file included from /home/jason/snap/arduino/current/Arduino/libraries/Adafruit_GFX_Library/Adafruit_GrayOLED.h:31:0,
                 from /home/jason/snap/arduino/current/Arduino/libraries/Adafruit_GFX_Library/Adafruit_GrayOLED.cpp:20:
/home/jason/snap/arduino/current/Arduino/libraries/Adafruit_BusIO/Adafruit_SPIDevice.h:61:22: error: 'BitOrder' has not been declared
                      BitOrder dataOrder = SPI_BITORDER_MSBFIRST,
                      ^~~~~~~~


Compatibility with the Adafruit_BusIO was broken by this change:
https://github.com/SpenceKonde/megaTinyCore/commit/adb5cbf0bbb470a34c5c206be97d49a165cff86f (https://github.com/SpenceKonde/megaTinyCore/commit/adb5cbf0bbb470a34c5c206be97d49a165cff86f)

Adafruit added support for megaTinyCore to the library here:
https://github.com/adafruit/Adafruit_BusIO/commit/374b86a1864da22fd275ff8465722943f82a00ca (https://github.com/adafruit/Adafruit_BusIO/commit/374b86a1864da22fd275ff8465722943f82a00ca)
but that was based on the previous build.board property value:
https://github.com/SpenceKonde/megaTinyCore/blob/93fe227c663664172fc1433ac0b5a9f785dc49c9/megaavr/boards.txt#L150 (https://github.com/SpenceKonde/megaTinyCore/blob/93fe227c663664172fc1433ac0b5a9f785dc49c9/megaavr/boards.txt#L150)
Code: [Select]
atxy7.build.board=attinyxy7

Since it's impossible to know how much other code might have been dependent on the previous macro, the best way forward would be to add a backwards compatibility macro definition here:
https://github.com/SpenceKonde/megaTinyCore/blob/596ca99fb5a491ac0cbe70f12aadc2233d2c2504/megaavr/boards.txt#L197 (https://github.com/SpenceKonde/megaTinyCore/blob/596ca99fb5a491ac0cbe70f12aadc2233d2c2504/megaavr/boards.txt#L197)
Code: [Select]
atxy7.build.extra_flags={build.serialevent} {build.millis} -DUARTBAUD{build.uartvoltage}
like so:
Code: [Select]
atxy7.build.extra_flags={build.serialevent} {build.millis} -DUARTBAUD{build.uartvoltage} -DARDUINO_attinyxy7
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: windoze_killa on Oct 19, 2020, 03:18 am
My head hurts
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: windoze_killa on Oct 19, 2020, 03:26 am
Well done. Thank you. It now compiles.

Now to get it to upload.
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: pert on Oct 19, 2020, 03:43 am
You're welcome. I'm glad to hear it's compiling now. I'm wishing you good fortune with the upload!
Per
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: windoze_killa on Oct 19, 2020, 03:45 am
Thats covered in another post under bootloader issues. I think I may have fried my programmer. (JTAG2UPDI)
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: grandaspanna on Oct 22, 2020, 03:36 am
Not sure if this is the right place, but I *think* it relates to BOD settings, which appear in the menu :-)

Under some circumstances, the microcontroller (1614 & 412 variants, at least) doesn't start properly if the on-voltage ramps up too slowly (suspicion, not yet measured). Target supply voltage is 5.5V and running at 20MHz.

Is this plausible? Would setting the BOD voltage higher help? Is there another approach?
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: DrAzzy on Oct 24, 2020, 02:25 am
Somehow I missed those posts about the issue with the build.board changes until they were independently reported to me today. Bus_IO library is now fixed in the adafruit repo (with a much better test - and support for DxCore), but I am adding backwards compatibility defines to 2.1.4 which I hope to release tonight.

@grandaspanna - it is.... plausible? maybe? Depending on the details of the test case and configuration. What is the BOD voltage currently set to? Is BOD enabled  on at least "sampled" for active mode? How do you know that it's not starting up, as opposed to some other sort of failure? It is not the sort of cause that my mind would jump to though - like, it's the sort of thing I'd be considering only if I could demonstrate a clear correlation with the rise time of the supply AND had also ruled out a peripheral misbehaving due to the slow rising power, AND the tiny was running outside of spec at some point in the startup process....

I think it would be far more likely if it, say, depended on communication with an external device, and tried to make contact X long after power off and would hang if the device didn't respond, and the device had a different BOD set point, such that slow rising power would result in the tiny trying to talk to it before it had started.... 
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: grandaspanna on Oct 24, 2020, 05:30 am
Re: Bus_IO - that's great news. Will aim to do some more tinkering with that.

Re; BOD - I wasn't really even aware of these settings and have never adjusted them. What was being programmed was:
-Ufuse1:w:0b00000000
Which is 1.8V, but not enabled.

The challenge I'm facing is that two users have reported intermittent issues that I can't reproduce, and they're both in different continents.

To test this theory, I've sent an updated board with 4.2V BOD and "Enabled with wake-up halted until BOD is ready".

There's some very basic code at the start of the program to flash an LED before it does anything else and it's not even getting there - the LED is either hard on or hard off. Maybe it's launching too early at 20MHz before the voltage is high enough to cope. My plan B is to get the code working at 4MHz (it's actually super simple and should be fine), but I'm also buying some additional hardware to try and replicate their use case.

I apologise for the vagueness here, I'm kinda bouncing in a vacuum without the ability to get my hands on the set-up that's not working.

Edit: I've also thought about adjusting SYSCFG1 to delay startup to the max 64ms.

On a different note, the AVR128DA32 board is cool. Can't wait for the DB and DD chips to start showing up at local distributors!
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: DrAzzy on Oct 24, 2020, 08:01 am
Well, I can't say I'm terribly surprised that you are having some sorts of issues, seeing as you have no BOD... and like, basically no countermeasures it sounds like? And you're starting it up 8ms after the POR circuit disengages at full speed, without any attempt to ascertain whether the power is okay or anything...You *are* kind of doing a whole bunch of things that would make it worse. The other problem with the tinyAVR 0/1-series is that unless you've fused them to switch the UPDI pin to reset, you don't have any way for them to guarantee that their attempt to power cycle it to fix the problem even caiused it to restart (a few times I had that issue, I think - no BOD, no reset pin, no regulator sucking a bit of power to pull the caps on the board below the POR voltage... I thought I was going nuts! (some people still think I am)

I'd be inclined to use BOD, as you suggested. If they don't have to run on batteries, might as well just do enabled/enabled, if they do, then enabled/hold wake as you said. The WDT might also be an option, depending on the application.

A longer SUT would also help; with 2.1.3 you can already choose 0/8/64ms SUT, and I'm adding the rest of the options for 2.1.4, which is coming out really soon (just gotta make sure the UART still works after what I did to it., and do a couple of boards.txt tweaks, plus move the version number defines into the platform.txt, because I have *got* got get away from having to change the version number in two places, since I literally have a near-zero-percent record of getting it in both places every release.....

Of course, the problem with your remedy is.... so they get the boards. Most likely, the new ones work, customers are happy.... but until you capture a non-working board and are able to make it fail yourself, you have no idea whether the problem was a manufacturing flaw (cold solder joints?) a problem with their environment, (power supply, EMI, the body of an electrical engineer from the 70's buried in a shallow grave in his back yard by the previous homeowner, directly facing his workshop), a combination of the two (cold solder joints on a cap such that fails with his crap power supply but not a good one)... And the worst part is, even if you pay for return shipping and get him to send it back (in my experience, the moment they have a working board, they promptly stop responding to your email)... and if you have an identical power source and EMI environment, and the dead engineers twin brother buried in your back yard (it wasn't easy! For one thing, the poor guy was still alive....), it STILL might not fail, because during the return shipping, thermal cycling and rough handling could have caused the dodgy solder joint to behave more consistently (I've had this sort of thing happen to me - the intermittent in my top of the line laptop healed itself en route back to the vendor's repair shop... and was still gone when I got it back, packed improperly, the CD drive ruined from it's trip back, and the warranty was expired by then... (never buy the top of the line laptops - they push the envelope, and reliability suffers; the other top of the line laptop I got is on it's third motherboard now).... Anyway, yeah, it's a very frustrating situation to be in; I wish you luck... but all things considered, with what you describe of it, I would definitely be using BOD



Aw man, you think the DA32 is cool?! It only has a single type A timer, 26 full function I/O pins, only 3 USARTs and type B timers - and it can't use a high frequency crystal for the system clock! Pah - it was only cool until they announced the DB-series ;-)

No, you want the AVR128DA64....  It's got alllll the good shit! The second TCA, the full complement of 6 USARTs and 5 TCBs, the full 8-pin MVIO-capable PORTC... not to mention the on-chip OPAMPS!

My plan with those bad boys is to make a board with the AVR128DB64... but add on this programmable regulator from Maxim that lets you set the voltage by tying 2 pins either high, low, or floating while switching the enable line.... So you will not only get the MVIO pins, but your code will be able to tell it what voltage to supply on those... Plus. naturally, crystal on PA0/PA1 with the serial port on PA4/PA5 (the alt pins). I'll need to do something about the TCD pins, of course - but kind of want to make a way to move those around anyway (apparently, the 128DA is the only part where the TCD mux is borked - it works fine of the rest of the DA's and the DBs). Microchip just this week has deigned to lower itself to selling the non-DIP versions of the DB-series in quantities of less than a tray from microchip direct, so they're not unobtainium anymore. Gotta get those board designs ready x_x )

Naturally what I'm most excited about is the DD-series - I love low pin-count devices, and MVIO on a 14 or 20-pin package would be just lovely (the crystal support is nice too, especially since the tinyAVR 2-series, (per digikey estimates, scheduled for release around 2 months from now (though, a month ago, it was 2 months from a month ago... so...)) won't have support for external crystal... but they've also got a unique potential for suggestive jokes, which doesn't come along very often in electronics....

Anyway, that was fun to write, now back to work on 2.1.4
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: grandaspanna on Oct 24, 2020, 08:22 am
Ok, my bad - I've been taking too many shortcuts :-)

I'm sure I only updated last week and now there's 2.1.3 - I was just about to hack boards.txt ;-)

My design should have been more robust, but the user supplies the power (from an RC brushless speed controller) and across the different brands I have, it hasn't been an issue to date. In hindsight, I should have thought it through...

Oh well, I'm more confident that it won't need any hardware changes, but need to get on with some testing.

The 5 TCB's seems like an awful tease! For one of my projects, it would streamline the code by probably 50% (maybe exaggerating, but you get the idea).

Any ideas on when they plan on shipping all the good new bits?
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: DrAzzy on Oct 24, 2020, 12:26 pm
2.1.3 (and 2.1.1/2.1.2) were panic fixes to resolve critical issues with 2.1.0 - and as was discussed above on the last page of this thread, clearly even 2.1.3 didn't do the trick. I found a bunch of other bugs as I was going through boards.txt too!

Oh god, it's coming from the same power circuit as a motor? Please tell me you at least have plenty of board-level decoupling caps! Motors are notorious for messing up electronics on the same circuit as they are, because of all the noise they put onto the power rails. Then again, these customers are only having problems at startup, so it can't be too bad, heh... 

Hm? The AVR128DA's have been shipping since like, april? (no MVIO, OPAMPs, HF crystal support... but they've got all the timers and stuff). The AVR128DB's have been on microchip direct since like august... but except for the garbage 28-pin ones, and occasionally some annoying QFN parts, they would only ship them to you if you bought a tray (160-250 parts or something stupid like that) - but this week, it looks like they removed the minimum increment; I'm going to place my order today. They claim to be shipping them next week too (microchip direct often sells stuff a week or two before it actually rolls off the production line)

Do be sure to read the silicon errata if you're going to be directly writing registers. Particularly the 128k parts (which they shipped first from these new Dx-series') are, ah, a little buggy.... They have been doing a much better job of updating the DB-series errata sheets than the DA-series (they admitted to me back in like, july, that on the 128DA parts, only the default portmux setting works - on the other settings, all 4 pins are controlled by the bit that is supposed to control CTRLA (basically, that means only the default portmux option, that is PORTA, works.... rather unfortunate.... but I suspect they will get that sorted out sooner rather than later, since the parts are generally such a shitshow of bugs, and the initial releases of all the 32 and 64k parts don't have nearly as many bugs. Generally, unless you're directly writing registers though, my cores either hide the bugs from you (like the ADC POSMUX one), or don't provide a wrapper around the broken functionality.  Where you see it most is in the fact that, for example, the pins DxCore chooses to put the TCD0 and TCA1 PWM seem to be poorly chosen... Well, if it worked like the datasheet said, yeah, I'd need my head examined - but the silicon errata forced my hand. 

The tinyAVR 2-series in 16k flash is probably by the end of this year or january 2021, based on the estimates from distributors? Though they may be telling the suppliers overly optimistic delivery dates... 



No idea on the the DD (and EA) series parts; they've just released like, the first few pages of the datasheets as a product brief - pinout images, IO pin multiplexing table, feature lists, that kinda stuff. And the EA-series isn't particularly interesting - tiny flash, lots of pins - probably mad cheap. If I had to guess, they're targeting the people currently building stuff with 8 and 16k classic AVR atmega parts. I think they would very dearly like to get people to switch to the new parts, as it's way easier to get someone familiar with the new peripherals to build something with a DB or DA, than if their only experience was with classic AVRs....My guess is, probably spring-summer 2021?
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: grandaspanna on Oct 24, 2020, 01:18 pm
The BEC (battery eliminator circuit) on most modern ESCs is not too bad, so haven't had any issues once it gets going. Most of them provide a regulated 6V from a 2-cell lithium battery pack that is used to drive a 3-phase/two-pole brushless motor via a collection of MOSFETS typically with a 3-8kHz PWM signal at full battery voltage. Some of them have a configurable BEC output for people who want to run their steering servos at 7.4V instead of 6V. I have a "HV" option of the board with an LDO and associated caps for that (works up to 3-cell configurations).

I was hoping for the smaller pin count DD series to be on the horizon. The attiny412 works great for this little item, the DA's could be a good workhorse for other scenarios (how did they miss the TCB OVF on the 0/1-series? :-) )

Sincerely appreciate the work you do in making this practical for hackers like me!
Title: Re: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc)
Post by: DrAzzy on Oct 27, 2020, 03:09 am
Getting ready to release 2.1.4....

Among other things, I took the external clock option for a spin.... 32 MHz at room temperature and 2.5V!

And the thing that crapped out first was the clock source: An AVR128DA32 with the internal oscillator cranked up to 32 MHz and CLKOUT turned on! Good job Microchip! They really have done a great job with AVR.... just a few years ago, I was worried that it was going to get left behind by the industry....

Almost makes me forget about the length of the errata sheets on the Dx-series..... ("How many Microchip engineers does it take to change a lightbulb?" "The whole team! One to change the bulb, and the rest to stand next to him rotating their hand while he does it, because they're all on the same PORTMUX bit...")