Flashlight Firmware Repository

ok, I think I am getting it now. Seeing a defined pin for the internal reference really threw me for a loop.

So if it is using the internal reference then it is also ignoring the pin defined for the voltage divider and I am free to use it for something else.

I wounder why the pin 7 is defined at all for those drivers? Seems like it would be commented out completely?

Thanks for taking the time to explain it.

My best guess: copy&paste as you can see the comment in hwdef-Emisar_D4.h

// (FIXME: remove?  not used?)
#define VOLTAGE_PIN PB2     // pin 7, voltage ADC

Thanks for answering all that over the past few posts. :slight_smile:

The API for voltage measurement is, um, not ideal. It’s not really designed so much as just kludged together over time. I’ll probably want to rewrite it when I add support for a new MCU architecture, but I don’t know when that will be. Writing all these abstraction layers takes a while, and the hardware abstraction parts aren’t anywhere near as mature as the UI abstraction parts.

So for the moment, it’s a bit of a mess.

Great, at least I can switch pin 7 to AUXled duty, using pin 3 would of been more difficult. So this is all I should have to do to setup the drive with FET + 1x 7135 + AUX led.

Having PB2 defined twice will not matter correct? Or should I comment out the ADC section entirely?

Sorry, this driver is kind of a last minute addition to a light Neal asked me for that is already in the works and I will not have time for a second prototype I am sure, so I need to get the hardware right the first time and preferably the firmware as well.

As I start to learn my way around Anduril I can see the advantages it brings to the table, although I am sure I will have more questions before I am comfortable with it. Took me 6 months to get comfortable with Bistro and then Narsil but I am getting better each time.

Thanks again for the help.

EDIT: Are the fuses the same as Bistro?

This is what I use now:

lfuse:w:0xd2:m
hfuse:w:0xde:m
efuse:w:0xff:m

Referring to PB2 from more than one place shouldn’t cause issues, as long as only one part tries to use it. The voltage pin thing isn’t used unless it also has the USE_VOLTAGE_DIVIDER thing enabled.

The recommended fuse values are always in bin/flash-85.sh.

There is some debate about whether BOD should be enabled, but it doesn’t appear to matter much in practice.

For what kind of light does Neal need a last-minute Anduril driver? Should I trust that people will follow the license requirements this time?

I was looking at the flash scripts and noticed that the fuses are different for the tiny25 and tiny85, I used to use the same settings for both, has that changed?

Tiny85 -
lfuse:w:0xe2:m
hfuse:w:0xdf:m
efuse:w:0xff:m

Tiny25 -
lfuse:w:0xd2:m
hfuse:w:0xdf:m
efuse:w:0xff:m

I am not sure that I am supposed to say anything about the light at this point, not sure what the status on it is, I was not really involved with it until a week ago and then only as a “hey, we need a better driver, can you make one? Oh and I would like to use Anduril” type thing lol.

I am not even sure who is making it come to think of it. Heck, I am not even sure about what the light is, I only know it needs a 17mm driver and to support a fair amount of power.

On my end, I always keep all the source files, and credit those needed on the silk screen (unless they remove it, like one manufacture did). So I try to do everything I can to maintain the license, just not always in the most timely fashion.

If you ever have questions or issues with the driver or firmware for a light I worked on, please let me know and I will get you whatever you need. It might be “messy” but I am happy to send it your way. Although I am getting better at keeping things a little more organized as I work now.

The low fuse value of D2 vs E2 selects a startup time of 64 ms or 4 ms. This is how long the MCU waits for power to stabilize before starting to run code. In general it doesn’t matter, as either one should be enough. But it used 4 ms on tiny25 since those are mostly clicky-switch lights where a fast response is important… and 64 ms on tiny85 since those are mostly e-switch lights where boot-up usually means the user is screwing the parts together.

Anyway, the license doesn’t care about whether someone’s name is inscribed onto the PCB. It’s about making sure that anyone who distributes the product also makes the source code available under the same license. Usually this means putting a note in the manual and/or product page stating that the product uses free software, with a link pointing to the code. Putting a conspicuous notice somewhere with the copyright and licensing info is mostly just a means to an end. Attribution isn’t the goal, but because of how copyright law works it’s kind of a necessary prerequisite.

I finally merged FSM into trunk again today. It included several bug fixes and other updates since the last merge.

  • Added support for Fireflies lights.
  • Tweaked thermal settings for a few lights.
  • Fixed a bug with one very specific click sequence causing a MCU hang.
  • Fixed a bug where changing the ramp style could sometimes jump to the wrong brightness.
  • Added a moon timing hint on hold-from-off.
  • Fixed a timing inconsistency on hold-from-off; stepped ramp took too long to start ramping up.
  • Added manuals for RampingIOS V2 and V3.
  • Added a ramp shape parameter to level_calc.py.
  • Added initial support for a second set of aux LEDs, but it simply copies the behavior of the first set.
  • Fixed a bug where thermal regulation could go up from the requested level after double-click-from-off.

The only UI change people would likely notice from this update is the moon timing hint.

What firmware would you suggest to use with a 7135 driver and a momentary switch (SRK style light)? At the moment I have Attiny13A with STAR firmware. Does that kind of driver work with Attiny25/85 and Crescendo, Bistro or NarsilM?

Bistro and Crescendo use a switch which disconnects power, not an electronic switch like the SRK has. So those aren’t really options.

The attiny13 doesn’t have much capacity in ROM, so it can’t fit Narsil or Anduril. However, if you put an attiny85 on instead, it should work. Those can usually fit onto the same pads, but you might have to bend the legs under the chip to make it fit.

There are some other e-switch firmwares though, and some can run on attiny13. For example, the Ferrero Rocher set has three interfaces to choose from. They just don’t have a lot of features.

So if I change the Attiny13 with an Attiny85 and NarsilM it should work? I was not sure if NarsilM is suitable for a 7135 driver. That would be great because I really like the ramping and the different features on my Emisar D4.

Depending on the details of the driver, it may or may not work. There are a lot of different circuits which can be called “a 7135 driver”.

It is the 46mm SRK 32x 7135 driver from MTN Electronics. There is no FET but only 7135 transistors. Maybe I will try it with Attiny85. I should find out quickly if it works or not when turning on the flashlight.

Oh, I have one of those. I ran Ferrero_Rocher/Ramping_UI_table on it.

It was okay, but the ramp resolution at the bottom was very coarse, and it had no extra features except battcheck. Giving it an attiny85 would give it more features, but would not improve the ramp resolution. Also, you’ll probably have to compile a custom version of the code to make it work, because I don’t think there are existing recipes for any single-channel drivers.

It may also be desirable to remove the voltage divider resistors, to reduce standby current, after getting everything else working. The tiny85 code can get that info from a different pin, so the divider isn’t needed any more.

Maybe the Ferrero_Rocher/Ramping_UI_table would do for me. I rarely use the special modes and the ramping sounds good. So I can just reprogram the soldered Attiny13 and do not need to change it. Also it would be too much for my limited coding experience to compile custom codes. Many thanks for all your useful advice and flashlight firmware!

Is there a driver schematic repository? I’m sure all the old hands know what pins go to where and the values of the passives from memory. I don’t.

I’m working out the Convoy 3/5 mode driver. It looks similar to a Nanjg 105C. Schematic for the Nangj is

Vcc cap and PB2 voltage divider appear to be the same but with different values. PB1 (pin 6) is connected to the 7135s.

Pins 1,2 and 3 are n/c ?

I got out the magnifying glass. Same as Nanjg without the stars.

Looks like this:

Battery + goes to cathode of D1. Battery - connects to the tail switch.

Hi TK and all BLF friends.
I would like to use crescendo in my TA drivers, but I’m having some trouble.
If I include the thermal regulation in the compile, the resulting hex file became too large for the attiny 25, even setting optimize to size in the toolchain menu.
If I deactivate all the special modes like bike, strobe, beacon etc, or reduce the ramp size, than I can use thermal regulation, because the hex file size became smaller, but that is not a real solution.
Is it possible to use crescendo with the special modes and thermal regulation for the attiny 25?

I get 2008 bytes for the FET+1 build, and 2016 bytes for the 3-channel build, without changing anything else. It can be up to 2048 bytes before running out of room. I’d suggest trying the compiler settings in bin/build-25.sh to get it to compile to the expected size.

TK thanks for the reply.
Later tonight I’ll try the build-25.sh and post here the results.