"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."
I guess I need new chips . All the 25's I have from MTN are the 20SSU "high voltage" variations.
RH you can try it. I'd recommend reducing the divider resistors to 500ohm total or adding a 500ohm bleeder, and don't cut corners on the cap. To be honest, I suspect you'll get by with it. At worst, you might have trouble getting medium presses when your battery is at 2.9V.
There is the potential corruption issue. Mike C says with the chips running extended times at low voltage he can verify EEPROM corruption. For awhile this bothered me, and I've seen some comments of lights misbehaving that do smell like corruption, but I can't actually see how eeprom corruption breaks the light. That's just configuration values, things like is memory enabled or not. The main menu should operate regardless of what the eeprom state is, and you should be able to get to reset, but I'm not 100% sure that some corner case can't break something. And is it possible to corrupt program memory? Again, I'm not sure. I have seen the non-V chips just occasionally do strange things when in very low voltage, with improper BOD setting, like lock up in a high current state, and so you may just get that the clicks occasionally don't work.
The specs documented are safe, but I'm sure over time people will figure out what they can get by with.
By the way, there's presently a known bug where turbo tap up doesn't work in the biscotti-HD build. Will be fixed in next version. Those features will move out of the untested category.
I have a draft of options for all 2-switch combinations including LEXEL's dumb click switch (his option 2). Some testing to do. Nothing posted yet, plans for next release are in OP.
-ESWITCH menu lockout didn't work, maybe fixed it, took a stab at it anyway, but no testing. Never was sure I liked it anyway.
-New TA v1.3 modegroups are included. I've also added 1 old mode from original and one hybrid of my own. The modegroup file for details, the extra modes are not well documented yet.
-OTSM_powersave which is not only for OTSM, is now available to save power on attiny13's too now (4mA to 2mA for on-current if similar to attiny25).
-New temperature step-down option, like BLFA6 turbo timeout and tap up, except the drop down is temperature-triggered. A minimum (not max) time in turbo is set to 10s by default.
-Both the minimum time and the level to step down to are configurable. All levels above that will get thermal protection (except strobes, in bistro way, reading temp is too slow to work with strobes).
More space savings, about 50 bytes, but this was mostly re-used by the new thermal stepdown and added modes.
-Trying to clean up cap-timing section and comments, adding clear preprocessor sections for every possible switch and timing combination.
1-switch: no_init, OTC, OTSM
2-switch: Eswitch + nothing, no_init, OTC, OTSM, or lexel mode.
-Dual switch noinit has a better chance of working correctly now (no eswitch or dual switch lights have been fully tested).
-Dual switch OTSM is discontinued for now.
-Dual switch dumbclick option/build is added. by request of Lexel, the power switch does nothing. It comes back on in the same mode it went off.
- Dual switch turboclick option/build is added. Variation of lexel request (that I like), power switch always comes on in first hidden mode (typically turbo).
Ideas for farther ahead:
Try shortening medium click in OTSM, may require adding finer timing resolution for all times, or possibly just early times. (has a cap performance cost, but it's performing better than needed now).
Maybe rework dual switch stuff so every click type can be given assigned an action type in the configs. Hard to keep the programming tight, and clean, but avoids endless options, I don't have a full vision for how to implement it yet, many details.
In particular considering reverse click order for power switch, maybe separately from above plan.
Here are the present build sizes, not updated in the manual:
Minor updated posted (see OP) to 1.3-r2. The code is not changed. Just added a one-click bat file buildall-AS.bat. If Atmel Studio 7.0 is installed in the default directory then double clicking that file from the windows file explorer will re-compile all hex files, which can then be found in the hex/ subdirectory. Editing the file : Makefile in any text editor you can find the ONEBUILD option, remove the # comment sign and define a single configuration to compile instead of making them all.
This is intended to allow compiling with the Atemel Studio 7.0 "toolchain" but without needing to actually import the project into Atmel Studio. You can still edit files with Atmel Studio, or with any other editor (Notepad, Notepad++, or whatever).
The one downside is build errors are not presently parsed. You'll be able to see them in the output window though, possibly requiring scrolling up.
When I compile this in Atmel Studio, I get a different (slightly larger) filesize from the pre-compiled .hex. Compiling in WinAVR gives yet another (even larger) filesize. Any idea what I might be doing wrong? Or does it even make a difference?
Short answer - Windows sucks. Texas_Ace was the first one I saw mention this, but someone else may have noticed it earlier. Compiling in Linux results in smaller file sizes.
The -Os in the makefile C_FLAGS overrides the settings in the solution properties screen. It won’t let you change any options in there anyway if you have a makefile selected.
I’m not going to worry about it. Tonight I’m getting started on building 6x 17mm TAv1 drivers for Bistro-HD/OTSM. Once I’ve got a board ready, I’ll try both .hex files (the provided one and the compiled one) and make sure they both work, and then move on to custom reverse and forward modegroups.
Hey friend, has the necessary component and layout changes require for otsm been illustrated somewhere? I’m not sure how to implement the changes to the ta boards. I’m sure it’s been discussed though, right?
The component changes are in THE_MANUAL.txt inside of the .zip file. I put together a quick cheat-sheet for myself (17mm, 1S, clicky), but have not actually used it yet, so I don’t know if there are any errors:
COMPONENTS —
U1: ATTiny25V
U2: SIR800DP
D1: RB751V40T1G
D2: none
C1: 1uF
C2: 47uF - 298D476X0010P2T
OTC: none
7135: AMC7135 (I’m going to use 350ma version)
R1: 1K
R2: 3.3K
R3: 100K
R4: 47
R5: 4.7
BR: none
edit: these values are all correct, I’ve built 6 drivers successfully
So apparently the tantalum capacitor for C2 (298D476X0010P2T) is polarized. As best I can tell, the anode needs to point toward R1/R2 on a 17mm TAv1 board. It seems to be working, but can you please confirm, Flintrock? Apologies if it is in the documentation and I just missed it.
This is funny, I see this over and over. A while back I consistently could compile Bistro in a smaller size under Atmel Studio than what TK could get under Linux. I passed along the compiler switch settings from Studio to TK, and she found an optimized setting in the Atmel Visual Studio setting she didn't know about, added it, then we matched.
I dunno what you guys are doin, but Atmel Studio works fully optimized, and great for me. Using it on a decent Win 10 system with a solid state drive and it's super fast, very easy, nice dev environment, lots of features in the editor, and believe, me, I've used a ton of dev environments.
Like I said, I'm clueless what your problems are with it. I've run it on at least 4 Win computers - no problems whatsoever.
Does anyone know the size of the latest v1.3-R2 version with the default config of "TAv1-OTSM-HD" for a ATtiny25?
I got text: 1818, bss: 41, dec: 1859, with a straight Atmel VS 7.0 build (latest version), standard options. Not sure if what's listed in the OP is this latest version.
Nothing special at all - put the files anywhere you like. I generally keep mine in one common folder since our drivers are so simple - might as well keep it simple . Only thing to understand is solution vs. project. A solution can contain one or more projects. Studio will want to create sub folders for each project, but I force them to be in only one common folder. For our use, I've only used one project per solution and name them the same. Our firmware is pretty simple compared to Visual Studio solutions I work on at work.
Even if you created a solution and project with the project in the sub-folder -- no problem, move all the project files in the sub-folder to the parent folder where the .atsln file is (solution file), delete the old project from the solution, add it again from it's new location and it all works fine.
Another important thing is to be sure you change the Solution Configuration from "Debug" to "Release". Debug turns off optimizations totally. All we want to use is "Release" since it's fully optimized. Once you change it to "Release", it's remembered and will default that way next time.
What I like is from right inside Studio, you can rename or delete files, projects, or even the solution. I like keeping all header files in the project since global searches/replaces will work thru the headers as well.
Basic Digikey cart with parts minus resistors since we will likely have them around. I am not sure that I have exactly the correct ATtiny25 in the cart…