I don’t know if this link about the avr-1 hardware is already in this thread, but I just came across it and found it pretty informative:
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.
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.
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.
Awesome, looking forward to reading more about it!
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.
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)
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.
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).
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.
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:
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.
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…
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.
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.
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.
Sorry for the possibly stupid question but does it matter on which pin the OTC is connected ? Either ADC0 or ADC1 pins ?
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
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.
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.