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

Your point is correct, but I just want to mention that the efficiency for the FET-only case is not as bad as the straight line in the graph. This is because there are 2 main contributors to lower efficiency at high current: one is the high current density itself and the other is the temperature. So when the PWM duty cycle is, say, 50, the temperature won’t be as high as it is at 100, so the light output curve won’t be a straight line. See here for some measurements:

That plus one seems to come a bit far up the curve. It's only 350mA. To me +1 is for moon modes, not efficiency. Tripple channel is to help a bit with efficiency, and yes, isn't a huge issue. I'm not exactly sure what the axes are on that plot though or why the ideal one goes verticle toward zero. Of course with any linear driver there's loss of efficiency of Vo/Vi, but that should be factored into "ideal" for a linear driver I suppose, as distinct from the PWM and LED heat issues. I find bucks more and more worth the money. Twice the cost of the light, ok, but it runs twice as long on high output, at least, and without all the fuss about wire gauge and tiny voltage drops. That's not really about efficiency though either. A second set of batteries aint cheap either. It just depends what you need to do with it. The efficiency also depends if you're looking at it as 80 vs 90% efficiency (only 10%) or as two times less heat in the driver, which again depends what you're doing with it. If you're not a turbo freak, the heat's probably not a big deal. Another reason to have the extra +N channels though is just to get a regulated mode for constant brightness/battery drain. Well like I said, regulated PWM is the feature that interests me most next.

Yes, this is exactly how dr jones RGBW firmware works. Once the codes are memorized it is quite easy to program each channel as desired. It is also available to use at all times, not just in a config menu. Although the advanced function of “Morse code” UI could be argued to be configuration in itself.

I like what I am hearing from you guys! :slight_smile:

Rats, I found 8 more bytes in the new bits. I'm ok really. I can stop anytime I want... I think, probably. Everyone counts bits in their sleep right? I mean that's normal isn't it?

The first (as I'm aware) purpose-built bistro-HD OTSM driver with BODS is constructed and on first look seems to be working fine. Will do a little bench testing and then close it up in the light to see how it handles. The board is a standard TA tripple and it's setup pretty in bounds, other than usinig an 0805 cap on an already generously sized 0603 pad. More details on the component selection to follow.

Hi

I am currently working on a light with Forward clicky and eswitch on Texas Avenger board

Which part of your code modifies normal Bistro to eswitch?

I want to implement Eswitch into Bistro Avenger triple

I am using an Attiny85, so the lengh of code should be no problem

I actually have a few updates (not posted yet), mostly to help with some corner case bugs in the preprocessor options. Anyway, that shouldn't matter. You don't need to mess with the code itself at all, just the preprocessor configs. I think the tripple_layout as I posted it has the e-switch already defined on the cap pin in the fr-tk-attiny.h, but you can check. Then you just need to uncomment the use_eswitch option in bistro-hd.c That's it.

Do realize it's experimental. The code itself is mostly all in PCINT0_vect, the pin change detection interrupt.

Unfortunately, the OTSM isn't quite working out. Details are here:

https://budgetlightforum.com/t/-/34900/1887

Basically it works on FETs but there is a mysterious difference on the 7135s, a difference that really shouldn't exist, sill trying to figure it out.

By the way OTSM is not very compatible with most available revisions of attiny85's. e-switch should be fine though. OTSM does work(well, in principle, given above mentioned problems) with attiny45V though. With that light, you might want both if OTSM gets working better. I was eyeing the Supfire A2 as a light like that. I might get one and test it out, but it's a difficult mod to get a custom driver in there. I think lightbringer modded one.

Oh, of course my original motivation for the e-switch was the Q8. Once once I get my hands on one of those you can bet I'll get it running, but I think that's e-switch only.

I got no expirience with programming

I was hoping there is an easy solution to change the OTC pin to eswitch

I opened the Bistro HD.c file in AVRStudio and searched for eswitch and its in there like dozens of code lines

Ok, I'll detail it for you shortly. You'll want to start to get some understanding of preprocessor defines, but anyway, it's simple. Most of the lines are where the options are used. You only need to worry about the ones where they're set (#define), near the top. I just don't have time right now to quote the relevant lines... I'll post back soon though, along with some notes on options for how to wire the clicky part of things.

Congratulations to everyone involved! Awesome job!

@RH64 Well the main original goal, OTSM, has some problems still, and it's a mystery at the moment that I'm a bit stumped on. The debugging required to get the bottom of it is maybe not lightweight at all either (maybe needs custom hardware to time triggered shutdowns for example, a bunch just to debug).

@Lexel I think I misunderstood where you're coming from. You're trying to port the e-switch into Bistro-TA. That's your mistake. Bistro-HD is a not a specialty release like some previous ones. It fully includes bistro-TA, as well as bistro-trippledown and plain bistro, and I may even get a BLFA6 emulation build into it. It's just a matter of selecting the right config options. I'm presently working on separating pre-set configs out into separate files so we can just have configs like this laid out for custom lights and ready to go. It will be part of the next release. I don't know much about biscotti, but ideally that would be config options too. That may be unrealistic, not sure.

Anyway, what you need is just to go to fr-tk-attiny.h

Go to the trippledown layout section.

Uncomment this:

//#define ESWITCH_PIN PB3

That defines the eswitch as being on the traditional CAP pin.

Actually there should be no problem with me leaving that uncommented by default, but it wasn't. You don't need to uncomment the CAP_PIN either (if everything works right), and in fact you can use it for both.

Then go to bistro-HD.c In the top section the #define statements turn options on and off, until line 209.

then enable USE_ESWITCH. (un-comment #define USE_ESWITCH)

You will want to go down and look at the first boot options and set them how you like too. Memory is turned on by default I think which wasn't actually my intent, probably happened during testing (another reason to have custom config files).

Now comes the complicated stuff. Is it a 1S light? Does it have an LDO, a protection diode? If it's 1-S with no LDO, I would set READ_VOLTAGE_FROM_VCC and comment out READ_VOLTAGE_FROM_DIVIDER This frees up the voltage pin from complication. This only works if Vcc sees the battery voltage (minus possibly a small diode drop).

Now, what about your clicky switch? We can have it use the tk noinit method that requires no cap. gchart and I have been working on an upgrade for that in BLFA6 to address a fairly serious reliability issue. It's working there. It's not in here yet, but could be soon. You can USE OTSM, but it's not working right yet, and may never be low parasitic drain. You could use OTC actually. You would just put both a cap and a switch on the OTC pads. The switch will short the cap and bring it down. Might want a small series resistance in line with the switch to reduce the cap discharge current. I think this is a good option for now.

If you want OTSM, and you're using READ_VOLTAGE_FROM_VCC you'll want R1 to be 1/3 (no more, less is ok) of R2. And the total bleed resistance (R1+R2 is part of that, parallel to bleeder) is still a mystery. It should work with a total of 4k but there are question marks still.

If you're using READ_VOLTAGE_FROM_DIVIDER and OTSM you'll want the max divider voltage to correspond to Vcc, or maybe 5% less. If it drops too low it will trigger OTSM. In that case you'd also need to reference the ADC off Vcc and I think the option for that only exists in my un-released version.

Anyway, either enable USE_OTSM or USE_OTC, or neither to revert to the noinit method. I wouldn't go with OTSM at the moment unless you want to help fix it. Even OTC or noinit in combination with E_SWITCH are still very alpha and you should approach it that initialliy it can be a lockout and get the e-switch working. If it does more on first try, that's a bonus. These combinations were tricky to work out and still untested.

At some point maybe I can work up a config for your case and all you'll need to do is select the right config file. The danger with doing too much of this is it's more baggage to maintain if the configs all need some re-working. Oh well, if they weren't there, they'd need to be reworked too, just not by the programmer who broke them. It puts more responsibility on the development side.

Ok if I get the settings right I do need to compile the hex file
I did it one time with a narsil triple.c
But how do I get the attiny.h on the hex or MCU?

Do I only need to disable the one OTSM line or also lines like
#if define(USE OTSM) || defined(use_eswitch)?

As there is only one Bistro HD.c file in that download is it set to 3 channels?

Cross posted, see above.

You change the .h files and other configurations before you compile. These are all part of the program source. The compiler translates these instructions into two-byte machine instructions that form the hex file. So it will all be in there after you compile. But yes, you will need to compile. If you know linux, you can avoid atmel studio by using TA's compile script. I forgot to include it, but you can find it in the original TA-bistro code. It should still work. Haven't tried it in awhile though.

I should say, working with experimental features like this is probably not the best place to get your feet wet with these things, but if you're up for the challenge, it's all learnable. There's a bunch of information around here.

So If I use OTC I need to add a resistor like 1kOhms? between switch and Ground and add a 1uF OTC
Do I need to enable the lines for OTC when using this wiring?

OK i found the define to 3 channels is already enabled

I use simple 1S setup with Texas Avenger layout
Not sure what to modify to get low voltage protection with OTC working

In the .c file it says compile the fk-tk file so Its like you said just compile it

There is also a line says short medium and long press activated does that mean the light can be turned off with long press and short and medium to change modes?

I also found a line that I need to change as I am using Attiny 85? Or does it be ok when compile to set attiny 85

Also which fuses do I need to define for flashing?

I also want to change one or two modegroups as I like, where to start?

Ok, many questions...

I guess 100 ohms would be fine. 1k probably would too though, yes.

The default is setup for 1S TA. VOLTAGE_MON should already be defined, and that gets you LVP.

1S TA uses a diode so you can use READ_VOLTAGE_FROM_VCC. That's good and can simplify some other things. Also the voltage calibration should just work reasonably close out of the box then regardless what R1 and R2 you use, so it separates issues there.

Short/med/long is standard bistro. Short changes mode forward, med backward, med from first mode goes into hidden modes, long reset to first mode if memory is not enabled.

If you don't using an OTC the clicky switch will only get short and long.

You should use the 85 define if you're using an 85 yes. That's important.

The fuses are documented in the comments near the top. If you're not using OTSM you can be conservative with them in all respects.

To change modegroups go to modegroups.h and just edit them. It's pretty self-explanitory. All mode groups must end with 0. Note when setting the initial default modegroup in bistro.c, 0 means group 1. This is because C arrays count from 0 but menu flashes must start at 1 (0 flashes is hard to interpret).

So from the TA thread it's clear that you don't want off timing at all on the clicky switch. So you don't need an OTC cap. We just need to get the software to not fallback to noinit timing on the click switch. That's not hard to add, but it's not in there now. I could make it always behave like a long press, then a click off will either reset it to mode 1 or will do nothing depending on how memory is configured. However that option affects both switches.

The other two possibilities are I could just make it a separate option that just makes the click switch always do nothing (doesn't change the mode), or a separate option that just always makes the click switch come back in mode 0. (with reverse modes set this can be turbo). Then the memory option would only affect the eswitch then.

I actually need to review the code for noinit using two switches. I'm not sure it works. You can configure it for OTC (but don't need the cap) and modify this code though:

#elif defined(USE_ESWITCH)&!defined(USE_OTSM)
if(wake_count==255) { // so we had a timed out clicky press, must use OTC
// translate OTC readings to wake_count
// could simplify and do this for normal OTC too (adds a few lines, but for a simple build anyway).
uint8_t cap_val = read_otc();
if (cap_val>CAP_MED) {
wake_count=wake_count_med; // long press (>= is long)
}else if (cap_val>CAP_SHORT){
wake_count=wake_count_short; // med press
}else{
wake_count=0; // short press
}
}
#elif defined(USE_OTSM)

to

#elif defined(USE_ESWITCH)&!defined(USE_OTSM)
if(wake_count==255) { // so we had a timed out clicky press, must use OTC
wake_count=wake_count_med; // long press
}
#elif defined(USE_OTSM)

If you change it to always wake_count_med that will actually make it always a long press and it will follow the memory mode setting.

It seems clear that I should change the names of wake_count_med and wake_count_short to wake_count_med and wake_count_long, lol. There is history to this though. Whatever. The thing is these are the threshold values and in this implementation <wake_count_short is a short press and > or = is a med press.

I'm in the same boat as Lexel. Probably worse.

To me this is just part of the hobby and I want to learn how to make it work so, I'm up for the challenge.

I started a new thread and I hope you PROS can come over and school us... NovicesFirmwareGuide: learn to use existing code for your custom builds (WIP)

Merging biscotti

Ok, got around to learning what biscotti is. So it really seems likely biscotti can be merged back in with HD, and in fact I've probably mostly done it already. I started creating a "BLFA6 emulation" config, but realizing that there are many differences in BLFA6, it's become more like a BLFA6 approximation, which basically means bistro on attiny13 for nanjg layout with BLFA6 mode groups. Hey, that's more or less what biscotti is! Modegroups are now setup as separate config files that can be selected, and I've already one setup for A6 modes. It looks like the present biscotti code has a bigger mode group, but that's easy to add in too. I just need to see exactly what other options biscotti is using. Biscotti is for a single FET where BLFA6 was FET+1 but that's all just part of the config options now.

I'll need to look more. Maybe TK has stripped/simplified some code to get some of it back down to similar to BLFA6 (hmm, at least count modes is much simpler with no reverse and no hiddenmodes needed, and some other optimizations now in HD may have too much overhead to pay-off in a simplified driver). I think it's a simple matter, anyway, might be doable to get a biscotti config option in the next HD release or maybe it should be called "bistro-universe".

So I was able to get HD to configure down to a biscotti build and it fits (barely, but it's 1022 bytes, just like the real biscotti which is a little surprising).

So I went ahead and made a combinatoric makefile that can be given firmware config files, grouped by the minimum chip they can run on, and then it builds all valid combinations of hex files.

I think can say I've fully re-united the bistro family code base. I have not put in modegroup.h files for the original bistro mode definitions (done) or the original trippledown modegroups yet(done), but it's simple to do (done) and along with a configuration to match the original bistro build (done).

The Makefile works directly from Atmel studio and can be used by selecting it from the Project->Properties->Build pane. Of course, I'll have to post it up first.

At the end the makefile presently spits out this:

text data bss dec hex filename

Live child 01298C28 (sizes) PID 19451072
text data bss dec hex filename
1022 0 34 1056 420 bistro-biscotti-attiny13.elf
1036 0 34 1070 42e bistro-biscotti-attiny25.elf
1040 0 34 1074 432 bistro-biscotti-attiny45.elf
1040 0 34 1074 432 bistro-biscotti-attiny85.elf
410 0 37 447 1bf bistro-battcheck-divider-attiny13.elf
426 0 37 463 1cf bistro-battcheck-divider-attiny25.elf
430 0 37 467 1d3 bistro-battcheck-divider-attiny45.elf
430 0 37 467 1d3 bistro-battcheck-divider-attiny85.elf
1748 0 42 1790 6fe bistro-bistro-HD-attiny25.elf
1752 0 42 1794 702 bistro-bistro-HD-attiny45.elf
1752 0 42 1794 702 bistro-bistro-HD-attiny85.elf
1732 0 41 1773 6ed bistro-TAv1OTC-attiny25.elf
1736 0 41 1777 6f1 bistro-TAv1OTC-attiny45.elf
1736 0 41 1777 6f1 bistro-TAv1OTC-attiny85.elf
1158 0 38 1196 4ac bistro-BLFA6_EMU-attiny25.elf
1162 0 38 1200 4b0 bistro-BLFA6_EMU-attiny45.elf
1162 0 38 1200 4b0 bistro-BLFA6_EMU-attiny85.elf
1696 0 38 1734 6c6 bistro-classic-attiny25.elf
1700 0 38 1738 6ca bistro-classic-attiny45.elf
1700 0 38 1738 6ca bistro-classic-attiny85.elf
1658 0 37 1695 69f bistro-trippledown-attiny25.elf
1662 0 37 1699 6a3 bistro-trippledown-attiny45.elf
1662 0 37 1699 6a3 bistro-trippledown-attiny85.elf
454 0 38 492 1ec bistro-battcheck-Vcc-attiny25.elf
458 0 38 496 1f0 bistro-battcheck-Vcc-attiny45.elf
458 0 38 496 1f0 bistro-battcheck-Vcc-attiny85.elf

So it's turning into a firmware factory. I'm not sure if there's actually any difference between the 45 and 85 versions. I guess I could diff them and see. There's no difference in the code (there is for the 25 though).

Updated: added battcheck builds to the list.