Yes and no. I didn’t make firmware for it, but gchart did… so most of the work is already done.
http://www.ghart.com/blf/firmware/
Merging that in is still on my todo list, because I’m slow. I really should do that soon, before my branch diverges too much.
Yeah, extra resolution would definitely be nice for the bottom of the ramp.
I’ve tried a bunch of methods to increase the resolution. Some worked, some didn’t. And some worked on my test host, but failed when installed on another light.
The most effective and reliable methods I’ve tried were the ones which increased resolution in an analog domain. Sometimes digital works, but it’s a lot more prone to failing. This is mostly because the analog components have an inherent noise floor, and no digital solution can increase resolution below that noise floor. When approaching that limit, it’s necessary to lower the noise level in order to make the signal more precise.
Like, let’s say a ramp can go from 1 to 10000, and there is a noise component of +/- 10. Toward the top of the ramp, let’s say it’s at level 9000, it doesn’t really matter if it varies from 8990 to 9010. But toward the bottom at level 100, going from 90 to 110 is probably visible… and even lower at a level of 15, varying randomly from 5 to 25 makes the signal basically unusable.
But give it a second analog path with everything scaled down to 1%, and we get something which can go from 0.01 to 100, with a noise component of +/- 0.1. Now level 15 is a lot more stable, varying only from 14.9 to 15.1.
It’s not always feasible to do this, due to space constraints on the driver… but when possible, it’s almost always the most effective solution.
Er, it might also be worth mentioning that the “noise” isn’t necessarily visible within a single light. Sometimes it’s visible, like the flicker seen at low levels on the KR4, but I’m also talking about the variation within a production run. Produce a thousand items, using a dozen different types of LEDs, and there will be a lot of variation. At the bottom edge of its output range, some items will work great while others don’t light up at all. So I’m mostly trying to stick to solutions which work for the whole batch, not just individual items.
In the case above, that often means that an individual light has a range of 1 to 10000, but the +/- 10 part is a static property of that light. Like… it’s always +5 or it’s always –7. So toward the bottom of its range, I could calibrate the ramp so it looks perfect on my +5 sample, but then when the same code runs on a –7 sample, it looks all wrong. I might set the ramp to start at “4,4,4,5,5,5,6,6,6,7,7”, but on another item it ends up looking like “0,0,0,0,0,0,0,0,0,1,1”.
If it helps at all, the exponent option can be an arbitrary number. Like, if “seventh” is close but not quite right, try giving it 6.9 or 7.03 to fine-tune it.
Anyway, I don’t have answers for Tiny1 circuit design, so I’m not helpful here… but I’d definitely recommend reading through gchart’s code if you haven’t yet.