Don’t worry, i’m in no hurry. I hope ToyKeeper add this option for all firmware. Aux clicks now are very tedious if you don’t leave them on steadily. Thank you man, this community is unbelievably beautiful
1 Thank
Hey man I am speechless… 
1 Thank
Hey @Light_Veteran,
So here am I, and have tried it just to be greeted with a ton of compiler warnings (which aren’t good news, but at least wouldn’t impede code generation) and a couple of “undefined symbol” errors (which is worse as they do):
$ ../../../bin/build.sh 1634 anduril -DCFG_H=cfg-emisar-d4v2-nofet.h
[...]
In file included from ../spaghetti-monster.h:66:0,
from anduril.c:77:
../fsm-ramping.c: In function ‘set_level_1ch’:
../fsm-ramping.c:94:9: error: ‘LOW_PWM_LVL’ undeclared (first use in this function)
LOW_PWM_LVL = 0;
^
../fsm-ramping.c:94:9: note: each undeclared identifier is reported only once for each function it appears in
In file included from ../fsm-events.h:7:0,
from ../spaghetti-monster.h:22,
from anduril.c:77:
../fsm-ramping.c: In function ‘gradual_tick_1ch’:
../fsm-ramping.h:123:29: error: ‘gt’ undeclared (first use in this function)
[...]
I’m pretty sure this means this flashlight on rev 721 is effed – not only because my mods didn’t get anywhere near the lines of code the errors are pointing to, but also because my wurkkoses compiled without any issues, and specially because the same Emisar D4V2 but without the “-nofet” does also compile without any issues:
$ ../../../bin/build.sh 1634 anduril -DCFG_H=cfg-emisar-d4v2.h
avr-cpp -DCFG_H=cfg-emisar-d4v2.h -Wall -g -Os -mmcu=attiny1634 -C -std=gnu99 -fgnu89-inline -fwhole-program -DATTINY=1634 -I.. -I../.. -I../../.. -fshort-enums -B /home/normal/mnt_-_src_-_flashlight/http_-_packs.download.atmel.com/Atmel.ATtiny_DFP.2.0.368/gcc/dev/attiny1634/ -I /home/normal/mnt_-_src_-_flashlight/http_-_packs.download.atmel.com/Atmel.ATtiny_DFP.2.0.368/include/ -o foo.cpp anduril.c
avr-gcc -DCFG_H=cfg-emisar-d4v2.h -Wall -g -Os -mmcu=attiny1634 -c -std=gnu99 -fgnu89-inline -fwhole-program -DATTINY=1634 -I.. -I../.. -I../../.. -fshort-enums -B /home/normal/mnt_-_src_-_flashlight/http_-_packs.download.atmel.com/Atmel.ATtiny_DFP.2.0.368/gcc/dev/attiny1634/ -I /home/normal/mnt_-_src_-_flashlight/http_-_packs.download.atmel.com/Atmel.ATtiny_DFP.2.0.368/include/ -o anduril.o -c anduril.c
avr-gcc -Wall -g -Os -mmcu=attiny1634 -mrelax -B /home/normal/mnt_-_src_-_flashlight/http_-_packs.download.atmel.com/Atmel.ATtiny_DFP.2.0.368/gcc/dev/attiny1634/ -I /home/normal/mnt_-_src_-_flashlight/http_-_packs.download.atmel.com/Atmel.ATtiny_DFP.2.0.368/include/ -fgnu89-inline -o anduril.elf anduril.o
avr-objcopy --set-section-flags=.eeprom=alloc,load --change-section-lma .eeprom=0 --no-change-warnings -O ihex --remove-section .fuse anduril.elf anduril.hex
Program: 10482 bytes (64.0% Full)
Data: 269 bytes (26.3% Full)
$
I’m now trying to backtrack to some previuos version where the original code compiles and then try and apply/adapt my diff to it.
Please stand by, and wish me luck (this is my first time trying to do anything with Anduril not involving Wurkkoses) 
2 Thanks
If LOW_PWM_LEVELS is undefined, but is defined in the header file, it means that generally the preprocessor isn’t reaching that definition, could be due to a syntax error. See if the .cpp file is created which dumps the preprocessed code and check the syntax there, otherwise double check it on your changes; gcc can do weird things sometimes where it points at the wrong place vs where trhe actual syntax or logical error is.
1 Thank
Just did (and glad to learn the .cpp is just the preprocessor output, was thinking until now it was C++ to which I’m totally alergic 
) and everything looks good syntax-wise.
I hear you loud and clear! 
Unfortunately it seems it’s the original code that is broken (at least on rev 721), here’s the abridged output of running plain stupid ./build-all.sh in a pristine source tree just expanded from 721.tgz:
$ ./build-all.sh
[...]
===== emisar-d4v2-nofet =====
../../../bin/build.sh 1634 anduril -DCFG_H=cfg-emisar-d4v2-nofet.h
avr-cpp -DCFG_H=cfg-emisar-d4v2-nofet.h -Wall -g -Os -mmcu=attiny1634 -C -std=gnu99 -fgnu89-inline -fwhole-program -DATTINY=1634 -I.. -I../.. -I../../.. -fshort-enums -B /home/normal/mnt_-_src_-_flashlight/http_-_packs.download.atmel.com/Atmel.ATtiny_DFP.2.0.368/gcc/dev/attiny1634/ -I /home/normal/mnt_-_src_-_flashlight/http_-_packs.download.atmel.com/Atmel.ATtiny_DFP.2.0.368/include/ -o foo.cpp anduril.c
In file included from anduril.c:45:0:
cfg-emisar-d4v2-nofet.h:35:0: warning: "DEFAULT_LEVEL" redefined
#define DEFAULT_LEVEL 80
^
In file included from cfg-emisar-d4v2-nofet.h:6:0,
from anduril.c:45:
cfg-emisar-d4v2.h:23:0: note: this is the location of the previous definition
#define DEFAULT_LEVEL 50
^
In file included from anduril.c:45:0:
cfg-emisar-d4v2-nofet.h:53:0: warning: "CANDLE_AMPLITUDE" redefined
#define CANDLE_AMPLITUDE 60
^
In file included from cfg-emisar-d4v2-nofet.h:6:0,
from anduril.c:45:
cfg-emisar-d4v2.h:58:0: note: this is the location of the previous definition
#define CANDLE_AMPLITUDE 33
^
avr-gcc -DCFG_H=cfg-emisar-d4v2-nofet.h -Wall -g -Os -mmcu=attiny1634 -c -std=gnu99 -fgnu89-inline -fwhole-program -DATTINY=1634 -I.. -I../.. -I../../.. -fshort-enums -B /home/normal/mnt_-_src_-_flashlight/http_-_packs.download.atmel.com/Atmel.ATtiny_DFP.2.0.368/gcc/dev/attiny1634/ -I /home/normal/mnt_-_src_-_flashlight/http_-_packs.download.atmel.com/Atmel.ATtiny_DFP.2.0.368/include/ -o anduril.o -c anduril.c
In file included from anduril.c:45:0:
cfg-emisar-d4v2-nofet.h:35:0: warning: "DEFAULT_LEVEL" redefined
#define DEFAULT_LEVEL 80
^
In file included from cfg-emisar-d4v2-nofet.h:6:0,
from anduril.c:45:
cfg-emisar-d4v2.h:23:0: note: this is the location of the previous definition
#define DEFAULT_LEVEL 50
^
In file included from anduril.c:45:0:
cfg-emisar-d4v2-nofet.h:53:0: warning: "CANDLE_AMPLITUDE" redefined
#define CANDLE_AMPLITUDE 60
^
In file included from cfg-emisar-d4v2-nofet.h:6:0,
from anduril.c:45:
cfg-emisar-d4v2.h:58:0: note: this is the location of the previous definition
#define CANDLE_AMPLITUDE 33
^
In file included from ../spaghetti-monster.h:66:0,
from anduril.c:77:
../fsm-ramping.c: In function ‘set_level_1ch’:
../fsm-ramping.c:94:9: error: ‘LOW_PWM_LVL’ undeclared (first use in this function)
LOW_PWM_LVL = 0;
^
../fsm-ramping.c:94:9: note: each undeclared identifier is reported only once for each function it appears in
In file included from ../fsm-events.h:7:0,
from ../spaghetti-monster.h:22,
from anduril.c:77:
../fsm-ramping.c: In function ‘gradual_tick_1ch’:
../fsm-ramping.h:123:29: error: ‘gt’ undeclared (first use in this function)
target = PWM_GET(TABLE, gt); \
^
../../hwdef-emisar-d4v2.h:91:23: note: in expansion of macro ‘PWM_GET8’
#define PWM_GET PWM_GET8
^
../fsm-ramping.c:423:5: note: in expansion of macro ‘GRADUAL_ADJUST_1CH’
GRADUAL_ADJUST_1CH(low_pwm_levels, LOW_PWM_LVL);
^
In file included from ../spaghetti-monster.h:28:0,
from anduril.c:77:
../fsm-ramping.c:423:40: error: ‘LOW_PWM_LVL’ undeclared (first use in this function)
GRADUAL_ADJUST_1CH(low_pwm_levels, LOW_PWM_LVL);
^
../fsm-ramping.h:124:9: note: in definition of macro ‘GRADUAL_ADJUST_1CH’
if (PWM < target) PWM ++; \
^
In file included from ../spaghetti-monster.h:66:0,
from anduril.c:77:
../fsm-ramping.c: In function ‘set_level_1ch’:
../fsm-ramping.c:94:9: error: ‘LOW_PWM_LVL’ undeclared (first use in this function)
LOW_PWM_LVL = 0;
^
../fsm-ramping.c:94:9: note: each undeclared identifier is reported only once for each function it appears in
In file included from ../fsm-events.h:7:0,
from ../spaghetti-monster.h:22,
from anduril.c:77:
../fsm-ramping.c: In function ‘gradual_tick_1ch’:
../fsm-ramping.h:123:29: error: ‘gt’ undeclared (first use in this function)
target = PWM_GET(TABLE, gt); \
^
../../hwdef-emisar-d4v2.h:91:23: note: in expansion of macro ‘PWM_GET8’
#define PWM_GET PWM_GET8
^
../fsm-ramping.c:423:5: note: in expansion of macro ‘GRADUAL_ADJUST_1CH’
GRADUAL_ADJUST_1CH(low_pwm_levels, LOW_PWM_LVL);
^
In file included from ../spaghetti-monster.h:28:0,
from anduril.c:77:
../fsm-ramping.c:423:40: error: ‘LOW_PWM_LVL’ undeclared (first use in this function)
GRADUAL_ADJUST_1CH(low_pwm_levels, LOW_PWM_LVL);
^
../fsm-ramping.h:124:9: note: in definition of macro ‘GRADUAL_ADJUST_1CH’
if (PWM < target) PWM ++; \
^
In file included from ../spaghetti-monster.h:66:0,
from anduril.c:77:
../fsm-ramping.c:429:9: warning: implicit declaration of function ‘GRADUAL_IS_ACTUAL’ [-Wimplicit-function-declaration]
GRADUAL_IS_ACTUAL();
^
In file included from anduril.c:45:0:
../fsm-ramping.c: At top level:
cfg-emisar-d4v2-nofet.h:19:30: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types]
#define GRADUAL_TICK_MODES gradual_tick_1ch
^
../fsm-ramping.c:563:62: note: in expansion of macro ‘GRADUAL_TICK_MODES’
GradualTickFuncPtr gradual_tick_modes[NUM_CHANNEL_MODES] = { GRADUAL_TICK_MODES };
^
cfg-emisar-d4v2-nofet.h:19:30: note: (near initialization for ‘gradual_tick_modes[0]’)
#define GRADUAL_TICK_MODES gradual_tick_1ch
^
../fsm-ramping.c:563:62: note: in expansion of macro ‘GRADUAL_TICK_MODES’
GradualTickFuncPtr gradual_tick_modes[NUM_CHANNEL_MODES] = { GRADUAL_TICK_MODES };
^
ERROR: build failed
[...]
===== 17 builds succeeded, 52 failed =====
FAIL: blf-gt-mini blf-gt blf-lantern-t1616 blf-lantern blf-q8-t1616 blf-q8 emisar-d1 emisar-d18-219 emisar-d18 emisar-d1s emisar-d1v2-7135-fet emisar-d1v2-linear-fet emisar-d1v2-nofet emisar-d4-219c emisar-d4 emisar-d4s-219c emisar-d4s emisar-d4sv2-tintramp-fet emisar-d4sv2-tintramp emisar-d4v2-nofet ff-e01 ff-pl47-219 ff-pl47 ff-pl47g2 ff-rot66-219 ff-rot66 ff-rot66g2 fw3a-219 fw3a-nofet fw3a fw3x-lume1 gchart-fet1-t1616 mateminco-mf01-mini mateminco-mf01s mateminco-mt35-mini noctigon-dm11-nofet noctigon-dm11-sbt90 noctigon-dm11 noctigon-k1-12v noctigon-k1-sbt90 noctigon-k1 noctigon-k9.3-219 noctigon-k9.3-nofet noctigon-k9.3-tintramp-219 noctigon-k9.3-tintramp-fet noctigon-k9.3-tintramp-nofet noctigon-k9.3 noctigon-kr4-12v sofirn-sp10-pro sofirn-sp36-t1616 sofirn-sp36 thefreeman-lin16dac
So I’m pretty sure the issue is with rev 721 proper (which seems quite broken and not only for emisar-d4v2-nofet), and not my modification (unfortunately, as it would be much easier to fix). That’s probably why it hasn’t been merged yet
Anyway, I’m now trying to backport my diff to a previous, known good version – on rev 654 (the last one I used with my TS10 before delving into the multi-channel branch for my FC13), OFC as per Murphy’s Law patch rejects it prima facie. Will try and adapt it, but would like to ask you first: do you know what is the most modern, known-good-for-emisar-d4v2-nofet revision, so I can backport to it instead and @Light_Veteran will get maximum value?
Thanks and TIA!
Went ahead and tried with a couple of older releases in the multi-channel branch, to no avail as they seem even more broken than 721 (which OFC makes sense when one thinks about it).
I then checked the ‘traditional’ anduril2 branch and confirmed that its latest release (rev 657) does build anduril.emisar-d4v2-nofet.hex with no issues in its pristine state, and then I backported my changes to it, ran ./build-all.sh and it lo and behold, a shiny and apparently good (as in, no compiler messages) anduril.emisar-d4v2-nofet.hex came out:
$ ./build-all.sh
[...]
===== emisar-d4v2-nofet =====
../../../bin/build.sh 1634 anduril -DCONFIGFILE=cfg-emisar-d4v2-nofet.h
avr-gcc -DCONFIGFILE=cfg-emisar-d4v2-nofet.h -Wall -g -Os -mmcu=attiny1634 -c -std=gnu99 -fgnu89-inline -fwhole-program -DATTINY=1634 -I.. -I../.. -I../../.. -fshort-enums -B /home/normal/mn
t_-_src_-_flashlight/http_-_packs.download.atmel.com/Atmel.ATtiny_DFP.2.0.368/gcc/dev/attiny1634/ -I /home/normal/mnt_-_src_-_flashlight/http_-_packs.download.atmel.com/Atmel.ATtiny_DFP.2.0.
368/include/ -o anduril.o -c anduril.c
avr-gcc -Wall -g -Os -mmcu=attiny1634 -mrelax -B /home/normal/mnt_-_src_-_flashlight/http_-_packs.download.atmel.com/Atmel.ATtiny_DFP.2.0.368/gcc/dev/attiny1634/ -I /home/normal/mnt_-_src_-_
flashlight/http_-_packs.download.atmel.com/Atmel.ATtiny_DFP.2.0.368/include/ -fgnu89-inline -o anduril.elf anduril.o
avr-objcopy --set-section-flags=.eeprom=alloc,load --change-section-lma .eeprom=0 --no-change-warnings -O ihex --remove-section .fuse anduril.elf anduril.hex
Program: 8318 bytes (50.8% Full)
Data: 225 bytes (22.0% Full)
[...]
$ ls -l anduril.emisar-d4v2-nofet.hex
-rwxrwx--- 1 root vboxsf 23409 Jun 12 18:17 anduril.emisar-d4v2-nofet.hex
$
Problem is, I wasn’t able to test it with any of my Anduril-capable lights (which presently comprises exactly 2, the TS10 and FC13) as this revision doesn’t support them… 
And this leads to my question: does @Light_Veteran have the guts to flash and test totally unproven, untested code?
If he does, here’s a download link to the above-mentioned hex: https://durval.com/xfer-only/anduril.emisar-d4v2-nofet.hex.zip
Seriously @Light_Veteran, I think it should be OK, but no guarantees. If you do flash and test it, please let me know how it went.
Why? Just because I mentioned you in the diff? Seriously, it was your idea so you more than deserve the credit, I’m just the code monkey translating it to C
1 Thank
Ok i am so stupid, I forgot the TS10 so we can use this flashlight for test. Sorry man
1 Thank
Hey, no prob. But I’m not sure I follow you – you mean you also have a TS10 and can use it for the test? If so that’s great because (as I have one too) I can give you an hex for the same version I’m now using on mine which is working great, including the 8C feature you asked for, and on the latest TK revision (721) too!
Please confirm so I can build you a generic one (mine has all my preferred configurations built-in), or even better, tell me what your preferred configurations are (memory mode, thermal temperature limit, ramp mode/floor/ceiling, etc) and I can build one with your configurations built-in so it comes up configured the exact way you like it, no need for lots of clicks after flashing and also comes back exactly so after any factory resets.
yes please, forgot the D4V2 and build for TS10 so in this way we can test with the same flashlight.
And Yes, a generic one with all
Here you are: https://durval.com/xfer-only/anduril.wurkkos-ts10_rev_721-8C_turn_aux_off_low.hex.zip
Built it from the latest revision (721) with its default configuration file.
Please let me know how it goes.
1 Thank
Thank you so much!
1 Thank
Is it for TS10?
Can I download it?
Thank you.
1 Thank
Yes!
Sure!
You’re more than welcome, just be aware that it’s a test build from Toykeeper’s revision 721 source code (which is itself still in development and outside the main “anduril2” branch) with my code added to implement switching from low aux to aux off and vice-versa by pressing 8C (that’s all explained along other posts above, this is just a TL;DR to summarize things for you).
1 Thank
Ok Thanks!!!
I’m downloading it now!
No problem.
1 Thank
Great! Let me know what you think, and my offer to @Light_Veteran of burning his specific configuration right into the hex extends to you too, just tell me how you’d like it and I will prepare a specific hex for you with it.
1 Thank
Replied on IRC, but worth mentioning here for anyone following.
15:17 < SiteRelEnby> yeah, that's fair enough, I'm always cautious with that with nontrivial changes... ramp tables definitely count
15:17 < SiteRelEnby> only really do that with feature changes where either the feature change works or doesnt
15:18 < SiteRelEnby> well, you could change LOW_PWM_LEVELS to PWM1_LEVELS and use set_level_legacy() which should work for now but I'm assuming that's going away at some point
15:19 < SiteRelEnby> but by then TK would have fixed LOW_PWM
Had a bit more of a look since then, as to why some other linear-only lights do build. It looks like in hwdef-emisar-d4v2.c, set_level_main() is just copypasted from set_level_2ch_stacked() so doesn’t apply to a linear-only D4, while the noFET config sets the first set_level_mode to use the predefined set_level_1ch (in fsm-ramping.c)*, but this method doesn’t seem to be working, as LOW_PWM_LVL here is undefined, and I’m slightly lost as to where it’s meant to be defined (although it does make sense what it needs to be, the output register, since the hwdef’s version uses CH1_PWM which is defined as an output register based on the driver layout, but my guess is, since the pin for the linear is PB3, you’d want to add #define LOW_PWM_LVL OCR1A (output register for PB3) in cfg-emisar-d4v2-nofet.h (and similarly, add the appropriate OCR in other single channel lights). Alternatively, since CH1_PWM and CH2_PWM are already defined, you could just use DEFINE LOW_PWM_LVL CH1_PWM which would be effectively the same thing.
* @ToyKeeper probably a bug here - because only the first SET_LEVEL_MODES method gets redefined, aux channels won’t work on this light as is even if they’re defined in the hwdef .h and NUM_CHANNEL_MODES > 1. I’ve fixed it in my commit below just for the example build, anyway, but there might be a better way with data structures to override a single method without having to redefine the whole list?
The gradual_tick_modes part (the error for fsm-ramping.h:123:29: error: ‘gt’ undeclared ) looks to me like it’s expecting gt to be defined. Not fully sure of all the implications here since I know stepped ramp probably needs something specific here, so I’m assuming this is just unfinished, and so I’m taking the easy solution here and just removing USE_GRADUAL_TICK_1CH and instead copying the boost DM11’s gradual_tick method into hwdef-emisar-d4v2.c with a simple if to determine which to use:
#if PWM_CHANNELS == 1
bool gradual_tick_main(uint8_t gt) {
PWM_DATATYPE pwm1 = PWM_GET(pwm1_levels, gt);
GRADUAL_ADJUST_SIMPLE(pwm1, CH1_PWM);
if ( (pwm1 == CH1_PWM)
) {
return true; // done
}
return false; // not done yet
}
#elif PWM_CHANNELS == 2
bool gradual_tick_main(uint8_t gt) {
PWM_DATATYPE pwm1 = PWM_GET(pwm1_levels, gt);
PWM_DATATYPE pwm2 = PWM_GET(pwm2_levels, gt);
GRADUAL_ADJUST_STACKED(pwm1, CH1_PWM, PWM_TOP_INIT);
GRADUAL_ADJUST_SIMPLE (pwm2, CH2_PWM);
if ( (pwm1 == CH1_PWM)
&& (pwm2 == CH2_PWM)
) {
return true; // done
}
return false; // not done yet
}
#endif
Here’s the overall change on github, which compiles for all 3 D4v2 variants, but I have not yet tested it. Included the .hex in the commit just for convenience’s sake, if you wanted to test it
Probably mostly of interest to @ToyKeeper from here on:
Fixing it moving forward for more lights, perhaps it’d make the most sense to parameterise the boilerplate set_level methods like set_level_1ch() so instead of just being passed the level to set right now (e.g. set_level_1ch(69)) and assuming it’ll always be using LOW_PWM_LVL, it gets passed to the method like set_level_1ch(69,LOW_PWM_LVL) for a single channel or linear+FET where the PWM counter to use is passed to the method, that way, for a light that had multiple linear-only channels then the hwdef might look something like
#define SET_LEVEL_MODES set_level_1ch(level,CH1_PWM_LVL), \
set_level_1ch(level,CH2_PWM_LVL), \
set_level_auxred, \
<...>
set_level_auxwht
#define GRADUAL_TICK_MODES gradual_tick_1ch(CH1_PWM_LVL), \
gradual_tick_1ch(CH2_PWM_LVL), \
gradual_tick_null, \
<...>
gradual_tick_null
(Or whatever other symbol in place of CH*_PWM_LVL, and doing the same for dual channel lights with 2 args, like set_level_2ch_stacked(level,LOW_PWM_LVL,HIGH_PWM_LVL). That way, if a light has, say, a linear+FET (but firmware for FET-enabled and noFET versions) and 1+ extra linear, the same method can be reused for all of them by just giving it the appropriate PWM counter, and using 2ch_stacked instead for the FET-enabled build parameterised in the same way (e.g. set_level_2ch_stacked(level,LOW1_PWM_LVL,HIGH1_PWM_LVL)vs set_level_2ch_stacked(level,LOW2_PWM_LVL,HIGH2_PWM_LVL) ) for linear+FET while still allowing other uses of the stacked method.
Unless I’m missing something, seems to me like IMO the .c part of the hwdef doesn’t need to have a copy of the set_level methods most of the time for most lights when they’re usually going to be the same so it makes more sense to only have them there when they do contain some kind of custom logic (e.g. the LT1S Pro) or there’s something special/weird about the driver and how its channels work, then most of the time most lights can just use the above. Interested in your thoughts though.
In terms of gradual_tick, I’m going to assume that’s just unfinished due to what I saiod above and also that GRADUAL_IS_ACTUAL() is still undefined. Ping me if anything here wasn’t clear and I can hopefully point out what I mean.
1 Thank
wow, that’s a fantastically detailed analysis, more than encyclopedic! Just finished reading it for the 3rd time and still can’t relate over half of it to my knowledge of the Anduril sources – which OFC only goes to show how little I actually know 
Seriously, impressive answer, many thanks for doing it and sharing it with us!
1 Thank
I would if I could, but I have no D4V2, much less one of the -nofet persuasion… @Light_Veteran, we need a volunteer here!
Tested now TS10… make me happy because now have to do only 8 clicks to switch off the aux in whatever position I am, nice!
The next step I think is memorize the chosen level.
So if I select HI for aux when I come back from OFF I want to find HI level and not LOW. What you think?
I know, I am a pain in the ass