Flashlight Firmware Repository

Cool. BTW, what size was the output? Does it let you see the actual gcc command line? I get 1002 bytes:

[-(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)

Here's the entire output stream;

---------------

"D:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-gcc.exe" -o GccApplication2.elf main.o -Wl,-Map="GccApplication2.map" -Wl,--start-group -Wl,-lm -Wl,--end-group -Wl,--gc-sections -mmcu=attiny13a -B "D:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATtiny_DFP\1.0.68\gcc\dev\attiny13a"
Finished building target: GccApplication2.elf
"D:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-objcopy.exe" -O ihex -R .eeprom -R .fuse -R .lock -R .signature -R .user_signatures "GccApplication2.elf" "GccApplication2.hex"
"D:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-objcopy.exe" -j .eeprom --set-section-flags=.eeprom=alloc,load --change-section-lma .eeprom=0 --no-change-warnings -O ihex "GccApplication2.elf" "GccApplication2.eep" || exit 0
"D:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-objdump.exe" -h -S "GccApplication2.elf" > "GccApplication2.lss"
"D:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-objcopy.exe" -O srec -R .eeprom -R .fuse -R .lock -R .signature -R .user_signatures "GccApplication2.elf" "GccApplication2.srec"
"D:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-size.exe" "GccApplication2.elf"
text data bss dec hex filename
996 0 13 1009 3f1 GccApplication2.elf
Done executing task "RunCompilerTask".
Using "RunOutputFileVerifyTask" task from assembly "D:\Program Files (x86)\Atmel\Studio\7.0\Extensions\Application\AvrGCC.dll".
Task "RunOutputFileVerifyTask"
Program Memory Usage : 996 bytes 97.3 % Full
Data Memory Usage : 13 bytes 20.3 % Full
Done executing task "RunOutputFileVerifyTask".
Done building target "CoreBuild" in project "GccApplication2.cproj".
Target "PostBuildEvent" skipped, due to false condition; ('$(PostBuildEvent)' != '') was evaluated as ('' != '').
Target "Build" in file "D:\Program Files (x86)\Atmel\Studio\7.0\Vs\Avr.common.targets" from project "C:\Users\FmC\Documents\Atmel Studio\7.0\GccApplication2\GccApplication2\GccApplication2.cproj" (entry point):
Done building target "Build" in project "GccApplication2.cproj".
Done building project "GccApplication2.cproj".

---------------

Hi,

Does anyone know if there is firmware that works similar to the FT NANJGs, i.e., where you can switch between one of 2 mode groups via clicking in low mode and which would work with a single FET driver with PWM on pin 6 on an ATTINY13A:

Group 1: Low - Medium - High
Group 2: Low - Medium - High - Strobe - SOS

Also, where it’d be fairly easy to modify the modes in the mode groups in the source.

Basically, I want to have a UI in a ATTINY13A-based FET driver that mimics the FT NANJGs, but where I’d probably add a moonlight to both mode groups.

Thanks,
Jim

Using JohnyCs star off time how would I get a tubo timer that is like 6 min?
http://bazaar.launchpad.net/~toykeeper/flashlight-firmware/trunk/view/head:/JonnyC/STAR/STAR_off_time/STAR_off_time.c

I see that I need either more possible ticks than 255 or longer than 500ms, but I am not certain what to change.

Oops, I just realized this thread wasn’t sticky. It is now.

Thanks! Good idea :)!

D’oh. It looks like that includes everything except the first step, the one where it converts a .c file into a .o file. And that’s the one I’m most hoping to see. :slight_smile:

In any case, it appears that the new version saves about 6 bytes. I’d like to know what build options it uses to make the result smaller. Maybe it’s just a newer version of gcc, but maybe not.

The main options right now are STAR or NLITE, and neither is quite what you described. I don’t think anyone has done the mode group switch via blink-on-low, because very few people seem to like that. Neither one has blinky modes, either. STAR’s code is open though, if you’d like to use it as a starting point.

Change the ‘ticks’ variable to a uint16_t and set its limit to 65535, and then you can have a turbo timeout up to about 9 hours.

This may be what you are interested in?;

Invoking: AVR/GNU C Compiler : 4.9.2
"D:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-gcc.exe" -x c -funsigned-char -funsigned-bitfields -DDEBUG -I"D:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATtiny_DFP\1.0.68\include" -Os -ffunction-sections -fdata-sections -fpack-struct -fshort-enums -g2 -Wall -mmcu=attiny13a -B "D:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATtiny_DFP\1.0.68\gcc\dev\attiny13a" -c -std=gnu99 -MD -MP -MF "main.d" -MT"main.d" -MT"main.o" -o "main.o" ".././main.c"
Finished building: .././main.c

Maybe I missed it this morning, as I was running late for work when I posted.



Thanks TK.

I clipped this beginning at line 272.

ISR(WDT_vect) {
    static uint8_t ticks = 0;
    if (ticks < 255) ticks++;
    // If you want more than 255 for longer turbo timeouts
    //static uint16_t ticks = 0;
    //if (ticks < 60000) ticks++;

Is this the correct place to change it from?

So it will look like this?

ISR(WDT_vect) {
static uint16_t ticks = 0;
if (ticks < 65535) ticks++;
// If you want more than 255 for longer turbo timeouts
//static uint16_t ticks = 0;
//if (ticks < 60000) ticks++;

Think it should be:

ISR(WDT_vect) {
//static uint8_t ticks = 0;
//if (ticks < 255) ticks++;
// If you want more than 255 for longer turbo timeouts
static uint16_t ticks = 0;
if (ticks < 65535) ticks++;

Oh duh, your probly right. I did not even notice that bit at the bottom where it already had the static uint16_t ticks = 0; bit.

I had tried before asking in the thread by just enabling the 6000 ticks part and commenting out the unit_8 bit.

I will try that and report back.

Thanks! That had all the info I was looking for.

It looks like the options make no difference in size, but the version of the compiler does. I’ve currently got 4.7.2 on one box and 4.8.1 on another; it seems debian doesn’t have 4.9.2 yet. :slight_smile:

Fortunately, the difference is small… 1002 bytes, 1000 bytes, or 996 bytes (for 4.7.2, 4.8.1, and 4.9.2).



Ok that did do the trick. T timer is good now.

One more question. Does anyone happen to know what causes that whining noise on MED mode. What I mean is with some setups I get it and some I dont. I use the same FET drivers for almost all my lights, just different firmware and emitters, hosts etc.

Right now I have this driver setup with 2 26650s and an XHP70. On low (2) I get no PWM whine, on med (39) I get a bad one. and of course none on high.

Is there a fix for this?

I surrounded my one driver that was doing this (Edit: JUST the FET, left room to attach the SOIC clip) with some RTV, seemed to help. I guess duct seal would work as well (search for POTTING here on BLF) and be more temporary if you wanted to remove it later…

I think the driver whining is still an unresolved question.

Has any tried potting a whining driver? Preferably with something removable like fujik heatsink compound, neutral cure silicone, or one of those removable potting mixes that people have posted.

30 sec too slow. :smiley:

You only potted the fet, not the caps and resistors, correct? Did the driver have a spring? Consider trying those small brass pillars that they sell?

Yes, just the FET, as far under it as I could. A big dab on top as well. It wasn’t that loud of a whine originally, but I couldn’t hear it afterwards… I would bet that changing something acoustically would cancel your whine, as it is a sympathetic vibration, not a direct tone being generated. Changing the airspace with a chunk of old pencil eraser or a packing peanut may even help…

Yes, I have potted drivers many times to resolve this. Using various items ranging from the silicone heat sink material that comes with some Chinese drivers all the way up to full encasement in JB weld.

EDIT: One other thing I have noticed that helps is not using a spring on the bottom of the driver. Especially one like the spring that comes out of the switch post of a maglte. These act like small record needles or amplifiers.

I was just hoping there was a fix that could be done by editing the firmware. For example tweaking the PWM level of medium mode a few percent or something.