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

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

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.

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

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?

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.

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)

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:

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

attiny1614.txt (11.1 KB)

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?

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

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.

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?

I'm not able to reproduce this issue with either manual or board manager installation.

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

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.