I think, to start with, I’ll probably refactor the interrupt handlers. It currently handles the logic of those inside the interrupt itself, which is a bit sloppy. If I reduce the interrupts to just setting a “something happened” flag, I can move the logic elsewhere and handle it at a more convenient time. This, in turn, might make it feasible to have the DSM interrupt running all the time without nearly as much timing jitter.
Basically, the DSM interrupt needs to happen every 256 clock cycles, out of the 8 million which happen each second. Or maybe every 137 cycles, or perhaps every 512 or 274. I can work out the exact details later. It’s roughly 30,000 to 60,000 times per second. In any case, this means the MCU must never get stuck in an uninterruptible state for more than ~100 clock cycles, because it would break the DSM timing. So I need to go through and reduce all uninterruptible states to be extremely short, and if necessary, move the longer portions of that code to a less critical place.
It’d also probably improve things in general, and as a side effect would make the sleep code able to react better by knowing what woke it up. This should, for example, eliminate the occasional short blinks in the aux LED blinking mode.
So… that’s step 1.
Then I should be able to at least test the DSM idea to see if it’ll work in C. If so, I can work on all the other steps… and if not, at least I improved something along the way.
Anyone know how to keep the switch / indicator LEDs the same brightness regardless of main LEDs? Specifically on a SP36. Currently the switch LEDs have low brightness while the main LEDs are in regulation and high when the FET is engaged.
Apologies if asked before, I searched and couldn’t find the answer. Also looked in the code and couldn’t find anything.
I want to highlight this comment. I agree that switching from smooth to stepped in Anduril is a bit too easy, and a 3H might help with that, and really like the idea of 3C as a shortcut to moon. That’s the shortcut to moon on an HDS, so it’s natural for me. I don’t know if there’s a feature vote option, but I think this idea deserves some thought.
I tried to implement it yesterday, turned out pretty easy, although I don’t know if it’s such a useful feature for me… will test for some time. Anybody wants to test it with me - save this diff to anduril.patch file next to anduril.c file and run
I finally think I have Studio 7 ready to go, did a test complile on the latest Anduril with the config target being the D4V2. I finally managed to get the full repo on my windows 10 machine. But, at build it is complaining about a missing version.h file and a error in the make file.
The logged errors are:
recipe for target ‘main.o’ failed
version.h: No such file or directory
Indeed, I do not have a version.h file and I cannot find it on the repo.
When I click the main.o error, it loads the makefile and highlights this line… @echo Building file: $<
Can someone point out what I am doing wrong?
UPDATE:
I did get it to build by commenting out this line: #define USE_VERSION_CHECK
That’s in fsm-ramping.c in the USE_INDICATOR_LED_WHILE_RAMPING sections. It’s kind of a mess, honestly. I need to refactor that part of the code to make it cleaner in light of some recent additions.
So in order to keep the switch led on low, am I correct in saying that I can’t just un-define USE_INDICATOR_LED_WHILE_RAMPING but would need to set indicator_led(0)?
I think you could probably just replace indicator_led((level > 0) + (level > MAX_1x7135)); with indicator_led(level > 0); . That should keep it on low whenever the main LEDs are on.
Is this the perfect location for speaking in general about the UI?
What I like or what I don’t like…
If not, please suggest me the right thread
Thank you
TK, I have my own branch with a number of commits. I’m new to bzr and it causes me a lot of troubles…
I’d like to upstream 3 minor tweaks. How do I organize the repo to do this well? Should I have a feature branch for each of them (note that the 2 smaller paches total 3 lines and the third is larger but nevertheless very minor)?
There are lots of ways it can be done. The easiest is probably to just commit the changes, if you haven’t already. Then push the branch up to Launchpad. Or if you don’t have an account and don’t want one, you could send me a diff (or three diffs) or a copy of the branch.
If you have an account, it’d be something like this:
bzr commit
bzr push lp:~myuser/flashlight-firmware/mybranch
Then make a merge proposal on Launchpad, or otherwise let me know there’s a thing waiting for review.
If you don’t have an account but are okay with making one, it involves creating an account with a web browser, creating a ssh key, uploading the ssh key, then telling bzr to log in. The last two are done something like this:
ssh-keygen
(paste ~/.ssh/id_rsa.pub into Launchpad’s ssh key editor)
bzr launchpad-login myuser
I really should move things to github though, since it’s so much more popular and more actively maintained.
On a different note, I made a bunch of kernel-level changes recently, and published the code and .hex files today. It still needs more testing before it can be considered stable, so any help with that would be … helpful.
So far, everything seems good except that thermal regulation might behave a little differently. It shouldn’t be any different, but each test run produces slightly different results… so it can be a little hard to distinguish between an actual change and a random expected variation in behavior.
The changes include a complete rewrite of how interrupts work, plus a bunch of other changes to the plumbing for how FSM works. This makes it a high-risk change since it affects so many things. However, there shouldn’t be any visible differences in the user interface. If anything, the only visible difference should be a general lack of glitchy behavior. I fixed most of the race conditions and other inconsistencies which could occasionally happen.
I did a bunch of changes to tweak the UI more to my liking.
I have one problem with it though - some configuration defaults don’t suit me (particularly aux LED config) and I don’t see a way to change it. Is there a good way to change the default config?
451: Looks like I never tried building with sunset mode but no beacon. Oops.
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.
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…
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.
