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