STAR Firmware by JonnyC - Source Code and Explanation

Er, on a side note… I just updated the Ferrero Rocher ramping UI.

http://bazaar.launchpad.net/~toykeeper/flashlight-firmware/trunk/files/head:/ToyKeeper/Ferrero_Rocher/

Details are here, but if anyone has a non-default page size the link won’t work:

The short version is I caught up on a few TODO items, added support for fast PWM, made PFM easy to turn off, added some precalculated ramps, and made the default build go extremely low on moon mode. On a full high-amp cell, the lowest mode dropped from ~3.6 lumens to ~0.1 lumens on my triple-219B with a Ferrero Rocher DD driver.

So, on my hardware at least, it goes from 0.1 lumens up to 1800 lumens on a full cell. When the battery charge drops though, the output drops to like 0.000001 lumens and 1200. That extra-low moon may as well be off unless the battery is close to full. At less than full voltage, it can’t get the emitters to light up with such short pulses — they’re like one ten-millionth of a second long!

Nope, that makes sense.

Most of that would be fairly small mods to the STAR-momentary code, but it could get a little hairy trying to make it tell the difference between medium and long presses, and it has no strobe. It may require some pretty significant changes to make it do both medium and long presses, and I’m undecided how best to add blinky modes.

Timed turbo step-down is already implemented. Low-voltage detection is probably possible, but might be tricky and would require getting a copy of the hardware to whoever writes the code. Thermal step down isn’t possible without extra hardware.

I like the whole idea behind ramping :slight_smile:

The button delays take awhile to get it all meshed right Garry… It’s not a lot of code you can stuff in there so your pulling out all the tricks to get to your goal.

But to answer your question Toy it’s for my Y3 (tail and eswitch). I’m trying to find quiet momentary button switches, but no luck so made my own.

Took sleep out to keep voltage monitoring on. While I was at it, might as well exploit the PWM 0 low moon as light ring refresher. It’s really nice if you give it a try. I throw together another board and try your ramps out.

Well forget that idea… Your code is for rgb and not the tiny13a :slight_smile: I deal with ghetto stuff

Played with the ramp I made last night… It’s about perfect imo- starting low to high or high to low, you don’t really need to worry about the in between.

Huh? I’ve only made firmware for attiny13a so far. Granted, the driver I was targeting has a couple indicator LEDs hooked up to extra pins, but it still works fine on boards which don’t have that.

Ok just put another board together… I saw the green and blue pins and thought, wait a second xd

I’ll flash it in tonight and check it. Thanks

Where do I find the source code for dual-PWM off-time?

Thanks for keeping at this guys (and girls)!!! I like playing with all my new FW’s but its nice to be able to default back to STAR every now and then when I just need something to work with no debugging / other trouble.

This might not have all of JonnyC’s most recent additions, but it does at least have dual PWM:

http://bazaar.launchpad.net/~toykeeper/flashlight-firmware/trunk/files/head:/JonnyC/STAR/dual_pwm/STAR_off_time/

I’m a little behind on merging in his latest changes.

So why not link here? GitHub - JCapSolutions/blf-firmware at dual_pwm

Because I forgot to save the URL where I could find it easily, and didn’t remember where I originally found it. Also, I had some difficulty getting a copy of that via git, because it kept giving me the master branch instead of dual_pwm (even using the clone URL suggested at that site). I need to learn more about git.

I merged the dual_pwm feature into the "master" branch, so it's in the latest version of the program...

https://github.com/JCapSolutions/blf-firmware/tree/master/STAR_off_time

Fair enough. I had to search for my own post on the topic to find the link. Or I thought I did - now that I say that it strikes me that JonnyC has added a link to the GIT repo on the firmware page of his website. I forgot about that.

FYI for Cereal_killer or anyone else, to go from the link JonnyC posted on his website to the dual_pwm branch you must use the little “branch:” dropdown menu that defaults to branch: master.

EDIT: I got ninja’d by JonnyC: apparently the dual-pwm branch has already been merged back into the master branch. The latest code in the master branch is what you want.

Thanks. Right after posting earlier I grabbed updates on the main branch and found that the dual_pwm bits had been merged in. :slight_smile:

Also, I got bzr-git working, which lets me use bzr to access git repos. This is much much easier for me, and should greatly simplify merging in changes.

Edit: … and it’s all up to date now. :slight_smile: (plus, future updates should be much easier) I should note that the dual_pwm/ dir is gone though, since it got merged back into the main STAR code.

Just FYI, I'm not sure that the latest versions with the dual-pwm have been fully tested, so please let me know if there are any issues.

Using dual-PWM whats the lowest you guy’s are able to get XP-L’s to light up?

Quad XP-L with BLF 17dd V3 driver

I don’t know the answer either way, but are you asking about 7135s, FET, or something else?

Er, the lowest mode is really hard to predict, and highly dependent on hardware (driver, emitters, battery, etc).

For example, I’m getting 0.1 lm from a triple-219B driven by a FET, using fast PWM=0. But that 0.1lm drops down to like 0.00001 lm when the cell gets down to like 3.7V.

On the same hardware, if I use phase PWM=1 instead, the minimum level is about 3.6 lm (drops to about 0.9 lm at 3.6V).

On nanjg/qlite drivers, the lowest mode seems to depend mostly on the exact bin of 7135 chips used.

Basically, you’ll just have to try it and find out.

So, I put together a test light today with an off-time cap on the driver, and I adapted the cap-reading code from STAR off-time to fit in with my “s7” EDC code. I also added another cap threshold for medium presses, so it can detect short/med/long presses.

I haven’t really tweaked it yet, but it seems a short press is about 0 to 0.7s or so, a medium press is about 0.8 to 2.0 seconds, and a long press is anything over 2 seconds. These are mapped to “next mode”, “previous mode”, and “reset to mode 0”, respectively. I think the timings need to be shorter, but I can calibrate it later.

If the user does a prev-mode action at mode 0, it’ll go into semi-hidden “negative” modes, so it gives quick access to turbo, my favorite strobe, and battery check. Also, a next-mode action from any negative mode will always return to mode 0; no need to cycle back up through them again. Doing next-mode at the end of the main sequence will loop back to 0, instead of going through the negative modes.

I’m considering making back-from-zero change the mode group instead of doing just limited “negative” modes, but I’m not sure if I’ll bother.

Anyway, this went together pretty quickly and it seems to work well. Now I have firmware ready to go for my Cypreus, as soon as the emitters arrive (tomorrow or the next day). :slight_smile:

Am I correct in thinking that the ATtiny13A defaults to REFS0==0 on startup? So if I want to use Vcc as my analog reference I must change this line:

DMUX  = (1 << REFS0) | (1 << ADLAR) | ADC_CHANNEL; // 1.1v reference, left-adjust, ADC1/PB2

to read this way:

DMUX  = (1 << ADLAR) | ADC_CHANNEL; // Vcc reference, left-adjust, ADC1/PB2

Thanks guys!

Not sure what bits REFS0 and ADLAR are setting in ADMUX. They start 0 I’m pretty sure though. Here’s a link on the basics- don’t see the bits for those two giving it a quick glance… I guess could just lave REFS0 out and it should be 0