Flashlight Firmware Repository

2239 posts / 0 new
Last post
pilotdog68
pilotdog68's picture
Offline
Last seen: 11 months 1 week ago
Joined: 05/30/2013 - 23:31
Posts: 6420
Location: Held against my will in IOWA, USA

I tried it with this one: https://www.diffchecker.com/zxnq3xvg

Still the same behavior. In the first mode group it steps down at 33 seconds, in the second mode group it doesn’t step down at all.
……………………….
Edit: For a sanity check I flashed the unmodified blf-a6 file and it behaves similarly. It steps down at 33 seconds in both mode groups. This leads me to believe I have a hardware problem. I’m going to try swapping the mcu.

Edit 2: Swapped the MCU and the turbo timer still behaves the same. However one thing has changed, I now have the dreaded Turbo-to-moon flash (Which I have never had with these parts before and was not there before the MCU swap.) Anybody have any ideas? I’m planning on starting from scratch with a whole new driver next.

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

Major Projects:  Illuminated Tailcap, TripleDown/TripleStack Driver

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 8 hours 17 min ago
Joined: 01/12/2013 - 14:40
Posts: 10613
Location: (469219) 2016 HO3

BTW, you can modify the timing if you want. Change the value of DELAY_TWEAK and it should alter the timing of almost everything the driver does. In general, it should be clock-speed-in-MHz times 250. However, on common attiny13a drivers the actual clock speed seems far less than its spec’d 4.8 MHz. So, it defaults to 950 (3.8 MHz) instead of 1200 (4.8 MHz).

In your case, it sounds like 1300 (5.2 MHz) might be about right… which is odd. (45 / 33 * 950 = 1295)

About not stepping down in the second mode group, I don’t have an answer. It worked when you tried the stock firmware but not a modified one… but all the modifications looked fine.

I wonder if setting the 7135 channel to 0 on turbo might help. This should reduce the heat level of the driver and increase lumen output, and I wonder if maybe the MCU could be overheating. I’d also suggest making it blink on step-down, for debugging purposes, and set the step-down to be much shorter (again, just for debugging).

pilotdog68
pilotdog68's picture
Offline
Last seen: 11 months 1 week ago
Joined: 05/30/2013 - 23:31
Posts: 6420
Location: Held against my will in IOWA, USA

In the most recent attempts I did have channel 2 at 0 for turbo. Heat shouldn’t be an issue at all, I am doing these tests outside of the light on my desk, amp draw capped at 1.2amps.

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

Major Projects:  Illuminated Tailcap, TripleDown/TripleStack Driver

pilotdog68
pilotdog68's picture
Offline
Last seen: 11 months 1 week ago
Joined: 05/30/2013 - 23:31
Posts: 6420
Location: Held against my will in IOWA, USA

Started from scratch and built a new driver. The FW in question does not work correctly on this driver either. I flashed a stock version of blf-a6 I had saved from back in May, and it appears to be working normally. The delay tweak of 1300 seems to have gotten the timing close to normal too. I know I am using a new spec C1 than I have before, could that be causing the issues?

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

Major Projects:  Illuminated Tailcap, TripleDown/TripleStack Driver

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 8 hours 17 min ago
Joined: 01/12/2013 - 14:40
Posts: 10613
Location: (469219) 2016 HO3

I just saw something really obvious that I missed earlier. (It helps to be awake while reading code. Smile )

Turbo steps down to the second-highest mode. And by second-highest, I mean second-to-last. Your second mode group has turbo in the second-to-last position, so it steps down to itself.

If you have no hidden modes, there is no need to step down from the “hidden” turbo, so it should work better to simply reduce the index by one. Instead of this:

mode_idx = solid_modes – 2;

Try this:

mode_idx —;

pilotdog68
pilotdog68's picture
Offline
Last seen: 11 months 1 week ago
Joined: 05/30/2013 - 23:31
Posts: 6420
Location: Held against my will in IOWA, USA

I feel like I should’ve caught that myself…. I’ve had to change that a few times before.

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

Major Projects:  Illuminated Tailcap, TripleDown/TripleStack Driver

Spike
Offline
Last seen: 5 years 1 week ago
Joined: 04/21/2014 - 15:36
Posts: 2

ToyKeeper wrote:
[-(Sun 2015-09-27 14:43:22)-(~/src/torches/trunk/ToyKeeper/blf-a6/)-]> ../../bin/build.sh blf-a6
avr-gcc -Wall -g -Os -mmcu=attiny13 -c -std=gnu99 -DATTINY=13 -o blf-a6.o -c blf-a6.c
avr-gcc -Wall -g -Os -mmcu=attiny13 -o blf-a6.elf blf-a6.o
avr-objcopy --set-section-flags=.eeprom=alloc,load --change-section-lma .eeprom=0 --no-change-warnings -O ihex blf-a6.elf blf-a6.hex
Program:    1002 bytes (97.9% Full)
Data:         13 bytes (20.3% Full)

Could you share your build.sh shell script? I assume from the output that’s it simple and straightforward but still.
ToyKeeper
ToyKeeper's picture
Offline
Last seen: 8 hours 17 min ago
Joined: 01/12/2013 - 14:40
Posts: 10613
Location: (469219) 2016 HO3

Spike wrote:

Could you share your build.sh shell script? I assume from the output that’s it simple and straightforward but still.

Yes, it’s at the link in my signature.
ToyKeeper
ToyKeeper's picture
Offline
Last seen: 8 hours 17 min ago
Joined: 01/12/2013 - 14:40
Posts: 10613
Location: (469219) 2016 HO3

FWIW, I added another published branch called “sandbox”, which holds stuff that has been checked in but isn’t quite ready for merging into the stable trunk yet.

https://code.launchpad.net/~toykeeper/flashlight-firmware/sandbox

For example, one extra in there right now is a s7.c firmware with its battery check mode changed to use a volts+tenths style readout. This style does work on attiny13a chips; it just takes enough room that I haven’t been able to fit it into blf-a6.c.

I’m debating whether to freeze blf-a6.c or keep allowing changes to it now that we’re post-production. I’ve refactored quite a bit of code shared between projects, including blf-a6, and am not sure whether to put the refactored one into the main branch or leave it in its production state. It’s both simpler and more complicated now, since some common functions moved into shared headers.

vestureofblood
vestureofblood's picture
Offline
Last seen: 1 week 5 days ago
Joined: 08/17/2012 - 15:21
Posts: 1930
Location: Missouri

Hey all,

Are there any of the OS firmwares available that have an oscillating strobe?    Not one that changes each time you turn it on, but one that changes frequently while its on?

In Him (Jesus Christ) was life; and the life was the light of men. And the light shineth in darkness; and the darkness comprehended it not.
http://asflashlights.com/ Everyday Carry Flashlights, plus Upgrades for Maglite.

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

I was going to ask about implementing this. I’ve read that a random strobe is much better at disorienting. Averaging around 12hz (?) but without always the same length flashes or pauses between flashes. This keeps the brain from being able to anticipate the next flash.
Does random require much resources from a tiny13?

Tom E
Tom E's picture
Offline
Last seen: 46 min 9 sec ago
Joined: 08/19/2012 - 08:23
Posts: 13386
Location: LI NY

I'm not aware of a strobe that does that, but certainly it can be done, just need to know a little about the randomness, constraints, etc. Any references for this? Great amount of detail and research explained here:

  http://www.candlepowerforums.com/vb/showthread.php?356772-Police-Study-of-tactical-use-of-Strobe

Best reference I've found.

 

Joat
Offline
Last seen: 11 months 1 week ago
Joined: 06/13/2013 - 23:43
Posts: 523
Location: Minnesota
ToyKeeper wrote:
I’m debating whether to freeze blf-a6.c or keep allowing changes to it now that we’re post-production. I’ve refactored quite a bit of code shared between projects, including blf-a6, and am not sure whether to put the refactored one into the main branch or leave it in its production state. It’s both simpler and more complicated now, since some common functions moved into shared headers.

I would think the released A6 code should be findable, should there be a branch that has that version in it?

Joat
Offline
Last seen: 11 months 1 week ago
Joined: 06/13/2013 - 23:43
Posts: 523
Location: Minnesota
Halo… wrote:
I was going to ask about implementing this. I’ve read that a random strobe is much better at disorienting. Averaging around 12hz (?) but without always the same length flashes or pauses between flashes. This keeps the brain from being able to anticipate the next flash. Does random require much resources from a tiny13?

I’ve played with a pseudo random strobe, I used Alex van Heuvelen’s no cap off time firmware and put in an array of randomish numbers in the same way he had the ramp coded. There is plenty of room an a atiny 13 for it.

vestureofblood
vestureofblood's picture
Offline
Last seen: 1 week 5 days ago
Joined: 08/17/2012 - 15:21
Posts: 1930
Location: Missouri

Tom E wrote:

I'm not aware of a strobe that does that, but certainly it can be done, just need to know a little about the randomness, constraints, etc. Any references for this? Great amount of detail and research explained here:

  http://www.candlepowerforums.com/vb/showthread.php?356772-Police-Study-of-tactical-use-of-Strobe

Best reference I've found.

 




As to the randomness I would say probly a rotation in a randomish order between about 4 frequencies would be enough.      I have an idea of what the guy is looking for because I made him a light with a similar strobe a few years ago.

https://www.youtube.com/watch?v=6nyw4tVGq2o

This was made with 4 of the random strobe drivers and 4 color LEDs.     I cant get the drivers I used for that anymore so I was hoping to dig something up here.

 

In Him (Jesus Christ) was life; and the life was the light of men. And the light shineth in darkness; and the darkness comprehended it not.
http://asflashlights.com/ Everyday Carry Flashlights, plus Upgrades for Maglite.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 8 hours 17 min ago
Joined: 01/12/2013 - 14:40
Posts: 10613
Location: (469219) 2016 HO3

Joat wrote:
ToyKeeper wrote:
I’m debating whether to freeze blf-a6.c or keep allowing changes …

I would think the released A6 code should be findable, should there be a branch that has that version in it?

Thanks, I’ll do that. Smile

It’s pretty trivial to branch and publish the released code separately. I’m a little embarrassed I didn’t think of it.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 8 hours 17 min ago
Joined: 01/12/2013 - 14:40
Posts: 10613
Location: (469219) 2016 HO3

vestureofblood wrote:
Are there any of the OS firmwares available that have an oscillating strobe? Not one that changes each time you turn it on, but one that changes frequently while its on?

Let’s see… I put a police-like strobe into ‘bistro’ in the tiny25 repository branch, but it only switches between 8Hz and 16Hz at slightly faster than once per second.

The ‘s7’ firmware has two self-ramping variable strobes, but they change smoothly and relatively slowly. It’s more for stopping and reversing fans and such, not for disorienting people.

I did a nice random disorientation strobe as a test at one point, but the rand function takes a lot of space. I also used it to make something like a lightning storm simulator at one point.

To save space I also made one which reads the ROM and uses it to make a pseudo-random strobe, which is probably the most feasible to put into an existing project. I don’t remember where it went, but might be able to find it again.

I think I found it. It needs to be put into other code in order to work, but the algorithm is really simple. It looks random but will repeat every 256 flashes. The speed is about 7.5 to 15 Hz. Something like this…

uint8_t myrandom() {
    static uint8_t *offset = 0;
    return pgm_read_byte(offset++);
}
...
void main() {
    ...
    while (1) {
        ...
        else if (mode_idx == STROBE) {
            uint8_t ms = 34 + (myrandom() & 0x1f);
            PWM_LVL = 255;
            _delay_ms(ms);
            PWM_LVL = 0;
            _delay_ms(ms);
        }
        ...
    }
}
testedandbaked
testedandbaked's picture
Offline
Last seen: 3 months 3 weeks ago
Joined: 09/04/2015 - 07:40
Posts: 60
Location: Australia

It turns if you remove the code pertaining to switching to the 2nd mode group, you can get the code down to 830 bytes, a 174 byte reduction! Finally, I can squeeze in some extra blinky modes to BLF-A6 for an egg timer and SOS mode.

I was wondering how I could share this modified code in the repository. Do I post the code on the forum somewhere or upload straight on Launchpad (made a Launchpad account, but still not sure how to upload)?

Tom E
Tom E's picture
Offline
Last seen: 46 min 9 sec ago
Joined: 08/19/2012 - 08:23
Posts: 13386
Location: LI NY

TK - pretty cool technique for random # generator, and sure does make it compact, as long as those 256 bytes contains code, which it does.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 8 hours 17 min ago
Joined: 01/12/2013 - 14:40
Posts: 10613
Location: (469219) 2016 HO3

testedandbaked wrote:
It turns if you remove the code pertaining to switching to the 2nd mode group, you can get the code down to 830 bytes, a 174 byte reduction! Finally, I can squeeze in some extra blinky modes to BLF-A6 for an egg timer and SOS mode.

I was wondering how I could share this modified code in the repository. Do I post the code on the forum somewhere or upload straight on Launchpad (made a Launchpad account, but still not sure how to upload)?


It’s funny you mention that. In the blf-a6 directory, there’s a file called tk-otc.c which is specifically created for people who want to exchange the runtime config options for extra space. Smile I think I may have forgotten to apply some recent blf-a6 changes to tk-otc though, so its code may be a little behind.

If you’d like to upload to Launchpad, that’s easiest for me. But you can also just post the code somewhere and I can add it. The Launchpad method is done using bzr’s “push” command. For example: bzr push lp:~myaccount/flashlight-firmware/my-branch

After that, either create a merge proposal or tell me that there’s a branch waiting. Smile

Update: I merged the pending blf-a6 updates into tk-otc. The resulting build sizes are 1002 bytes versus 706 bytes. So, almost 300 bytes saved for others to fill with custom code. Smile I also made a stable maintenance branch for blf-a6, so it can get bugfixes without having to pull in the entire refactoring project I started:
https://code.launchpad.net/~toykeeper/flashlight-firmware/blf-a6-final

Joat
Offline
Last seen: 11 months 1 week ago
Joined: 06/13/2013 - 23:43
Posts: 523
Location: Minnesota

Is there a list of OTC and voltage sense calibrations for different drivers? Maybe it could be done with #if’s like you have done for the attiny 25 code.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 8 hours 17 min ago
Joined: 01/12/2013 - 14:40
Posts: 10613
Location: (469219) 2016 HO3

Joat wrote:
Is there a list of OTC and voltage sense calibrations for different drivers? Maybe it could be done with #if’s like you have done for the attiny 25 code.

Yes, though I’ve currently got those measurements in the middle of a re-organization of sorts. It’s moving from a single file for all measurements to an individual file per driver per calibration type.

Check battcheck/readings.txt, battcheck/otc-readings.txt, and battcheck/readings/* to see values from existing drivers.

The mechanism being used at the moment is to #include “../tk-calibration.h” for all this stuff, so you can edit that single file and have it apply to everything you build from then on. The detailed voltage values there can be generated by battcheck.py; you don’t have to measure every exact value in the list; just one high value and one low value, and the script will calculate the rest.

(BTW, I don’t like putting “tk-” at the beginning of each include, but C doesn’t really have namespaces and I don’t want to run into naming collisions, so I prefixed a namespace-like identifier)

Joat
Offline
Last seen: 11 months 1 week ago
Joined: 06/13/2013 - 23:43
Posts: 523
Location: Minnesota

Thanks, I never did run battcheck and set the ADC levels when I put your cypreus2 code into my AX6, and it looks like the values are way off where they should be, in the dangerous direction.

laythaws
Offline
Last seen: 10 months 3 weeks ago
Joined: 01/15/2015 - 00:57
Posts: 107
Location: Location::Location::

Hi, anyone can help me what is the problem with my attiny13a. It’s a second batch of attiny13a that i bought from ebay, 10 pcs. The first batch that i bought earlier this year from the same seller all works well but this 2nd batch all 10 gives an error when i try to use this command avrdude -p t13 -c usbasp -n

avrdude: error: programm enable: target doesn’t answer. 1
avrdude: initialization failed, rc=-1 Double check connections and try again, or use -F to override this check.

I checked the connections and they are properly connected. To be sure that my usbasp is not the problem I programmed again attiny13a from the 1st batch and they work well.
What is the problem with the 2nd batch of attiny13a that i bought, are they all dead?

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

They could have spi or reset disabled or be counterfeit chips.

laythaws
Offline
Last seen: 10 months 3 weeks ago
Joined: 01/15/2015 - 00:57
Posts: 107
Location: Location::Location::
Halo… wrote:
They could have spi or reset disabled or be counterfeit chips.

How do i enable reset or spi?
If it’s counterfeit then here is where i bought it http://www.ebay.com/itm/10PCS-NEW-SOP-8-ATTINY13A-SU-TINY13A-SU-SMD-IC-/381375008462 to warn others not to buy from this ebay seller survy2014. But i did not see any negative feedback for this item on his feedback section. He has already sold 56 10pcs of this and i did not see any negative feedback.

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

A high voltage programmer or fuse doctor / fuse reseter would be needed to fix reset, spi. But new genuine chips will come with it all be enabled and ready to flash.

Did you ever, even once, get a different error (without “target doesn’t answer”) from those 10 chips?

laythaws
Offline
Last seen: 10 months 3 weeks ago
Joined: 01/15/2015 - 00:57
Posts: 107
Location: Location::Location::
Halo… wrote:
Did you ever, even once, get a different error (without “target doesn’t answer”) from those 10 chips?

No, always the same error
avrdude: error: programm enable: target doesn’t answer. 1
avrdude: initialization failed, rc=-1 Double check connections and try again, or use -F to override this check.

Tom E
Tom E's picture
Offline
Last seen: 46 min 9 sec ago
Joined: 08/19/2012 - 08:23
Posts: 13386
Location: LI NY

Sounds like the same exact problem I had from an eBay seller: polida2008. These chips are probably pre-programmed left over inventory with the reset disabled - probably why they are so cheap. Not that they were ever used, as mounted on a board, but they were programmed for a certain application. Richard at MtnE has the package: Atmel's AVR Dragon, that will disable that, and make them programmable once again. Can't be sure that's your problem but sounds that way.

testedandbaked
testedandbaked's picture
Offline
Last seen: 3 months 3 weeks ago
Joined: 09/04/2015 - 07:40
Posts: 60
Location: Australia

ToyKeeper wrote:
testedandbaked wrote:
It turns if you remove the code pertaining to switching to the 2nd mode group, you can get the code down to 830 bytes, a 174 byte reduction! Finally, I can squeeze in some extra blinky modes to BLF-A6 for an egg timer and SOS mode.

I was wondering how I could share this modified code in the repository. Do I post the code on the forum somewhere or upload straight on Launchpad (made a Launchpad account, but still not sure how to upload)?


It’s funny you mention that. In the blf-a6 directory, there’s a file called tk-otc.c which is specifically created for people who want to exchange the runtime config options for extra space. Smile I think I may have forgotten to apply some recent blf-a6 changes to tk-otc though, so its code may be a little behind.

If you’d like to upload to Launchpad, that’s easiest for me. But you can also just post the code somewhere and I can add it. The Launchpad method is done using bzr’s “push” command. For example: bzr push lp:~myaccount/flashlight-firmware/my-branch

After that, either create a merge proposal or tell me that there’s a branch waiting. Smile

Update: I merged the pending blf-a6 updates into tk-otc. The resulting build sizes are 1002 bytes versus 706 bytes. So, almost 300 bytes saved for others to fill with custom code. Smile I also made a stable maintenance branch for blf-a6, so it can get bugfixes without having to pull in the entire refactoring project I started:
https://code.launchpad.net/~toykeeper/flashlight-firmware/blf-a6-final

I didn’t even realise that tk-otc was the single mode group version of BLF-A6, having never looked at it. Somehow you’ve managed to squeeze out another 120 bytes!

I’m not too familiar with bzr and Launchpad, so I’ve posted the code here instead.
This version has:
config_star code removed (before I discovered it was not really necessary)
Single mode group with 6 modes
Memory selection by 16 clicks
20s turbo timeout

Hidden modes

  • Strobe
  • Turbo
  • Biking strobe
  • Battery check (10% steps with ADC values measured from my Attiny13A and % to voltage conversion from HKJ’s tests for the efest 10440)
  • SOS mode
  • Egg timer

Pages