UPDI pin float OK? (ATTiny202)

[jazzjohn27]

When not connected to a programmer, can the UPDI pin be left floating or is it better to pull up or down?

[SpenceKonde]

As long as it is configured to act as either Reset or UPDI, the internal pullup is forced on. so the pin is not in a floating or intermediate state and is fine: In this case the OUT and DIR register bits for the UPDI pin are ignored, and since the pin is held HIGH by the internal pullup, your configuration consistent with low power consumption.

The other pins are a different matter: If you care about power consumption, you need to do something to ensure that they aren't floating or at an intermediate voltage neither high nor low. Either use pinConfigure to disable the input buffer, or set the pins to output, preferably outputting a LOW (in the datasheet, they just say that it should be either HIGH or LOW - but when they test the chip and report typical power consumption, at the top of the table they say they set all the pins output and low; if you could save power by setting some or all pins HIGH, I'm sure Microchip would be testing like that ;-)

There are some cases where setting the pin output is not effective, namely, analog inputs (like a voltage you're reading with analogRead() or monitoring with an analog comparator) the analog output (eg, PA6 from the DAC on 1-series), because those pins pins either must not be output (if it's being used as an analog input you can't also use it as a digital output, at least if you want meaningful data from the ADC/AC), and in the case of the DAC pin, the direction register is overridden by the peripheral, which is outputting a voltage likely neither 0V nor Vdd. In that case, the correct thing to do to minimize power consumption is to use pinConfigure(pin,PIN_INPUT_DISABLE);

However, don't do that for PIN_PA0 (UPDI/Reset) when it is being used those modes. The direction and output registers are ignored (overridden by UPDI or RSTCTRL - and the pullup is forced on... but the input sense configuration can be set to disabled, and that unfortunately does have an effect. Programming the chips after doing that doesn't work (though when I tested this earlier today for someone else in a different thread here, I found that pressing upload repeatedly would eventually work, though I can't rationalize why - my favored theory is that the UPDI peripheral is activated when it goes low, and that overrides the pin function - but waking up that subsystem takes long enough that it has missed enough of the sync field to not recognize it.

(If you haven't seen the note about referring pins, it is recommended that you always refer to pins using the PIN_Pxn macros (where x is the letter of the port (A, B or C on tinyAVRs with 20+ pins, A or B on ones with 14 pins and A only on 8-pin parts) and n is the number of the pin within the port (0 through 7), eg, PIN_PA6 is the DAC output pin, as opposed to using "digital pin numbers" The PIN_Pxn macros are just #defined as the digital pin numbers, but as you likely know, a given pin (say, PA7) won't always have the same number. It's pin 1 on the 8-pin parts, and pin 3 on parts with more pins. (port B gets even more annoying, because of how the pin numbers are backwards compared to the other ports) but in any event, that's not my point: The key point is that across different pincounts within one family, and sometimes between families, if you use the PIN_Pxn macros, your code is much easier to port to different parts: Except on 8-pin parts, PB3 and PB2 are the default Serial pins for all tinyAVRs, and on all pincounts of all tinyAVR 0/1/2 parts, PA1 and PA2 are the alternate Serial pins.

With the exception of the 8-pin parts like the 202 (I think this is why the 8-pin pincount was left out of the 2-series), every new part series' pin functions are a superset of the previous generations pinout. It's even more rigidly consistent on the full-size parts.

Based on how consistent the pinouts of the modern (post-revolutionary*) AVRs are (all the 14+ pin tinyAVRs are consistent with eachother, and full-size parts add new pin mapping options in later part families, but don't remove them), and considering and how engineers in their silos tend to be all like "well if just in this one case we were to move this special function to that other pin, you can handle a weird corner case" and want to do it - that's how the classic AVRs wound up looking like the pin functions were assigned using a diagram of the package, a dart board, and a blindfold - I'm pretty sure there's some manager there whose job it is to keep the engineers in line so they don't make the new parts into another incomprehensible and incoherent mess of adhoc exceptions and special cases)

'*' as in, post Microchip buyout in 2015 - though they were certainly working on the 0/1-series tinys and 0-series megas before the revolution. I think had the buyout happened a year earlier, PORTB would not have been numbered clockwise while PORTA and PORTC are numbered counterclockwise), but they were too far in to change it without the schedule slipping further - yet they desperately wanted to get out the newer more competitive parts. In the early 2010's and late 2000's, Atmel seemed to think the future was XMega. Sometime in the early 2000's they realized Xmega had lost the war, the tinyAVR team rushed out the last few chips they had in progress (there are signs of rushing to varying degrees in all 4 of them. The 841 and 441 were the most polished: their only issue off the top of my head was that the PUE registers are in extended I/O space, even though there are unused registers in the low I/O space that they could have (and should have) used, and that the 241 got dropped, even though the early datasheets said they were for the 841/441/241. The 1634 fared somewhat worse, with a bugged pin that sinks current if the ULP (watchdog timer) isn't enabled, and a very uninspiring ADC, while the 828 fared the worst - not only does it have the bugged pin, the bugged pin is one of the I2C pins, so you have to have the it was clearly originally planned to have a differential ADC very similar to the 841. I think the silicon came back, they discovered differential mode was hosed, told management they needed a respin, and management said "No!" and had documentation hastily remove all references to the differential ADC from the datasheet and shipped. I say hastily because there are many references to "single ended channels", which is a phrase they normally only use when the are also differential channels, and if you look at the ADC register layout, it's the same as the fancier ADC on the 841, except that half the register bits are marked "reserved".), while the megaAVR team pushed out the 168/328PB, and the 324PB - but the 324PB's larger siblings (644PB and 1284PB) were never released. (and let's face it, while the PB's were improvements, they were hardly revolutionary - they were just the P/PA, only with a couple of extra timers and an extra copy of the SPI, TWI and USART interfaces, and no full swing crystal option, and a few other small tweaks (it may well have been only part of the megaAVR team doing that work under a strict deadline, while the others were laying the groundwork for the modern AVRs). Around 2015, Atmel was looking for a buyer (I imagine there might have been some cash pressure - as I said, they appeared to have bet the house on XMega. XMega was initially targeting the same market segment as the ARMs. But an 8-bit core clocked at 32 MHz with a 16-bit address space was sorta bringing a knife to a gunfight, and they weren't very popular (Can't imagine why - unless it's because they clocked lower, had a narrower core, didn't work at 5v logic levels (nor were they even 5v tolerant like many ARMs), and had traded the simplicity of the classic AVRs for byzantine complexity and a steep learning curve... or because they charged more than their competitors even though their chips weren't as capable).

That sort of "rushed development" is also evidenced in the dozens of silicon bugs in the 2016-2020 parts, and the fact that they clearly got the peripherals for the modern AVRs by digging around in the XMega junkyard for useful peripherals, dropping all the baroque, confusing and rarely used features, held the result together with duct tape and spraypainted the result Microchip Red (a great example of the ducttaping can be seen by following the evolution of the event system from the tinyAVR 0/1 (which is illogical shitshow - the 1-series has two sync channels which are the only ones that the TCA and USART can use, and four async channels (other event users could use both sync and async channels).... but the sync channels had the peripherals in different order than async ones, and all the RTC options were on one event channel only) to the megaAVR 0-series, which was at least sane (no more sync/async dichotomy, each port had 2 channels that could use it as a generator, and even number channels had one set of RTC options and odd channels a different set), to the Dx-series - and according to the headers, the EA-series is going to finally get it right - there, all event channels can use the same list of generators, and they gave each port, and the RTC, an EVGENCTRL register; there are thus 2 generator options for each event channel corresponding to each port and to the RTC, and the EVGENCTRL register is how you tell it which pin the that event generator will reflect in a port, or which bit of the RTC to use. Hence all event channels are the same, and you never end up being like "Damn, I used channel 3 for the RTC, but now I realized I needed another pin event from portd, channel 2 is already used for a pin input, so I'm going to have to go back and use channel 5 or channel 1 for that RTC thing...." (the reason I am so familiar with this issue is the event library. I tried very hard to turn the event library into something that one could use in a library; my mental test case was "I should be able to make a library that #requires Event.h, and provide a nice user-friendly way for someone to use a TCB for input capture, without having to understand the guts of the event system".. I didn't get it to that point, (have you noticed that there's no library that uses a timerb to time a pulse on a pin? Why do you think that is? The event handling infrastructure isn't really able to support that, because you DO need to know about the internals of the event system, because you need to plan which channels to use for what, since each channel (on a post tiny 0/1) can only do 2 of the 4-7 ports and half of the RTC options), and for all my effort, I determined it just wasn't possible to have any automated scheme to "pick a channel that isn't used for something else and wont be needed by something a couple lines further down". Code runs sequentially. On line 20, if you need to pick channel 1, 3 or 5 (or 0 2 or 4) and have already used channel 4, your code has no way to know that on line 30, the application is going to need the channel 5 and that it had thus better not use that one.