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

Have you tried 4-channel PWM on hardware?

I got it working in FSM, but the 4th channel is inverted and I haven’t found quite the right tweaks yet to un-invert it.

Yes, I tried it, although I don't promise that it works in precisely the latest build combination, but the code for it should be fundamentally fine. Yes I definitely had inversion problems at certain stages of developing a solution at least. This is precisely one of the biggest cases the simulator came in very very handy. You can step through tick for tick and watch what the timer ramps and matches are doing and see when the interrupts get called, and watch your portb values.

I don't recall all the details now, maybe it will come back to me. Just looking quickly at my code, it seems I set portb on compare match, and clear portb on max. That does sound pretty backwards and even seems contradictory to my not very clear comments for the interrupts, and I kind of recall being temporarily((and now again) confused by this. I'll see if I can get a chance to run the simulator in the next few days and try to remember what's going on.

Mostly unrelated, but the biggest problem in the end was getting the light to shut off. Again I forget the details, but there is some delay or jitter in the interrupt calls that makes full off not happen. So I passed a global (actually a general purpose register bit, to facilitate streamlined assembly interrupts) to the interrupt handlers that disabled them entirely for mode 0. I didn't test extremely low modes extensively. As I recall the timing error on the simulator was around 6 timer ticks, but the simulator runs I think at 1MhZ, so one could hope that's about 1 tick in the real world.

Wish I could remember this better, might soon.

I do seem to recall that my timer is counting down, not up, and that does explain the backwardness. The thing I don't remember is why it's counting down. I think this is configurable right? So did I configure it backwards for a reason? I don't recall.

Update: Well, I just ran the simulator, and it's definitely counting up (and the manual says it should). So ... hmm.. So let's define the question better. Did you copy my implementation and that's inverted or did you re-implement it and yours is inverted? I've got a test rig read to flash and can test this again very quickly as soon as I get to it. It turns out I'd forgotten, but the modegroups included do include a 4th pwm for testing still, so it's ready to test as is. I'll give a shot again soon.

In the end though, if it's inverted, reversing the interrupts is clearly the cure.

I implemented it last month sometime, and didn’t know you had one until yesterday. I’ll have to check how yours works and see if it resolves the issue I ran into. The inversion isn’t really a problem though; it’s just inconsistent compared to the other three channels. A bigger problem is that the lowest few levels appear less stable, but it sounds like you ran into something similar with inconsistent timing.

For my purposes it’s still fine… but if there’s a way to improve it I’d like to do so.

Yeah, I'm starting to wonder if the header file has the interrupt vector numbers swapped. It's worth a look at the header or the proprocessor output to see. No reason to stay inverted though. Just swap the interrupts.

I tried to compensate the low-level timing error and failing. In the end, the off-override was the way to do it. You save quite a few bytes by keeping these interrupts in carefully crafted assembly that doesn't touch any registers, and getting the override variable to work with that was fun. The trick is that if you use the machines gpio registers (which aren't normally used for anything) that you can do conditional logic with them without first copying them to working registers (which would clobber something in the interrupted process, which would thus need the usual full stash and restore mechanics the compiler performs).

Well, the header is fine. It's also possible that my interrupts are just backwards and broken now. In the end I used timer1, non-phase, which should be pretty simple.

So funny enough, my interrupts were reversed. I think I know why now too. I remember switching this from some testing last minute and thinking it seemed wrong. It was, that test was flawed too.

Anyway, I'd never tested with a proper driver (just a resistor from the mcu) until now. With a 7135, I just tried a moon level of 4/255 at 16khz. It works fine. I didn't test down to 1. 255 works too and everything in the middle. So I'll be swapping the interrupts back as they should be in the next release.

In the end though, no, there's nothing inverted about it. It works the way I'd expect it to (which just happens to be wrong presently).

version 1.4 posted,

* 1.4 Enhancements:
* Applied TEMP_STEP_DOWN to all configs as default now, replaces bistro thermal regulation.
* Added an eswitch-TA-HD build (hunh.. why wasn't that there before?). Experimental single e-switch build.
* ALthough dual-switch-noinit should also work on a simple e-switch light.
*
* Added safe_presses to dual-switch-noinit-HD
*
* 1.4 Bugs fixes, cleanup, etc:
* Fixed bug in 4-channel PWM.
* Fixed bug where fast presses wouldn't time-out in a strobe mode.
* Fixed mode_idx initialization when FIRSTBOOT wasn't used (Kfulton's BLFA6_EMU random-mode bug, first exposed in 1.3)
* Arranged for safety check to prevent corruption etc from potentially resulting in getting stuck in non-existent override mode.
* No code-size cost for this check! Corruption may still cause an un-predictable brightness level, but will reset on next short-click.
* This is actually a secondary guard for the BLFA6 random-mode bug and other similar problems.
*

Hmm I got drivers with odd behavior

it has extremly low timing for the medium press
ist almost impossible to do short clicks

I checked the 47uF voltage it falls slowly when the switch is pressed
also all parts were checked and the solder pads soldered by hand again

Then i tested another Driver with v1.4

It seems the newer versions of OTSM hex make this
the old v1.3 from march works well

Thanks for the feedback. I found the problem. I accidentally sneaked in an incomplete part of a new feature that I thought I'd commented out. Simple fix. I'll release an update 1.4.1 along with a new 1.5. In a few minutes.

This actually confirms to me that I should finish that new feature. I actually almost like this new timing (it's exactly twice as fast for short-med threshold, although it wasn't exactly meant to be). The new feature is supposed to allow it to be right in between those two speeds without losing much cap time. Of course the actual speed would still be adjustable, just more resolution for the adjustment. Well no complaints about the old timing, so probably not a priority still. With twice as fast I could just BARELY manage a short click with double-clicks, if I tried very hard. To me, that's almost perfect, but a little too fast.

Posted version 1.4.1 (just fixes the timing bug) and 1.5 (fixes many bugs in e-switch build). I tested timing on both, they're working much better.

Dedicated Q8 build

Updated to 1.6 with addition of a dedicated Q8 build with a new layout, customized mode ramps and an indicator. Tested on a Q8 mockup. I'd consider 1.5 more stable at the moment for other builds. Please try 1.6 though.

/* Latest Changes
*
* 1.6 Enhancements:
* Includes Q8 specific eswitch build for FET+1 and indicator LED "bistro-eswitch-Q8-fetplusone-HD.hex"
* Ramp matching is designed specifically for the Q8
* Light is off with switch pressed. Long-press off. Indicator/locator acknowledges off press.
* Adds a new Q8 layout and adds the INDICATOR_PIN layout define, and USE_INDICATOR config define.
*
* Bug-fixes : Fixed corner case that would cause high off-drain in dual-switch OTSM config.

Instructions for single-point "Internal" read calibration using battcheck.

I kept meaning to add the math arithmetic to the comments in fr-calibration.h, still didn't. The issue with calibration is that the voltage references on these chips have a big tolerance.

But to calibrate the inverted ("internal") READ_VOLTAGE_FROM_VCC method used on 1S OTSM builds, you can run the battcheck with a full battery and it will flash out an adc reading, let's call it R

example strobe.. 7 ... pause strobe : R = 70

strobe 7 ... 2 strobe: R = 72

The goal is to get the internal reference voltage (which I should probably just flash out, but...), so

V_ref= (Vbatt-0.2)*R/255

R is the ADC readout and the 0.2 is a correction for the diode and may depend on your diode.

So that's it, get R from battcheck on a full battery and use 4.2 for Vbatt, plug into your calculator and you have Vref.

Place the Vref value in fr-calibration.h (#define reference_V) , and recompile.

So for example if you had a 4.2V battery and battcheck flashes 75 you get

V_ref= (4.2-0.2)*75/255 = 4.0*75/255 = 1.176 V

I will add this to the manual and comments for future reference.

Regarding the Q8 build. Staring at it and observations about the light a little, the modegroups are maybe tilted a little too much toward the low side. The ALL7135 equivalent is set at about 15% of output, and it seems like it should be closer to 25 probably. Also modegroup 17 has two equal modes, oops. I'll probably either bend the ramps or modify the modes a little to fine tune it for the Q8.

Posting here for those following. The Q8 build is still untested, and the first problem is found. It's setup for a voltage divider but the Q8 doesn't have one. It's a 4 keystroke fix and will be in the next release. That release won't come until after I get a chance to test it in an actual Q8.

If anyone playing along compiles themselves the fix is just to comment out the divider read option and uncomment the vcc read option in the Q8 config, and recompile.

I ran into problems with v1.5 on 1S boards
one 1/3 drivers the timing worked, the 2 other did not work medium presses

Thanks for testing it and for the feedback.

So you've got the exact same software and different hardware and you think it's a software problem?

It's not completely impossible for that to be true actually, but it's far from likely.

Do they all work on older versions? You are using a different cap from me, and for the small LDO boards you're not using a diode, something I've never tested myself and it depends on the LDO quality as you've seen. Is this an LDO build? Does it have a diode?

It's possible that you're right on the edge with your hardware, and some work and some don't. Watchdog clocks have a little variation. Capacitors have a little variation (20% actually for yours), etc. My hardware has TONS of room to spare, but if your hardware is marginal, then this can happen.

Have you ever gone through the exercise of determining how much extra cap time you have? Voltage measurements are one way, but the most reliable is to use the OTSM-debug config option and compile.I probably should document that better, not that anyone will likely read it. Then on every click press it will flash out the number of sleeps that occurred. For long presses you'll either get the number or a 255(or maybe nothing instead of 255). No blinking at all or 255, means it lost power. A number (in quarter seconds) means it was still going. So you can see what the longest click possible is.

Did you try them with an earlier version? Even if the answer is yes and they worked, it doesn't change the possibility of things being right on the edge, but it gets more interesting. I have tested timing on 3 boards with >1.5 builds and they all work. 2 of those were OTSM and one was e-switch, which never runs out of power. Anyway, let me know if and which earlier version worked.

If you're using different hardware though, you really should go through the exercise of running that test.I haven't invoked that config option in awhile, so let me know if it's not working. There's a chance the debug blink-out got moved to early with some changes.

All this said, there is a known bug (that I'm zooming in on slowly I hope) that causes very occasional instability, that was introduced somewhere recently I think, I'm guessing maybe between 1.4.1 and 1.5, but, although it does present strangely, never anything remotely like what you're describing. Still if 1.3-r2 works for you, great. (I may re-post it soon).

I'll take note though and keep an eye out for poor timing performance.

it was normal 1S builds
same hardware as usual

flashed v1.3 on them after v1.5 failed and it worked flawless

I did one v1.3 on 2S with diode after the LDO and it worked fine

hmm,

Same hardware as usual still doesn't tell me if your hardware is on the edge of working or not though.

How does 1 work and 2 don't? It's the same software. It's very strange. If they all have room to spare, that would be interesting to know.

However, 1.3-r2 is still the most stable build for basic OTSM and I'll repost it when I get a chance. Maybe when I fix the other bug we'll see if it fixes your issue too. I don't see how, but I don't know.

I'm zooming in on the other one.

If you feel like flashing 1.4.1 (not the same as 1.4) and seeing how it goes that might be helpful too. There was some re-arrangement of the timing code from there to 1.5 and 1.6 to make it more readable. But it’s still hard to read too much into any timing test without really knowing for sure what the hardware is able to do. Measuring sleep time capability of the hardware has been the standard benchmark for everyone trying OTSM hardware development from the start. It’s not that I’m saying your hardware is bad either, it’s just a matter of pinning things down and ruling things out. We’ve got a matrix that looks like this

                    Hardware:  1                   2
Software:                        
   A                              works            works
   B                              works            !works

And then I’ve got more hardware in category 1, three of very different builds.
So is that a software problem or hardware problem? I just don’t know.