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

Other Hardware 3rd Party Boards
81

megaTinyCore 2.0.2 released!

This fixes a few 2.0.x related bugs, fixes tinyNeoPixel compatibility issues with WS2812 (as opposed to SK6812 clones, which were more tolerant of it's incorrect timing) at 16MHz and higher. The same thing that caused that issue (ST indirect completes in 1 cycle, not 2), also allowed the ugly hackjob to get rid of the menu implemented in 2.0.1, and now there's one version of each of the libraries for all ports, with no submenu!
Wire library issues (excessively sized buffer and compile errors on 20-pin 0-series parts) fixed; also coding defensively around the way we plan for pinswaps being an option - now it always makes sure the swap exists before proceeding under the assumption that it is. Also, since 2.0.0 (or maybe earlier), the alt and default pins were backwards on 20-pin parts.
The macros that were used to identify part families were wrong for a bunch of parts
Finally - analogReadResolution() which was planned for 2.0.0 but forgotten about is now in - it has two valid options, 8 and 10. 2.1.0 will add options 11, 12, and 13 which will use oversampling and decimation (with appropriate warning from the app note on when this is applicable, and the downsides of this) by using the accumulator function)
Last but not least (er, well, I guess actually least, because it also isn't in yet). this week expect 2.0.3 which will pull in improved toolchain version to fix the R_AVR_13_PCREL errors when out of space....

Yeah, I like the idea of the jumpers. I recently found some jumper outlines that I really like - the next version is going to have a lot of tiny little jumpers for people who are interested in doing weird stuff with the board (and it's going to be the same across all the modern AVR breakouts I make - and I am going to have full set)... My current list (not all boards will have all of these, due to space/sanity):

All jumper names are preliminary, suggestions wanted - I think

Jumpers relating to Power Supply
REG: normally closed. Cut to disconnect regulator output from rest of circuit entirely
VUP: normally closed. Cut to isolate Vcc from Vcc pin of UPDI header(s)
VSER: normally closed. Cut to isolate Vcc from Vcc pin of FTDI header.

Relating to Reset:
RST_EN (reset enable or disable) - on tinies, this disconnects the whole reset circuit from the pin, on others, this only disconnects DTR from the cap - for the below:
RST_CAP (not for tinies) - if RST_EN cut, jump this to tie the side of the cap normally on DTR to gnd?
DTR_IO (not for tinies)- if RST_EN cut, jump this to tie DTR to an I/O pin
ERZ_RST (on tinies) - if RST_EN not bridged, this could connect another pin for "ersatz reset"

Others:
CTGN - connected by default, connects the "CTS" pin of serial header to ground.
CTXD - if CTGN cut, bridge this to connect "CTS" pin to an I/O pin (specifically, UART0's XDIR pin - so you could use that header for RS485 if you wanted to)

82

Others:
CTGN - connected by default, connects the "CTS" pin of serial header to ground.
CTXD - if CTGN cut, bridge this to connect "CTS" pin to an I/O pin (specifically, UART0's XDIR pin - so you could use that header for RS485 if you wanted to)

I like how you're making the normally redundant "CTS" pin useful - awesome! Could you add one more use for this pin? ... a jumper to connect "CTS" pin to PA0 to to allow UPDI programming and serial monitor all in one 6-pin connection.

Edit: ...to allow a "plug-n-play" connection scheme like this:

988×394 375 KB

83

Aaah - hmm - the catch with that is it doesn't work well on a tiny, because if using DTR for autoreset, UPDI doesn't work (I haven't been able to make UPDI work with an autoreset circuit on UPDI pin, even if the pin isnt enabled for autoreset, just electrically connected. Have been trying to work out a way to pull that off (but working on another project as top priority now)

Though, for megaAVR 0-series and my other project, it will make a lot of sense (we basically end up with two variants on the 6-pins serial/programming header - 1x6 FTDI-inspired, and the 2x3 (there's the microchip pinout, and the mcudude one with extra pins)...

How many connectors will the new boards that have plenty of space (for the megaAVR 0-series parts) going to support by now? 3? plus cut+jump at designated points to support at least 3 variations on one of them...

That's the great thing about standards - there are so many to choose from! (I don't like proliferating them - and I'm already guilty of this via the 3-pin UPDI header, though I can't say I regret it, since the 6-pin one with 3 pins unused is unnecessarily bulky for the small ATtiny boards.

As an aside, I made the decision to bite the bullet and design my own CH340G adapter and try to get a batch produced in China - hoping they will end up being cheap enough that I won't lose money offering them as the addons, but am not happy with how any of the ones you can buy easily do the voltage switching, most don't break out all the modem control pins - and I'd add a few other jumpers on them too, most notably a "direct" connection (bypassing the usual ~1k resistor) for the TX pin, and ones to disable the RX led so it doesn't lead the pin at all. (and yes, I just had to do things like this last night for what I would argue was a really simple use case - I wanted to monitor the serial data that avrdude sent to my nano with jtag2updi on it - but serial wouldn't even work with just a scope probe on it without making that connection more forceful)

84

Right now I'm using a connection scheme similar to this on a breadboard without any programming or reset issues. Quite anxious to get the prototype PCBs soon so I can test the switching of RX/TX from programmer to target (and back) automatically and complete the firmware and documentation. For the HV programmer (on the breadboard), I'm using your ATtiny1604 breakout board with a 1606 board as the target. I've programmed the 1604 with a revised version of jtag2updi from ElTangas. It doesn't matter what configuration the target's PA0 is set to, because the programmer automatically sends a HV pulse sequence on power-up to ensure UPDI mode until the next POR. As a result, no DTR signal or reset pin is needed on the target as far as burning the bootloader or uploading sketches is concerned. After programming, I'll be monitoring the DTR status to determine if the serial monitor is open or closed to auto-switch the TX/RX signals.

EDIT: Just did a re-read ... yeah, any load connected to the UPDI pin (auto-reset or other) needs to be disconnected prior to programming.

Oh, If your scope's probes have a X10 switch, try this as it will load the circuit far less than X1.

85

Interesting! So the HV programming stuff is working well?

As it happens I've been up to my armpits in jtag2updi code recently making it support the "new" NVM peripheral, which behaves very differently from the old one...

86

Interesting! So the HV programming stuff is working well?

For the Nano HV Programmer and the devices I have on hand, yes (since mid March).

One thing I'd like to add later is improved capability with programming in the field (in-circuit), where it would be ideal to send the HV pulse automatically just after power-up. Might need to use some hardware circuit solution with the atmega328 (Nano), but I've tested this to work when using a tinyAVR as a programmer because it "boots-up" very quickly (5ms).

I have to say that when I started working with the tinyAVRs a few months back, I had the fear of messing with the UPDI pin and getting locked out, but that seems like a distant memory now.

87

DrAzzy:
The new megaAVR 1-series and 0-series ATtiny parts bring exciting new features to the ATtiny family. However, until now there has been no support for these parts on the Arduino IDE. This core provides Arduino IDE support for these new parts. This is the initial release, and we expect issues to come up, however, basic functionality is there, with support for the entire ATtiny 1-series and 0-series product line. Please alert us to any issues you encounter with the core.

Hey DrAzzy, thanks for all your hard work supporting these boards! It's a great service!

I'm using the Attiny412 and I'd like to use the DAC on PA6. I've read where you have stated that there is DAC support, however analogWrite() has no effect or output so I'm assuming the DAC is not already initialized in the IDE board setup? How can I access the DAC in Arduino IDE?

Thanks for so much for your help!

From the Datasheet:

31.3.1 Initialization
To operate the DAC, the following steps are required:
• Select the DAC reference voltage in the Voltage Reference (VREF) peripheral by writing the DAC and AC Reference Selection bits (DAC0REFSEL) in the Control A register of the Voltage Reference(VREF.CTRLA).
• The conversion range is between GND and the selected reference voltage.
• Configure the further usage of the DAC output:– Configure an internal peripheral (e.g. AC, ADC) to use the DAC output. See the accordingperipheral's documentation.– Enable the output to a pin by writing a '1' to the Output Enable bit (OUTEN) in the Control Aregister (DAC.CTRLA). This requires configuration of the Port peripheral.
• Write an initial digital value to the Data register (DAC.DATA).
• Enable the DAC by writing a '1' to the ENABLE bit in the Control A register (DAC.CTRLA).

88

Just a bit more information to followup on my post above:

I'm using the most recent version of the megaTinyCore - at least as of 48 hours ago. I can provide the version number when I get home tonight.

I did find this on your Tindie page for the 412: DAC output (just do analogWrite() on the DAC pin - voltage is between 0V and the DAC reference voltage set in the tools menu; this voltage must be less than Vcc).

However analogWrite is not producing any output on PA6 (Pin 0 in IDE). All other pins work as expected and PA6 does work functionally for serial data.

I did not notice any setting for DAC reference voltage in Tools menu, I will check again later. If I had not set it in Tools, does it default to a setting? The chip is operating at 5V so even if defaulting to the highest reference it should still work.

89

One quick update...

I just got home and re-tested. The DAC is functioning, that's good news, however the voltage output range is 0.0 to 0.625V. I didn't notice this output last night because the voltage out was much lower than I was expecting/looking for.

So the reference voltage must be set, however I have no setting for that in the "Tools" menu as the documentation states. Am I missing it? I adjusted the BOD voltage setting to see if that may affect it however it did not produce any change for the DAC output levels.

90

gabenix:
One quick update...

I just got home and re-tested. The DAC is functioning, that's good news, however the voltage output range is 0.0 to 0.625V. I didn't notice this output last night because the voltage out was much lower than I was expecting/looking for.

So the reference voltage must be set, however I have no setting for that in the "Tools" menu as the documentation states. Am I missing it? I adjusted the BOD voltage setting to see if that may affect it however it did not produce any change for the DAC output levels.

Since 2.0.0, you use DACReference() to set the DAC reference voltage - it can be set to any of:

INTERNAL0V55
INTERNAL1V1
INTERNAL2V5
INTERNAL4V34
INTERNAL1V5

Let me know where in the documentation I missed updateing the method of setting DAC voltage reference. I removed all the stuff from those menus that could be done in the code because, in practice, sucked to have to keep a record of what settings each sketch needed, and very easy to end up with bugs because those settings are saved globally and reset when you switch boards, rather than on a per-sketch basis.

91

Hey, thanks! That works perfectly. I have since discovered this info on the root Master branch of your megaTinyCore GitHub so it's published there. I had ended up at the megaTinyCore/megaavr/extras/ATtiny_x12.md page which has much less information on it (my fault for not tracing back).

The page that does need updating is the Tindie here --> https://www.tindie.com/products/drazzy/attiny412402-dev-board-arduino-compatible/

Thanks again for responding, great work!

92

Just have to throw this out there.

Most of this thread has flown way over my head but these chips have I2C pins. Why can't they be programmed through these?

93

windoze_killa:
Most of this thread has flown way over my head but these chips have I2C pins. Why can't they be programmed through these?

The simple answer is that the chips aren't designed for that.

I'm a hobbyist and have been playing with the attiny1614 and attinty1616 parts and am loving the UPDI programming, which means only three wires (Vcc, GND & signal) from the programmer to the circuit. Many of my designs are meant to be small, so the space that an ICSP header takes up is significant. In some cases, I only need to add a single pad for the UPDI connection and can program the chips easily. I'm naive, but I haven't yet seen the need for a bootloader and been embarrassed to ask :slight_smile:

I'm using an Arduino Nano as the programmer, which is dirt cheap and has been very reliable so far.

My next step is experimenting with an external crystal oscillator as the clock - I have one use case that needs better than 1% accuracy.

These chips have some really cool features. I'd love to see a USB-equipped one.

94

I haven't yet seen the need for a bootloader

Single (cheap) connection for both program loading and serial comm with the host...

95

The main advantage of programming through a bootloader is that you don't need an additional microcontroller running jtag2updi or similar between the computer and target (which of course also entails a USB-serial adapter chip, either on the board of that microcontroller - if it's say a nano - or on a separate board - if it's, say, a pro mini) - you just need the USB-serial adapter.

In practice, I usually don't use the bootloader on these; the nuisance of the reset pin is enough to make it less appealing. What I usually end up doing, instead, is having the serial port connected and the output piped to a terminal program, and then program via UPDI - has the added advantage of the programming process not breaking the serial connection (though this also makes clear the fact that jtag2updi seems to reset the part after programming multiple times - which, despite my farting around with jtag2updi for like two weeks, I still haven't fixed....)

windoze_killa:
Just have to throw this out there.

Most of this thread has flown way over my head but these chips have I2C pins. Why can't they be programmed through these?

For the same reason that an atmega328p can't be programmed over the I2C pins.

The chip, out of the box, only supports one means of programming - for the classic AVRs, that was ISP (SPI pins, using Reset like chip select), for the modern AVRs it's UPDI. Any other method of programming is achieved via a bootloader.

People often want to program over serial, so bootloaders (well, really only one bootloader these days, WestFW's Optiboot) get written to support programming via serial (UART).

There is much less interest in programming via I2C, so bootloaders that do this don't get written (there's also some awkwardness about timing - as you'd need to reset into bootloader, since the flash protection prohibits code executing from non-bootloader sections of the code from rewriting the flash, but resetting the part immediately before starting an I2C transaction is tricky. Probably the way to do it would be to have the device generally configured as I2C slave, and then listen for a specific command that starts the programming routine, and react to that by doing a software reset to run bootloader)... besides, even if you did this, there isn't a convenient way to make a computer do I2C, nor is there a standard for this...

96

I have had a bit of a look at the data sheet but not sure if I am reading it right. Can the UPDI pin also be used as an analog in? If so it would be the perfect chip. I was trying to get away with only 3 pins + VCC in my design.

97

Can the UPDI pin also be used as an analog in?

It looks that way to me... typically AIN0.
I don't yet have a programmer that does the HV UPDI handshake, so I haven't had the guts to reprogram the pin to anything other than the default UPDI function.

98

I am about the design a board for a micro and the 3216/17 seems to be the way to go. Small and has the program memory I need. At least I think thats what I need. When I compile my program for the 2560 it says it takes 14K and I still have a few things to add. The board has to be small and will have a 1.3" OLED display on top. In total I wil have 4 wires coming out, GND, VCC, Analog in and a switched O/P.

99

Hi again. Just before I go butchering my UNO with caps and resistors I would like to make sure I have the process correct.

Being the first time programming a clean chip I want to make sure I get it right. I load the UNO with the programming sketch. Connect it to my custom board using VCC, GND and UPDI and load the optiboot bootloader. Then I do the same with my program sketch.

I think I saw somewhere that the bootloader when you switch on or reset waits for 8 seconds for data on the UPDI pin before running the loaded program. Is this correct? If so, can you shorten that or remove it totally once I have the program in a state I finally like.

100

I'm throwing this here, I think it's right, but happy to have my knowledge tested/corrected.

  • You need to select the right board from the tools->board menu
  • Note how you can choose plain or Optiboot variants (in 2.0.5, at least). I choose the plain one (ie: no Optiboot)
  • You must also select the right chip from the tools->Chip menu
  • Set your other chip settings as appropriate

Now, you choose "burn bootloader". This doesn't install the bootloader (unless you chose one in step 1 above), but sets the fuses consistent with your settings.

After this, you can simply load your programs via the jtag2updi programmer.

Been working a treat for me so far. I have a little test bed 1614 on a SOIC breakout and it's been awesome. Got some PCBs arriving tomorrow for a new project that will use some of the timing functions for pulse width and frequency.