Cool. I can just invert the value then.
What I was thinking is to do something roughly like setting the maximum PWM level to 255 minus the difference between some hardcoded value and the actual thermistor value. This way, it would ramp down smoothly and gradually above a certain temperature, and step back up just as gradually when it cools off. The scale might need to be multiplied or curved or something, but it seems like the concept should work.
The goal is something similar to ZL’s “PID” thermal controls, which behave like this (but less advanced):
Low voltage, though, should just use the standard approach found in STAR. When low, step down. If it’s already at the bottom level, warn and shut off.
Not really. The attiny can only measure one at a time, and it’s asynchronous, so it needs a bunch of extra logic just for switching back and forth between the two ADC channels. Plus, low voltage logic never steps back up.
I agree, both would be redundant. Thermal protection will use more ROM space than turbo timeout though. We’ll have to see what will fit.
It’d be nice if we could just replace the standard attiny13 with attiny25 chips in all the common drivers. Twice the ROM space, and since half the space gets used for overhead it means like 1500 bytes to play with instead of 500.
I have no idea. I’ve only done voltage indicators once, and the circuitry side of things was already fully taken care of. I just had to do the measurement and logic in the firmware.
This is just a guess, but I would assume that the attiny’s output pins run at the same voltage as its power source, so whatever the buck is feeding the attiny. It can run at up to 5.5V though, I think, which should be enough. And to control how much power is fed to those indicator LEDs you’d have to insert appropriate resistors along that path; the attiny can only turn it on or off. I don’t recall off-hand what the default attiny output pin current is, but you’ll almost certainly need to reduce it for indicator light use.