Sorry, don’t know what you mean. I don’t have “flashes after direct floor and before ramping”. We need more info: Which build, which target, which configuration? Looks like you have something with legacy button timing.
That one should not have any flashes when you hold the button while off. When the light is off and you hold the button, it should do nothing for about half a second, then turn on in floor and half a second later start ramping up.
Are you in smooth or stepped ramping? Have you changed the ramp settings?
As I said, that’s not recently, that’s default since 2019-06-02. For almost two years. It was changed to remove the flashes (that indicated when it is safe to release to stay at floor).
Your version seems to be 2020-09-27 (the zero is shorter than one) with model 0131 (Emisar D4S). And that build should not flash.
I had to check this and flashed the version you’ve linked above onto my D4S. Result: Exact same behavior as intended and shown in my video. Turns on after a short delay and absolutely no flashes.
What ever happened to the optic nerve programming idea on the FW3A? Last I heard of it, they deemed it unreliable to use the LED as a photo receiver but does that mean 2 pin programming is a possibility? Could we adapt it to program a attiny1634 with 2 pins?
As far as I can see you have the delay as well. The flashes you are seeing are not the “flashes” from the legacy button timing, they look different. Your driver might have issues regulating low levels, maybe one of your 7135 doesn’t like the short pulses. Or the ramping table in the flash memory got corrupted (you could try to download the hex again, but it should contain checksums and the normal programming validates the flash as well).
Maybe. Likely? As I said, wenn I stop in the middle of those flashes, the light can go below floor level. I cannot explain this with a defect 7135.
At 1, I see actually nothing, then it comes on but is unstable. At 3, the light is stable and extremly dim.
Ok, so I should flash it again :weary:
Tried all floor levels up to 18, where the ramp started to become linear with a low enough floor level. Actually looks normal now, so I’ll leave it as it is. Thanks for your help and sorry for being such a noob. Need to learn much more about these things.
I haven’t heard much about it in a long time. Another concern was speed: programming that way was time consuming, IIRC.
With the AVR 1-Series whose support recently made it into the main branch of Anduril2, you only need 3 pins: Power, Ground, and UPDI/Reset. That’s a lot closer to your “2 pin” programming.
But I was getting an error while running make due to some references to Simple UI in ramp-mode.c:
ramp-mode.c: In function ‘ramp_config_save’:
ramp-mode.c:425:26: error: ‘simple_ui_config_state’ undeclared (first use in this function)
if (current_state == simple_ui_config_state) style = 2;
^
ramp-mode.c:425:26: note: each undeclared identifier is reported only once for each function it appears in
ramp-mode.c: In function ‘nearest_level’:
ramp-mode.c:480:41: error: ‘simple_ui_active’ undeclared (first use in this function)
uint8_t num_steps = ramp_stepss[1 + simple_ui_active];
^
ramp-mode.c: In function ‘ramp_update_config’:
ramp-mode.c:508:9: error: ‘simple_ui_active’ undeclared (first use in this function)
if (simple_ui_active) { which = 2; }
];
// special case for 1-step ramp… use halfway point between floor and ceiling
if (ramp_style && (1 == num_steps)) {
uint8_t mid = (mode_max + mode_min) >> 1;
@@ -505,7 +511,9 @@
// ensure ramp globals are correct
void ramp_update_config() {
uint8_t which = ramp_style;
#ifdef USE_SIMPLE_UI
if (simple_ui_active) { which = 2; }