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

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.

Hi TK. Glad you like it (well, no real tests yet). I had a good starting place to work from.

Yeah, I'm a little likely to take a break a bit for real life. I don't have much opinion where you put it. Of course I don't mind if you copy it. probably should get TA's build script in there if you've got it handy. It should work as is from previous versions. I'll try to add it when I get around to it. I did forget to mention that my test rig is a very violated TA board.

It's got 30uA of capacitance on C2, nothing on the OTC. I think 22k on R1, but the value doesn't matter because there is no R2. I'm only using the voltage there as OTSM shutdown detection, which is why I haven't tested the voltage divider read option, just vcc read, and that's how would wire any 1S build.

C1 capacitance and the bleeder (total resistance of bleeder and parallel divider to be accurate) are important for getting OTSM working well because they determine how fast the power off is detected, and there's a bunch off-time power wasted while that's happening. I'm presently using 1uF C1 and 500 ohms bleeder. DEL likes 1uF C1 for stability against spikes, although 0.1 might do the trick. Lower bleeder is ok, unless you want heroic moon mode lifetime to survive the apocalypse. Anyway, I think after adding power saving in bistro, there's at most maybe 20% improvement to be had in off-time by going to lower values.

I'm buying a V-chip now and a couple of these caps:

http://www.digikey.com/short/3fnfr4

It's quite expensive but being tantalum it won't lose capacitance with a DC bias or with high temperature(there is the whole explosion thing but that adds fun), and it's the best I can find in an 0805. I think TA is trying to make space for 1206 C2's on his new boards, and there should be some benefit from adding an extra cap in the OTC position if it's not otherwise in use, or even if it is (can wire a switch across the cap). I'll try to build it into a present model TA board and see how it goes.

Great to hear you are back poking around!

I am about to take some time off for real life myself so I also understand the break. Thats why I have been trying to finish this last driver before life takes over.

I should hopefully have a hardware setup nailed down before long for people to play with for the firmware side of things.

Well, I’m not at all versed in firmware, so I can only say what I think I’ve seen/heard. If you’re interested, take a look at DrJones and tterev3 UI’s for inspiration. tterev3 even has R-G-B-W-UV working with e-switch. He uses PIC chips instead of ATtiny, but that doesn’t change the fact that he has an excellent single e-switch UI. I can’t remember now for sure if he has per-channel output-level ramping, but I think he has some kind of advanced color mixing.

Dr jones really has the ultimate RGBW UI. And he does it with an mcu, capacitor and amc’s. Quite amazing.

An adaption of bistro or narsil for 4channel would be great but I imagine a good RGBW UI would have to have its own firmware…

Yeah, I know the RGBW firmware would NOT be Narsil or Bistro. I wouldn’t want a RGBW light to work like a white-only light. The “four channel” aspect of a Bistro or Narsil light is just a way to have more efficient mode levels. It’s the next step up from three channels, which is the next step up from two channels, which is a bit better than one channel. It’s almost like having a 8K television versus 4K versus 1080P versus 720P versus “standard DEF” in that it deals with “resolution”.

And it does open up the possibility of having multiple led outputs. Like an all red mode or an led on the side and front of head as I’ve seen in some mods out there. It opens up many more possibilities and is a step toward another possible color firmware.

Well yeah, that too. :stuck_out_tongue:

Yeah, they’re designed for only one actual LED, or maybe one plus an indicator somewhere. Adding more channels to a one-LED light has diminishing returns. Here’s a conceptual comparison of 1-channel, 2-channel, and 3-channel drivers:

As far as I can tell, the Tripledown or QuadrupleDown (lol) method is how Zebralight and some other premium brands do their drivers. On close inspection, their medium modes have fast oscillations between two stable output levels… just like what Bistro and Narsil do. Not all premium brands operate like the led4power linear drivers.

The really interesting parts of having more PWM channels is the ability to do more than one LED. Like, RGBW or white plus an indicator or two, or multiple color temperatures for adjustable CCT, or things like that. Or use extra pins for extra I/O, like another switch or an external temperature sensor or a backshine/feedback sensor. Of course, those aren’t going to happen in most cheap hosts, so I expect the 2-to-4-channel single-LED drivers will remain popular.

I have the house to myself for about 5 months and plan to make the most of it. After that, I don’t know what will happen.

Before you go, could you upload the saber driver to oshpark? :slight_smile:

I had some similar experiences while trying to make bistro fit onto an attiny13 for biscotti. I hope to merge together both of our space-saving ideas soon, to make all the projects as small as possible.

I must admit I haven’t really made time yet to read through it, after barely a week of catching up, and I don’t have hardware to test it on. But it sounds like you’ve been doing good things. :slight_smile:

Ideally, I’d rather curate people’s code instead of writing it. I never intended to write ALL TEH CODEZ, just to get it all together in one place and make it easier for people to collaborate. So, I’m really happy to see people making cool new stuff.

First folks should understand this is not a 4 channel firmware. It's actually many different firmwares programmable by the c-preprocessor options, and 4 channel is just one option. You can build it for only one channel or two or three, and you can select whichever of the 4 channels you want (although 1 and 2, on pins pb0 and pb1 are preferred slightly at least). 4-channel was really just a why not kind of thing after figuring out how it was possible. The Vcc-read and the eswitch ire probably the most immediately useful features on existing hardware and the OTSM will I hope be a great benefit in the very future possibly even on existing boards with some changes to the components. It also combines well with the other two features.

Color mixing was pretty much what I thought you were getting at David. But before someone can program it they'd need a vision of how it would be used. If you just want to set up some color for photography I guess it can require a little setup and several menus for each led to fine tune things. Using a standard UI I'd probably do color mixing at a medium brightness level in the hidden modes or just have a dedicated modegroup like that, just have as many preset mixes as you want. Then standard modes are just W or maybe equal RGBW, or anyway a fixed custom tint.

One thing I've thought would be nice though, similar to hidden modes, but somehow make it easy to switch back and forth between two or three mode groups. Not the full menu 5 thing, some kind of quick access toggle. It could be a short menu in the hidden modes. Then the user can define their 2 or three bookmarked groups from the main menu. For me I use my light walking and biking and indoors, and kind of want different mode groups for all three (but especially for indoor vs outdoor). I wouldn't mind if it even defaulted back to the indoor settings after an hour. (RAM actually lasts that long with these big caps, but without an eswitch there's no good timer and the RAM probably actually lasts too long).

Anyway, lots for room for creative advances still. I was kind of hoping to mostly knock out the real hardware-driver side of the firmware with as many configurations as can cram into 5 pins. Then the "application" side of the software can be developed more, but I'm sure there will be more ideas on the hardware side too. There already are a couple of ideas that fall in between, like pseudo regulated PWM, that aren't in here. If I do more that might be my next thing.

[quote=ToyKeeper]

I knew this is what you meant, I just couldn't come up with the expression at that instant.