Adventures in TinyAVR 1-Series

This is what I've been buying, current syringe from Jan 2021: https://www.amazon.com/gp/product/B017RSZFQQ/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1

I keep it in the refrig, but occasionally forget and leave it out for a day. It's really not sticking too well, and stays on the syringe as you described for the print grade. Not sure if it's from the age, leaving it out, or what. Think it's worse now though then it used to be, not sure. It's probably dried out some.

Yea, that RMA291 looks good - thanks! Now just wondering if I should commit to the $$$... Wish I had the ability to design and layout my own drivers . You two are doing great jobs on the drivers, btw!! Very jealous

Well without talking about the circuit design, it didn’t take me too long to learn how to use an EDA software (I use Kicad, I think eagle and easy EDA are also popular ?) just by following tutorials. Making drivers that fit in whatever host is quite rewarding.

For the circuits, FET+7135 are very simple and there must be some shematics on the forum, the linear driver above if it works properly I’ll share the schematic (the boards shipped a few days ago).

For the paste not sticking well, pre applying a thin layer of tacky flux helps (not too much otherwise the paste spreads out)
Using a small dispense tip is also better, less area to stick to, I use red plastic ones… hmm 24G I think it is (they are color coded). For precise dispensing, using a small syringe is incomparably better than the one the paste comes in, I use 1mL ones.

Edit : thanks for the compliments :blush:

Yea, I know the ATtiny85 FET+1's all too well, and have OSHPark drivers of them to accommodate just about anything, many dating back to 2017 from DEL and Texas_Ace mostly. CC linear and optionally a full FET with power efficiency and no visible PWM is preferred now.

Ideally, the most desired support would be having true regulated constant output (lumens) up til a certain power level, depending on the light's design, no visible PWM. Not sure if this requires buck/boost - think so? But certainly for a single cell driving a 6V or 12V LED, then boost is all that's needed, I assume. Same for just buck needed if 2S-4S cells, 3V LED. But certainly for single cell 3V lights, buck/boost with a wide open FET channel would be the best setup?

Gchart's runtime graphs on the SP10 Pro are dang impressive! (https://budgetlightforum.com/t/-/56521)

I have mixed opinions about buck boost due to their lower efficiency and low input current limit. The ones from TI are limited to a peak input current of 4 or 4.5A IIRC, which means that at 3V in they can boost to maybe 2.5A, the most powerful buck boost converter with integrated switches that I know of is the newly realeased LT3120 from Analog with 9.5A average input limit which is much higher and with four 25mΩ switches, better as well. But still if you look at the efficiency graphs page 7 it still dips significantly at higher current in boost mode.
At 2.6Vin 3.3Vout, it dips to 70~75% at ~2.9A out and quite steeply, the graph page one shows 3V to 5V at ~2.9A with 80% efficiency so that’s better, might be able to do 4A at 3Vin 3.3Vout.

It’s quite expensive so I hesitated buying some when there was a few available early July, now it wont be available until mid 2022. It has a relatively larger footprint than TI buck boost converters.

I think for single LED it can make sense, for multiple LEDs I’m less convinced since with the lower Vf a linear driver or a buck in dropout are still able to push some current.

About the FET+ buck-boost topology, it has the issue (with Lume 1 drivers) to not have PWM dimming on the FET channel
One reason is the noise generated due to the 4kHz frequency, but TK new PWM code should solve that.
The second reason is that the FET and BB channel can’t be ON at the same time contrary to linear/7135+FET.
For the latter you ramp up the CC channel to its max say 3A, then the FET starts to add brightness on top of that.
With the former you ramp up the BB channel to 3A, then when the FET turns ON the BB must be OFF, but since FET is unregulated we don’t know what duty cycle gives us 3A and I it is Vin dependant so that we can’t ramp up smoothly from there.

I thought Zebra was known for compact buck/boost, but maybe amp limited, but thought they were one of the best efficient drivers. I don't really know the details though. I'm sure you are right.

Where I work they just bought $75K worth of parts from brokers, like twice the regular price, but will get us about one year in production. It's scary, desperate times.

The SC64c actually uses a 3A buck converter. The SC/H600 MKII did use a buck-boost, I don’t know about the other 3V models.

Yeah, yesterday a bought some boost regulator, a few minutes after that they were all gone from Mouser and Digikey, even the ones in order for the end of the year, that was close :open_mouth: . I was actually wondering if with the current situation there might be scalpers.

Ahh, so if the SC64c uses only a buck, it would drop output/amps when the battery drains below a certain level, least on the high modes?

I saw somewhere a mention of a shortage of these parts, but Digikey claims to have 5000+ of them (3217) in stock right now. I suspect the commercial lights are using 32 bit parts now, and we (Anduril fans) should be looking in that direction too. They have features we will want someday, that will never fit in an AVR. Examples: USB PD charging, powerbank function, OLED screen, etc.

Link here: https://www.digikey.com/en/products/filter/embedded-microcontrollers/685?s=N4IgTCBcDaIIYBcEEsB2BPAzGAjAdhAF0BfIA.

All the 17's (1617, 3217, etc.) are 24 pins with extra I/O, but in the bigger 4mm x 4mm package, compared to the 1616 at 3mm x 3mm.

Commercial lights mostly use lower grade MCU's, not more advanced. All depends exactly what you are talking about w/commercial lights. 32 bit MCU's are fairly big footprints, costly. Projects at work use them for high end controllers on fairly complex boards, having to do some complicated tasks. It's hard to describe, but a flashlight is a simple device compared to most use cases of MCU's.

By 32 bit parts, do you mean a 32 bit MCU or 32K bytes of flash? The ATTiny's, and actually all AVR's are all 8 bit processors (https://en.wikipedia.org/wiki/AVR_microcontrollers)

What I do like about the 24-pin VQFN at 4x4 is the pin spacing is larger than the 20-pin VQFN, 0.5 mm vs. 0.4 mm - should be easier to reflow.

I assume there is no DIP package available for the tinyAVR 1 series? Would be great for breadboard prototyping. Otherwise I’ll have to reflow it to an adapter PCB.

Tom, oops, I didn’t mean to imply “most” commercial lights, just that there are some fancy commercial lights with features Anduril doesn’t support and probably would be difficult with an AVR. By 32-bit I meant 32-bit MCU like ARM or RISC-V. I’m a programmer but not really a hardware guy, so I trust your wisdom about circuit board difficulty. One thing I’ve wondered in particular is how difficult it is to use WLCSP packages, which are very tiny.

Here is an example of a fancy commercial light that would be hard to implement with Anduril/AVR:

Add to that, it seems like most Anduril lights other than Hank’s are quite difficult to reflash, and Hank had to make special arrangements like his USB dongle. The AVR1 makes it easier but it would be a lot nicer to have a USB-rechargeable light with 2-way USB communication, so that if you wanted to change the firmware or customize the UI, you could just plug the USB cable into your computer and customize away. So that means the MCU needs a boot loader and a USB comms stack. It might also be possible to handle li ion charge control in the software instead of using a separate board for that.

Here’s the Pine64 Pinecil soldering iron, which is controlled by a 32-bit RISC-V processor: Pinecil | PINE64

We can think of a soldering iron as a type of deep-infrared incandescent flashlight, so the control issues they face are not that much different than ours. Their MCU is a GD32VF103 which is similar (basically a clone) of the ST32F103 except VF instead of F designates RISC-V instead of ARM. They also have ARM versions. It is a very nice chip with analog i/o galore, that supposedly costs under $1. Here is a dev board for it:

I agree that the package for that chip is rather large for a flashlight. I believe there is a QFN version that’s a little smaller, but something even smaller with fewer pins as needed would be nice.

Hhmm, I don't think a display is a stretch for Anduril on a AVR ATTiny. There was one, maybe two threads here on incorporating a display with a custom driver and think they used a PIC, but still an 8 bit MCU. Even with 16K Bytes, the build I've done for the 1616 is still like 9200 bytes, so 44% code space still available.

Here: https://budgetlightforum.com/t/-/42991 and https://budgetlightforum.com/t/-/61255

Some Background:

https://budgetlightforum.com/t/-/43444

https://budgetlightforum.com/t/-/63478

https://budgetlightforum.com/t/-/26036 (goes back to 2014)

I found he mentions: PIC16F1575, but not sure that was the only PIC. tterev3 was way ahead of his time here on BLF, and many of us didn't really know what to do with this tech.

I don't know, the more I read about these mods, there was little we could do but be amazed. Too difficult for most of us to do those type of mods, didn't hook up with a manufacturer or even someone who could make the parts that I know of. He did post source code at one point but think it was written in ASM, if so, difficult to work with.

I was very interested in the MELD RGB stuff at the time, but was scared off by his abilities with micro wiring - didn't think I could do it. tterev3 is super talented in many ways.

For the I/O to a OLED display, I believe the USART/SPI/I2C would have it covered.

His latest EC01 mod uses the PIC18F26K40.

The QFN version is apparently 6x6mm which in a multi cell light is a totally acceptable size.
WLCSP uhh…
Firstly with the basic affordable capabilities of board houses you can’t fit traces between the pads (looking at a STM32 WLCSP with 0.4mm pitch), using vias to route on the other side requires a special capability called filled via otherwise the solder will fill the via and could make poor contact to the chip’s pad.
So theses manufacturing requirements (and maybe other ones) will make the PCB significantly more expensive.

Secondly for hobby makers like us the soldering is a bit scary, I suppose it can be done with paste and precise stencilling, but I think manually placing balls would be more reliable (I’m just guessing, never done that) but time consuming.
If anything goes wrong during reflow you have to start over from the beginning, whereas QFN bridged pads can be easily fixed with a soldering iron.

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.