Hey wight, nice to have you back.
I joined after you started your break, but I have seen the drivers you created. Hope you have a nice time here on BLF :+1:
wight catch-up. Now that bought a smile to the dial. Welcome back. For those that don’t know wight also built a light or two that defied the laws of magic. Must go find the threads for a refresher.
I remember back when I joined, people were talking about the missing “wight”.
Here’s my catch-up. Maybe I am wrong. I think the hobby has changed. As I understand, years ago the average person expected Alkaline/light-bulb performance, so showing them a lithium/LED flashlight was a mind-blow. Everyone had fun.
Now there are lithium/LED flashlights on every retail shelf. And while it’s will always be possible to out-perform a mass-produced light, it takes more money and effort than ever to ‘wow’ the average person. The “Giggles” light for example is great for wow-ing people, but had to be built so absurdly big it’s hard to even think of an excuse to take it off the shelf.
Good to see you back Wight, while our times here did not cross your work was what heavily influenced the TA driver series (with the work of PD68 and DEL adding there share in the mean time of course).
I look forward to seeing what you cook up now.
Getting the OTSM working with some viable firmware would be nice for the time when clicky lights are required for example. Right now the only firmware that supports it is a bit too buggy to make widespread use possible and dealing with the OTC is a royal pain, having to deal with this right now actually and think I might just revert to a non-OTC firmware in order to solve the problem.
Flintrock disappeared quite a while ago, but whilst he was here, he had, lets say, a high opinion of his abilities, and derision for almost every one else who questioned some things.
The code supporting OTSM was tricky mostly because it relied on bare interrupts running raw assembly code. This made it extremely hardware-specific, and it also appears to have made the code buggy in some pretty unpredictable ways. I think perhaps the bare interrupts were less safe than Flintrock had thought, and may have had subtle unintended effects, but I haven’t tested to verify that. I just know that, whenever I tried BistroHD on real hardware, it exhibited a pretty wide variety of issues which were not easy to reproduce on purpose.
I’ve been trying to push code in the opposite direction instead — making it less hardware-specific and more portable, so people can mix and match whatever hardware they want with whatever UI they want. And for that, I think it’s about time to support more than one MCU architecture. I’m not sure which one to add next, but I’m thinking maybe tiny84 or tiny841 or tiny1634. New driver designs frequently seem to need more pins, and I have a bad habit of filling space, so it wouldn’t hurt to have more ROM too.
I agree, a new MCU is needed, something with both more pins and rom space.
I am also very grateful for the move to more universal firmware setup, now that I have started to play with Anduril I am seeing the flexability, I just need to figure out what the limits are. I tend to push past the bounds unless I know exactly where they are.
OTSM is absolutely reliable, pretty simple to handle, no "raw assembly code" required! This is the proof-of-concept code I sent to Mike C on request almost 2 years ago. I would have given it to anyone here who had asked but sadly there was no interest.
Try it!
/* Simple sample firmware for otc less design (single cell).
Half press less than about 300 ms: next mode
between 300 and 900 ms: previous mode
longer: blink out voltage reading
(0 to 255) in 3 decimals
Suggested capacity of buffer cap (C2): >= 47 uF.
Vbatt is connected to PB3 (Pin2).
Voltage divider still connected to Pin7.
Timing specified for Attiny25 at 10 Mhz.
Don't fuse BOD.
Created and built with Atmel Studio.
Fuses for Attiny25: lfuse: 0xD2, hfuse: 0xDF.
*/
void blink_value(uint8_t value)
{
// 100er
if ( value < 100 )
blink_once_short();
while ( value >= 100 )
{
value -= 100;
blink_once();
}
delay_1_sec();
// 10er
if ( value < 10 )
blink_once_short();
while ( value >= 10 )
{
value -= 10;
blink_once();
}
delay_1_sec();
// 1er
if ( value == 0 )
blink_once_short();
while ( value > 0 )
{
value--;
blink_once();
}
delay_1_sec();
Oh, nice. I didn’t know anyone except Flintrock had done it. This is much more useful, and demonstrates a pretty clean way to do it. It would not have occurred to me to go to sleep inside an interrupt handler.
A legend returns! Welcome back wight. Even though I joined after the start of your “sabbatical”, it seems like I’ve read (and re-read) so many of your posts. Thanks for your contributions thus far.