I’ve done C on embedded systems a couple times. It’s definitely possible. I don’t think it would help anything in this case though. Ramp creation and per-hardware code selection haven’t really been issues. Switching has costs though, at least in terms of time but also potentially in terms of code size. Some build targets are already at 99.8% full, and a change of language could easily push them over the limit.
There’s certainly an argument to be made for moving the ramp shape calculations from a table to an onboard formula, since working in units of linear power instead of perceptual brightness would probably make the thermal code a lot more reliable. But that’s unrelated to the language the code is written in.
I think treellama meant that the compiler will calculate the ramps.
Btw. a user at TLF (and who already contacted you here) wrote a new regulation that is absolutely amazing (at least in the simulation). Just not implemented in Anduril.
Yeah, that’s what I was assuming too. But there are reasons why it doesn’t calculate the ramp values on the fly, either at compile time or at run time. The ramp generally needs very careful fine-tuning to make it work well, and often even needs the calculated values modified by hand. The ramp calculator is a good start, but it doesn’t get us 100% of the way to the values the program needs.
Yeah, it sounds really promising! It sounds like things are waiting on shipping at the moment.
I suppose I hadn’t considered the need to hand-tune ramps. I’ve been replacing table generation scripts with compile-time generation and it seemed like the ramp would be a good candidate for that. An abstract perceptual-to-linear interface would also make it easier to do things like interpolate between ramp values for smoother ramps on small firmware.
Yes, but my D4V2s arrived yesterday, the Reflashing kit is still on its way. The firmware revision on my D4V2s is <= 450. The temperature target is set to 45 °C and the temperature sensor is properly calibrated.
I think the problem is that 7135 heats up driver and attiny85 measuring bogus temperature. Why just not turn off 7135 in high modes? After 350mA there is no stabilization anyway.
Disabled by default. Only supported on CPUs having a 16-bit PWM, which means only attiny1634, which means only Emisar D4v2 and D4Sv2. I don’t have a D4Sv2 to test, so currently it’s only implemented on D4v2. The relevant functions could probably be directly copied from hwdef-Emisar_D4v2.h to hwdef-Emisar_D4Sv2.h.
Strobe rate can be continuously varied from 1Hz to 500Hz. Theoretically it could run faster, but this is already enough to freeze something that’s spinning at 30000 RPM. Uses full brightness (1x7135 plus FET) with a 1:256 duty cycle (party strobe) or 1:4 duty cycle (tactical strobe). Rate adjustment has acceleration, going twice as fast after 1 second and 4x as fast after 2 seconds. It still takes about 10 seconds to traverse the whole range from 1Hz to 500Hz.
With this I was able to freeze my Proxon drill (similar to Dremel) running at 20000 RPM. Unfortunately the flash rate fluctuates by about 0.1%, probably due to the CPU’s RC oscillator.
Anduril have no indicator led LVP ? Aux leds maybe off, but indicator led keeps shining until battery kaputt
Maybe this line have to be fixed?
#if defined(USE_INDICATOR_LED) && defined(TICK_DURING_STANDBY)
// beacon-like mode for the indicator LED
void indicator_blink(uint8_t arg) {
// turn off aux LEDs when battery is empty
if (voltage < VOLTAGE_LOW) { indicator_led(0); return; }
In blinking mode LPV works , but in low or high modes not at all.
// TODO: turn off aux LED (s) when power is really low
if (0) {} // placeholder
So…it seems simply unimplemented yet
You may try adding
// turn off any aux LED (s) when power is really low #if defined(USE_INDICATOR_LED)
indicator_led(0); #endif #if defined(USE_AUX_RGB_LEDS)
rgb_led_set(0); #endif #ifdef USE_BUTTON_LED
button_led_set(0); #endif
before the placeholder.
EDIT: upgraded the code
ADDED: Note that if the flashlight is on it will turned off when LVP fires. It needs to be checked whether turning it off won’t turn the aux LEDs back on.
I think the aux leds do not need many amps. It can run on months with fresh batteries. So it would lasts a long time till the batterie is dead.
Many Aux-LEDs will turn off on low battery. This is implemented in some Aux-Boards from Lexel, such as MF01S or MF01 Mini or some Fireflies Flashlights.
Whithout this behaviour the LEDs will turn off because of the too low Voltage. This means they will use much less amps than with full battery.
But as Agro, it can be implemented to be on the safe side.
Otherwise the Low Battery-Indication on a MF01S or MF01 may not work as implemented, if the driver switches the aux-board off.
You don’t come here often, do you? Anyway, thank you for your help.
