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

Version 1.7.1 now tested on OTSM as well. No problems showing up and in principle, even on OTSM it should have a little more stable click timing than 1.4.1, and of course it works on e-switch. As always feedback will ultimately tell, but 1.7.1 is now the version I would recommend to try.

Updated to 1.7.1 in the repo.

I got here a request for Bistro using just 2 channels for´1+1 AMCs

I got first tried to just replace the channel use for the 20 brightness levels
It works in modes, but when going to special modes the Turbo does not light up as it seems to be programmed somewhere else not using the 20 levels

Then I tried to bridge FET output to the AMC channel, the chip does not like it breaking normal operation

Then I tried to change to 2 channel output in the TA config file and get the modegroups again changed, but it still does not use the pin 6 for FET output

First, merry Christmas. Turbo uses the 20 levels even in hidden modes, but obviously you've got something not quite right. It sounds like something I could look at pretty easily, and actually there may already be something pretty close in the latest 1.7.1 release which does include a FET+1 build or two, maybe not on the channels you need. I'm a bit pre-occuppied with the holidays for a while though. That might mean I get time to think about it soon, or might mean it takes a couple of weeks, not sure.

how would i go about using bistrohd otsm on a ta fet+1+ board without the fet?

I mean no FET on the board. Just 7135’s.

A pretty simple way would be to start with the “modegroups-TA-triple-v1.3plus.h” modegroup definition and edit the ramp matching your FET to all 0.

this wont work if you do not copy the ramping tables for 1 and all AMC from 2 Channels to 3 Channels as well as edit all FET to 0

Has someone a project that produces working hex files?

I downloaded several versions but making an Atmel Studio 7 project and compile a hex does not work on the driver

Yes, today I ran a build for TAv1 OTSM, flashed it, and built a light. Works great! I really like the new thermal system.

Its the HD OTSM build did you had your own atmel studio or use the existing hex files?
if so I need the atmel studio project

I ran my own build, since I customized the modegroups and default settings. Here are the steps I followed:

1. Install Atmel Studio with default directory. When prompted, select only the 8-bit option.

2. Extract bistro-hd archive to temporary directory, then move main folder to c:\firmware\HD

3. In Atmel Studio, start a new project with default settings (C/C, GCC C Executable Project). When prompted, select ATTiny25.

4. In the Solution Explorer window on the right side, right-click main.c and click remove. Then right-click GccApplication2 (or whatever your project is named, it’s the line with the yellow page icon) in Solution Explorer and click Add->Existing Item. Select C:\firmware\HD\bistro-HD.c and click add.

5. At the top of the window, click Build -> Configuration Manager. Then change “debug” to “release” on that screen, you might need to change it in two places. Click Close.

6. In Solution Explorer, right-click GccApplication2 and click Properties. In Build->Configuration, make sure Active (Release) is selected. Check the box for Use External Makefile, then Browse to C:\firmware\HD\Makefile and click Open. Then click the Save icon (or press Ctrl+S).

7. At the top of the window, click Build -> Build Solution. Check the Output window at the bottom of the screen, especially for the avr-size output. ATTiny25/45/85 has 2/4/8K of memory, so make sure your build fits. The resulting files should appear in C:\firmware\HD\hex and should work when flashed.


Here are the options I use for avrdude (I always erase manually even though it does it before flashing):

avrdude -p t25 -c usbasp -e -u

avrdude -p t25 -c usbasp -u -Uflash:w:FILENAMEGOESHERE.hex:a -Ulfuse:w:0xd2:m -Uhfuse:w:0xde:m -Uefuse:w:0xff:m

Total facepalm moment, I just now noticed the “Atmel Studio 7.0 Command Line” shortcut. New, better build instructions, no solution file needed:

1. Install Atmel Studio with default directory. When prompted, select only the 8-bit option.

2. Extract bistro-hd archive to temporary directory, then move main folder to c:\firmware\HD

3. Open “Atmel Studio 7.0 Command Line”. Type in the following:

cd \firmware\HD

make all

1. Install Atmel Studio with default directory. When prompted, select only the 8-bit option.

what means 8 bit?

Apologies, I should have specified that I used the web installer instead of downloading the full installer. When you run the web installer, you get a pop-up that asks which devices you want to install support for. There are three check boxes, and 8-bit is one of them. If you aren’t getting that prompt, it shouldn’t be a problem for compiling, it just means it will install more than what you need to get the job done.

I just wanted to say thanks for such useful and well documented firmware!

I got further testing with 2S builds

The Battcheck and LVP does not work properly
at 8.4V I get 3 and 7 blinks for 3.7V
at 7V I get 3 and 9 blinks for 3.9V
at 6V again 4 and 2 for 4.2V

2. driver
8.4V—>3.1V
7V—>2.6V
6V—> 2.5V

4 years ago, and I suppose you either worked it out or didn't, but I will point out a couple of things for reference anyway. Basically presently the voltage monitoring and battcheck system are based on 4.2V so it's voltage per cell, not total voltage. 8.4 should flash as 4.2. That said, it's still wrong, but for that you just have to calibrate. There are "battcheck" hex (different from battcheck mode) built for every configuration that when flashed and used with a full or partial battery provide the corresponding ADC values. This helps (often trivially) with adjusting values in fr-calibration.h. That's all documented in the first post, although if the full battery value is pegged (255) you may have to extrapolate its effective value (above 255) from lower battery readings. It looks like this was the opposite problem, which I think was unexpected for a properly built 2S (and maybe problematic), but I haven't thought about that in too long. I do know that with well chosen resistors I never needed to calibrate 1S builds. Anyway, aside from that, for the calibration being too low it's just a matter of entering the number from the battcheck hex result in the calibration, or just correcting proportionally by hand.

It's possible to get the UI to flash total voltage. The simplest way is to just adjust the voltage_blinks table in tk_voltage.h by 2x and otherwise keep things internally as volts/cell. I suppose a config option could be added to multiply the blink table, but it's not there now. Anyway ADC_LOW is presently set in fr_calibration.h to 28 (2.8 volts) so it's based on a single-cell calibration, not total. Of course that could be changed too to make everything referenced to total voltage, but I don't see the point in doing that. For that matter, I wouldn't adjust the blink table either. Just unerstand that the battcheck mode flashes Volts/cell.

I'm recalling my previous thoughts on this too:

https://budgetlightforum.com/t/-/46073/363

"2S are also the only ones I see as potentially truly calibration free, assuming the LDO has good specs. inverted, or "Internal" read, divider-less 1S still uses the 1.1V internal reference (so does the normal method not referred to as "internal"), but on 2S you can reference the LDO. "

Yep, right, using

#define REFERENCE_DIVIDER_READS_TO_VCC

As my included LDO configs do... gives you a more stable voltage reference than any 1S build. OTSM builds require using the max range on pin7 (voltage sense pin) to stay above the pin change spec at low battery voltage* (pin change triggers an interrupt). So if 1% resistors are chosen correctly for R1/R2, there should be no calibration needed at all for LDO builds.

* From the manual:

For a multi-cell(ex: 2S) light, Vcc will be powered by a regulator and cannot be used to read battery voltage. If a 3.0V LDO is used, then the highest shutdown trigger level on the voltage pin is 1.8V or0.6*3.0. If we reference voltage reads to Vcc the max we can read is is 3.0V. Conveniently 2.5V is 0.6* 4.2V so a typical battery operating range just barely fits in the available headroom. Resistors must be selected in 1% tolerance so that max voltage corresponds exactly to 3.0V** or maybe 1 or 2 %less. The voltage should be read from the divider and the option to reference divider-reads to Vcc should be set, since these voltages are necessarily above the 1.1V internal reference.

** Actually 3.0V minus the diode voltage, if any, to be exact. Details on that are in the manual too, but it's a small correction.

A lot of rumors of buginess came from Lexel's experience or words. He PM'd me about a similar problem on a FET+1 (which is a similar config) saying basically "look, here are my ramps, the TURBO level (20) is set to 255, why doesn't it work." Except his 7135 channel had 20 entries, but his FET channel only had 19. The 255 was NOT on entry 20. It was on entry 19. Entry 20 was undefined and probably zero initialized or even random RAM. So of course it didn't light up. I suspect that was a cut and paste related to the same error in the post. He's also gotten resistor values wrong on other builds as above for 2S. There's a big difference between using a pre-built ROM and modifying your own. In the second case you do of course have to not make mistakes. They happen, but then in multiple threads he accused my bistro-HD of being a pain to use and such without saying why. Customizing firmwares is indeed harder than counting to 20, but counting to 20 is a start. He also had trouble compiling when others did not, and had a habit of blaming HD for his mistakes.