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

I've had about zero time in the last week and won't likely have much for another week, but I think little by little I've made the e-switch bug become apparent. Flashy Mike was actually right I think about watchdog timer but I think for the wrong reason (not entirely sure). Watchdog timer certainly doesn't reset just because interrupts are disabled or are not implemented. That's only if WDE is set to 1. But if wdie is set to 1 without setting wde to 1, it's in a purely interrupt mode without reset, or it certainly is according to the manual and to anything you can read about it. And that must be true because I used interrupts that did not reset the watchdog and that fact is required to explain the later parts.

However after some sequence of events I believe that the watchdog reset was somehow arming and tripping. There were a few things I had not understood about the watchdog reset (because I never intended to use it) or might have understood that sooner.

A) The watchdog prescale register gets reset to 16ms. I guess that's obvious, it's a full hardware reset, but I hadn't considered it.

B) The wdrf (watchdog reset flag) gets set in mcusr and causes the watchdog to be automatically armed on next start.

Then since my watchdog interrupts don't reset the watchdog, it dies again in 16ms. Initially this seemed just like locking. After building a minimal test case that happened to get the light on faster, it istead made a low pwm strobe. Then when I clicked the switch, it would seem to react and light correctly briefly, on short press and for quite awhile after restarting from long press off. Well my switch interrupt resets the watchdog timeout too 1/4s on short press for 1/4 sleeps and to 9s on long press. So it temporarily extended the timer. the 9 seconds really confused me because it would step through some code with no branches and suddenly just strobe again (reseting prescale again upon restart).

So it all adds up now except for one thing. Why is it triggering in the first place? And do I care? I cannot find any answer for that. Presumably something is writing to wde but only very rarely. The chance of it happening does seem to depend on random code variations, things like the length of time that interrupts are disabled for example. There is absolutely nothing in the manual that says a truly empty interrupt is required in interrupt mode or that missing or delaying interrupts should arm the watchdog if wde wasn't already set (this happens in combined interrupt/reset mode but not interrupt-only mode).

I find it hard to believe I have some corrupt runaway pointer that finds its way all the way down to the watchdog register and doesn't clobber a whole ton of other stuff first, and I see no sign of it on the simulator.

Still I'm assuming that if I do one or a few things, reset the watchdog in the interrupt, or clear wdrf on start, or both, that the problem will go away or at worst become a very rare misread click.

I'll give a shot soon. Sure would like to know the root cause though.

For what it's worth the manual does instruct one to do these things, but it also says basically to protect from runaway pointers or brownout corruption. Could I be seeing brown out corruption? on the attiny85 switch light? How? Or on the low voltage OTSM mcu with BODS? It doesn't make sense.

At this point I don't think the hardware debugger will help. I don't think there's a way to get a stack dump just prior to a watchdog reset.

Flintrock, thanks much for documenting this stuff! It’s not only to our benefit now but also for those to come. :slight_smile:

Well sadly this watchdog stuff is written up a ton of places, but it's just always confusing. I've read all those places and if I was struggling with it, (I was) I wouldn't mind having one more experience yet to read. I didn't add anything that isn't known, just maybe known things that still weren't obvious to me.

Everyone’s experience, method and perspective is different. The same diversity can be found in the learner. Documentations like this help bring together the two that mesh. To some it will be a bore and to others a bookmark. :slight_smile:

So I found it, there was a very tiny race in how I setup the watchdog, and just in those latest e-switch versions, although I find that I'm not resetting the zero time well in the earlier versions too, so this should also improve click time stability. The race was almost impossible to hit normally but some loop phase maybe made it more likely.

Anyway, the e-switch bug seems gone, so have to package a new version, do a bit more testing on non-switch again maybe, or maybe just release it as beta for now so long as it works on Q8.

Posted version 1.7

1.7 Q8 e-switch build now working and tested (with indicator). It’s long-press off.
Presently comes on with battery connection.

(More Fet+1 drivers can now be easily configured).

Improved click-time stability (maybe, nothing noticeable)
Includes TA e-switch build with dividerless read and indicator (wired to pin 7). (untested)
Includes a build for the dividerless 15mm OTC board.
Double-click autoflash scripts. Linux Makefile.

Many code improvements (including some aimed at portability). See CHANGES.txt in download for more detailed changes.

Dual switch builds should work now, but only fully tested e-switch build is the Q8. A dual-clicky switch just kills power. Every build must work when power is restored clearly, the only question being what they do on power on and if they also handle timing of some kind on the clicky switch

The new autoflash scripts allow flashing just by double-clicking a hex file (assuming of course your usbasp is hooked up). You first need to associate the appropriate bat file included. To do that, right click on the one for your chip and run as administrator. It will associate itself as the default program for opening hex files. Then just double click a hex and it flashes.

You may want to edit the bat file for fuses you like, but the included ones should work with HD. Although actually I should double check the attiny13 fuses.

The Makefile also works in linux now, so there's auto-building and auto-flashing all around. For the linux Makefile, I just downloaded the toolchain from here:

https://www.arduino.cc/en/Main/Donate

And unzipped it into / without installing it.

There seems to be another toolchain package availabel from Atmel (probably the more normal one), and if you use that or even just a different version number, you'll need to edit the Makefile paths to point to it. I will probably update the Makefile to point to a more normal Atmel installation soon. That's just the first link I found for whatever reason. I don't usually compile in linux, but it did work.

Flintrock, I must apologize. All this time I have stayed away from hd as I assumed that it required otsm for each build. :person_facepalming: I guess it’s obvious that it’s not but it simply never clicked. Even while reading the words over a number of times I didn’t get it. So, ive has parts for otsm for a while but now that I know I don’t have to figure out the hardware, hopefully I can finally give it a try. It will help a lot if I can learn to use hd and your make files. It could save a lot of time!

Apologize? You have not harmed me, lol.

In fact the OTSM builds are the centerpiece, in particular the OTSM TA triple. Other builds are usually less well tested, and have been getting attention little by little. I try to test all features, and for the most part combining them in different ways shouldn't really cause issues, but there's always a possibility. Until now, none of the switch builds were well tested . At this point I hope the dual switch configurations work and I plan to bench test soon.

OTC has certainly had some testing, although not since many versions back. In principle nothing has changed with the OTC code.

But, yes, the build and configuration platform is a big part of what I've tried to make HD about. It has very easy to use compiling scripts I hope and then once that makes a person comfortable, it is hopefully also very easy to get more brave and try to change the configurations files a little.

One detail I've just become aware of is that bistro had soft start by default and having started with the TA configuration of the code, I don't think I ever put that back into bistro-classic-HD. But that's a detail.

I’ve found soft start to be “choppy” in about 1/4th of my builds. Don’t know what makes the difference.

So, foot-mouth, I may have detected minor debouncing issues occasionally on e-switch (I think it's debouncing, some other click sequence logic was also changed so I'll review it). This wasn't happening just before release but I did change the debouncing time at the last minute with only quick testing. I thought it would save a couple of bytes. Actually it wasn't necessary for saving bytes anyway, but then I left it because I thought it was enough anyway. Probably just a matter of bumping the stabilization time back up around 50ms, as previously advised and tested. Things are working pretty well, certainly well enough for people who want to try it, but I do occasionally get a short click interpreted as medium on e-switch.

Posted version 1.7.1 see OP for link.

1.7.1

Polishes some claims in 1.7, particularly click timing stability.

Now solid e-switch click interpretation even when clicking furiously.

E-switch timing sped up slightly, long click off now only 1.0s. medium click threshold reduced to 0.375. That could be too low on forward-clicky OTSM lights but is nicer on a lightweight e-switch like the q8.

Adds "fetonly" single channel (PB4 pin) OTSM builds with TA's triple modegroups mapped onto one channel. These were planned for awhile but particularly inspired by Schoki's boost driver plans, which should maybe work with the OTSM-LDO-fetonly build.

I have not tested this one on my OTSM light yet. No changes made to the OTSM code though since 1.4.1 really. Once I get that tested, hopefully this version can get upgraded to "stable".

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