Flashlight Firmware Repository

guardior · May 11, 2015, 6:44pm

Yeah I managed to fix the problem with sizeof as my arrays are hardcoded compile time. But I did read up on the things you talk about too. Stackoverflow has tons of answers on just about any possible coding problem. But now I ran into another problem, _delay_ms() only takes compile time constants as value! What da heck is up with that? I was thinking about making it possible to set strobe frequency at run time but now I don’t know if that is even possible to do with just a few bytes.

_the · May 11, 2015, 6:37pm

That's the nature of standard _delay_ms(). I replaced it with my own approximate delay function, which fixes that problem and also saves a couple of bytes. See TheStar.c in the repo.

guardior · May 11, 2015, 8:42pm

Thanks man! Saved 4 bytes too.

Edit: Your function seems a bit unstable, it doesn’t work properly.

Edit2: Could it be that it must have 16 bit integers as value because those seem to work properly? 8 bit doesn’t work?

Edit3: Forget what I wrote above, found a simple bug, will report back soon.

ToyKeeper · May 11, 2015, 8:55pm

I’m using nearly the same function in pretty much all my firmwares, so I’d like to hear more about this bug.

guardior · May 11, 2015, 10:00pm

Yes there seems to be a bug whan passing a uint8_t from eeprom as parameter. My strobe frequency is not stable to say the least. Any fix much welcome.

Edit: It’s this line: strobe_delay = eeprom_read_byte((const uint8_t *)(uint16_t)2);

Edit2: My strobe is on friggin shuffle mode!!!

Edit3: My 15hz strobe works ok for a few seconds and after that it freaks out. Slower faster and whatnot.

Edit4: Just a guess, when WDT kicks in after one second it mess things up for short delays.

guardior · May 12, 2015, 9:18pm

Ok, it’s not exactly a bug but here’s what I found. The _delay_loop function runs in software and doesn’t work reliably if you use a wdt. But I found out that _delay_ms runs on a hardware clock so I switched to that but it didn’t work anyway. So I was just about to throw in the towel when I realised that I don’t really need 1ms resolution so I tried with 5ms instead. And bloody he it worked. So now I can set the strobe frequency in run time. I also saved a few bytes in the process as I could get rid of the uint16_t too.

github.com

xerxes2/flashlight-firmware/blob/master/sharkdrv/sharkdrv.c#L100


      
          uint8_t mode_idx = 0; // Mode position in modes array
          uint8_t mode_memory; // Mode memory
          uint8_t mypwm = 100; // Mode identifier/output level
          uint8_t spress_cnt = 0; // Short press counter
          uint8_t ftimer; // Full mode timer
          uint8_t strobe_delay; // Strobe frequency delay
          //### Globals end ###
          
          static void delay_5ms(uint8_t n) { // Use own delay function
            while(n-- > 0) {
              _delay_ms(5);
            }
          }
          
          void get_mypwm(const uint8_t modes[], uint8_t mode_cnt) {
            if (spress_cnt >= PROGRAM_SPRESS && spress_cnt < PROGRAM_SPRESS + PROGRAM_MODES) {
              mypwm = 254; // Enter program mode
            } else {
              if (mode_idx >= mode_cnt) {
                mode_idx = 0; // Wrap around
              }

Strobe seems super stable running with the delay_5ms function.

guardior · May 14, 2015, 1:12pm

Added ramping too and still got a few bytes left to play with so if you got any ideas. But in another thread there is a guy that wants to set his own modes and this got me thinking if anyone has written a firmware that is completely empty and you have to program the modes yourself? That would be a bit cool actually. If you want ie 65, 32, 100, 42 you can have it that way.

guardior · May 15, 2015, 9:45pm

Was going out with the dog in the night and wanted something to play with so I made an almost empty firmware, only took a few minutes. Only got one mode full blast by default and then you would have to program all other modes by yourself. I tested it right now in the night and it’s a bit tedious but you can have your own exact group as you wish. I set a limit on max six modes but can be increased easily if wanted.

cajampa · May 16, 2015, 5:08am

This is very cool can you program the turbo step down on the fly like dr jones guppydrv also?

How do you program it when its in the light? would it work with a twisty? or is it very many very quick clicks that would make it hard to do in a twisty?

And can you reset the modes whenever you want later?

ToyKeeper · May 16, 2015, 7:21am

I’ve been a bit busy lately, but I’d like to include all of the above as soon as I get time to add it to the collection.

guardior · May 16, 2015, 2:00pm

RTFM! I’m a flashlight noob and don’t know much about twistys. But you program the firmware with making 10-19 short presses and then you count flashes and switch off when you get the value you want. IE if you want 90 seconds turbo timer you make 11 short presses and then count 90 flashes and switch off. If this works with a twisty I don’t know.

Edit: And of course you can set all settings as many times as you want.

guardior · May 16, 2015, 2:16pm

I’m still updating my firmwares if I find anything broken or missing so maybe better just put a link or something. BTW, how do you rename links in your sig?

cajampa · May 16, 2015, 5:12pm

Very nice, sounds extremely useful.

A twisty is the colloquial term here for a flashlight that don’t have a button for on off, but you twist the body & head to turn off & on

Often used on small AAA size & smaller lights, to be able to build them smaller & shorter than if they had a switch. The downside is more than a few modes is a hassle on them, because you can’t twist as fast as you can push a button, especially with one hand.
But for programming them when needed, it sounds manageable

Does it have the basics like low volt protection shut off & step down & such features? Sorry if this is all spelled out in the manual……

guardior · May 16, 2015, 5:26pm

Yeah I understand what a twisty is but I don’t got one myself. But thinking about it I do got an old mini-mag but I don’t count that one. There is only low voltage shut off right now but there’s plenty of space left so I’ll add step down too. Just to copy and paste some code from one of my other firmwares anyway.

ToyKeeper · May 16, 2015, 7:10pm

I’m treating the code repo somewhat like a Linux distro. The projects there aren’t expected to be 100% complete, just mature enough to be useful… and updates over time are totally fine. The idea is to get all the good stuff in one place as a convenient and curated collection.

HTML.

BLF allows a large subset of HTML in posts and in signatures, so you can do a regular <a href=“http://foo”>Foo!</a> to make a link.

cajampa · May 16, 2015, 8:34pm

Good, LVP is the most important bit anyway.

Bat check is another nice feature to have, also 2 pwm channels support. But that could get complicated.

Is you pwm fast for the lower pwm levels & phase for the max output mode, as is often recommended?

guardior · May 16, 2015, 9:31pm

None of my firmwares support dual-pwm even though they’re kinda prepared for it. As you say it will get a tad complicated as different people will have different opinions on how it’s going to be used. Just setting both outputs to the same value is easy though. And yes I’m using phase for full output (mostly just doing as ToyKeeper says :laughing::

github.com

xerxes2/flashlight-firmware/blob/master/geniedrv/geniedrv.c#L159


      
            sei(); // Enable interrupts
          }
          
          inline void ADC_ctrl(void) { // Battery monitoring
            if (BATT_MON) {
              ADMUX  = (1 << REFS0) | (1 << ADLAR) | ADC_CHANNEL; // 1.1v reference, left-adjust, ADC1/PB2
              DIDR0 |= (1 << ADC_DIDR); // disable digital input on ADC pin to reduce power consumption
              ADCSRA = (1 << ADEN ) | (1 << ADSC ) | ADC_PRSCL; // enable, start, prescale
            } else {
              ADCSRA &= ~(1<<7); // ADC off
            }
          }
          
          void set_output(uint8_t pwm_lvl, uint8_t pwm_mode) {
            if (pwm_mode) {
              if (pwm_lvl > FAST_PWM_START && pwm_lvl != 255) {
                TCCR0A = PWM_FAST; // Fast-PWM
              } else {
                TCCR0A = PWM_PHASE; // Phase corrected PWM
              }
            }

I haven’t thought of battery check, yet. Don’t think I’m gonna bother with it but you should never say never. If I do it I think I’m gonna hide it in 30 short presses or something like that. Will maybe have to throw out something else to make it fit though.

zeremefico · May 18, 2015, 5:34am

Hi TK, do you have any ramping firmware in your repository?

ToyKeeper · May 18, 2015, 11:20am

Yes. To get a list, browse to the index file, and search for “ramp”:
http://bazaar.launchpad.net/~toykeeper/flashlight-firmware/trunk/view/head:/INDEX

Mike_C · May 19, 2015, 12:04pm

Is there any firmware in the repository that has a good formula for smooth PWM brightness adjusting? The ones I have looked at all have a predefined arrays. I’m looking to avoid that and would rather do it with coding. Increasing by the same amount just doesn’t work very well. So far I haven’t come up with one that smoothly and evenly goes from moon to 255.