For drivers with enough room, another option is to use a 6x1 1.27mm pad layout, since adapters for those can be purchased pre-made. This covers pretty much all the other reasonably compact layouts though, and should be pretty universal as long as the pads are kept together in a tight formation. 
Gchart has had some success with the new one series mcuās (ported ramping ios). They only need three pins.
Thatās what Iām doing next, actually. I just need to get a programming key built so I can actually flash the MCU. And, of course, do all the porting work. But 1634 has pretty decent support in avr-libc, so I donāt think there will be as much trouble there as trying to get newer MCUs to work.
Most of the difficulty will probably come from removing assumptions built into my code, making it amenable to different MCU architectures. The 2nd arch is generally the hardest to addā¦ 1st is easy since everything can be hardcoded. 2nd is hard because everything was hardcoded the first time. Then the 3rd and later should be easier since the 2nd did most of the hard parts.
Preach it, sister! If/when you get over the ā2nd chipā hurdle, Iād be up for trying to port it to the new 1-Series. Since ya knowā¦ youāve done most of the hard work in abstracting some of the architecture. Oh, to have HAL-like stuff done and all kept within tk-attiny.hā¦ what would make things a breeze.
Oh, um, I forgot to post about it before, butā¦ I have tiny1634 working, thanks to a HQ adapter. Dingwat sent me a couple.
I should have the code published sometime soon.
Nice work HQ and TK. 
Awesome, hopefully you have lots of memory left over.
Are you planning on sticking with the 85 or do you want to transition to the 1634?
I like the idea of making an adapter board to convert one of the new mcuās to the old 85 footprint. The new one series has a chip with 2M of memory and a lot of pins. Enough for a crystal to make timing accurate and for an external temperature sensor on the driver and/or mcpcb. Plus only three pins on the programming key.
Not sure how feasible it is but you and the hardware people would be set for a long time.
It also has virtually no support in the open-source toolchains, so I donāt have a way to build code for it or flash code after building. I canāt really consider it as a viable option until those issues are fixed. Itāll be pretty cool some day though.
For now, the tiny1634 provides plenty of room to grow. It has twice as much ROM as tiny85, and a bunch of extra pins. Iāve also started on tiny841 support, but I donāt have it working yet.
Iāve been compiling for the the 1-series chips using GCC, you just need to include Microchipās ādevice family packā files. Now, I havenāt flashed them from Linux yetā¦ I really need to try that.
The 1-series chips have been pretty nice. While limited to 4KB, the attiny412 makes a great PIC replacement in existing lights due to itās pinout. I just replaced the MCU in my Convoy H1 with one (with RampingIOS). Iāve done the same with the D25 headlamp. For new development (custom boards), Iāve been using the X16 (ie: 416, 816, 1616, and 3216) where I need a smaller footprint, more pins, or more flash.
If you come up with something cool though, I bought 25 of the 1634 right before I switched over to mostly 1-series dev. Hopefully theyāll get used someday, even if itās not by me.
It sounds like we should coordinate to get FSM supported added for those too. Or perhaps I should get off my butt and take a close look at the work youāve already done. This may just boil down to me being slow.
Do you know if the newer chips have support in avr-libc? If so, that would make a lot of things easier. If not, itās definitely still doable, but itāll need to abstract out potentially the entire C library. Or at least parts of it, and how it hooks into other files.
Also, Iām way behind on getting your code into the repository. Would it be okay for me to import everything at Index of /blf/firmware ?
I took a look at FSM a while ago, I should take a stab at it. I havenāt worked with finite state machines since college (about 12-15 years ago!) but it shouldnāt be terrible. Mostly just swapping out register names. Oh, and for timed tasks Iāve been using the RTC instead of WDT. But thatās about it.
Iām using avr-gcc but you need to bring in the Atmel Device Family Pack files. A sample build script is here (originally based on one of yours)
Yup, you can grab the stuff Iāve got up there if youād like.
Itās not exactly the cleanest code. Itās a spaghetti monster, after all. And the published branches donāt have tiny1634 support yet, so they lack the changes I made to improve portability.
Iām still pondering how best to support lots of different hardware simultaneously, in a manner which is relatively clean. It could use a lot of refactoringā¦ beyond what I did for tiny1634 support. But Iām not sure exactly how to structure it yet.
This is from a previous post by gchart. Adventures in TinyAVR 1-Series
The 3217 is cheaper and more future proof. Iād like to think that this latest generation chip would have better internal clocks and temperature sensors but I canāy find anything in the spec sheets to prove it.
No one spends more time programming and testing than you do. It doesnāt seem like it took a long time to outgrow the 13,25,45 and 85. This time you get to choose the new chip. Twice as much memory as a 1634 and a three pin programming key canāt be a bad combo.
Iāve written and flashed simple firmware for the 3217 for a specific project. Iāve got most of the stuff working: Internal temp sensor, ADC, PWM, pin interrupts, software reboot and RTC (instead of WDT). All I have left for full functionality support is OTSM with the low power consumption options to run the MCU from the cap. After that I just have to fix the definitions and Iāll be ready to go. Besides 3 pin flashing, the 1617/3217 interested me because it has a DAC. The choice between 1617 and 3217 was pretty easy, the 3217 only costs a few more cents than the 1617, no reason not to go with 32 kb.
Thatās a really interesting feature. Have you found it to be stable enough to supply control voltage to other chips?
I havenāt started testing it yet. I have a 3217 driver that will be on itās way from OSH Park shortly. I had some space over so I included a via for DAC output so I can play with it a little. Just got to get my 1634 firmware fully compatible with 3217 by defines first.
The low-level hardware interfaces usually seem to me like the hardest part of making firmware. Each chip has its own particular way of setting registers to configure it in a useful manner. Once the hardware is configured though, I like building the upper layers of the code.
Thatās why it takes me so long to add support for new MCUs in my UI toolkit. Most of that work is about the low-level interfaces, and Iām more of an application developer at heartā¦ not as much of a hardware enablement developer.
I should probably rewrite the entire hardware abstraction API. What I have now is completely ad-hoc and not particularly coherent. But until Iāve added a few more chips, I donāt know how best to organize it. Attiny1634 was relatively easy compared to something like tiny3217 or a PIC chip, because it wasnāt much different than tiny85.
If you can help isolate the hardware-level stuff, Iād be glad to try and help with the porting to 1-series.
Iāve never looked at PIC but I probably should sometime as it seems that many non-BLF flashlight drivers use PIC. But it has been handy that the X12 AVRās use a PIC layout (thinking retrofit here).
Tterev has done some beginners guides to picās, I think Toykeeper has stashed some of his work on the repository.
I think an adapter board would be the easiest way to tackle picās. Wight made one for the eight pin chips although I donāt think anyone ever finished the project.
Hereās something unrelated that may interest Toykeeper, hopefully the arduino code doesnāt make her eyes hurt. gxb172-attiny841/GXB172ATtiny841_V1p0_WIP.ino at master Ā· loneoceans/gxb172-attiny841 Ā· GitHub
Iām very glad to learn about the port to attiny1634.
The smaller size coupled with larger capabilities is good.
So is the slightly lower price.