[UPDATE:v1.7.1,Q8&1chanOTSM]bistro-HD, bistro your way. OTSM, eswitch(devel), Vcc reads, safe_presses, turbo timeout...

This is great! Looking forward to quad-channel PWM becoming the standard for BLF drivers! The next step up from quad-channel for me is RGBW with independent dimming controls for each channel (and maybe some presets for quick access).

This is great!

By chance is there an easy way to make the level of each channel variably selectable by the user? Basically like a channel mixer. I’ve always wondered why bistro does not have variable dimming anyway, especially since it already has a ramp table.

Please don’t let my questions down play what has been created here! This is very exciting to see these advancements in such short time!!!

This is awesome. Great to see such progress in firmwares lately. :partying_face: :beer:

Congratulations!

ORSM!!! Congrats! You must’ve put a lot of time and effort into this. Terrific work. :+1: :beer:

Look'n Good!! Glad to see the 4 PWM channel feature worked out. Interested in the board designs/parts, etc. pairing up with all these features.

Well done! Glad to see firmware improvements keep chugging along. Peaking at the code now…

Sounds amazing although I admit most of that read went right over my head. Great summary of features although having not worked on the previous one I don't understand what the advantages are with the new ones. For example I'd love to understand why I want 4 PWM's instead of 2?

OTSM "off-time sleep mode" got it :)

But what is LDO? Triple Down? 3-way mode?

I don't understand allot of other advantages either but that's just because I am so new to this. :)

So OTSM requires a new driver board build, but will this run on current boards like the ones from RMM? Sounds like it would just need to be configured to do so which is why I ask the stupid questions above :)

Sorry I'm c-tarded I'm a mostly a java web app developer :) This is a fun new world over here though.

Wow. Orsm effort. Well done. :beer:

Wow! I've been out of the loop on flashlight modding (including keeping up with FW developments, but this sounds like some seriously great achievements. So many developments. I really dig that you have disconnected OTC performance from the various factors that influence the OTC capacitor's behavior.

Hope you are ok with me adding a link in the OP of the "25" thread to this thread.

Expect problems. There's a ton of new stuff. There's going to be bugs I missed. I've tested on a bench, which has some advantages as far testing layout cases, but also misses some of the experience of real-world use. Yeah, sorry about the fast write-up.

4 channels was requested (I think by DavidEF) for RGBW. No, at the moment there are no disco strobes or new ramping or anything like that. Yes the softstart code toy keeper wrote should be a solid starting point for ramps, but I think narsil is the ramping king probably. I knew someone would ask about party modes, lol. The main goal was to squeeze this into an an attiny25, although TA is now squeezing 85's onto smaller things anyway (I'm almost bummed about that lol). Setting this free onto an attiny85 would probably allow tons of stuff like that. I don't know how much I'll carry the ball forward with that kind of stuff either. Contributions are of course welcome. It's gpl.

LDO is, well some of those comments are for people pairing it up with new hardware. LDO stands for Low drop Out, but it means tiny voltage regulator on the input to the mcu. It's used for 2S etc lights as a better alternatve to a zener to power the mcu, and can provide a voltage reference to the adc. that's the only way to get voltage reading and power-off detection (and/or switch) onto the same pin in this firmware. But in an unregulated 1S build you don't need to. You can just use the Vcc-pin voltage reading.

Trippledown is as far as I can tell the original 3 channel version of bistro. Actually I kind of skipped that version and went from stock to TA version, which I think is based on trippledown. Three way, I was just referring to the short/med/long click options, that give mode reversal and hidden mode access, compared with short/long, that doesn't.

I think the most immediately-available test case for the biggest part of the code is probably e-switch lights. I kind of imagine DavidEF building an RGBW SRK or Q8.

Oh, one thing that's completely untested is the traditional divider voltage reading in the new parameterized form. I don't have a voltage divider on my test setup. I tested the Vcc method and that works for me, but not the divider. There is a hidden define in the voltage.h that unleashes the original ToyKeeper calibration table as a backup, but that's not tested either. It should work, but there could be a typo or two still there.

Oh, and I forgot to package in TA's build script. I'll add it back when I get a chance. It's useful for compiling on Linux.

Very nice work!

Don’t be bummed about the swap to tiny85’s in the new drivers, we will still need the space at some point plus all the older drivers still use tiny25’s and this firmware should work for them as well.

Texas_Ace, do you have a new driver board for this firmware? I know you’ve been talking about new driver design(s) you’ve been working on. Is this it? I’d love to see the hardware released that utilizes this firmware. :smiley:

A couple of notes for anyone looking at the code. The 4 channel stuff is mostly setup in fr-tk-attiny.h, init_mcu, and a couple of timer interrupts.

The OTSM and e-switch stuff is mostly done from PCINT0_vect, the watchdog interrupt (that does nothing), and some mild trickery with main_init and the early parts of main. All that is kind of together in bistro.c

I have a new driver that is almost ready from the hardware side, although the firmware is not quite ready yet but a lot of the features in this firmware came about for this new driver.

I am going to be calling the new driver the “Texas Commander”.

It will take advantage of the OTSM and PWM regulation among other software features but no 4 channel at this time, mostly because it is not needed with this driver.

Long term I would love to see bistro and narsil come together to make a single firmware for both clicky and eswitch lights that can be selected in the menu thus allowing for a single driver to be produced and work with virtually any light setup with little to no hardware changes needed.

Yeah, I'd veer more toward talking about 45's than 85's if OTSM is something that matters. We still have no datapoint of anyone having a late revision 85 where BODS actually works, and possibly three examples where it didn't. Who knows, maybe those revisions have only been sold through certain contracts and the retail supply has a 15 year production run of early revisions on the shelf. It does seem that on the other hand maybe almost every attiny45 in the wild is late revision and compatible (we don't really know). For use on existing builds, it's going to be a YMMV situation. For new builds you can at least look at the bottom of the chip and find out.

I want to add more emphasis of the credit to Flashy Mike and Mike C. Maybe it comes off like they did early test of my OTSM designs or something. Not the case. They made the first prototypes for hardware and software and communicated very useful results of that that heavily influenced this. TA also was very involved in helping to figure out what configurations we can actually get into a driver and DEL even chimed in with some useful contributions to limits on the electronics. A bunch of people put thought and effort into it.

As far as merging things. I think Tom E is probably the most consistently dedicated software person here, and don't expect that to change from my perspective. If some of this stuff just serves as a demo to get worked or reworked into Narsil, that's great, especially considering he will probably continue to maintain it. Much of it would probably have to be done very differently in Narsil though. They are just completely different animals at the program flow level.

Hmm.. I don't have a concept of a comfortable UI for that. How would it work? Already you can predefine combinations. Clicking into 4 different ramps sounds pretty uncomfortable, and distinguishing 4 switches on one pin with battery read and poweroff detection, is technically not quite impossible, but probably not going to happen.

This looks awesome so far. I’ve been pulled away by Real Life™ for most of the past 5 months, but I’m finally back to making my backlog smaller instead of larger, and I hope to catch up on recent developments.

Do you mind if I copy the code into the main repository?

Also, is there much interest in migrating to github? I personally prefer launchpad, but git is quite a bit more popular so it might be useful to move the repository.