Flashlight Firmware Repository

You can actually eliminate the eeprom mirror entirely, and IIRC it doesn’t really increase ROM usage. I’ve been doing it that way lately. I also just found out that avr-size can do a lot of the counting for you if you run it like “avr-size -C —mcu=attiny13 foo.elf”. However, you still have to leave room for the stack, not just the variables. It’s not usually very big on a processor this small, but some temporary data still gets stored in RAM on top of the explicitly-declared variables. For example, the function call stack, and any expressions which don’t fit entirely into registers.

The extra info in that avr-size command can definitely help when you start approaching the limit.

Yes that was the avr-size command I was talking about. So the missing byte could be something else then. I think I’ll keep the eeprom mirror for now but if I need ram more than flash I know I could get rid of it. And yeah, I also read somewhere that you should keep a few bytes on ram for the mcu to use, dunno how many though. IIRC there was a figure 70% floating around. If you go above that then you might run into ram problems.

Hey TK, is the extended config mode (memory) in blf-a6 supposed to be working? I remember seeing somewhere that it wasn’t fully implemented yet, but now I’m not sure.

Sorry if it was already mentioned.

It works if recompiled with that option enabled, but it’s necessary to remove both the tactical strobe and bike flasher to make room.

The extended config mode simply converts it to use two config options (mode group and mode memory) instead of one (mode group). But if you’re recompiling anyway, you can set those both at compile time (in tk-otc.c) and have lots of room left over for other stuff.

I might still be able to reduce the size a little, and I’ll definitely try… but for now the default is one config-mode option and one star-based option.

So by ‘enable’ you just mean un-comment it? I prefer to be able to toggle both mode group and memory without disassembly. I also have no problem deleting blinkies.

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

Still got some time before my flasher arrives and I got a little interested in this. So to use the whole 64 byte eeprom I first must change the 31 to 63 in this line?
eepos=(eepos+1)&31; // wear leveling, use next cell

And then I decrease the eeprom array from 32 to 8 byte and loop over it 8 times? Sounds not very difficult to do and will not take that many more bytes in flash.

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.

TK - you probably haven't re-visited the Ferrero-Rocher driver in a while, but today I saved a bunch of bytes by taking "inline" off of next_mode() and prev_mode(). Basically if you call a function more than once, chances are "inline" will waste space. I did this to my version of the e-switch driver the other day, and same thing - saved a lot on program space.

Basically, comment out the ‘#define CONFIG_STARS’ line. Then make room by commenting out the two strobey modes.

I did some code changes today to make this easier. Also, I found some new ways to reduce the size overall, so it’s possible to put in the full config mode plus one of the two strobes, or full config plus both (with the bike flasher simplified). You can try that version here: Index of /torches/pilotdog68

In full config mode, it will blink twice for each config option. Turn the light off between the two blinks to toggle that option. There are only two options though, mode group and mode memory (in that order).

I’m still merging changes into tk-otc.c and generally cleaning up, but it should get published in the trunk branch soon.

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.

I tried that, actually. I think it’s a matter of compile options, but for me it made no difference at all in the size or content of the build. But if it helps at least sometimes I don’t mind making it default. :slight_smile:

Here is what I see when building it (same with/without inline):

~/src/torches/trunk/ToyKeeper/Ferrero_Rocher/> ../../bin/build.sh Ferrero_Rocher
avr-gcc -Wall -g -Os -mmcu=attiny13 -o Ferrero_Rocher.o -c Ferrero_Rocher.c
avr-gcc -Wall -g -Os -mmcu=attiny13 -o Ferrero_Rocher.elf Ferrero_Rocher.o
avr-objcopy --set-section-flags=.eeprom=alloc,load --change-section-lma .eeprom=0 --no-change-warnings -O ihex Ferrero_Rocher.elf Ferrero_Rocher.hex
Program:     970 bytes (94.7% Full)
Data:         26 bytes (40.6% Full)

If my guess is correct, the “-Os” option will automatically un-inline everything which has been used more than once.

Weird - just tried it again, and the difference is 48 bytes saved - 984 with inline, 948 without. I'm using Atmel Studio 6.2, and the -Os option is specified.

This is what 6.2 studio invokes for compiling:

Invoking: AVR/GNU C Compiler : 4.8.1

"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. :slight_smile:

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

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.

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 :slight_smile:

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

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.

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.

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

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. :stuck_out_tongue:

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.