I can add support for the 1616/1617/3216/3217 chips whenever there’s toolchain support for them, but that’s not really up to me.
Even then though, I still plan to support older hardware… the whole point of having a kernel on these is to abstract out the hardware details as much as possible so hardware and software can be mixed and matched. I don’t want to abandon all the nice lights people already have.
There's no toolchain support? I see those devices listed under AtmelStudio, so I would think the underlying support in the toolchain it uses would be there?
Tests are still running, but so far the MF01-Mini looks totally fine. It regulates to a stable level more quickly than older versions, and then stays pretty flat afterward. So far I’ve tried starting from turbo and starting from the ramp ceiling, with similar results on both. I don’t see any of the bouncing he observed.
However, the stable level on this MF01-Mini appears to be only about 400 lumens… which is pretty embarrassing compared to the D4Sv2’s stable level of ~1200 lumens in similar conditions. Perhaps that’s a matter of having SST-20 in one and XP-G2 in the other, but I think the difference is too big to be explained by just that. The two lights are almost identical in size, shape, and power level… so it’s really weird that one can sustain 3X as much light as the other.
Looking at older tests though, I see the same result. 1000+ lm on both D4S lights I’ve measured, and about 400 lm on this MF01-Mini. It seems man of light had similar results, even with an added heat sink… 400 to 600 lm. So I wonder why it runs so much hotter.
Support in gcc exists but is still in somewhat early stages… like, someone got it working in November, and as of a month ago it appears to still be in “patch it yourself” territory instead of having compiled packages available. Debian still has avr-gcc 5.4.0, and it looks like the newer chips may need 8 or newer, so that’s another thing to figure out. Then there’s also the matter of finding ways to flash the chip, getting it into flashlight driver designs, etc.
It’s getting there, but it’s going slowly.
Here's my latest Anduril w/tweaks: https://drive.google.com/drive/folders/1jdx8U3LruVaAzHQi7MOk2UqsE5VW7wKK?usp=sharing
It's the zip file with TE v1-1 in the name. Summary of changes:
I added MF01-Mini test results to my earlier comment:
MF01-Mini: I tested both turbo and the ramp ceiling, because this thread indicated regulation problems at the ramp ceiling level. Here are the results for both. I let the second test run until the battery was empty, to see how the rest of the graph would look:
For some reason, this light gets the “brighter on a low battery” thing a lot worse than most. Maybe it’s getting an unusually large portion of its heat from the driver instead of the LEDs? I’m not sure why, but it’s the same pattern I’ve seen on every MF01-Mini test.
If anyone was wondering about those small but sharp-looking stairstep adjustments later on in the graphs, they’re not actually sharp. Here’s a close-up of one. It took 32 seconds to adjust output by about 3, moving up one small step (0.39) every 4 seconds:
Each of those 8 steps is the smallest adjustment possible using the given hardware’s PWM controls. The changes are not visible by eye during use.
Gchart seems to have figured out how to flash them in Windows.
Adventures in TinyAVR 1-Series , post one.
Post 29 might interest you as well.
He has RampingIos working and has some drivers plus an Pic12 to ATtinyX16 pin adapter on Oshpark.
Being able to replace pics might be interesting.
Thanks TK for those very useful graphs! I’m surprised the 4 emitter Q8 can sustain a higher output than 18 emitter MF01S. Which emitter did the MF01S use?
Also that mystery light looks sweet. The regulation is really amazing. I’m guessing 7x emitters.
As that because you don’t use Atmel Studio? When using Atmel Studio, programming these chips are just as easy as the good old 85, the 1 series is fully supported.
Chicken or the egg? There is no firmware because there are no boards, or there are no boards because there is no firmware? Aren’t there plenty of people here that design BLF open source boards? It’s wouldn’t be to hard for them, it certainly wasn’t for me. Board design rules are exactly the same.
1-series come in all shapes and sizes. I’ve only been using 3217 which is the same size as 1634, gchart has used SOIC chips.
As mentioned, when using Atmel Studio, programming these chips are just as easy as the good old 85, the 1 series is fully supported. The registers and method of setting them is different, but if you can read an 85 datasheet, then you can read a 1-series datasheet 
gchart did all the hard work and figured this stuff out, he has released code samples and a port of RampingIOS which are sufficient to get started. Flashing is nicer too, besides MCU power and GND, it just requires 1 wire (UDPI).
That would be up to the author of Anduril. The MCUs themselves support everything the old ones do, it’s just a matter of taking the time to do the porting.
All components are the same expect MCU. Where I buy my MCUs, the 3217 is slightly cheaper than the 85. The added cost is the board for programming them, to my knowledge you can’t use those ISP USBASPs. I use the ATtiny416 Xplained Nano, it costed me about $11.5.
But yeah, not everyone wants to use Atmel Studio or wants to pay $11.5 for a programming board. Maybe linux support and cheaper solutions for flashing will come available, but until then I guess BLF drivers and firmware will be sticking to these older MCUs. They are still in production so they are by no means obsolete.
If I ever could loose my job (might be more likely with the virus), I just might have the time to do or help in the Anduril port. Just need a development/test setup, but again, not sure I'd have the time right now. Working at home now - been sick for the last few day - upper respiratory, they say bronchitis but that was with a 10 min facetime session with a PA...
On the MF01 Mini...
Yes, it is sort of baffling but the copper heatsink seems to make a world of difference. The factory stock plastic driver retainer is horrible. Plus I'd prefer a simpler FET+1. Not sure the extra zone of 7135 bank regulation is worth it.
Maybe they are using a FET clone that doesn't handle the heat as well? Not familiar with the D4S's design.
Factor 3x is incredible. Especially that the weaker light is actually larger.
What is the surface temperature of D4S and MF01 Mini while sustaining high load?
Maybe the latter actually has lower surface temperature at the same MCU temp?
Maybe the latter has less uniform surface temperature, leading the average to be lower further?
I remember the discussion on FET gate being kept only partially open at intermediate modes due to some resistor slowing it down.
This improves efficiency. Maybe Mateminco driver doesn’t have this resistor? (ADDED: probably not, because all-7135 seems too high anyway)
Here's a MF01 Mini (not a good look at the the driver though):
Prep'ed for the copper heatsink:
Lot of things, and it's Lexel's design.
Psssst! Don't tell anyone, super secret! 
first 2 pictures are not MF01 Mini
I can't edit Lexel's quoted copy of my post, but I updated my own.
Got my pics mixed - that was an Haikelite HK04 driver... Think I can break Lexel's quoted copy by removing those pics - should be in that MF01 mini folder anyway.
:FACEPALM: :FACEPALM: (double stupid of me...)
More importantly, Lexel - any ideas on why or if there's potential or possible heat issues with this driver?
The new revisions are not in the firmware trunk?
So, it’s not in the master branch yet
I can not find it
FSM branch:
https://code.launchpad.net/~toykeeper/flashlight-firmware/fsm
https://bazaar.launchpad.net/~toykeeper/flashlight-firmware/fsm/files
Sorry, I’m a couple months late to the party. I’m feeling the itch up get back into firmware after a little hiatus. Hopefully dust off my T816 dev board and make some progress with Anduril.
Compiling for the 1 series on Linux is pretty easy, you just need to download and include the Atmel Device Family Pack (DFP). Sample build script (also linked in my 1 series thread)
http://www.ghart.com/blf/firmware/bin/
Where I need to start off is to make sure I can build for the 85 or 1634 so that I know my Anduril files are downloaded properly and I’m familiar with the process. I’m sure I saw a primer somewhere, but I can’t seem to find it… 
So I’m looking at making a build of Anduril for the GT90 (if nobody has done that yet) - I’ve traced out the driver as such:
(note that there’s some components I’m not 100% sure of - I need to finalise those)
The pinout looks to be the same as a D4/D1/D1S, sans the 7135. What I’m thinking is drop PWM1_LEVELS to 0? Would love to be pointed in the right direction
(note - K G D are the e-switch)