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

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.

Come to think of it, actually the nice thing about having a real Makefile, is that you don't need Atmel studio at all, just the gcc-avr toolchain. This works from command line, or a batch file of course. This might simplify things for folks who struggle to get up and running with Atmel Studio, which is a bit of a pain actually for minor edits and compiling.

As Tom E made in his Narsil code, a minor change he got the function I wanted from eswitch light with forward clicky in tail
as simple he changed the startup to be on Turbo like it was in the original Klarus XT11GT light

Super. That should be a good solution for you. I'll probably look into these dual switch cases more soon though. They were the last afterthought in building HD actually. Anyway, your post and some others had me wanting to first organize things even better for many configurations. That's pretty much done. Making new configurations is relatively easier.

If you document those changes in a text file people can change the code themself as they need or add mire comments in the .c file

There's a whole bunch of comments already, more comments than code really, but almost any time I look at a code I read them and add more. I think the part of the code I pointed out to you is pretty well commented, especially being it's litterally the latest lines added to the code (that might not even remain the same), but suggestions for clarification are welcome. There can never be an instruction manual for everything anyone might want to do to a code. At some point you have to have look through the actual program lines and understand what they do. If you're not sure exactly what wake_time_med does, you press cntrl-f, type wake_time_med, and find every place it's used and see.

Anyway, this is more along the lines of something that I'll likely end up just including soon as a config option and possibly in a predefined build configuration. Most people will just use pre-configured builds or change a feature or two in the configuration. A big part of what I've done in HD is actually to make this all more clear and make the options all play well together again. Having the automated build helps keep that in control too, since the developer now sees immediately if one configuration fails to build.

I have two bugs/typos. That's good because it solves problems. One in particular may explain a bunch, certainly should break OTC in the original post. The error is

PORTB=~DDRB;

should be

PORTB|=~DDRB;

The difference is the first one disables OTC cap charging, which meant OTC builds probably didn't change modes at all, oops. I was only testing with OTSM at the end.

The other bug is

#define OPT_firstboot (EEPSIZE-1)

should be

#define OPT_firstboot (EEPSIZE-8)

could cause interference between reset toggle and muggle mode toggle. I'll probably post a bug-fix only build shortly, but I'm working on a much overhauled version with all new bugs ;) .. and need to get some of those sorted out, the ones I know about at least.

The OTC bug, may well explain the OTSM problems, as it means the OTC pin was floating, which can drain power during sleep, in random ways. It might explain it, or might not.

Well that did get the driver working properly in a normal OTC build, but it didn't solve the OTSM bug and in fact that code path wasn't relevant for OTSM. This really seems to be a hardware issue and is a mystery still.

At lexel, I've been working on a manual to go with the next release. This is a good process because it makes one think through things. I realized that actually you should get the behaviour you want just by building an e-switch only build, no OTSM or OTC enabled, preferably no off-time cap on the board. The clicking switch will obviously always "work" no matter what configuration you use. In e-switch-only, with a standard small C2 cap, the click time will always default to a long press on a full power-off.

If you don't use memory mode this means it will reset to the first mode, so you'd just want to setup the first mode as your signaling brightness. Or, you could turn on mode memory, and it will just always stay in the last mode, and you can signal in whatever brightness you want.

Normally many fast presses hit the menu, but that won't happen, because they will get interpretted as long presses. Only the e-switch will be able to access the menu.

Big new release coming soon with lots of good stuff, but I hope it's a little better tested this time (still will have much that isn't too though). I'll try to remember to include an e-switch only build for you.

Updated OP with new version.

Lots of new stuff including many build configurations (that you can pattern new ones off of) especially for all the bistro variants. Especially, it has a biscotti-HD build included with all the latest space savings and as a result some added features (specifically a more stable noinit method, and (untested) turbo timeout/bump-up, and room for you to configure in a couple more yet. More especially, at least some of it works this time. The TAv1-OTC hex and its battcheck are pretty well tested on attiny25 (everything except thermal calibration, haven't really tried to test that closely, but never messed with it much either).

I wanted to get the universal concept really flushed out and a bit more stable (many of the space savings techniques resulted in a bunch of changes to iron out) before pushing forward with advancing new features too much more, although there are some new ones.

OTSM is fixed. (OP updated) and is working perfectly on a TAv1 17mm light. I don't see any reason this shouldn't become the default setup for these lights. It's just so much better than OTC. As this TAv1-OTSM build is now really (was always meant to be) the flagship HD build, maybe I need a new name for it.

Below are some details about how to build it, also found in the Manual and the OP. In the end this worked so well that it's likely possible to cut some corners, like use cheaper ceramic caps. Personally I probably just wouldn't, but it may work fine.

VIII.1 Parts and build for tested TAv1 board

OTSM is working better and better, but getting it there required a combination
of software work and the best parts. It may be possible now to use cheaper or
lesser parts since OTSM performs a little better than needed with these, but
these are tested and work.

MCU:
It's required to have BODS support for the mcu (see theory below). From page 36
of the manual this requires:
• ATtiny25, revision E, and newer
• ATtiny45, revision D, and newer
• ATtiny85, revision C, and newer

[This note not in manual yet: Revision letter is lower left most letter on bottom of Attiny 25. I forgot on attiny 45 where it is, might be on top.]

The spec for OTSM also requires V version (10Mhz, low voltage version) chips.
You might get by without it, but it won't work as well and may cause
corruption.

Unfortunately most ATtiny 85s reported off the shelf have been revion B, for
the past many years even. They don't work. So far Attiny25, attiny25V,
attiny45 and attiny45 v's where reports exist on this, have been of recent
enough version. Of course attiny25V is available in the smaller footprint and
fits 17mm TAv1 boards. At the time of this writing all HD features including
OTSM can fit on an attiny25.


Diode part number: RB751V40T1G
http://www.onsemi.com/pub/Collateral/RB751V40T1-D.PDF

This is the MCU protection diode. It isolates voltage from the C2 cap that
powers the MCU while input power is down. It was chosen for its low leakage
even at high temperatures. Leakage below 1 or 2 uA is probably fine.

C2 cap (powers MCU during off time, quality counts here)

Cap part number: 298D476X0010P2T
http://www.vishay.com/docs/40065/298d298w.pdf

This cap was chosen to get the most capacitance in an 0805 possible and because
Tantalum does not suffer from DC bias de-rating or temperature fluctuation.
Capacitance this high (47uF) in an 0805 are all low voltage. For Ceramic if
the DC offset is more than about 1/3 of the rated voltage the capacitance
starts to drop, some times a bunch. This cap does have a large tolerance
though unfortunately.

Voltage divider:

Tested with R1 of 1K and R2 of 3.3K R1 should be no more than about 1/3 of R2,
but this ratio should be ideal for OTSM performance in a 1S light (but only in
a 1S light). Lower values can improve OTSM performance, at the expense of
higher mood mode drain. If you use lower quality caps or diode, you can try to
add a bleeder of about 500ohm to gain a little advantage on off time, not much.

OTC:
None, unpopulated.

C1: 1uF (see TA instructions for part numbers)

For all other parts, see the Texas Avenger instructions.

I haven't had a chance to read in detail yet, but this sure seems like some really exciting stuff you're doing here Flintrock.

Click click, whoo.. lol. Fun at least. Don't forget Mice C and flashy mike who took the early talk is cheap attitude to get this all going.

Version 1.1 posted (see OP)

Includes firmware for an LDO OTSM TA build. Latest Build instructions will be maintained in the Manual, and the OP, but the excerpt is below.

Also split the dual switch build into a noinit version and an OTSM version. The OTSM version is specifically targeted at lexel's "option 3", but an option 1 configuration should arrive soon.

These are not tested builds/firmwares, but the differences from the regular OTSM versions are fairly straightforward and those differences have each been independently tested. The LDO build should work. Dual switch, enh, probably. No guarantee or implied anything.

VIII.1b Parts and build for TAv1 board for LDO (2S, 3S etc)

Quick version:
See section VIII.1a for mcu, cap and diode selection.
Place the diode on the R7 resistor pad with the anode (+ side) pointing away
from C2. No OTC cap is needed. Use the following divider resistors, in ohms.

R1 R2
2S: 1780 2210
3S: 2250 1500
4S: 2870 1100

Should be 1% or better. Dropping R2 by 1% or 2% might help get full range of voltage read on the very top end and the risk of pushing the specs slightly at the low end. Not a big deal either way. The default calibration is centered around the values above though.

No bleeder. That's it.

For all other parts, stick with the original Texas Avenger instructions.

Long version:

For 2S or more build, the attiny must be fed power by some form of voltage
regulation such an LDO. This means that Vcc (input voltage) cannot be used to
measure the battery voltage. The divider must be used. Furthermore because
the divider pin must stay logic high to indicate power on, the 1.1V reference
cannot be used. The REFERENCE_DIVIDER_READS_TO_VCC option must be used (It's
compiled into the LDO firmware) This reads pin voltage as a fraction of Vcc
with Vcc being the max, allowing the highest possible divider voltages.

There's some difficulty here because a low battery, 2.5V/cell is 0.6 the
voltage of a full battery: 4.2V/cell. 0.6Vcc is also the maximum trigger level
for a pin change interrupt, which indicates a click and puts the light into
sleep. In reality the trigger level should be below this, but by spec it can be
this high. So we need the divider voltage to really stay as high as possible.
Furhtermore Vcc is reduced from the LDO voltage by the diode voltage. This
fluctuates slightly with temperature and current, so we need to estimate this
max voltage as well as possible. From the diode spec sheet a maximum diode
voltage of about 0.4V at 2 to 4mA is seen, but more typical is 0.35V and this
should be correct within 0.1V even when hot.

Parts:
Using a TA generation 1 (v1) LDO board, a diode must be added, the same one as
for the 1S configuration above. The diode can be added in place of the R7
0-ohm resistor. The same caps are used as for the 1S OTSM version.

The only other difference is the correct resistor values should be chosen. We
want a total resistance R2+R1= about 4kOhms. We need the voltage on pin 7 to be
equal to the LDO voltage minus the diode voltage, ie Vcc, when the batteries
are at max voltage, Vbm.

So the divider should be R2/(R1+R2) = Vcc/Vbm.
Following the TA build specs and the diode used here, Vcc is 5.0-0.35 = 4.65V

This gives R2 = Vcc/Vbm *4kOhm.
And R1 = 4kOhm-R2

here is the calculated table for various voltage levels:
R1 R2 Vcc/Vbm ideal:
2S: 1786 2214 0.5536
3S: 2524 1476 0.3690
4s: 2892 1107 0.2768

Of course these resistors don't exist, so we need to look for something close,
with the ratio being the most important thing.

R1 R2 Divider Error %
2S: 1780 2210 0.06
3S: 2250 1500 0.36
4S: 2870 1100 0.1

These should be in 1% tolerance or better. Any inaccuracy here pushes the
measureable voltage range up against the spec limits.

:+1:

So, please humor me… It looks to me like a normal AT25 driver such as the X6 driver could be converted to OTSM if the OTC was removed? Or am I making this way to simple?

You mean attiny25? I'd have to consider case by case, (lots of the details are explained in the manual). But generally it should be possible to convert one, so long as there's a place to put a diode between the voltage divider and the mcu input bypass cap and so long as the input bypass cap is at least an 0603 footprint (there may always be ways to squeeze past these rules with enough hacking/squeezing).

No, just removing OTC isn't enough. You need to follow the full parts selection above for diode, mcu bypass cap ("C2"), and divider resistors. I should make it more clear but the diode and cap for the LDO lights are the same as for the 1S. I also forgot to point out that the anode of the diode (+) should point away from C2, but I guess that's obvious. I'll add a picture shortly. You can surely find other components than the ones I found that will work. I've gotten tests working with very different resistor combinations too (for 1S, LDO has pretty strict requirements there), but not just anything will work, and you can be pretty sure the original parts won't work. The ones I list are what I know works. They probably aren't the cheapest, but figuring out how best to cut corners wasn't my goal.

I still need to stop and remember the issues with lighted tailcaps, if there are any issues.

Oh at the moment I don't know any way to make this work on a zener driver, not without replacing the zener with an ldo at least. The LDO is needed for the LVP voltage reference.

I’ve been trying to plow through all this information. It’s been a struggle but I know that if I keep at it I’ll eventually get it:)

It would be great if someone could write do a write up of the process. Kind of like comfrchair did here. That’s the thread that really got me going. Basically go through an example build and take photos/screen shots along the way. This is asking a lot though. And most who are capable of this have already done so much. It would be helpful though…

Thanks for all your efforts!!!