Flashlight Firmware Repository

When I try and compile NarsilM I am down to a few errors related to

#if USING_3807135_BANK error if with no expression.

Edit-Fixed

I just compiled and built Anduril on Win 10 Atmel VS 7.0 - compiled fine. Again, no issues, easy, just copy the required files.

That "USING_3807135_BANK" should be commented out. You really should not be using 380 mA 7135's.

What setups file are you using?

You should have a line:

//#define USING_3807135_BANK // (default OFF) sets up ramping for 380 mA 7135's instead of a FET

Thanks I had to change the #if to #ifdef

Ohh, some difference in compilers or compiler settings then.

I guess, I tried several times. Kept getting related Errors. just did a quick search

Compilation error #if with no expression

the first thing that I looked at said change the #if to #ifdef

Loaded it onto a loose chip just fine. Now I am going to try my fet+1 setup.

Mine compiles fine with the #if in VS 7.0. This is why I always distribute the full source with the associated solution and project files so it's all set to go in VS 7.0.

I have been compiling and flashing for good part of the day. Did some minor code changes(reduce brightness on momentary) just to see if I could. Getting ready to put Anduril into a Wowtac A2. My TA driver from Lexel should be here early next week. I am really having a good time with this. I am a long way from writing my own code but this is getting me one step closer.

Thanks for every ones help today.

Hi, I am trying to flash  dth_Momentary_v1_1 (attiny13A)

I did the compiler optimizations on AVRStudio, and flashed it using AVRDude:

avrdude -p t13 -c usbasp -u -Uflash:w:dth_momentary.hex:a -Ulfuse:w:0x75:m -Uhfuse:w:0xFF:m

But I am getting an error:

avrdude: ERROR: address 0x0404 out of range at line 65 of dth_momentary.hex

I found that it means that the file is too big for that attiny, but the author of this code said that it worked on his 105C.

What am I missing here ? Any help would be much appreciated :slight_smile:

Yeah, 4 bytes over looks like. Could be optimizing, etc. I'll take a look:

Ok, I just compiled it and it fit - 1012 bytes. Here:

Build started.
Project "dth.cproj" (default targets):
Target "PreBuildEvent" skipped, due to false condition; ('$(PreBuildEvent)'!='') was evaluated as (''!='').
Target "CoreBuild" in file "C:\Program Files (x86)\Atmel\Studio\7.0\Vs\Compiler.targets" from project "C:\Tiny13aProjects\dth_momentary\dth.cproj" (target "Build" depends on it):
Using "RunCompilerTask" task from assembly "C:\Program Files (x86)\Atmel\Studio\7.0\Extensions\Application\AvrGCC.dll".
Task "RunCompilerTask"
Shell Utils Path C:\Program Files (x86)\Atmel\Studio\7.0\shellUtils
C:\Program Files (x86)\Atmel\Studio\7.0\shellUtils\make.exe all --jobs 12 --output-sync
Building file: .././dth_Momentary_v1_1.c
Invoking: AVR/GNU C Compiler : 5.4.0
"C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-gcc.exe" -x c -funsigned-char -funsigned-bitfields -I"C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATtiny_DFP\1.0.68\include" -O1 -ffunction-sections -fdata-sections -fpack-struct -fshort-enums -g2 -Wall -mmcu=attiny13a -B "C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATtiny_DFP\1.0.68\gcc\dev\attiny13a" -c -std=gnu99 -MD -MP -MF "dth_Momentary_v1_1.d" -MT"dth_Momentary_v1_1.d" -MT"dth_Momentary_v1_1.o" -o "dth_Momentary_v1_1.o" ".././dth_Momentary_v1_1.c"
Finished building: .././dth_Momentary_v1_1.c
Building target: dth.elf
Invoking: AVR/GNU Linker : 5.4.0
"C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-gcc.exe" -o dth.elf dth_Momentary_v1_1.o -Wl,-Map="dth.map" -Wl,--start-group -Wl,-lm -Wl,--end-group -Wl,--gc-sections -mmcu=attiny13a -B "C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATtiny_DFP\1.0.68\gcc\dev\attiny13a"
Finished building target: dth.elf
"C:\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 "dth.elf" "dth.hex"
"C:\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 "dth.elf" "dth.eep" || exit 0
"C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-objdump.exe" -h -S "dth.elf" > "dth.lss"
"C:\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 "dth.elf" "dth.srec"
"C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-size.exe" "dth.elf"
text data bss dec hex filename
1000 36 0 1036 40c dth.elf
Done executing task "RunCompilerTask".
Using "RunOutputFileVerifyTask" task from assembly "C:\Program Files (x86)\Atmel\Studio\7.0\Extensions\Application\AvrGCC.dll".
Task "RunOutputFileVerifyTask"
Program Memory Usage : 1012 bytes 98.8 % Full
Data Memory Usage : 12 bytes 18.8 % Full
EEPROM Memory Usage : 24 bytes 37.5 % Full
Done executing task "RunOutputFileVerifyTask".
Done building target "CoreBuild" in project "dth.cproj".
Target "PostBuildEvent" skipped, due to false condition; ('$(PostBuildEvent)' != '') was evaluated as ('' != '').
Target "Build" in file "C:\Program Files (x86)\Atmel\Studio\7.0\Vs\Avr.common.targets" from project "C:\Tiny13aProjects\dth_momentary\dth.cproj" (entry point):
Done building target "Build" in project "dth.cproj".
Done building project "dth.cproj".

Build succeeded.
========== Build: 1 succeeded or up-to-date, 0 failed, 0 skipped ==========

Thanks Tom!
I’ll try to compile it manually using your parameters.
If it won’t help, I’ll try using AVRStudio 7, right now I’m using v5.

Hi!

My first post here. First of all, I would like to say big thanks to all the people behind the BLF A6 project, especially ToyKeeper for providing the firmware source and pin diagrams.

As I was looking for a good mountain biking helmet light, most of the ones I found were either too expensive ( eg. Exposure ) or weak/large/heavy/poor quality/inpractical… you name it. I found the BLF A6 which looked perfect, although I found it a bit hard to use while riding and hated the time limit of the turbo mode, so I decided to fork, refactor and heavily modify the original firmware.

I would like to give something back to the community there, so I decided to publish this firmware and share it with you. You can find the features, source code, build & flash instructions etc. on my GitLab: Patrik Gajdoš / A6-MTB · GitLab

Cheers.

[ edit: removed an s-word ]

I imagine it should be possible to just move the candle mode EV_tick handler into the main loop somewhere and put a 16ms delay at the end to keep the timing close to the original.

It could also be interesting to try to get FSM working on clicky-switch lights, but I’m not sure how much it would really help. It’s weird having the controller suddenly reboot all the time.

Using the “bzr diff” command might show a few possible reasons. It sounds like something changed, but it’s hard to say what.

It might also be useful to increase the THERM_WARNING_SECONDS to a higher number to make it trigger overheat events less often. For a big light with a lot of thermal mass, the default of 5 seconds might be too fast.

I’ve got several patches to merge, including this one. Hopefully I’ll get to that soon.

In general, make a copy which mirrors the upstream trunk, and don’t edit that copy. Then branch that into a copy you do development in. Check in changes as you go along in the development process. Then when you want updates from upstream, go into trunk and do a “bzr pull”. And then to merge that into your dev branch, go to the dev branch and use “bzr merge …/trunk” to get it to merge the upstream changes along with your changes. Most of the time it should merge cleanly and then you should be able to commit the merge immediately.

If there are any conflicts though, things get more interesting. Gotta look for the conflict markers in any files listed as a problem, the fix the problem, and tell it “bzr resolved foo.c”. Then it should be able to be committed.

Calibration is not optional.

I tried to set the default calibration toward the safe end of the range of expected values though, so in general it should be stepping down early by default instead of late.

That’s on my list too. I should be able to test it on a FW3A driver.

The minimum number of supported modes is 2. It doesn’t even try to handle the case of only one mode. I’m not really sure what would even make sense for it to do when it only has one mode, since the floor and ceiling are generally not the same number. Maybe it could set floor and ceiling to the same value, using whatever is halfway between the two?

Fireflies worked with some BLF people to make lights. After releasing the ROT66, Fireflies contacted me to see if I could make a simplified version of NarsilM for their next light, so I told them I already did and it’s called Anduril. So they started using that.

About Mateminco, I have no idea. I think they probably just bought stock BLF-X6 drivers from Banggood. I’d like it if I can get them to comply with the license requirements, but I haven’t spent much time yet trying to get in contact about it. There are always too many license issues to chase down.

While it’s largely a matter of personal preference, I have similar complaints about GUIs. It doesn’t make sense to bother learning a completely new way of doing everything every year or two when I can learn a CLI method once and never have to care about it again. The GUI methods for things seem to change a lot for no reason, while most CLI tools pick a rational method once and then stick with it for decades.

That’s always good to hear. It’s what BLF is all about. :smiley:

Thanks! I’ll add this to my list. Also, welcome to BLF! :slight_smile:

BTW, if the forum tells you anything about having a “reported post”, it probably just means someone felt the need to report swearing. There’s a rule against that here. I think it’s a bit silly, but these things really bother some people.

1: I am not sure how to use the BRZ diff but I will try to look it up. That said I have not changed anything in the code at this point besides coping the D4S HWdef and config files and adding them to the build script as new drivers. I then copied the ramp from narsil and that is basically it at this point besides a few define changes in the config file.

Would the THERM_WARNING_SECONDS effect the step up as well? It steps down perfectly. The issue is that it will then step back up even when it is WELL over the set temp limit (such as a self reported 90-100C vs the 45c set point).

2: Great! Once they are updated I will update my code and see if it works better.

3: I was not even aware most of these options existed, I will try to look them up. An example of why a GUI can be nice, poking around menus can show you these types of options and it handles all the syntax and usage methods for you. :wink:

4: I have read that the calibration is not optional a few times? Is every D4 manually calibrated before it is shipped? I can’t figure out how calibration could be the reason that it allows the light to ramp back up even when the temperature is at a self reported 90c+? This is the root issue that I have, it steps up even when WELL above the max temp it should allow by it’s own blink out. If it would just stop ramping the power up when above say 10-20% above the set temp, then it would be fine but it just keeps ramping until the temp is over 100c.

I have calibrated my light and the results were the same BTW, just 2-3c more accurate.

I am really liking what you have done with Anduril so far, the thermal runaway is the only issue preventing me from using it at this point since that is dangerous. The other features that were mentions are just icing on the cake. :partying_face:

Umm… I have a question. If I’m trying to set the thermal limit on my Q8 with NarsilM 1.0 and it never reaches “hot” state, is there a way to exit without saving the state (at too cool a level)? Or, will I have to take it as it is, then recharge my cells, and try again, attempting to find some way to get it hotter? I am in my house, where ambient temp is 69F right now, but I want to calibrate the Q8 for a higher temp, because I might be using it in the summer, when outside ambient temps can still be around 80F or more after dark. I have the light in thermal config mode, waiting for it to get hot. I’m afraid the cells may run down too much before the light gets hot enough. According to voltage check in the Q8, it was at 3.7V before I started thermal config.

Always do thermal config at full battery.

Yeah, I didn’t think about it until I was already a few minutes in, and the head had only got to “just warm” and now I’m thinking I have to start over. :person_facepalming:

But, I have to make sure my cells are at full power, and do it when I have time to wait around for it to get hot. I didn’t know it would take so long to heat up, but I’m glad it does! Meanwhile, I don’t want to retain this “failed” setting if there’s a way out of it. :wink:

The temp started dropping, so I just shut it off. I’ll try again later. I’d still like to know the answer, if someone will tell me. Is there a way out of thermal config without saving state, if “waiting” needs to be cut short for any reason?

What you just discovered is the reason I like anduril… Just set the thermal limit, at an exact temp, with a series of clicks.

Yeah, I saw discussion about that. It would be nice, but it’s not the way Narsil works, and I don’t have the ability to re-flash the driver. :weary: