Flashlight Firmware Repository

1798 posts / 0 new
Last post
Mitko
Mitko's picture
Offline
Last seen: 17 hours 32 min ago
Joined: 09/19/2014 - 05:20
Posts: 1529
Location: Bulgaria

I tried Star 1 mode on wight`s A17DD driver and it works, the problem is that it give only 3.5amps max

How can one solve that problem?

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

Mitko wrote:
I tried Star 1 mode on wight`s A17DD driver and it works, the problem is that it give only 3.5amps max

How can one solve that problem?


The only firmware change I can think of which might be relevant is to change FAST_PWM_START to 255, to force it to use phase-correct PWM. But this would likely only change the numbers by a tiny tiny amount (like half a percent).

The rest is probably due to hardware. You might want to try bypassing springs, checking your measurement setup, using thicker wires anywhere possible, using a hotrod cell, etc. Might also be worth checking to make sure the light hadn’t already stepped down from maximum when the measurement was taken.

The emitter type and vintage makes a big difference too… if it’s a recent XM-L2 it might not be able to go as high as an older XM-L2, for example.

I’m not sure what the best practices are for high-amp measurement, but it seems like most people prefer to use a clamp meter and thick short wires and it probably doesn’t work as well to use a traditional DMM on an open tailcap. I recall a lot of discussion about this on the BLF X6 thread, and how hard it is to accurately measure amps. It might be easier to measure lumens instead.

Mitko
Mitko's picture
Offline
Last seen: 17 hours 32 min ago
Joined: 09/19/2014 - 05:20
Posts: 1529
Location: Bulgaria

Already did that ToyKeeper- 3.5amps tops, wierd, tried on 3 different emitters , and 2 drivers- on Samsung 25r battery

Since its the best even hunting firmware and there are lotsa hunters, i use this one most Smile

P.S Same drivers with your A6 firmware top up arround 4.8-5amps with U2 1A XML2

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:
guardior wrote:
Mike C wrote:
If RAM space does turn out to be your problem, you could re-write that EEPROM wear leveling routine …

And then I decrease the eeprom array from 32 to 8 byte and loop over it 8 times?

Or you could copy save_state() and restore_state() from blf-a6/tk-otc.c, which already fixed the issue. The array is completely unnecessary, since you can simply read one byte at a time. We don’t really care about speed here, just space. It uses all 64 bytes of eeprom, but only requires 1 byte of global-scope RAM and up to 2 more bytes of local-scope RAM.

I use this method on the 84 and 85 as it has 512 bytes. I already have an array of 16 bytes full of different settings not that are changed unless user enters the user programming mode, so before this array gets filled up with the stored settings I use it for looping through as described to find the mode bytes.

On the 13A I’d go withToyKeeper’s suggestion. There is no need for the array really, just use a single byte. You won’t notice any difference in start-up speed, takes less space to program and uses less RAM.

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

Mitko wrote:
… 3.5amps tops, …
P.S Same drivers with your A6 firmware top up arround 4.8-5amps with U2 1A XML2

That’s really strange. I’m not as familiar with STAR; I only changed what was necessary to make it work as a 1-mode driver.

Looking again, I see one other thing which could make things a little weird. STAR sets alt PWM (in set_output()) to the same value as the primary channel (regardless of whether it’s compiled to use dual PWM), so it’s turning on both channels on a 2-channel driver. In my blf-a6 tests I found that turbo is actually brighter with only the FET channel — turning on both the FET and 7135 causes lower output. So if you’re using a 2-channel driver it might be that the 7135 is actually getting in the way.

More generally, I’m not certain it’s a good idea to run at full direct-drive amps on a 1-mode light, unless you make the turbo timeout really short. If it’s mounted on a weapon, there’s no skin contact so nobody would notice if it gets really hot.

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

ToyKeeper wrote:
Tom E wrote:
Weird - just tried it again, and the difference is 48 bytes saved - 984 with inline, 948 without. ... This is what 6.2 studio invokes for compiling: "C:\Program Files (x86)\Atmel\Atmel Toolchain\AVR8 GCC\Native\3.4.1056\avr8-gnu-toolchain\bin\avr-gcc.exe" -x c -funsigned-char -funsigned-bitfields -Os -ffunction-sections -fdata-sections -fpack-struct -fshort-enums -Wall -mmcu=attiny13a -c -std=gnu99 -MD -MP -MF "Ferrero_Rocher.d" -MT"Ferrero_Rocher.d" -MT"Ferrero_Rocher.o" -o "Ferrero_Rocher.o" ".././Ferrero_Rocher.c"
Thanks! The important option there was "-c -std=gnu99". I added this to my build script and am now getting the same results you are. This also has reduced the size of every firmware I've tried so far, so I'm leaving it in as a permanent thing. Smile This also saved enough room to let the full config mode fit into the blf-a6 firmware without having to remove anything. :D

Wow, interesting... Not sure if the Studio IDE set that somehow by default. It's in the Compile "Miscellaneous" settings. When I create new solutions/projects, I simply copy a previous to begin with.

Oops - the "48" saved should be "36"... Smile

guardior
Offline
Last seen: 3 years 3 months ago
Joined: 04/06/2015 - 14:06
Posts: 129
Location: Sweden

ToyKeeper wrote:
Or you could copy save_state() and restore_state() from blf-a6/tk-otc.c, which already fixed the issue. The array is completely unnecessary, since you can simply read one byte at a time. We don’t really care about speed here, just space. It uses all 64 bytes of eeprom, but only requires 1 byte of global-scope RAM and up to 2 more bytes of local-scope RAM.

I was thinking about doing it byte by byte but thought it would be too slow so I went with a 8 byte array instead. I got plenty of space in ram anyway but I may switch later when my flasher arrives. But i don’t want a noticable boot time in my driver. Silly

Edit: Using an array was a bit tricky with a weird pointer to the eeprom adress. Must get my flasher to confirm I got it right.

guardior
Offline
Last seen: 3 years 3 months ago
Joined: 04/06/2015 - 14:06
Posts: 129
Location: Sweden

ToyKeeper wrote:
The only firmware change I can think of which might be relevant is to change FAST_PWM_START to 255, to force it to use phase-correct PWM. But this would likely only change the numbers by a tiny tiny amount (like half a percent).

Is it better to put pwm to phase when in 255 level? What do you get by default? Or maybe there is no default?
ToyKeeper
ToyKeeper's picture
Offline
Last seen: 59 min 57 sec ago
Joined: 01/12/2013 - 14:40
Posts: 7910
Location: (469219) 2016 HO3

guardior wrote:
I was thinking about doing it byte by byte but thought it would be too slow so I went with a 8 byte array instead. I got plenty of space in ram anyway but I may switch later when my flasher arrives. But i don’t want a noticable boot time in my driver.

The attiny13a is running at 4.8 MHz. It only takes a few clock cycles to check each eeprom byte, and there are 64 bytes. Let’s say it takes a dozen cycles each; that’s 768 cycles, which should take about 0.16 ms total. The data sheets suggest an array might save about four clock cycles per byte, but it’ll still be roughly 0.1 ms.

Can you feel a boot-up difference of 0.05 milliseconds?

guardior wrote:
Is it better to put pwm to phase when in 255 level? What do you get by default? Or maybe there is no default?

In general, yes, phase-correct PWM is a good idea on the highest level. It doesn’t usually make any noticeable difference, but it’s nice to make the code default to phase-correct to account for the few cases where it matters. I don’t think the hardware has a default; you have to explicitly tell it to generate pulse waves because those pins can also serve other functions.
Mitko
Mitko's picture
Offline
Last seen: 17 hours 32 min ago
Joined: 09/19/2014 - 05:20
Posts: 1529
Location: Bulgaria
Quote:
More generally, I’m not certain it’s a good idea to run at full direct-drive amps on a 1-mode light, unless you make the turbo timeout really short. If it’s mounted on a weapon, there’s no skin contact so nobody would notice if it gets really hot.

Well, the timer is set to arround 1.5minutes- then it ramps down to 50%, the FL body gets only warmer this way ….plus when its mounted on a weapon it lights for usualy 10 seconds tops- i use simple momentary on self made remote switches, made from thick Cu pads: found that those are most reliable, especialy with all that forest fog and moisture

The 7135 thing…..you might be right, i have to try the 024 version out then

Once again, 10x for that 1mode version, i waited for this long time

guardior
Offline
Last seen: 3 years 3 months ago
Joined: 04/06/2015 - 14:06
Posts: 129
Location: Sweden

ToyKeeper wrote:
The attiny13a is running at 4.8 MHz. It only takes a few clock cycles to check each eeprom byte, and there are 64 bytes. Let’s say it takes a dozen cycles each; that’s 768 cycles, which should take about 0.16 ms total. The data sheets suggest an array might save about four clock cycles per byte, but it’ll still be roughly 0.1 ms.

Can you feel a boot-up difference of 0.05 milliseconds?


Most likely not. Smile But, you can have all the mhz in the world, if it’s slow reading from eeprom it’ll still be slow. Look, I’m not saying it’s too slow reading byte by byte. I thought it was faster reading 8 byte blocks but if it works reading byte by byte that is a simpler solution.

ToyKeeper wrote:
In general, yes, phase-correct PWM is a good idea on the highest level. It doesn’t usually make any noticeable difference, but it’s nice to make the code default to phase-correct to account for the few cases where it matters. I don’t think the hardware has a default; you have to explicitly tell it to generate pulse waves because those pins can also serve other functions.

Got it, I take it you mean something like this then: http://pastebin.com/z9HBuUpi

Is it possible to paste code directly in the forum?

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

Ish. I normally use phase-correct on moon and turbo, and use fast for everything between. The pulses are longer with phase, which makes moon more stable (drops less with voltage).

But if it doesn’t bother you, you could use phase everywhere. I don’t like the whining sound or visible flashing, but not everyone is sensitive to those.

guardior
Offline
Last seen: 3 years 3 months ago
Joined: 04/06/2015 - 14:06
Posts: 129
Location: Sweden

Getting rid of buzzing pwm modes are my main motivation for writing my own firmware. But was thinking about something else. How do the different sleep modes work? SLEEP_MODE_IDLE just seems to be doing more or less nothing. I’m more curious about SLEEP_MODE_PWR_DOWN though. Does it turn off the output? If you run a special mode like ie strobe it could be a bit tricky to turn it off manually otherwise. You only got a few bytes to play with so would be nice if output is turned off automatically when going to SLEEP_MODE_PWR_DOWN.

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

TBH, I haven’t really optimized much for sleep mode. I have some relevant patches waiting for me to merge and test, but I haven’t done it yet…

In sleep mode the PWM counter stops, but I haven’t specifically tested to see what that does when I don’t set it to zero first. I expect the emitter would stay on if it’s not turned off before entering sleep (which is a trick I use for the standby light on my Roche F6, but first I set it to a special non-PWM low mode).

Interrupts can wake up the MCU from sleep mode, if they are enabled and a relevant event happens. Touching the e-switch is one example, or the watchdog timer can do it too. So for low-power shutdown it’s usually a good idea to disable interrupts too. On e-switch standby though, at least the switch interrupt needs to stay on.

guardior
Offline
Last seen: 3 years 3 months ago
Joined: 04/06/2015 - 14:06
Posts: 129
Location: Sweden

ToyKeeper wrote:
Tom E wrote:
Weird – just tried it again, and the difference is 48 bytes saved – 984 with inline, 948 without.

This is what 6.2 studio invokes for compiling:
“C:\Program Files (x86)\Atmel\Atmel Toolchain\AVR8 GCC\Native\3.4.1056\avr8-gnu-toolchain\bin\avr-gcc.exe” -x c -funsigned-char -funsigned-bitfields -Os -ffunction-sections -fdata-sections -fpack-struct -fshort-enums -Wall -mmcu=attiny13a -c -std=gnu99 -MD -MP -MF “Ferrero_Rocher.d” -MT“Ferrero_Rocher.d” -MT“Ferrero_Rocher.o” -o “Ferrero_Rocher.o” “.././Ferrero_Rocher.c”

Thanks!

The important option there was “-c -std=gnu99”. I added this to my build script and am now getting the same results you are. This also has reduced the size of every firmware I’ve tried so far, so I’m leaving it in as a permanent thing. Smile

This also saved enough room to let the full config mode fit into the blf-a6 firmware without having to remove anything. Big Smile


Hey thanks for the tip. By adding c99 to the makefile and using inline for a few functions that only run once I managed to save 40 bytes. Smile It looks like c89 is the default you get. Using c11 didn’t change anything for me though.
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

ToyKeeper wrote:
pilotdog68 wrote:
Another weird question: is it possible to have lvp protection enabled in one mode group, and disabled in the other?

Possible, yes. But there is no code for this right now so someone would need to write it. I think it would be reasonably simple though, just wrapping the whole LVP logic clause inside an “if (modegroup == 0)” or similar.

Sorry, I’m still a total noob at this. Is this close to what would need to be done? The purpose is for my XinTD X3, i want to have one mode group for 18650, and one for use with 3x alkaline AA’s. So I don’t need LVP for the AA’s.

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

ToyKeeper wrote:
Ish. I normally use phase-correct on moon and turbo, and use fast for everything between. The pulses are longer with phase, which makes moon more stable (drops less with voltage).

What is the lower PWM limit where you switch between phase-correct and fast?

ToyKeeper wrote:
Interrupts can wake up the MCU from sleep mode, if they are enabled and a relevant event happens. Touching the e-switch is one example, or the watchdog timer can do it too. So for low-power shutdown it’s usually a good idea to disable interrupts too. On e-switch standby though, at least the switch interrupt needs to stay on.

Interesting. I never looked at the E-switch versions of Star. I coded my own E-switch routine by changing the watchdog timer to the fastest and have the switch test in my main while(1) loop. It may have made the logic pretty easy but I guess it’s not a power efficient way of running things as my entire main routine with voltage monitoring and all gets executed a whole lot more. Has anyone done any tests? Or maybe this stuff can be found in the datasheets, haven’t looked at MCU power consumption at all.
ToyKeeper
ToyKeeper's picture
Offline
Last seen: 59 min 57 sec ago
Joined: 01/12/2013 - 14:40
Posts: 7910
Location: (469219) 2016 HO3
pilotdog68 wrote:
ToyKeeper wrote:
… wrapping the whole LVP logic clause inside an “if (modegroup == 0)” or similar.
Sorry, I’m still a total noob at this. Is this close to what would need to be done? The purpose is for my XinTD X3, i want to have one mode group for 18650, and one for use with 3x alkaline AA’s. So I don’t need LVP for the AA’s.

Close. You used a preprocessor “#if”, which runs at compile time. What you need instead is a regular C “if” which runs during regular operation.

if (some condition) {
  do this;
}

Other than the syntax, I think you nailed it. The whole LVP clause just needs the “if” around it so it’ll only run in one mode group. Smile

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

Mike C wrote:
What is the lower PWM limit where you switch between phase-correct and fast?

I use phase for moon and turbo only. The threshold is whatever level I need for moon. Usually I calibrate this per-light, using whatever gets me closest to 0.3 lm. However, if the two nearest phase levels are too far apart and a fast PWM mode gets closer, sometimes I’ll use fast instead.

Mike C wrote:
Interesting. I never looked at the E-switch versions of Star. I coded my own E-switch routine by changing the watchdog timer to the fastest and have the switch test in my main while(1) loop. It may have made the logic pretty easy but I guess it’s not a power efficient way of running things as my entire main routine with voltage monitoring and all gets executed a whole lot more. Has anyone done any tests? Or maybe this stuff can be found in the datasheets, haven’t looked at MCU power consumption at all.

I doubt the MCU power consumption is a significant factor when the main emitter is on. I mean, it normally spends most of its time in busy loops… so I doubt it matters if you check things more often.

As for e-switches, I’ve been meaning to write a new e-switch code base from scratch. The approach used in STAR works and is compact but makes it relatively difficult to handle or map events. I’m hoping instead to keep an event queue where actions can be mapped in more intuitive ways. For example, “if (events_eq(triple_click)) { blah; }”. This might require a bigger MCU though; my early experiments ran out of space quickly.

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

After using cypreus2 on a real light for a day, I decided the hidden modes were in the wrong order. I updated it to make things a little nicer by default. Here’s the new interface:

I still have 70 bytes left to do something with, but I’m not sure what. I know I don’t have to fill all the space, but maybe there’s something worth adding? I might be able to fit soft-regulation for moon, to make it more stable at different voltages…

BTW, the reason it has two turbos is because it’s running on a light which goes well beyond the sane limit for power in its size — 10 to 15 amps in a little 18650 tube light (2200 to 3300 lumens, depending on the hardware). That’s the same as a Skyray King or Supfire M6, only in a much smaller host. This is configurable in the firmware, of course, but I don’t want to melt my nice new hotrod.

Crux
Crux's picture
Offline
Last seen: 8 months 3 weeks ago
Joined: 05/03/2011 - 16:27
Posts: 227
Location: Northcoast, Ohio, USA

ToyKeeper wrote:
... the reason it has two turbos is because it's running on a light which goes well beyond the sane limit for power in its size ...

In this case you may want to consider renaming 'Max Turbo' to 'Nitrous'!

guardior
Offline
Last seen: 3 years 3 months ago
Joined: 04/06/2015 - 14:06
Posts: 129
Location: Sweden

ToyKeeper wrote:
TBH, I haven’t really optimized much for sleep mode. I have some relevant patches waiting for me to merge and test, but I haven’t done it yet…

In sleep mode the PWM counter stops, but I haven’t specifically tested to see what that does when I don’t set it to zero first. I expect the emitter would stay on if it’s not turned off before entering sleep (which is a trick I use for the standby light on my Roche F6, but first I set it to a special non-PWM low mode).

Interrupts can wake up the MCU from sleep mode, if they are enabled and a relevant event happens. Touching the e-switch is one example, or the watchdog timer can do it too. So for low-power shutdown it’s usually a good idea to disable interrupts too. On e-switch standby though, at least the switch interrupt needs to stay on.


I think that if you go to SLEEP_MODE_PWR_DOWN output should be turned off, hopefully. Found this pic:

http://2.bp.blogspot.com/_9WOJMofzxU0/S9PyagiuISI/AAAAAAAAHY8/tGlOUPRman...

So turn off WTD and go to SLEEP_MODE_PWR_DOWN should be enough to turn off as much as possible. But will test when I get my flasher.

Crux
Crux's picture
Offline
Last seen: 8 months 3 weeks ago
Joined: 05/03/2011 - 16:27
Posts: 227
Location: Northcoast, Ohio, USA

Also remember to turn off the ADC...

guardior
Offline
Last seen: 3 years 3 months ago
Joined: 04/06/2015 - 14:06
Posts: 129
Location: Sweden

Crux wrote:

Also remember to turn off the ADC…


Looking at the picture i posted earlier that should not be needed. Hopefully the power down mode takes care of that already.
Crux
Crux's picture
Offline
Last seen: 8 months 3 weeks ago
Joined: 05/03/2011 - 16:27
Posts: 227
Location: Northcoast, Ohio, USA

Correct me if I'm wrong but I believe that chart shows the wake-up sources from the various sleep modes, and doesn't imply that all other systems are disabled.

This is an excerpt from the ATtiny13A datasheet (doc8126):

"7.4.1 Analog to Digital Converter
If enabled, the ADC will be enabled in all sleep modes. To save power, the ADC should be disabled
before entering any sleep mode. When the ADC is turned off and on again, the next
conversion will be an extended conversion. Refer to “Analog to Digital Converter” on page 82 for
details on ADC operation."

guardior
Offline
Last seen: 3 years 3 months ago
Joined: 04/06/2015 - 14:06
Posts: 129
Location: Sweden

As I understand it ADC is turned off in power down mode. It is still enabled but it doesn’t run. If you leave power down mode the ADC will start working again.

Edit: I posted the wrong pic earlier, this is the right one for attiny13: http://we.easyelectronics.ru/uploads/images/00/04/62/2011/05/02/646e36.png

Crux
Crux's picture
Offline
Last seen: 8 months 3 weeks ago
Joined: 05/03/2011 - 16:27
Posts: 227
Location: Northcoast, Ohio, USA

In my testing, I was able to see quite a difference in current draw during sleep with and without the ADC disabled.

It's worthy of a quick test.

guardior
Offline
Last seen: 3 years 3 months ago
Joined: 04/06/2015 - 14:06
Posts: 129
Location: Sweden

Hmm ok. Just checked, it only takes two bytes to disable adc explicitly before enter power down mode. But it would be nice if not needed. And also not needed to fiddle with the pwm output too.

Edit: It seems that you are right my fellow yank. Smilehttp://www.technoblogy.com/show?KX0
“I confirmed that the ADC uses about 320uA in sleep.”
ADC does take some power even in power down mode, so it should be disabled first.

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

Measurements trump theory, and Crux was nice enough to measure a lot of code for power use. Smile

I still need to fit as much of that as possible into various firmwares. Like, the blf-a6 code only has two bytes left so I should probably use that to shut off the single biggest remaining power drain after LVP.

guardior
Offline
Last seen: 3 years 3 months ago
Joined: 04/06/2015 - 14:06
Posts: 129
Location: Sweden

So my flasher arrived today. I ordered these items:
http://www.dx.com/p/343981
http://www.dx.com/p/268210
http://www.dx.com/p/80207

And it works but … if you look at the clip it got tighter pins than normal female cable pins. Arrgh, but I managed to cut the plastic on the clip around 10mm and bend the pins and then it bloody worked to fit the ribbon cable. Smile Otherwise the clip seems to be of decent quality. So I managed to get my code in order too, used the one byte reads as suggested by ToyKeeper and got it to work. Got a compiler warning when using a line from blf-a6 but managed to fix it with this:
eep = eeprom_read_byte((const uint8_t *)(uint16_t)eepos);

Don’t ask me exactly why it should be like that, I found the fix on the net somewhere. Smile Finally there is a simple firmware too, code here:
https://github.com/xerxes2/flashlight-firmware/tree/master/tacdrv

Bugfixes most welcome. Smile

Pages