I was gonna say I might be closer and could send you an MCU, but then I realized your in Poland lol.
Sorry, it sucks to brick an MCU. Been there, done that, you’re not alone at least.
I was gonna say I might be closer and could send you an MCU, but then I realized your in Poland lol.
Sorry, it sucks to brick an MCU. Been there, done that, you’re not alone at least.
You live and learn. Eh…
Could you explain how to do it correctly for the future reference?
Will probably use your offer Lexel and place that long overdue order for couple drivers and get MCU straight away.
Actually how would it work with new ATTiny, do they come preprogrammed or how does one place initial firmware on it?
Excuse stupid questions but have no experience with it.
there are 2 ways of programming
pre solder with a SOIC socket adapter
or past reflow with an SOIC clip pusching on the MCU from above the PCB
indutrially with a pre reflow flashing robot that may be also able to retube/rerail the MCUs after flashing for PCBA machines feeder
Lexel, can you also slightly modify the code of Anduril/Ramping IOS V2 in such a preflashed MCU? With a appropriate remuneration of course.
In Poland it seems almost no one is capable of doing ui flashing related stuff.
I always work with NarsilM and Anduril constantly doing small easy code modification regarding replacing numbers or switching features on or off
But I can not write code itself like changing original code sections
No, not yet. I was trying to find a method which would work for FW3A, but it can’t detect the switch until quite a while after power is connected… and I haven’t added it yet for other lights where it’s easier to do.
So far I only have it on my lightsaber.
Sorry about the bricked MCU. It sucks when that happens… and there’s no easy way to fix it.
Normally, it’s best not to set fuse values at all. Just let them stay as is, and there’s virtually no risk of bricking the MCU. But if you do flash them, I recommend using the bin/flash-*.sh
scripts in the firmware repository. They have the correct fuse values; just pick a script which matches your MCU type.
It’s in a few parts of the code — anything which refers to dynamic underclocking. Since it’s a compile-time option, the exact relevant parts of the code are already marked.
Okay, may we see your lightsaber? I wonder if you lean towards the light, or a bit towards the darkness It seems the darksiders have all the cool toys
I’ve not purchased/ made one yet, but I’m waning. Strangely enough, I feel it’s impractical. Doesn’t do anything more than be a cool thing. Of course I’m also the guy with a bunch of flashlights just sitting on a shelf in my office…
You mean this one?
Here’s a closer look at two sabers I use… green for the good days, purple for the not-so-good days:
The one I’m using a custom driver in, though, is a rainbow saber. It is all colors… sometimes even at the same time.
Good answer! Those are top notch.
Funny, I don’t remember seeing the middle one in the movies though
So, quick question… In the version used on the FW3A, assume ascending ramping… the first buzz in the pattern is 1 full 7135 and the second buzz is 7 full on 7135’s?
When ramping? Are those called buzzes? I think of them as blips, and the buzzes are when the light flutters during config modes.
As for your question, that’s a config option at compile time, but I’m pretty sure the stock firmware the first blip is a helper indicator to let you know you’re at moonlight mode, so absolute bottom of the ramp, barely using 1 7135, and the second blip, which in the default ramp config is also the top of the ramp, is max 7 7135s. I think.
Could be way wrong, but that’s how I understand it
The FW3A has 8 7135s.
It does have 8. 1 in a single channel and 7 in the other channel. It is a 1+7+fet driver. If starting at 1 level moon there is a blip fairly quickly, then another and then ramp top.
It may be just a terminology difference, but here’s how I’ve been using the words:
Anduril on the FW3A does up to four blips while ramping up from the lowest to highest level. Hold from off, and these blips may happen:
However, depending on where the floor and ceiling are configured, the two middle ones may or may not actually happen. Or they may be at exactly the same level as another blip, in which case only one happens. In the default configuration, the 8x7135 to FET blip is the same level as the ceiling, so only one happens.
It also buzzes or flickers in the ramp config mode, to tell the user when they can click to enter a new value. It goes for 3 seconds, or until the user stops clicking for at least 3 seconds. Each click is confirmed by a blink.
Unrelated question: I'm trying to set double click from off to turbo instead of max ramp.
I've taken this line from the double click from on section of the code: "set_level(MAX_LEVEL);"
And I've added it to the double click from off section of the code, to change it from this:
" else if (event == EV_2clicks) { set_state(steady_state, MAX_LEVEL); return MISCHIEF_MANAGED;
To this: " else if (event == EV_2clicks) { set_state(steady_state, MAX_LEVEL); set_level(MAX_LEVEL); return MISCHIEF_MANAGED;"
This seems to work, but I don't understand why. And I couldn't find any other references to MAX_LEVEL in the main code, though now that I think of it it's probably in FSM somewhere.. hmm.
Anyway, is this the correct implementation?
Adding a set_level(MAX_LEVEL)
right after changing the state works right now, but it’s not guaranteed to work in the future. The reason why it works is due to a quirk of the execution order:
set_state()
tells FSM to replace the top of the state stack with something new.EV_enter
handler to be called.steady_state :: EV_enter
calculates the brightness to use by calling nearest_level()
. It also activates this brightness level.set_level()
and overrides what steady_state
just did.But this isn’t guaranteed, because at some point the lower-level code might be changed to defer the EV_enter event handler until after the old state returns. Events are asynchronous, so their exact timing should not be expected to happen with any particular order or timing. It behaves in a synchronous manner in this case, but it might not always be that way. FSM probably should do this instead:
So it might instead be cleaner or safer to remove or change the clause which checks the brightness while entering the steady state. Like, if the EV_enter parameter happens to equal turbo, go to that directly instead of using nearest_level() to verify the values. This would work even if I fix FSM to make it queue state changes instead of doing them immediately.
Some recent updates which are now published:
New builds are up in the usual place. I count 19 different build targets now.
If anyone has the ability to reflash easily, testing is appreciated.
Thank you!
Holy crap TK! YOU’RE AWESOME!
First off, thanks for the insight on double click turbo from off. I’ll admit this is a bit like sorcery to me, so it’s gonna take me a few re-reads to parse out and fully understand what you’re talking about.
Secondly, I finally got around to flashing my FW3A last night. I wanted fancy moon lockout mode. Before I built the hex I thought… I should probably merge the latest fsm just in case. And then when I went to enable fancy moon I seen it was already enabled by default! Took me by surprise, I had to make sure I didn’t mix up my files. I figured you had enabled it by default now, which is pretty cool.
But then this morning, I just read your change log here, and DANG! I was literally sitting on my couch with my FW3A, giggling as I tried every new feature that I didn’t even realize I flashed last night haha.
You’re the best, and your changes to the code have solved many problems. Most recently one friend had been bothered by the thermal regulation on his D4, does this solve that thermal problem as well? Or alleviate it? I suppose I’ll flash it to test it for you best I can as well.
Also another friend had been confused by the ramp in strobe modes, but now that is much more intuitive, thanks!
Of course momentary strobes seem fun, and candle and lightning mode are already awesome, but it’s nice to see them receiving tweaks.
I don’t have much use for the button mode timing options and such, I’ll just trust your opinion on the defaults, but I’m glad the option is there.
Anywho, I guess I’m one of the first to test your newest revision haha. I’ll let you know if I find any trouble!
Sorry if this is a bit too flattering, but honestly, thank you for your hard work. You rock!
Edit: ah, it seems I merged before your final revision. I don’t have the use_Manual_memory enabled apparently. Well I guess I know what’s next, I’ll be reflashing this FW3A lol