E-switch UI Development / FSM

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.

Ah gotcha, I worked through the build-all.sh -> Build-85 and think I have a relative handle on things, at least for now. The ubuntu windows 10 plugin is stupid easy and set up after an “apt-get update”
Compiling works out of the box using your scripts after downloading a copy of the branch.

I think I initially overlooked it because im not familiar with the AVR-GCC options and flags, but is it the “-DFSM_${TARGET}_DRIVER” in (…/…/…/bin/build-85.sh “$UI” “-DFSM_${TARGET}_DRIVER”) what defines it? The lack of a space after the -D threw me off.

It just defines, that for example, FSM_BLF_Q8_DRIVER is defined.

In C, you can both check if a define exists and if it exists, test for values.

In that case, it just uses the define to test with #ifdef or #if defined(...)

Flashed my D4 with Andúril. Used 2018-09-07.EMASAR_D4.Hex

I am getting step down almost instantly. Not feeling any heat unless I keep double clicking to Max. I have tried several fully charged cells. So I am looking at the thermal config.

I 3 click from off to bat check, 2 click through sunset and beacon. I think I am ending up at TempCheck I am getting a 2-1 blink. I believe it means 69 Fahrenheit.

I click 4 times and get a stutter light. I click 22 times, stop, light stutters again and goes back to 2-1 to 2-3 binks, thinking 30+22= 55 celsius for 131 Fahrenheit.

Is this correct?

Edit- I am only holding Max for about 2-3 seconds, and then it steps down, another 2-3 seconds steps down again.

Do I need to set it much higher?

Ok, watching a video, Looks like I need to click 30 times, then 22 times.

Edit, still getting almost instant step down. From fresh cell.

I’d suggest doing about 20 clicks on the first step, to calibrate the sensor to room temperature. This is, of course, after the light has had a chance to settle to room temperature. Then about 20 clicks on the second step too, to set the ceiling to 50 C.

You could also try compiling with THERM_HARD_TURBO_DROP disabled, to make it less cautious about heat. But this risks having the opposite problem, overheating.

I need to rewrite the thermal regulation algorithm entirely at some point, but I’ve been avoiding it because it’s a huge pain to actually do.

I damaged the driver removing it. the little square thing by the R5 is gone

You accidentally removed a resistor from the driver and you’re wondering why the light is behaving weirdly?

LOL, didn’t know I removed a resistor at the time.

47r is back on. Now I need to get the switch out. Lost wire off switch.

Im still working on my own personal build of RampingIOS V3 (and Anduril) and wanted to alter the voltage calibration as its reading about ~.2V high until 3.6v, then consistently .1v high until LVP on both of my D4S.

Looking at the readme\config txts for SpaghettiMonster, fsm-adc.h and RampingIOSV3 and I only see references to VOLTAGE_LOW and VOLTAGE_FUDGE_FACTOR. The Fudge factor seems more oriented towards voltage drops over protection diodes though.

I found a tk-calibration.h file in the root of the ToyKeeper folder but I couldnt find an include or a define that would pull it. Is that the correct place to be altering the readings?

Edit: tk-calibration.h is also defined by tk-voltage.h/TK_VOLTAGE_H but im not finding a reference for that either.

Change voltage drop value, it should resolve the problem.