E-switch UI Development / FSM

Thanks, those look useful.

  • 451: Looks like I never tried building with sunset mode but no beacon. Oops. :slight_smile:
  • 452: Allowing the user to disable momentary mode at compile time is a good idea. I think it just hadn’t come up before.
  • 455: This is very interesting. Adding a -fwhole-program flag changes how the linker works, and appears to save a significant amount of space without changing any functionality. I’ll definitely be adding this, since it provides space to do other things people have been asking for. :slight_smile:

I suppose it depends on what exactly you want to change.

I’ve been meaning to go through and make sure each of the USE_ flags can be set or unset in the config files. This would mean that, for example, people could copy cfg-emisar-d4sv2.h to cfg-my-emisar-d4sv2.h (or just #include the upstream one in the personal one) and then change whatever they want, producing a custom version without needing to make changes which could get overwritten by later upstream revisions.

For example, it might work to have a cfg-my-emisar-d4sv2.h which looks like this…

#include "cfg-emisar-d4sv2.h"
#undef USE_BIKE_FLASHER_MODE
#undef USE_PARTY_STROBE_MODE
#undef USE_TACTICAL_STROBE_MODE
#undef USE_LIGHTNING_MODE
#undef USE_BEACON_MODE
#undef USE_MOMENTARY_MODE
#undef DEFAULT_LEVEL
#define DEFAULT_LEVEL MAX_1x7135
#define USE_DEFAULT_AFTER_LOCKOUT

Or something like that.

If the UI options are desired on a bunch of different lights, those parts could go in a “my-cfg.h” and then include that in each custom build target, to avoid duplicating the same code a bunch of times.

When I said config I meant “whatever is in eeprom”. It gets reset upon every flash - and to values that don’t work for me.
Though that custom cfg file is a good idea, more maintainable than what I’ve so far. :slight_smile:

You can set the EESAVE fuse so that the EEPROM is not erased during flashing. But then you have to make sure that the addresses of the variables stay the same.

Thanks. Manual configuration every time I change EEPROM format is way better than every time. Though if there was an easy way to change the defaults - that would be great. :slight_smile:

Ah. If you just want to change the default runtime configuration, like the stuff a user can modify by pressing the button, that can be done in the cfg-*.h file.

#define RGB_LED_OFF_DEFAULT 0x18  // low, voltage
#define RGB_LED_LOCKOUT_DEFAULT 0x37  // blinking, rainbow

That’s it, thanks you :slight_smile:

Anyone know how to disable thermal control with anduril?

I can’t seem to change it even after following the manuals I have found.

I click 3x, then 2x, 2x, 2x, then 4x to get to thermal config according to this diagram: Updated Anduril UI instructions for Aux LEDs - Imgur

It gives me 2 menu option, then first I have tried everything from 1 click to 30 clicks. Then I just click the 2nd option 50-100 times to try to set the temp high enough it will never kick in. Yet it still kicks in almost instantly when the light is still cool to the touch.

To completely disable it, compile with something like this in the config file:

#undef USE_THERMAL_REGULATION

Thanks, I might have to do that, was just hoping for a quick fix without having to take it apart.

Otherwise, get it hot, calibrate the sensor to tell it it’s only 1 degree, and set the ceiling as high as it can go… 70 C or 40 clicks. That should give it a lot of headroom.

Not guaranteed to completely disable regulation, but it should at least reduce the chance of ever stepping down.

Yeah, not worried about it never stepping down, it just steps down way too much right now.

I have now tried to get a new version of Anduril built

Problem No. 1 is that all the code is totally exploded with Java

Its so bad even Atmel Studio crashes, not even to think to get that anyhow converted to be compatible

Looks like Atmel Studio bug.

Using your Atmel project, with last Anduril.c. All works. Must be your soft go mad

seems save file as in the firmware trunk with right click does add HTML Java code
id the download button pressed only the Atmel code downloaded

Lexel, I don’t see any Java in your screenshot. Just HTML because you’ve saved the page instead of the file. Also please note that Anduril is not a single source file. It consists of multiple files in several directories. Use bazaar to clone the code and you won’t have such issues.

Now the firmware seems to blink out 28.9°C as 2 8 9 I don’t like, the MCU is very imprecise even when the room temp is set
it’s a wast of time to try to blink out another digit

It looks like you saved a web page as a .c file and then tried to compile it. Please use bzr instead, if at all possible. You’ve had quite a few issues due to downloading source files individually instead of using the revision control tools it’s meant to be used with, and using the right tools would avoid a lot of headaches.

It doesn’t try to track or display fractional temperatures. The function which blinks out numbers has an 8-bit unsigned integer for its parameter, so the highest value it can display is 255. If you saw 289 I suspect the problem is user error of some sort.

[quote=ToyKeeper]

Its blinking out 3 numbers now instead of 2 with latest build I downloaded
I have even seen at first numbers of >400

Temp blinks 23.8 and 24°C of Anduril the latest build

Again, it’s not doing a decimal point. It’s an 8-bit unsigned integer. The values go from 0 to 255.

The temperature itself is a 16-bit signed integer, which can go from –32768 to +32767, but the display function can only do 0 to 255. That means only the lowest 8 bits are displayed. If it says 238, either it thinks it is running at 238 C, or more likely, –18 C. Or some other number between –32768 and +32767 which happens to have the same bottom 8 bits.

Or it could be a mismatched version of the code again, including some of the recent changes but not others, which could easily lead to all sorts of strange behavior.