Flashlight Firmware Repository

1798 posts / 0 new
Last post
Mike C
Mike C's picture
Offline
Last seen: 2 months 3 weeks ago
Joined: 01/22/2014 - 08:03
Posts: 2009
Location: Sweden

ToyKeeper wrote:
I seem to recall that Mike C did some interesting things with using a single pin for multiple purposes. The results were somewhat vague though, and no code has been posted.

I thought I posted the details somewhere… Oh well, can post some here.

I use the E-switch, off time cap and voltage divider on the same pin.

The voltage divider resistors must be a lot higher that normally used because R2 becomes a bleed resistor for the off-time cap. I use 1300K for R1 and 300K for R2.
When the light gets turned on, the first thing to do is read the ADC for off time cap result. When that is done, start the WDT interrupt. In the WDT interrupt a voltage check is done. If the result is 0, or very close to it, the E-switch is pressed. If not, it’s a cell voltage reading.

The firmware has to work a little differently than for example Star. I haven’t looked at any other firmware so I wouldn’t know what’s been going lately. I run the WDT interupt at the highest speed so E-switch presses can be detected instantly. Consideration must be taken so the ADC readings from pressed E-switch are not interpreted as low voltage readings by the voltage monitor.

I’ve been working with this setup for a while now on a few different drivers and it’s fairly reliable. The off-time cap values can vary depending on cell voltage and heat, but so far I’ve had no issues detecting short and long off presses. However, I have had consistency issues when attempting to detect short, medium and long off presses. I can post code snips of certain parts of interest but the concept itself is very simple.

Halo...
Halo...'s picture
Offline
Last seen: 2 years 1 month ago
Joined: 12/15/2011 - 02:39
Posts: 3304
Location: Halo island

ToyKeeper wrote:

The FET+1 I’ve been using for clicky-switch development has a place to add an e-switch wire, and I’ve got a switch to hook up… the pad is awfully tiny though. I’ll have to see if I can possibly find a tiny wire and get it connected without blocking SOIC8 clip access… It’s the little copper dot next to the “3” here:

It would be easier to use the OTC pads, but then I wouldn’t have an OTC… and that might be important for a dual-switch light.


Yea, that pad is really tiny. More intended as a “star” connection for soldering to ground. I doubt there was any e-switch use in mind.

Personally, rather than force you to solder up that tiny pad, I think we should send you different driver designed for an e-switch on that pin. One with a nice tiny85 for max code room. To help support firmware development. Considering that some people are more hardware people, others just more software. What do you think? Iirc Comfy sent you the Roche F6 “Ferrero Rocher” driver. If I may ask, are you in the US? I once had the feeling you were in the UK instead, but I don’t recall anymore where it came from! Big Smile Or if you would rather not give your address to some random forum user (which I would certainly understand!), perhaps RMM would be willing to assemble and send a driver based on a board he doesn’t normally carry.

finges
Offline
Last seen: 17 hours 24 min ago
Joined: 11/19/2014 - 14:50
Posts: 481
Location: Germany

pilotdog68 wrote:
Ok firmware wizards, I can’t remember if I have asked this before or not. I’m looking for a firmware to use in a dual-switch light. I’ll list what I’m looking for, and hopefully there’s already something close or a more advanced FW that I can dumb down or something. If it runs on a 13 that’s preferred, but I could use a 25 or 85 if need be.

- on/off by tail power switch only
—- always comes back on in last mode
- side switch changes modes
—- click forward, hold for backward
- precise control of two pwm channels

That’s the main stuff, other nice things would be a shortcut to a certain mode by holding the side switch while applying power, or double click then hold enters a second mode group.

So what’s out there?


I would also be interested in such a firmware.
I am using STAR_dual_switch atm in a Yezl Y3 with a FET driver but I would like to upgrade to a FET+1 driver so I also need to control two pwm channels.
pilotdog68
pilotdog68's picture
Offline
Last seen: 3 weeks 5 days ago
Joined: 05/30/2013 - 23:31
Posts: 6419
Location: Held against my will in IOWA, USA

Most of the current momentary firmwares use pin 2 for the switch… As such most of the boards have pin 3 hidden, or a few boards use it for something else

My Favorite Modded Lights: X6R, S8 , X2R , M6, SP03

Major Projects:  Illuminated Tailcap, TripleDown/TripleStack Driver

pyro1son
pyro1son's picture
Offline
Last seen: 3 weeks 8 hours ago
Joined: 03/21/2013 - 08:18
Posts: 432
Location: UK

Mike C wrote:
ToyKeeper wrote:
I seem to recall that Mike C did some interesting things with using a single pin for multiple purposes. The results were somewhat vague though, and no code has been posted.

I thought I posted the details somewhere… Oh well, can post some here.

I use the E-switch, off time cap and voltage divider on the same pin.

The voltage divider resistors must be a lot higher that normally used because R2 becomes a bleed resistor for the off-time cap. I use 1300K for R1 and 300K for R2.
When the light gets turned on, the first thing to do is read the ADC for off time cap result. When that is done, start the WDT interrupt. In the WDT interrupt a voltage check is done. If the result is 0, or very close to it, the E-switch is pressed. If not, it’s a cell voltage reading.

The firmware has to work a little differently than for example Star. I haven’t looked at any other firmware so I wouldn’t know what’s been going lately. I run the WDT interupt at the highest speed so E-switch presses can be detected instantly. Consideration must be taken so the ADC readings from pressed E-switch are not interpreted as low voltage readings by the voltage monitor.

I’ve been working with this setup for a while now on a few different drivers and it’s fairly reliable. The off-time cap values can vary depending on cell voltage and heat, but so far I’ve had no issues detecting short and long off presses. However, I have had consistency issues when attempting to detect short, medium and long off presses. I can post code snips of certain parts of interest but the concept itself is very simple.

That’s very interesting. I would like to see this implemented on more boards and firmware. Would free up some pins for extra outputs Wink

Pastebin                                      &nbs

Halo...
Halo...'s picture
Offline
Last seen: 2 years 1 month ago
Joined: 12/15/2011 - 02:39
Posts: 3304
Location: Halo island

pilotdog68 wrote:
Most of the current momentary firmwares use pin 2 for the switch… As such most of the boards have pin 3 hidden, or a few boards use it for something else

ToyKeeper is looking to do a dual switch firmware though. Tail clicky + momentary side button. You need to keep the OTC (normally pin2) to distinguish between tail clicks.
Also ToyKeeper’s newer firmwares use a separate tk-attiny.h header file to define the pin arrangement. Feels easier to define a different arrangement if needed for a particular board.
Tom E
Tom E's picture
Offline
Last seen: 1 month 5 days ago
Joined: 08/19/2012 - 08:23
Posts: 10899
Location: LI NY

I'm keeping the e-switch on pin #2 for now. I'm working on indicator LED support on pin #3 (locator and low voltage indicator).

mattlward
mattlward's picture
Offline
Last seen: 1 week 3 days ago
Joined: 06/19/2015 - 09:20
Posts: 2319
Location: Illinois, USA

chouster wrote:
PD, there is also the ATtiny13A diagram in that .c-file, right at the beginning. So there are enough pins. I think you’re confusing dual PWM with dual-channel or something?

For indication purposes maybe we could control 2 LEDs with one MCU-pin by charlieplexing. Has anyone done that before here at BLF, or thought of it at least?

Why not just use 1 pin to control 2 colors? A high on the pin will trigger 1 side of an LED and a low can trigger the other side of the same dual color led. I have not looked into the amount of current this chip can source and sink, but 30 ma should be enough. I have not tried this with the tiny13 but have done it on the Pi and Arduino several times.

Matt

EDC rotation:
Convoy S2+, 6*7135, XM-L2 3D, 10 degree TIR, PilotDog lighted tailcap.
Convoy S2+, H17F, XM-L2 4C, lighted tailcap
Zebralight SC52w-L2
Olight S1A
Olight S1R

pilotdog68
pilotdog68's picture
Offline
Last seen: 3 weeks 5 days ago
Joined: 05/30/2013 - 23:31
Posts: 6419
Location: Held against my will in IOWA, USA

Halo… wrote:
pilotdog68 wrote:
Most of the current momentary firmwares use pin 2 for the switch… As such most of the boards have pin 3 hidden, or a few boards use it for something else

ToyKeeper is looking to do a dual switch firmware though. Tail clicky + momentary side button. You need to keep the OTC (normally pin2) to distinguish between tail clicks.
Also ToyKeeper’s newer firmwares use a separate tk-attiny.h header file to define the pin arrangement. Feels easier to define a different arrangement if needed for a particular board.

Well, that’s one kind of dual-switch arrangement. I thought people would just use brown out for click sensing. My main worry is that she will make this great firmware that won’t work with most of the driver pcb’s we have. Then if we make pcb’s for that firmware, we won’t be able to use Pin3 for other things, like indicator led’s or extra outputs (TripleDown)

I have a couple of dual-switch lights sitting around that are just empty shells because I don’t have a firmware I like for them. Like was posted a little earlier today, I would be very excited if we could add dual-pwm support to star-dual-switch or added memory support to Star-momentary. I’d literally freak out and jump up and down if that happened and if it could work with the extra output for my TripleDown board like DEL helped with on blf-a6 a couple weeks ago.

My Favorite Modded Lights: X6R, S8 , X2R , M6, SP03

Major Projects:  Illuminated Tailcap, TripleDown/TripleStack Driver

Mike C
Mike C's picture
Offline
Last seen: 2 months 3 weeks ago
Joined: 01/22/2014 - 08:03
Posts: 2009
Location: Sweden

pyro1son wrote:
Mike C wrote:
ToyKeeper wrote:
I seem to recall that Mike C did some interesting things with using a single pin for multiple purposes. The results were somewhat vague though, and no code has been posted.

I thought I posted the details somewhere… Oh well, can post some here.

I use the E-switch, off time cap and voltage divider on the same pin.

The voltage divider resistors must be a lot higher that normally used because R2 becomes a bleed resistor for the off-time cap. I use 1300K for R1 and 300K for R2.
When the light gets turned on, the first thing to do is read the ADC for off time cap result. When that is done, start the WDT interrupt. In the WDT interrupt a voltage check is done. If the result is 0, or very close to it, the E-switch is pressed. If not, it’s a cell voltage reading.

The firmware has to work a little differently than for example Star. I haven’t looked at any other firmware so I wouldn’t know what’s been going lately. I run the WDT interupt at the highest speed so E-switch presses can be detected instantly. Consideration must be taken so the ADC readings from pressed E-switch are not interpreted as low voltage readings by the voltage monitor.

I’ve been working with this setup for a while now on a few different drivers and it’s fairly reliable. The off-time cap values can vary depending on cell voltage and heat, but so far I’ve had no issues detecting short and long off presses. However, I have had consistency issues when attempting to detect short, medium and long off presses. I can post code snips of certain parts of interest but the concept itself is very simple.

That’s very interesting. I would like to see this implemented on more boards and firmware. Would free up some pins for extra outputs Wink


I’ve mentioned it before, but there doesn’t seem to be a lot of interest, so I silently keep working on my boards and firmware Smile
chouster
Offline
Last seen: 9 months 2 weeks ago
Joined: 02/20/2014 - 15:05
Posts: 683
Location: germany

mattlward wrote:
chouster wrote:
PD, there is also the ATtiny13A diagram in that .c-file, right at the beginning. So there are enough pins. I think you’re confusing dual PWM with dual-channel or something?

For indication purposes maybe we could control 2 LEDs with one MCU-pin by charlieplexing. Has anyone done that before here at BLF, or thought of it at least?

Why not just use 1 pin to control 2 colors? A high on the pin will trigger 1 side of an LED and a low can trigger the other side of the same dual color led. I have not looked into the amount of current this chip can source and sink, but 30 ma should be enough. I have not tried this with the tiny13 but have done it on the Pi and Arduino several times.

Matt

That’s what I had in mind, sort of, I guess.

I found a nice explanation of how it could work that even a dumb dumb like me could understand. I thought maybe someone could make something useful out of it, that’s why I asked…

@Mike C, the things you do are both very impressing and over my head at the same time. Looks genius from my point of view! I’m sure it looks genius not only from my dumb-dumb point of view… Smile

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 42 min 41 sec ago
Joined: 01/12/2013 - 14:40
Posts: 7910
Location: (469219) 2016 HO3

Halo… wrote:
ToyKeeper is looking to do a dual switch firmware though. Tail clicky + momentary side button. You need to keep the OTC (normally pin2) to distinguish between tail clicks.

Well, that… and I’m hoping to be able to use one dev board for both clicky firmwares and e-switch firmwares, and for both single-channel and dual-channel firmwares. It’s nice having a few bits of versatile hardware instead of a lot of single-purpose pieces. I’ve got a growing pile of decapitated light heads with drivers hanging out on long wires.

It doesn’t have to require OTC for a dual-switch project.

RMM’s FET+1 SRK board looks really nice, but I don’t know if he still sells it. My SRK might make a decent all-in-one dev host, and it’s not really getting used for anything else now that there’s a Meteor…

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 42 min 41 sec ago
Joined: 01/12/2013 - 14:40
Posts: 7910
Location: (469219) 2016 HO3

Mike C wrote:
I’ve mentioned it before, but there doesn’t seem to be a lot of interest…

I’m interested! Smile

Even without the hardware, the code would be a great source of ideas and reference material. Like the 3-way-overloaded pin. That’s brilliant!

I’m a big fan of release early, release often.

pilotdog68
pilotdog68's picture
Offline
Last seen: 3 weeks 5 days ago
Joined: 05/30/2013 - 23:31
Posts: 6419
Location: Held against my will in IOWA, USA

I assume it would be pretty difficult to add the battery monitoring code from Ferrero Rocher into a clicky firmware like star-offtime?

My Favorite Modded Lights: X6R, S8 , X2R , M6, SP03

Major Projects:  Illuminated Tailcap, TripleDown/TripleStack Driver

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 42 min 41 sec ago
Joined: 01/12/2013 - 14:40
Posts: 7910
Location: (469219) 2016 HO3

Realtime battery status on a clicky shouldn’t be terribly difficult. Of course, it can’t display anything while it’s off. Smile

Details aren’t worked out, of course. And it’s hard to add more to STAR because it doesn’t leave a lot of extra room… but after removing things we don’t need any more (like solderable star support), there’s enough room to add other stuff.

pilotdog68
pilotdog68's picture
Offline
Last seen: 3 weeks 5 days ago
Joined: 05/30/2013 - 23:31
Posts: 6419
Location: Held against my will in IOWA, USA

Well I have a special use in mind. The driver will (almost) always be powered, but quick interrupts will be used to change modes.

My Favorite Modded Lights: X6R, S8 , X2R , M6, SP03

Major Projects:  Illuminated Tailcap, TripleDown/TripleStack Driver

chouster
Offline
Last seen: 9 months 2 weeks ago
Joined: 02/20/2014 - 15:05
Posts: 683
Location: germany

pilotdog68 wrote:
Well I have a special use in mind. The driver will (almost) always be powered, but quick interrupts will be used to change modes.

I swear I knew you’d come up with something like this when I read your post #742. Must be a special kind of tailcap board again or some sort of on-on-clicky?
chouster
Offline
Last seen: 9 months 2 weeks ago
Joined: 02/20/2014 - 15:05
Posts: 683
Location: germany

hey,

I’d appreciate some help. I played around with bistro, wanted to make a single channel version for a p60-drop-in with 105C-based-driver, that’s working so far. I know it’s also quite easy to make a 2-channel-driver out of a 105C by rearranging the traces a bit, that’s easier in fact. But with this Nichia I wanted to prioritize best as possible tint over efficiency, and a smooth as possible ramp. And that’s where my lack of knowledge comes to play. If I were to increase RAMP_SIZE to 128, would that cause any trouble? I tried to adjust both attiny.h and bistro; https://www.diffchecker.com/ow8bdznq; https://www.diffchecker.com/7rr33hvf. But that doesn’t seem to work right… What am I doing wrong?

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 42 min 41 sec ago
Joined: 01/12/2013 - 14:40
Posts: 7910
Location: (469219) 2016 HO3

To increase the ramp size, you’ll need to turn off something else to make room. The ramp itself can be calculated by level_calc.py. I’m not sure right now how hard it’d be to disable dual PWM entirely, but if there’s room you can always just leave the second channel at all zeroes.

I’m on a phone at the moment, so I can’t really do much with the code…

chouster
Offline
Last seen: 9 months 2 weeks ago
Joined: 02/20/2014 - 15:05
Posts: 683
Location: germany

Thanks Tk!

Ramp was calculated with level_calc.py, 128 modes, I think I got dual PWM disabled completely, compiles (2022 bytes, 98,7 % Full, with AS6.2) and flashes fine. All modes ramp up, but Turbo gives two short flashes, little pause, than 100% const. Also the ramp with the modes that work correct doesn’t seem as smooth as the ramp of my X6 with dual channel driver and bistro with 64 mode-ramp.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 42 min 41 sec ago
Joined: 01/12/2013 - 14:40
Posts: 7910
Location: (469219) 2016 HO3

The bottom end of the ramp will be less smooth with more 7135 chips on a single channel. The steps are bigger, and in the lowest modes those steps are pretty visible. Notice how it has a bunch of the same number at the beginning, then at the end there are 5 PWM levels between steps? A bigger ramp can’t increase the physical resolution of the hardware.

As for the highest mode blinking, I suspect that might be because the soft start uses a signed 8-bit integer to determine how far to ramp (and which direction), and your path from zero to full is one step too long for a signed 8-bit int. Perhaps try with 127 or fewer ramp steps?

chouster
Offline
Last seen: 9 months 2 weeks ago
Joined: 02/20/2014 - 15:05
Posts: 683
Location: germany

ToyKeeper wrote:
The bottom end of the ramp will be less smooth with more 7135 chips on a single channel. The steps are bigger, and in the lowest modes those steps are pretty visible. Notice how it has a bunch of the same number at the beginning, then at the end there are 5 PWM levels between steps? A bigger ramp can’t increase the physical resolution of the hardware.
hmm, now that you say it, it makes things very clear. Yery well explained, thanks. Maybe I should give a dual channel 105C a try.

ToyKeeper wrote:

As for the highest mode blinking, I suspect that might be because the soft start uses a signed 8-bit integer to determine how far to ramp (and which direction), and your path from zero to full is one step too long for a signed 8-bit int. Perhaps try with 127 or fewer ramp steps?

I went down to 100 ramp steps, now it works when going through the modes normally, but reversing from moon to turbo still gives weird flickering. Since I have only forward clickies in my P60 hosts (that has to change) I will be ditching offtim3 anyways, however I still would like to find out what causes it.
Mike C
Mike C's picture
Offline
Last seen: 2 months 3 weeks ago
Joined: 01/22/2014 - 08:03
Posts: 2009
Location: Sweden

ToyKeeper wrote:
Mike C wrote:
I’ve mentioned it before, but there doesn’t seem to be a lot of interest…

I’m interested! Smile

Even without the hardware, the code would be a great source of ideas and reference material. Like the 3-way-overloaded pin. That’s brilliant!

I’m a big fan of release early, release often.


I’ll have something shortly and will make my own driver thread. The code itself is not much different to current voltage reading code. It’s just run much more often.
Disclaimer: More often than Star. I haven’t looked into any other firmware than my own for quite some time.
Microa
Offline
Last seen: 21 hours 50 min ago
Joined: 06/29/2011 - 21:20
Posts: 232

Dear ToyKeeper,

I am building a 7.2V light which will be flashed the Baton firmware. Would you please educate me that the ADC_0, ADC_25, …. ADC_100 are used for.

Am I going the right way to modified the codes like this. The R1 is directly connected to B+, no diode in between.


ToyKeeper
ToyKeeper's picture
Offline
Last seen: 42 min 41 sec ago
Joined: 01/12/2013 - 14:40
Posts: 7910
Location: (469219) 2016 HO3

Microa wrote:
I am building a 7.2V light which will be flashed the Baton firmware. Would you please educate me that the ADC_0, ADC_25, …. ADC_100 are used for.

Am I going the right way to modified the codes like this. The R1 is directly connected to B+, no diode in between.


Those values are used to control the realtime battery indicator lights, and to decide when low-voltage protection should start.

Rather than calculating with a formula, I find it more reliable to measure. You can do this by using the battcheck.hex firmware. Basically measure a full battery and a near-empty one, then use the battcheck.py script to calculate the values at each voltage, then plug those into the actual firmware you want to run.

Microa
Offline
Last seen: 21 hours 50 min ago
Joined: 06/29/2011 - 21:20
Posts: 232

ToyKeeper wrote:
Microa wrote:
I am building a 7.2V light which will be flashed the Baton firmware. Would you please educate me that the ADC_0, ADC_25, …. ADC_100 are used for.

Am I going the right way to modified the codes like this. The R1 is directly connected to B+, no diode in between.


Those values are used to control the realtime battery indicator lights, and to decide when low-voltage protection should start.

Rather than calculating with a formula, I find it more reliable to measure. You can do this by using the battcheck.hex firmware. Basically measure a full battery and a near-empty one, then use the battcheck.py script to calculate the values at each voltage, then plug those into the actual firmware you want to run.

Many thanks for your prompt reply.

I have omitted to read the README enclosed in the battcheck folder. I will try the battcheck firmware.

Thanks again, your Baton firmware is working great.

Microa
Offline
Last seen: 21 hours 50 min ago
Joined: 06/29/2011 - 21:20
Posts: 232

Excuse me. Would you please guide me how to run the Python scripts. My pc already have the Python 2.7.6 installed.

I have checked the ADC of my driver with my battery pack as following;
214 – 8.30V
175 – 7.21V
The battery pack was discharged to 6.07V and then recovered to 7.21V after removed the loading.
I have translated it to 4.2V, 214 – 4.15V, 175 – 3.61V and put them in file mydriver.volts as per your description.
However, I have no luck to run the scripts.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 42 min 41 sec ago
Joined: 01/12/2013 - 14:40
Posts: 7910
Location: (469219) 2016 HO3

I don’t really know how to run these things in Windows. I tried Windows for a short while in the mid 1990s, but haven’t used it since.

You do bring up a good point though, that the voltage calculator should probably support voltage ranges other than the usual 1-cell li-ion configuration. This might be a little tricky due to driver sources assuming they’re running at 3-4 volts though.

chouster
Offline
Last seen: 9 months 2 weeks ago
Joined: 02/20/2014 - 15:05
Posts: 683
Location: germany

What’s an easy way to post/share code? I thought I would share the variant of BLF-A6 I “made” today.

It’s for single channel drivers, has the specific header files integrated, and it has battcheck in volts plus thenths style. I know it’s nothing big, but a buddy of mine asked for it, and I thought maybe someone else finds it useful… Tested and calibrated it on a 105C 8xAMC7135 driver from Simon (Convoy) with added 1µF OTC from Star4 to ground.

FmC
FmC's picture
Offline
Last seen: 1 day 16 hours ago
Joined: 03/31/2013 - 05:23
Posts: 2085
Location: Brisbane, AU
chouster wrote:
What’s an easy way to post/share code?

http://pastebin.com/

Pages