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

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: https://github.com/SpenceKonde/megaTinyCore/blob/master/megaavr/extras/PinInterrupts.md

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:

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() {
  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)) ;
}

Where do we get "BMI160Gen.h"?

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.

This minimal example demonstrates the issue.

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

megaavr:

    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.

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?

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.

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!

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.

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!

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.