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

It is now available through board manager as well! Same json file as ATTinyCore (see signature)

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!

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.


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


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.

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

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.

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?

hansibull: 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.

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.

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.

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:

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 ( ). 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:

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!

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)?

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.

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).

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:

#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() {
  BMI160.begin(BMI160GenClass::I2C_MODE, i2c_addr);
  BMI160.setAccelerometerRange(2); //setzen der Range für den Beschleunigungssensor. Erlaubte Werte: 2, 4, 8, 16
  BMI160.setGyroRange(125);  // setzen der Range für den Gyro. Erlaubte Werte: 125, 250, 500, 1000, 2000

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)) ;

Where do we get "BMI160Gen.h"?

Hi DrAzzy, I am using the Emotibit library ( 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.

This minimal example demonstrates the issue.

#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:

    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);


    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) )

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.