Adventures in TinyAVR 1-Series

Tom_E · 2021-08-27T11:26:59.000Z

I've come across the JayCarlson website before, probably this article. It is a pretty good article, though would be nice if it was more active with comments, and updated. Maybe Gabe can add a link to the OP.

thefreeman · 2021-08-30T07:12:07.000Z

The programming key linked in the first post is the older one (with UDPI in the middle).

gchart · 2021-08-30T12:19:02.000Z

thefreeman:

The programming key linked in the first post is the older one (with UDPI in the middle).

Good catch. Updating the first post now…

https://oshpark.com/shared_projects/Nf5s0GMe

I need to go through and update that first post a bit. I’ll add Tom’s link later today. I also want to add another driver and info about using serial adapters and pymcuprog to flash.

thefreeman · 2021-08-30T12:25:14.000Z

gchart:

Good catch. Updating the first post now…

OSH Park ~

I need to go through and update that first post a bit. I’ll add Tom’s link later today. I also want to add another driver and info about using serial adapters and pymcuprog to flash.

Cool :+1:

I’m making a series of linear drivers with high dynamic range, I received and tested the one mentioned above. I’m making some modifications and others sizes and I’ll make a new post for them with building info.

gchart · 2021-08-30T12:29:08.000Z

Awesome, looking forward to reading more about it!

gchart · 2021-08-30T13:53:57.000Z

Ok, I’ve added a few things to the first post.

One thing worth calling out… I’ve recently been trying to come up with a more universal and accessible flashing method. I think I’ve settled on one.

Uses a USB to Serial TTL adapter such as one built on the CH340 or CP2102. I’ve even built one from scratch. Note, on the CP2102 style I had to disable the LED that was connected to the RX pin (bad design!). And the one I built from scratch, I had to thicken the USB port area so it wouldn’t fall out of the port (typical PCBs are 1.6mm thick and a USB slot needs around 2.2mm).
Those adapters are cheap and easy to come by. If you do stuff with Arduino or other dev boards, you might already have some sitting around.
Use the pymcuprog utility to flash firmware. This utility is open-source, based on Python (install using pip) so it can be used on any platform, and was actually created by the folks at Microchip.

thefreeman · 2021-08-30T19:32:30.000Z

Ah nice you made a serial programming oshpark board

Regarding the SOA for the frequency, the limit for 10MHz seems to be 2.7V, so if there is diode before the MCU VCC falls a bit under that just before LVP, I guess in practice it’s not a problem, that’s how it is on the driver you made ?

Edit : if I can suggest to add holes for pins/dupont connectors to it, when flashing a driver with a different programing pad layout (or with just UDPI pad)

gchart · 2021-08-30T19:06:02.000Z

Actually, I should clarify… that’s not my board (I am not Stefan Wagner). I just downloaded his gerber and ordered the parts. Since his creation of that, there has been an update to the UPDI serial recommendations to use a diode to connect the RX and TX pins. So I used his PCB design but actually ran a 1.5K resistor + Schottky from the TX pad to the RX instead of using the existing pads meant for a 4.7K resistor. I think the original layout technically works, but isn’t as clean/reliable of a solution.

Regarding 10MHz down to 2.7V… I should do some more testing on that I guess. This is one reason why I think it’s better to use PFETs instead of diodes for reverse polarity protection. It’s not dropping voltage and therefore increases the accuracy of a voltage read against the VCC pin.

thefreeman · 2021-08-30T22:48:34.000Z

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 · 2021-08-30T19:26:41.000Z

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 · 2021-08-30T22:28:22.000Z

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:

Tindie

Arduino Nano HV UPDI Programmer for tinyAVR 0/1 by Dlloyd's Store on Tindie

This Arduino Nano 12V HV UPDI Programmer is for tinyAVR® 0-1 series MCUs and Arduino IDE. Works with ease for all modes of the UPDI pin.

Price: USD 5.00

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 · 2021-08-31T09:48:57.000Z

Forsyth P. Jones:

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 · 2021-08-31T09:53:56.000Z

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 · 2021-08-31T12:01:06.000Z

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 · 2021-08-31T12:03:39.000Z

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 (2x2mm 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 · 2021-08-31T12:32:39.000Z

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

gchart · 2021-08-31T13:13:14.000Z

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 · 2021-08-31T17:27:47.000Z

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 · 2021-08-31T17:32:38.000Z

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 · 2021-08-31T18:26:48.000Z

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