Flashlight Firmware Repository

2052 posts / 0 new
Last post
zeroflow
Offline
Last seen: 2 months 2 weeks ago
Joined: 05/23/2017 - 02:15
Posts: 189
Location: Austria
Texas_Ace wrote:
zeroflow wrote:
Yeah, I feel pretty bad about using that non-free spying bullshit. But gaming keeps me from switching to a free OS based on GNU/Linux.

Exactly the same reason that I can’t switch, that and Adobe.

Not to mention the insistence on using the terminal for even basic tasks in Linux. Once they have reached windows levels of GUI integration it will be a lot more practical to switch. I just don’t have time to memorize all the terminal commands.

Interesting. Because I think that terminal tools are a big plus for GNU/Linux. As you can easily automate things.

Texas_Ace
Texas_Ace's picture
Offline
Last seen: 4 hours 7 min ago
Joined: 03/24/2016 - 07:44
Posts: 8374
Location: Everything is brighter in Texas
zeroflow wrote:
Texas_Ace wrote:
zeroflow wrote:
Yeah, I feel pretty bad about using that non-free spying bullshit. But gaming keeps me from switching to a free OS based on GNU/Linux.

Exactly the same reason that I can’t switch, that and Adobe.

Not to mention the insistence on using the terminal for even basic tasks in Linux. Once they have reached windows levels of GUI integration it will be a lot more practical to switch. I just don’t have time to memorize all the terminal commands.

Interesting. Because I think that terminal tools are a big plus for GNU/Linux. As you can easily automate things.

Oh, I love having the Terminal in linux, just like the command prompt in windows.

What I hate is the requirement to use the terminal for even basic things in linux. It is 2018, it should be like windows where you can do basically everything with the GUI but have the option of using the terminal if you want.

For example I have quite a few batch files and scripts for tasks that I do a lot along with commands memorized for those tasks. But for anything I only do every now and then, I just use the GUI, it is easier then trying to memorize the commands.

For the record, I started out using DOS on an 8088, I know the power of a terminal interface but I also know the memorization and time it requires to be used fluidly. GUI is simply quicker and simpler for 98% of users and even advanced uses it doesn’t make sense to memorize commands that you might use once a year. Better to just use the GUI.

All this is off topic though lol.

chadvone
chadvone's picture
Offline
Last seen: 1 month 1 day ago
Joined: 08/28/2015 - 23:48
Posts: 1829
Location: Iowa

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

Tom E
Tom E's picture
Offline
Last seen: 1 week 3 days ago
Joined: 08/19/2012 - 08:23
Posts: 12183
Location: LI NY

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
 

 

 

chadvone
chadvone's picture
Offline
Last seen: 1 month 1 day ago
Joined: 08/28/2015 - 23:48
Posts: 1829
Location: Iowa
Tom E wrote:

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?


 

Thanks I had to change the #if to #ifdef

Tom E
Tom E's picture
Offline
Last seen: 1 week 3 days ago
Joined: 08/19/2012 - 08:23
Posts: 12183
Location: LI NY

Ohh, some difference in compilers or compiler settings then.

chadvone
chadvone's picture
Offline
Last seen: 1 month 1 day ago
Joined: 08/28/2015 - 23:48
Posts: 1829
Location: Iowa
Tom E wrote:

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.

Tom E
Tom E's picture
Offline
Last seen: 1 week 3 days ago
Joined: 08/19/2012 - 08:23
Posts: 12183
Location: LI NY

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.

chadvone
chadvone's picture
Offline
Last seen: 1 month 1 day ago
Joined: 08/28/2015 - 23:48
Posts: 1829
Location: Iowa

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.

HiTiT
Offline
Last seen: 6 months 18 hours ago
Joined: 06/30/2012 - 18:12
Posts: 98
Location: Israel

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.

Quote:
* Created: 1/11/2015 7:15:48 PM * Author: Dzung Hoang * * Firmware for NANJG 105C-based LED drivers using ATTINY13A MCU * using momentary switch for mode change.

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

Tom E
Tom E's picture
Offline
Last seen: 1 week 3 days ago
Joined: 08/19/2012 - 08:23
Posts: 12183
Location: LI NY

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 ==========

HiTiT
Offline
Last seen: 6 months 18 hours ago
Joined: 06/30/2012 - 18:12
Posts: 98
Location: Israel

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.

IDVert3X
Offline
Last seen: 5 months 1 day ago
Joined: 10/11/2017 - 18:07
Posts: 1

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: https://gitlab.com/IDVert3X/a6-mtb

Cheers.

[ edit: removed an s-word ]

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 1 hour 28 min ago
Joined: 01/12/2013 - 14:40
Posts: 9609
Location: (469219) 2016 HO3
nick779 wrote:
im going to aim for crescendo with an added candle mode, thats going to be one heck of a challenge.

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.

Texas_Ace wrote:
Any ideas why this would happen?

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.

zeroflow wrote:
Texas_Ace wrote:
I personally prefer the light turning off for a moment before going to turbo if you do double click.

If you have a bit of patience, I think I can do that.

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

Texas_Ace wrote:
I am sure this is a silly question but is there a simpler way to update the code for anduril besides making a whole new copy of the repository and then manually copying the driver config files over and making all the edits to the main files again (such as adding the new driver hwdef / cfg files)?

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.

Texas_Ace wrote:
zeroflow wrote:
A much simpler question: did you calibrate the temperature sensor for your particular light? You have to do that after each flashing procedure.

No, as this is not possible for a production light.

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.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 1 hour 28 min ago
Joined: 01/12/2013 - 14:40
Posts: 9609
Location: (469219) 2016 HO3
zeroflow wrote:
Did you also fix the wrong PWM frequency? If not, take a look at this branch: https://code.launchpad.net/~arthofer-thomas/flashlight-firmware/HW-HAL-bugfixes

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

Cereal_killer wrote:
Hi TK, are there any known bugs with anduril when it comes to the modes group and you try to set number of modes to 1?

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?

vestureofblood wrote:
Also are these two companies just ones that picked up on the idea of using the trunk code in their products or do they have a deeper connection here at BLF? For example were any of the light designed with other help from members as a group project etc?

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.

Texas_Ace wrote:
it doesn’t make sense to memorize commands that you might use once a year. Better to just use the GUI.

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.

chadvone wrote:
I am really having a good time with this.

That’s always good to hear. It’s what BLF is all about. Big Smile

IDVert3X wrote:
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: https://gitlab.com/IDVert3X/a6-mtb

Thanks! I’ll add this to my list. Also, welcome to BLF! 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.

Texas_Ace
Texas_Ace's picture
Offline
Last seen: 4 hours 7 min ago
Joined: 03/24/2016 - 07:44
Posts: 8374
Location: Everything is brighter in Texas
ToyKeeper wrote:
Texas_Ace wrote:
Any ideas why this would happen?

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.

zeroflow wrote:
Texas_Ace wrote:
I personally prefer the light turning off for a moment before going to turbo if you do double click.

If you have a bit of patience, I think I can do that.

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

Texas_Ace wrote:
I am sure this is a silly question but is there a simpler way to update the code for anduril besides making a whole new copy of the repository and then manually copying the driver config files over and making all the edits to the main files again (such as adding the new driver hwdef / cfg files)?

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.

Texas_Ace wrote:
zeroflow wrote:
A much simpler question: did you calibrate the temperature sensor for your particular light? You have to do that after each flashing procedure.

No, as this is not possible for a production light.

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.

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. Party

DavidEF
DavidEF's picture
Offline
Last seen: 1 hour 33 min ago
Joined: 06/05/2014 - 06:00
Posts: 7195
Location: Salisbury, North Carolina, USA

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.

The Cycle of Goodness: “No one prospers without rendering benefit to others”
- The YKK Philosophy

ZozzV6
ZozzV6's picture
Offline
Last seen: 4 hours 2 min ago
Joined: 03/24/2016 - 12:19
Posts: 2241
Location: Near to my soldering iron.

Always do thermal config at full battery.

DavidEF
DavidEF's picture
Offline
Last seen: 1 hour 33 min ago
Joined: 06/05/2014 - 06:00
Posts: 7195
Location: Salisbury, North Carolina, USA

ZozzV6 wrote:
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. Facepalm

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 Cycle of Goodness: “No one prospers without rendering benefit to others”
- The YKK Philosophy

DavidEF
DavidEF's picture
Offline
Last seen: 1 hour 33 min ago
Joined: 06/05/2014 - 06:00
Posts: 7195
Location: Salisbury, North Carolina, USA

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?

The Cycle of Goodness: “No one prospers without rendering benefit to others”
- The YKK Philosophy

Cereal_killer
Cereal_killer's picture
Offline
Last seen: 2 months 1 week ago
Joined: 07/22/2013 - 13:10
Posts: 3719
Location: Ohio

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

 RIP  SPC Joey Riley, KIA 11/24/14. Now I am become death, the destroyer of worlds.

DavidEF
DavidEF's picture
Offline
Last seen: 1 hour 33 min ago
Joined: 06/05/2014 - 06:00
Posts: 7195
Location: Salisbury, North Carolina, USA

Cereal_killer wrote:
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. Tired

The Cycle of Goodness: “No one prospers without rendering benefit to others”
- The YKK Philosophy

HiTiT
Offline
Last seen: 6 months 18 hours ago
Joined: 06/30/2012 - 18:12
Posts: 98
Location: Israel

I have a general question about the modes in the firmwares.

I’ve read the code of several firmwares in the repository to understand how “multiple-clicks” function works for e-switches.

All of them had the same technique of counting clicks each time the button is not pressed and press-duration > 0.
So for the simplest UI of: 1 click = ON/OFF and 2-fast-clicks = TURBO :
When you double click (and the light is initially ON), first of all – the light turns OFF and then moves into TURBO mode.
Am I right or missing something?

What I don’t get is how do you distinguish a single click from multiple clicks? Because from what I can see, the firmwares in the repo, always run the code for 1-click, and when multiple-clicks detected, it’s code will run in addition to the 1-click code.

Thanks Smile

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 1 hour 28 min ago
Joined: 01/12/2013 - 14:40
Posts: 9609
Location: (469219) 2016 HO3
HiTiT wrote:
What I don’t get is how do you distinguish a single click from multiple clicks? Because from what I can see, the firmwares in the repo, always run the code for 1-click, and when multiple-clicks detected, it’s code will run in addition to the 1-click code.

FSM solves that issue. Using this UI toolkit, it does not do the 1-click code before the 2-click code or the 3-click code… unless you specifically tell it to.

On some FSM-based interfaces, it intentionally goes to the 1-click level before going to the 2-click level, but it’s not a side effect. It only does that if it’s instructed to do so on purpose. Otherwise it’ll wait until the user is done clicking before it responds. For example, the Baton clone UI demonstrates both methods.

HiTiT
Offline
Last seen: 6 months 18 hours ago
Joined: 06/30/2012 - 18:12
Posts: 98
Location: Israel

Thanks for the reference Smile
It’s an interesting implementation, ill test on my diving light soon

Chatika vas Paus
Offline
Last seen: 4 hours 52 min ago
Joined: 09/03/2017 - 13:46
Posts: 417

TK
I wanted to flash Anduril in my D4 with xpl-hi. But what does the lower muggle ceiling mean? I found it here

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 1 hour 28 min ago
Joined: 01/12/2013 - 14:40
Posts: 9609
Location: (469219) 2016 HO3
Chatika vas Paus wrote:
TK I wanted to flash Anduril in my D4 with xpl-hi. But what does the lower muggle ceiling mean? I found it here

That was a one-off special build because someone requested a version with muggle mode limited to ~150 lm.

contactcr
Offline
Last seen: 19 min 54 sec ago
Joined: 05/19/2017 - 18:52
Posts: 2054
Location: US
zeroflow wrote:

I’m currently not at a PC with Atmel Studio installed, but check your settings for the project.


One big one is the -Os setting.


Otherwise, take a look at the command line flags reported in AVR/GNU C Compiler and compare that with the flags used in build_25.sh: https://bazaar.launchpad.net/~toykeeper/flashlight-firmware/fsm/view/head:/bin/build-25.sh


If there are some missing, I think you can add them under “Other optimization flags”


 


But from what I see, the most critical thing is Optimization level. You want -Os


Thanks for this. This is exactly what I needed after I enabled some additional code in Anduril for dual switch support. I ran out of space and couldn’t make sense of the compile options I was missing in Atmel Studio. Now it compiles without issue!

beastlykings
beastlykings's picture
Offline
Last seen: 14 hours 12 min ago
Joined: 12/29/2017 - 17:06
Posts: 181
Location: Michigan, USA

Texas_Ace, were you ever able to suss out those problems with the GT70 style driver and Anduril? I’ve been researching a lot, and trying to find a way to get Anduril onto my GT70, but am not coming up with much information unfortunately.

Chatika vas Paus
Offline
Last seen: 4 hours 52 min ago
Joined: 09/03/2017 - 13:46
Posts: 417

Are Anduril inputs and outputs assigned to the same ports as Narsil and bistroHD?
Narsil:

bistroHD:

And Anduril?

Pages