E-switch UI Development / FSM

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.

Oops, that was my fork with stepped ramping disabled, my bad.

Otherwise, I see the same values as you do.

I made a video about how to use and setup Andúril if it is new for someone:

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…

@Toykeeper:

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.

Simply add:
#define ATTINY 85
#define FSM_BLF_Q8_DRIVER

At the top of anduril.c (or darkhorse.c). You may have to use your driver’s name.

I didn’t think it would take 27 minutes to show all the functions, since they all fit on one page. :wink:

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:

  1. 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.
  2. 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.

Any thoughts?

So Toykeeper, next question:

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?

What’s inside is not perfectly clear as it is some Atmel Studio / Visual Studio XML crap.

And yes, it contains the compiler switches and include paths.
So if there is a change in that areas, this could lead to problems.

Maybe a guide how to get Ubuntu on a Win10 machine may be the better solution.

ToyKeeper, have you considered switching to a git-based platform like GitHub or GitLab? I personally have no idea what I’m doing with BZR, and I find the branching structure confusing.

ETA: Doing GitHub would allow for the use of an organization profile for BLF, and would allow for easier delegation of access, PRs, binaries as “releases”, automated builds, and more, which is why I also would suggest something along these lines. It would also allow for forks of the repository, so I could easily maintain a slightly different set of shortcuts to the UIs available, and just pull in changes using git merges.

Yes. I’ve brought it up at least half a dozen times over the years, and the general response has been that almost nobody on BLF has any preference.

The feature sets of Git and Bzr are almost identical, though they expose those features in different ways and they are built around different mindsets and different cultures. For example, in Git, branches all exist within a single directory and the user checks out one at a time into the working copy. Bzr can do that too, but by default it instead uses one directory per branch, and uses standard filesystem tools to compare them instead of using special built-in tools. So, use “cd” to change between branches instead of “git checkout”.

The main conceptual difference between them is that Bzr has a mainline, while Git has no such concept. This is unfortunate, since the mainline is very useful. It basically asserts a single official left-most path leading backward from any given revision to the origin. And this predictable, consistent ordering can then be used to provide extra info about each revision, like whether it’s stable or part of a development branch, and to generate meaningful human-friendly revision numbers.

The lack of a mainline has shaped Git’s culture. For example, it is the main reason why, after completing development, people are encouraged to rewrite all code submissions as a series of small standalone patches. Merging with the full development history creates problems in Git’s history model. It is also a large part of the reason why Git relies heavily on rebasing instead of merging, and why fast-forward merges are the default. Meanwhile, in Bzr land, those things are generally considered sloppy. But opinions on this vary depending on who you ask. I once published a side-by-side comparison of the two, and people in both camps viewed it as proof that their tool is better.

Anyway, about Github vs Launchpad, they are also very similar… but Launchpad has quite a few more project management features and Github has better comment formatting plus a wiki.

And perhaps most important of all is the difference in popularity between the two sets of tools. This is the sole reason I’ve brought up Git over the years. However, I’m a bit more reluctant to migrate ever since GitHub was bought by Microsoft.

Have you a link to this, please?

I can definitely see your points. We use git extensively at work using the Git Flow model of branching, along with tagging releases on the master branch. Forcing people to that model seems to work very well for organization.

Using the flow model, I’ve never rebased, cherry picked, etc. We just merge our topic branches into our feature branches and all of the history gets preserved.

As for M$ buying github, I actually see that as more of an indication of their changing culture towards oss. Although if that’s a real sticking point, GitLab is an option, and still retains the benefits (to me :wink: ) of git.

Once I can get Andruil to build, what else will I need to do go get it running properly on a TA-derived driver design (Lexel’s OSHPark variant)?

It looks like I can use one of the existing configs for 3-channel lights as a starting point.

Anything else I should know?

Just wanted to share a little story from today:

My 5-year old daughter was gifted a little halloween lantern, “powered” by a tealight. Not very kid-friendly. FIRE = BAD :smiley:

So a D4 with Andruil in candle mode, and a kinder surprise-toy-shell as a orange diffuser: success

So cheers to ToyKeeper for the awesome work. This absolutely made my daughters day :heart_eyes:

Short video of the setup: Impro Flickr light - Album on Imgur

inside a pumpkin. great idea! wasnt planning on buying a pumkin but you just gave me an excuse. thanks!

There was a comment on here (I thought) with the command/list of packages needed to install on a fresh ubuntu build, but I cant for the life of me find it anymore. can someone point me to it?

Im thinking about just making a bootable USB with storage space and booting that up when I want to flash.

Second question, RampingIOSv3. Im backtracing some of the options and default configs, and in the driver define section, it calls cfg-emisar-d4s.c, but the only file with that name is in the /ToyKeeper/spaghetti-monster/anduril directory on launchpad. In that file it explicitly stated its a config for Anduril, yet in RampingIOS there arent any config files.

The defines seem ok, but I wanted to make sure im looking at the right driver file for this os.

The setup instructions are in the README file at the base of the repository. Also in the first post of the firmware discussion thread linked in my signature.

I had the cfg-*.h files symlinked at one time, but people with Windows complained about symlinks not being supported there, so I replaced them with a script to copy the configs before each build. The build-all.sh script should pull those in. They use the same configs.