Setting CKDIV8=1 doesn’t actually make any difference for Anduril, because it overrides this value in the firmware. It constantly adjusts clock speed based on the brightness level, to reduce power use. This is how it increases the runtime of moon mode by 3X, and how it makes moon less hardware-sensitive.
But in Narsil the CKDIV8 fuse would probably make almost everything (including PWM) run 8X slower. Button timing should still be the same, because it runs from a timer interrupt, but everything else would slow down.
Interesting to see, that the version in Atmel Studio (avr-gcc (AVR_8_bit_GNU_Toolchain_3.6.1_1750) 5.4.0) seems to produce a slightly smaller binary than the default Ubuntu install (avr-gcc (GCC) 4.9.2)
I’m not surprised. Switching from gcc 4.9.2 to 5.4.0 will probably change the binary slightly. I’ll probably switch soon, because it’s already available in Debian.
…
Trying it now, though, I get a change from 7996 to 7990 bytes… not 7984. So I think Atmel Studio may be passing in an extra compiler option somewhere. Any idea you could get the gcc command line it’s using?
It should be reasonably easy to do, but I haven’t applied the multi-target build system to DarkHorse yet. So far, it has only been built for (and tested on) the Emisar D4… and not very recently.
The GT Mini build is very similar, but it has a button LED… which isn’t really supported yet in DarkHorse. So, the D4 build should be able to run on it, I think, except for the button lighting up. It’ll definitely need some thorough testing though, since it hasn’t gotten any attention in a while.
At some point, I want to expand the build system so it’ll build all interfaces for all hardware targets, but I haven’t yet. So at this point it only does the full set of builds for Anduril.
I’m trying to build FSM (specifically Dark Horse but just trying to get ANYTHING to work right now) and am running into an exuberant amount of errors I dont know how to correct. It started out with more errors, missing defines and stuff but I worked threw those and got it down to a more manageable 15 errors, 6 warnings and 3 messages lol.
Seems to be a problem with the fsm-adc.c file so I re-downloaded that to make sure I didnt screw it up somehow, same results…
After seeing the changes for the BLF Lantern, wouldn’t it be beneficial to have a hardware or fallback state below where the light is forced off at the configured temperature if the temperature event is not handled by the current state?
For example, the strobe state could benefit from that as the tactical strobe can produce a lot of heat in small lights.
Also, how about a 2nd check with an even higher temperature limit inside the temperature ADC function where the light is forced off before the state even gets to handle then temperature event?
Did you add the defines for your driver at top of anduril.c ?
Atmel Studio needs those defines in the code as you are not building via the build_all.sh file.
I didn’t think it would take 27 minutes to show all the functions, since they all fit on one page.
Anyway, everything seemed accurate except that sunset mode goes for an hour. At some point I should probably try to refactor it to use the same timer as candle mode, but I haven’t yet and there’s not much space to work in.
I’ve also been trying to decide whether to redo how the aux LED configuration works.
Currently, the aux or button LED can be changed by doing the following:
Go to lockout mode (4 clicks).
To configure the lockout mode aux LED behavior, click 3 times. Repeat to change the value until it gets to the setting you want.
To configure “off” mode aux LED behavior, click 3 times but hold the 3rd click. Let go when it gets to the setting you want.
Optional: Exit lockout mode (4 clicks).
But I’ve been wondering if it should have each setting attached to the mode it affects:
To configure “off” mode aux LED behavior, click 7 times from off. Repeat to change the value until it gets to the setting you want.
To configure lockout mode aux LED behavior, first go to lockout mode. Then click 7 times.
The upside of this is that it’s simpler and more consistent — go to the standby mode you want to configure, then click 7 times. The downside is that 7 is a lot of clicks, and it might need to be done several times. I’d make it a smaller number, but 1 to 6 are already used for other things.
Or it could be 7 during “off” mode and keep it at 3 for lockout, but then it’s not consistent.
Every method so far is inconvenient, but how often do people want to change it? I normally set it once and then leave it, unless I’m showing someone how it works. But people might want an easier way to turn the aux LED on and off, especially if it’s on a model where that LED is relatively bright.
Atmel Studio can be set up to use the same folder structure as the linux build environment.
It just needs 3 extra files inside each project (anduril, darkhorse, …)
Is this something you want uploaded in the repository or should it stay windows-only?
If it should get uploaded, is just anduril important or should that be done for all projects in your folder?
I’ve pondered that, and I don’t have a clear answer for what would be correct behavior. It’s simple enough to add an overheat handler in the default / base state, and that’s actually how FSM worked originally * before I removed it. But simply shutting off is not necessarily the right answer. It takes more space, and some people want it to stay on even if it’s very hot.
* In very old versions, the default state checked for low voltage and overheating, and called functions it expected to exist to handle those conditions. I took out the overheating one but kept the low voltage one, which is why all empty-battery conditions are handled in one place.
I’d need to rewrite the thermal code first. At the moment it already produces extremely high temperature estimates, because it’s projecting the current trend out into the future, and sometimes it gets so high that I think it may be having an integer overflow. So it can’t reliably tell whether the light is actually very hot or if it just thinks that it might be at some point in the future.
Granted, I need to rewrite the thermal code anyway. I’ve just been reluctant to do it, because it’s a huge pain to mess with.
Here’s something I could probably do instead though… When it sends out an overheating event, it could check the return code. If an overheating event comes back as “not handled”, then it could panic. Basically, go back to the first idea where the base state simply tells it to shut off.
If those files are added, I will not be maintaining or supporting them. If they get out of sync with the code, I would never notice, so it creates an un-monitored source of potential issues. Like, if an option is different between build environments, it could create bugs which depend on which OS was used to compile the code. But if it’s something which only needs to be dropped in place once and then would “just work” forever, it could be okay.
I’m concerned that it might work in the short term and then get out of sync and guide people away from the right answers, like having old comments which describe how the code used to work instead of how it currently works.
So, what are the 3 files? What does each one do? How likely are they to go stale over time?
