Adventures in TinyAVR 1-Series

276 posts / 0 new
Last post
thefreeman
thefreeman's picture
Online
Last seen: 3 min 28 sec ago
Joined: 01/06/2020 - 09:56
Posts: 871
Location: France

Isn’t that a board you made ?
https://oshpark.com/shared_projects/URoxundY

Yeah I was thinking of swaping the diode with a PFET, plus with a diode the output current will start to decrease once input voltage reach ~3.05V. (Not that much, should be ~90% output at 2.8V input)

What package size is consireded not too small ? I use SOT-723 personnaly but maybe I should use a package a little bigger so that it’s easier for other people to build ? (but SOT-23 is definitely too big).

gchart
gchart's picture
Offline
Last seen: 12 hours 37 min ago
Joined: 03/19/2016 - 11:57
Posts: 3158
Location: Central IL

Ohhh yeah. I forgot I had shared that out. I haven’t ordered that yet, but it’s based on Wagner’s schematic just with the recommended Schottky diode added. Adding holes for header pins is a good idea.

In terms of PFET size, I’ve got a bunch of SC-70 / SOT-323 so I usually use that. It’s small, but not crazy small. I’d say use whatever you want though.

Forsythe P. Jones
Offline
Last seen: 6 days 8 hours ago
Joined: 08/15/2021 - 00:40
Posts: 413
Location: California

UPDI looks nice and should normally require just one special pad in a flashlight board, the bidirectional data pin, since VCC and ground can be obtained from the battery contacts.

It looks like it’s possible to get the cpus into a state where to activate UPDI, you have to send a 12 volt pulse, like in the old avr’s. There are gadgets around for that:

https://www.tindie.com/products/dlloyd/arduino-nano-hv-updi-programmer-f...

I like that UPDI gives a full bidirectional debugging interface and there is even gdb support for it. I wonder how much code space the gdb remote stub consumes.

The CH340 thing looks nice though I think it’s good to support also programming using a generic MCU board or raspberry pi with gpio pins.

thefreeman
thefreeman's picture
Online
Last seen: 3 min 28 sec ago
Joined: 01/06/2020 - 09:56
Posts: 871
Location: France

Forsyth P. Jones wrote:
UPDI looks nice and should normally require just one special pad in a flashlight board, the bidirectional data pin, since VCC and ground can be obtained from the battery contacts.

That’s what I do in small dense drivers where I don’t have the space for the + and GND pads, when there is space I think the 3 pins programming key is more convenient though.

Regarding clicky firmware, nobody has ported the community firmwares like bistro, biscotti… etc to the attiny 1 series yet ? Not that I am particularly interested myself in clicky flashlights but I might as well add hardware support for it to make the drivers universal.

I haven’t looked too much into it but if I understand correctly there is OTC that require a small capacitor (1uF) connected between an ADC pin and ground (looking at TA drivers, but shouldn’t there be a high value resistor in parallel for it to discharge?), or OTSM which is more reliable and require a bigger capacitor (such as a 0805 47uF one) to power the MCU while power is OFF, connected between VCC and ground I suppose?

Mike C implemented OTSM in his firmware which I think is not finalised yet, if I recall the discussion we had he explained that on the 1616 he couldn’t get the frequency to switch between 3.33Mhz and ULP clock (32.768kHz) so he had to run it at ULP all the time which was limiting for ramping and stuff…

Forsythe P. Jones
Offline
Last seen: 6 days 8 hours ago
Joined: 08/15/2021 - 00:40
Posts: 413
Location: California

That’s interesting if changing the clock being a hassle. I wonder if they made a boo boo. The “fuses” that control the clock are eeprom cells so I was imagining being able to reprogram them and self-reset somehow. But I haven’t looked into it. Oh well. I could imagine the 0805 capacitor being an issue on the smallest boards. I wonder how the many cheap 1aaa lights with these functions do it? I have a dead one that I’ve been wanting to tear down, so I will check for large capacitors on the board.

If there’s no actual connector for the UPDI then I hope the programming gizmo can use a clip or ez-hooks or something, so you don’t have to press it down on the board manually. I think it would be very useful to be able to connect to the board and set it down so you can use your computer with both hands, for debugging and so on.

I can look into the UPDI gdb integration if that’s helpful. It will make life easier for software dev. Earlier I had been fooling with the idea of running a Forth interpreter on the AVR, but gdb is probably less crazy for most C programmers.

I better say that I’m a generally good C programmer but it’s been mostly with Unix-oid systems and I’m not that clueful about this small embedded stuff. I’ve always found it interesting though.

gchart
gchart's picture
Offline
Last seen: 12 hours 37 min ago
Joined: 03/19/2016 - 11:57
Posts: 3158
Location: Central IL

I have had no trouble changing the clock speed at any time. It’s done right in the firmware and doesn’t require messing around with fuses. Changing clock speed is actually part of the Anduril hwdef files I have for the 1 Series. Ohh, and I have a big clock speed/PWM testing file on my server (link to post)

I have written clicky firmware for the 1-Series. It’s nothing too special and in general most lights are going towards e-switch anyhow. Like thefreeman pointed out, the 1-Series requires the use of an OTC to track presses (noinit decays in about 45 minutes instead of around 1 second as on earlier chips).

The UPDI protocol does not have a defined connector. In flashlights generally there isn’t enough room for anything else besides pogo pin pads.

I have done debugging on the 1-Series chips (within Atmel Studio). It doesn’t require anything special, just plug in the UPDI to an adapter; I used the nEDBG on an Xplained Nano.

thefreeman
thefreeman's picture
Online
Last seen: 3 min 28 sec ago
Joined: 01/06/2020 - 09:56
Posts: 871
Location: France

Yeah I’ll just add pads for an OTC, looking for in detail about OTSM it seems like it would require a LDO with reverse current protection, which I haven’t found in SC-70 package, the ones small enough than I found (and use) are WSON (2×2mm QFN) but I think people won’t like using those, plus they’re more expensive.

Indeed there isn’t enough space for a connector, but if a more permanent connection is needed for debugging then just solder wires.

thefreeman
thefreeman's picture
Online
Last seen: 3 min 28 sec ago
Joined: 01/06/2020 - 09:56
Posts: 871
Location: France

Sorry for the possibly stupid question but does it matter on which pin the OTC is connected ? Either ADC0 or ADC1 pins ?

gchart
gchart's picture
Offline
Last seen: 12 hours 37 min ago
Joined: 03/19/2016 - 11:57
Posts: 3158
Location: Central IL

Not really, either can be used.

I can’t remember if this is fully functional, but it’s a Star-based clicky firmware for t412 that uses an OTC and has borrowed the temperature and battery monitoring from another firmware (likely RampingIOS / D4 UI V2). http://www.ghart.com/blf/firmware/Tests/t412_clicky_otc.c

Forsythe P. Jones
Offline
Last seen: 6 days 8 hours ago
Joined: 08/15/2021 - 00:40
Posts: 413
Location: California

It occurs to me, maybe there is no need to keep the cpu powered from a capacitor while the light is off, to implement clicky switching. Just have an RC timer that is pulled up when the cpu is running and discharges when the cpu off, with a time constant of 0.2 second or whatever. Then on reset, use an adc pin to check the capacitor voltage. That tells you how long the light has been turned off. Could that work? I think the adc inputs have quite high impedance, which suggests there is a chance. You’d still need a capacitor but maybe it could be smaller than 0805.

gchart
gchart's picture
Offline
Last seen: 12 hours 37 min ago
Joined: 03/19/2016 - 11:57
Posts: 3158
Location: Central IL

That’s pretty much exactly what we mean when we refer to an OTC (off time capacitor). We use a small one hooked up between ground and an ADC pin. When the light is on, we charge it up. And when the light is first turned on, we get an ADC reading from it to see how far the capacitor has dropped.

Forsythe P. Jones
Offline
Last seen: 6 days 8 hours ago
Joined: 08/15/2021 - 00:40
Posts: 413
Location: California

Aha, thanks, I didn’t understand the acronym.

thefreeman
thefreeman's picture
Online
Last seen: 3 min 28 sec ago
Joined: 01/06/2020 - 09:56
Posts: 871
Location: France

I measured the current draw on my linear driver.
10MHz : 2.4mA
2.5MHz : 1.1mA

VCC is 2.8V, other stuff should account for less than 0.1mA (LED=5uA) so this is mainly the MCU current draw.

~4 months at 2.5MHz with a 18650 is pretty good.

Your measurements post 29 were done at VCC=5V I assume ? That would explain the difference.

Forsythe P. Jones
Offline
Last seen: 6 days 8 hours ago
Joined: 08/15/2021 - 00:40
Posts: 413
Location: California

There is a very good writeup of the AVR-1 series here, with links to some dev boards on Tindie:

https://github.com/SpenceKonde/megaTinyCore

The page is not new, but I just found out about it. I might order one of the Tindie boards to attempt some software hacking.

Forsythe P. Jones
Offline
Last seen: 6 days 8 hours ago
Joined: 08/15/2021 - 00:40
Posts: 413
Location: California

Oh this is interesting, there is also a new “DX core” line, a follow-on to the old MegaAVR. Most have high pin counts but of flashlight interest is the “DD” series, which will have as few as 14 pins (SOIC only). The 20 pin version will be available in 4×4mm VQFN:

https://www.microchip.com/en-us/product/AVR64DD32

They will have up to 64k program flash, 8k ram, and a bunch of new analog capabilities not seen in the Tiny series. Writeup here:

https://github.com/SpenceKonde/DxCore

Microchip also posted and deleted a document about an AVR-DU series that is probably a ways off, that will have USB on the chip. The document is preserved here:

https://github.com/SpenceKonde/DxCore/files/7041383/AVR-DU-Product-Brief...

14 and 20 pin versions SOIC only but there will be a 4×4mm 28 pin VQFN.

I think in the long run we will want USB in our flashlights (lots already have USB charging). It will make configuration a lot easier than 15 clicks this, 7 clicks that. We can do it with the AVRISP or UPDI wires now, but that takes comparatively special hardware vs. a common USB cable.

thefreeman
thefreeman's picture
Online
Last seen: 3 min 28 sec ago
Joined: 01/06/2020 - 09:56
Posts: 871
Location: France

Forsythe P. Jones wrote:
Oh this is interesting, there is also a new “DX core” line, a follow-on to the old MegaAVR. Most have high pin counts but of flashlight interest is the “DD” series, which will have as few as 14 pins (SOIC only). The 20 pin version will be available in 4×4mm VQFN:

https://www.microchip.com/en-us/product/AVR64DD32

I was thinking that with 12 bits ADC, Vsense could be read by the MCU and the current regulation done with a PID algorithm, like it is done in the YLP Unicorn 1.0 or gekko, which decreases components count a lot, but the min Vref is 2V of those so in the end it’s not more precise than 8 bits with 0.55V Vref…

The 10 bits DAC could be used instead of 10 bits PWM in CC drivers.

USB communication with would certainly be nice if you could load a config file instead of having to compile and flash.

Forsythe P. Jones
Offline
Last seen: 6 days 8 hours ago
Joined: 08/15/2021 - 00:40
Posts: 413
Location: California

Spencer Konde’s document mentions differential ADC in some of the 2-series parts, and also increasing ADC resolution by oversampling. Could any of that help?

I have another crazy idea for getting data into the light, for stuff like configs. It would be mostly for existing lights. The idea is replace the battery with a dummy one with wires coming out, so the power would actually come from outside. You’d need a tailcap with a hole to run the wires through. Then you could modulate the voltage (say between 3.5 and 4) to send data. Do you think this could work? Any idea what speed it could run at? That is, would the MCU get confused if its Vcc changed too quickly?

Even if it were only a few bits/sec, that would be more convenient for loading a config than all that clicking. It would be great if it could reach the kilobit range, allowing uploading a complete firmware build in reasonable time. It would not have to run the main flashlight led, so only a few milliamps would be needed. So it could be run by an MCU with a DAC output and a small amplifier, powered by USB.

gchart
gchart's picture
Offline
Last seen: 12 hours 37 min ago
Joined: 03/19/2016 - 11:57
Posts: 3158
Location: Central IL

thefreeman wrote:
I was thinking that with 12 bits ADC, Vsense could be read by the MCU and the current regulation done with a PID algorithm, like it is done in the YLP Unicorn 1.0 or gekko, which decreases components count a lot, but the min Vref is 2V of those so in the end it’s not more precise than 8 bits with 0.55V Vref…

The 10 bits DAC could be used instead of 10 bits PWM in CC drivers.

USB communication with would certainly be nice if you could load a config file instead of having to compile and flash.

I’ve wondered what it would take to just use the MCU for a linear driver instead an op-amp. I know even the brand-new 2-Series has improved DAC and ADC. Shoot, it looks like Mouser even has the new attiny1626 in stock

thefreeman
thefreeman's picture
Online
Last seen: 3 min 28 sec ago
Joined: 01/06/2020 - 09:56
Posts: 871
Location: France
Quote:
Spencer Konde’s document mentions differential ADC in some of the 2-series parts, and also increasing ADC resolution by oversampling. Could any of that help?

Probably, maybe this is what Inferion ( Unicorn/Gekko driver designer) talks about here and other comments further down. This goes well above my head though.
The end result is a driver with very few components : a RPP PFET, the MCU (+ decoupling cap), a current sense resistor, a NFET and RC filter to drive the gate of the NFET with PWM, 7 components! Compare that the 17 components for the same functionality with by using an Op-amp (18 in the Noctigon KR4 driver).

gchart
gchart's picture
Offline
Last seen: 12 hours 37 min ago
Joined: 03/19/2016 - 11:57
Posts: 3158
Location: Central IL

Scratch that, the 2-Series does have a better ADC but they actually removed the DAC. Hmm, could probably still do with PWM through an RC filter.

I have some reading to do.

Tom E
Tom E's picture
Online
Last seen: 4 min 47 sec ago
Joined: 08/19/2012 - 08:23
Posts: 14685
Location: LI NY

Also Microchip themselves has them in stock, little cheaper in shipping actually, least for me.: https://www.microchip.com/en-us/product/ATTINY1626

 (ref: https://en.wikipedia.org/wiki/ATtiny_microcontroller_comparison_chart)

 

thefreeman
thefreeman's picture
Online
Last seen: 3 min 28 sec ago
Joined: 01/06/2020 - 09:56
Posts: 871
Location: France

gchart wrote:
Scratch that, the 2-Series does have a better ADC but they actually removed the DAC. Hmm, could probably still do with PWM through an RC filter.

I have some reading to do.

In the Unicorn they use PWM with an RC filter :

R2 and C1.
It’s possible that the resolution of the DAC would be insufficient anyway since a small difference of the drive voltage can result in a big resistance change of the FET.

gchart
gchart's picture
Offline
Last seen: 12 hours 37 min ago
Joined: 03/19/2016 - 11:57
Posts: 3158
Location: Central IL

Hmm, that’s with an attiny25. So clearly it’s feasible. Based on that article you linked to, he clearly has a lot of fancy math/firmware stuff going on. But I wonder if that can be simplified a bit (or made easier with the newer peripherals of the 1- or 2-Series).

thefreeman
thefreeman's picture
Online
Last seen: 3 min 28 sec ago
Joined: 01/06/2020 - 09:56
Posts: 871
Location: France

The Unicorn goes from 2.7A to ~10.5mA (rated 850lm to 3lm), so about about 255:1 dimming range, with a 16mΩ shunt, Vsense= 43.2mV meaning that he manages to read 170uV with a 10bit ADC.

In the gekko he improved the dimming range, 900 to 1lm, probably 2.9~3A to 3mA, so about 1000:1, with a 10mΩ shunt, Vsense = 30mV down to 30uV!.
The board even says 5A-1mA, which would mean a even higher range : http://forum.fonarevka.ru/showthread.php?t=45395
(There is one additional resistor and capacitor near the MCU, no idea what they are for).

So yeah, fancy maths indeed.

Edit : the resistor and cap are probably a low pass filter to generate noise via PWM for dithering as mentionned in this App note

There is also an App note about oversampling with Attiny0 and 1 series with example code.

Mike C
Mike C's picture
Offline
Last seen: 2 days 21 hours ago
Joined: 01/22/2014 - 08:03
Posts: 2582
Location: Sweden

Hi again, been on vacation in Switzerland climbing, cycling, hiking etc etc, and us usual my vacations are email and computer free… so a late reply as I’m catching up a bit.

I’ll just clarify this a little…

thefreeman wrote:
Mike C implemented OTSM in his firmware which I think is not finalised yet, if I recall the discussion we had he explained that on the 1616 he couldn’t get the frequency to switch between 3.33Mhz and ULP clock (32.768kHz) so he had to run it at ULP all the time which was limiting for ramping and stuff…

With the 3217 I ran it 3.33MHz, then when power off with clicky switch is detected I ran the periodic power on check interrupt by using the ULP (ultra low power) clock at 32.768kHz. With 125ms intervals I got plenty of time, around 10 seconds if I remember correctly. The problem I have with my 1616 driver is not changing the clock, it’s that when the clock switch is done the OTSM cap is drained to the point where detectable off time is too short for me to use (around 1 second). I couldn’t solve it out so I just went with ULP clock all the time. Issues with slow ramping have been sorted so I don’t really have any reason to use any other clock than the ULP now.

With all of this said it could very well be a driver design issue. I’ve only used the 1616 with my boost driver which is 17mm. It’s the first driver that forced me off the larger 3217 due to space constraints. The boost driver has 2 × 68uF input caps and these of coarse have to be depleted before the pin interrupt can detect power off, which in turn can mess a bit with remaining capacity on the OTSM cap once the pin interrupt triggers. Instead of figuring it out completely I just went with ULP all the time as it appears to buy me enough time to use OTSM as intended with my current boost driver design.

thefreeman
thefreeman's picture
Online
Last seen: 3 min 28 sec ago
Joined: 01/06/2020 - 09:56
Posts: 871
Location: France

Thanks for the clarification.

BTW Digikey just received new stock of Attiny1616-MNR , currently has 1780 in stock.

Forsythe P. Jones
Offline
Last seen: 6 days 8 hours ago
Joined: 08/15/2021 - 00:40
Posts: 413
Location: California

What is the advantage of OTSM (leaving the MCU powered by a capacitor while the battery is disconnected) instead of OTC? OTC would seem to use smaller parts. Just wondering.

gchart
gchart's picture
Offline
Last seen: 12 hours 37 min ago
Joined: 03/19/2016 - 11:57
Posts: 3158
Location: Central IL

With OTSM you actually keep track of time and can say with certainty “the light was off for 0.73 seconds”. With an OTC you’re just taking a measurement of the capacitor which is fairly imprecise and will change depending on whether the light is hot or cold.

Mike C
Mike C's picture
Offline
Last seen: 2 days 21 hours ago
Joined: 01/22/2014 - 08:03
Posts: 2582
Location: Sweden

In addition to what gchart wrote, you get different readings depending on the battery voltage with OTC. If light temperature and the actual off time are both exactly the same you will get a different reading if battery voltage is 4.2V compared to if was 3.5V. If you only have a single type of off press in the firmware, not short off and long off doing different things, then OTC is reliable, tried and tested. I have short and long presses in my firmware, OTC is not consistent enough for that.

I find an old posting I made about the subject: https://budgetlightforum.com/comment/1263664#comment-1263664

Forsythe P. Jones
Offline
Last seen: 6 days 8 hours ago
Joined: 08/15/2021 - 00:40
Posts: 413
Location: California

Thanks, that was interesting, I didn’t realize that the capacitors were that unstable with temperature and (apparently, from the linked thread https://budgetlightforum.com/node/58172 ) with air pressure. There are stable types of capacitors but I guess they are bigger. I’d hope that resistors are pretty stable either way. You can measure the battery voltage to calculate the RC timing if R and C are known, and you can measure the temperature too, but maybe the capacitance change with temperature is not predictable enough to calculate. It’s still interesting to hear that OTC ends up being too imprecise to distinguish a short from a long button press.

Do you mean you use ULP (32khz clock) literally all the time, and the Anduril UI still works? Is there a reasonable way to switch out of ULP at least some of the time, when more CPU is needed?

Pages