Go Down

Topic: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc) (Read 20132 times) previous topic - next topic

DrAzzy

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)?
ATTinyCore for x4/x5/x61/x7/x8/x41/1634/828/x313 megaTinyCore for the megaavr ATtinies - Board Manager:
http://drazzy.com/package_drazzy.com_index.json
ATtiny breakouts, mosfets, awesome prototyping board in my store http://tindie.com/stores/DrAzzy

Kattiny1616

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.

DrAzzy

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).
ATTinyCore for x4/x5/x61/x7/x8/x41/1634/828/x313 megaTinyCore for the megaavr ATtinies - Board Manager:
http://drazzy.com/package_drazzy.com_index.json
ATtiny breakouts, mosfets, awesome prototyping board in my store http://tindie.com/stores/DrAzzy

Kattiny1616

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

DrAzzy

ATTinyCore for x4/x5/x61/x7/x8/x41/1634/828/x313 megaTinyCore for the megaavr ATtinies - Board Manager:
http://drazzy.com/package_drazzy.com_index.json
ATtiny breakouts, mosfets, awesome prototyping board in my store http://tindie.com/stores/DrAzzy

Kattiny1616

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.

DrAzzy

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.
ATTinyCore for x4/x5/x61/x7/x8/x41/1634/828/x313 megaTinyCore for the megaavr ATtinies - Board Manager:
http://drazzy.com/package_drazzy.com_index.json
ATtiny breakouts, mosfets, awesome prototyping board in my store http://tindie.com/stores/DrAzzy

Kattiny1616

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?


DrAzzy

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.
ATTinyCore for x4/x5/x61/x7/x8/x41/1634/828/x313 megaTinyCore for the megaavr ATtinies - Board Manager:
http://drazzy.com/package_drazzy.com_index.json
ATtiny breakouts, mosfets, awesome prototyping board in my store http://tindie.com/stores/DrAzzy

Kattiny1616

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!

DrAzzy

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.
ATTinyCore for x4/x5/x61/x7/x8/x41/1634/828/x313 megaTinyCore for the megaavr ATtinies - Board Manager:
http://drazzy.com/package_drazzy.com_index.json
ATtiny breakouts, mosfets, awesome prototyping board in my store http://tindie.com/stores/DrAzzy

DrAzzy

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!
ATTinyCore for x4/x5/x61/x7/x8/x41/1634/828/x313 megaTinyCore for the megaavr ATtinies - Board Manager:
http://drazzy.com/package_drazzy.com_index.json
ATtiny breakouts, mosfets, awesome prototyping board in my store http://tindie.com/stores/DrAzzy

BJHenry

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.

Kattiny1616

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

Kattiny1616

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? 

Go Up