Unfortunately, we don’t have an e-switch… nor any way to store much info about button press sequences without putting a lot of gunk into eeprom. More complicated stuff will be possible with an e-switch or dual-switch host.
Can you read 3 quick presses with clicky switch?
I’m using a noinit variable to track how many times in a row the user has fast-pressed. It can count 3 easily enough, but that’s low enough that the user may hit it by accident while changing modes. The config mode triggers at anywhere from 16 to 31 fast presses, long enough not to happen during regular use.
So, quick press sequences are already implemented, but it has no way to track mixed sequences of medium and short presses. A medium press is long enough for RAM to decay, so it wipes out the noinit variables. That leaves eeprom as the only way to track it, which would require a lot more code (and ROM space) and would eat through the eeprom write cycles an order of magnitude faster. It’s a bit difficult to reliably get a medium-press too, due to the lack of feedback while off, and the temperature-related timing variations.
Because of these things, I’m not planning to implement mixed sequences without an e-switch.
I neglected to mention my rational. A lot of people seem to already have a preference when it comes to these config options. If you know what you like then you will only access a given config option once, if the default isn’t already want you want.
If the popularity of mode memory is 50/50 then regardless of what the default is, half of the users will be going in to change it. If the popularity of moon mode is 49/51 then the default should be whatever 51% prefers. And 49 out of a hundred users will be looking to change that config option.
What about people who don’t know what they like? Ah, ignore them! How could we predict how frequently they would toggle an option?
Muggle mode is the only one imo with the potential to be accessed semi-frequently by some users.
I see you switched the options around a bit in bistro 205, looks good to my eye. Of course it’s all a guess. 
I'm looking to purchase some 85v's, but there are a few different types.
http://au.rs-online.com/web/p/microcontrollers/7380690/
http://au.rs-online.com/web/p/microcontrollers/6962342/
Those two appear to have the shorter legs that can be folded to suit the 13a board footprint.
TomE, which one have you been using with your current e-switch firmware?
Cheers :beer:
- edit -
This is the filtered list of 1.8volt Attiny's that are available to me, including the 25 & 45's.
For tiny13 and 25, get the SSU package. For 45 and 85, get the SU package. It’s the closest available to SSU.
This should allow the chips to fit onto existing drivers and be flashed in place with a common SOIC8 clip.
Thanks TK.
I'm almost finished reading through this thread from the start;
I'm ordering some 85v-10SU's, & using TomE's files from post#304, I should be good to go, as long as my wiring on my clip is correct...
Sorry, haven't been keeping up with this thread as of late. I'm still working on my version - calling it: eswBrOutCfg for now (e-switch BrownOut w/Configuration settings).
The last 85's I bought are these: http://www.mouser.com/Search/ProductDetail.aspx?R=ATTINY85V-10SHvirtualkey55660000virtualkey556-ATTINY85V-10SH. I think I went with the SH because I tried the SU in the previous buy, so I thought I might have a long shot at programming them more reliably, but that was before I figured out the ground problem in my SOIC-8 clip wiring.
SH are matte tin leads, while SU are NiPdAu leads. Not sure if one is better than the other for our application of soldering - I use lead based solder. I'd say go with the cheapest, but dunno -- one may be better... I see Richard is selling SU's for the 25 and 85 - great prices, but not the "V" lower voltage spec version.
The config settings are pretty awesome. I changed the order around, hopefully for the better. 1 thru 6 now makes a whole lot more sense. Here's what I'm using now:
Mode Set Order |
Mode Count |
Mode Percentages |
Notes |
1 |
1 |
full only |
(full is always max FET, no 7135) |
2 |
2 |
10-full |
max 7135, max FET |
3 |
3 |
5-35-full |
5=1/2 7135, 35=mixed |
4 |
4 |
2-10-40-full |
10=max 7135, 40=mixed |
5 |
5 |
2-5-10-40-full |
10=max 7135, 40=mixed |
6 |
6 |
TK BLF A6 7 mode |
6 well evenly spread |
7 |
3 |
10-35-full |
10=max 7135, 35=mixed |
8 |
4 |
TK BLF A6 4 mode |
4 well evenly spread |
Moon mode has been broken out separately to enable/disable it.
Thanks Tom.
I noticed an SH version that is listed as only having 256B RAM, rather than the 512B of the others. Not sure if that will have any bearing for our usage or programming.
That must be a typo - I don't believe the Atmel spec sheets say that. I'd trust the Atmel data on this. I'm using Atmel Studio 7.0 now, and Studio definitely sets the 85 (any 85) for 512 bytes RAM.
That makes more sense.
Are you planning on adding the "eswBrOutCfg" to the Repository?
Ohhh - actually I'm workin on it now - trying to add the n.n voltage level blinky feature. Didn't post it anywhere yet - gong slower to get it done than I thought.
I have a lock-out feature that works with the light OFF, do 2 quick clicks followed by an extra long hold -- it indicates lock-out by 4 quick blinks. Once locked-out, you have to do the same sequence to unlock it (2 quick clicks followed by a extra long hold).
For voltage monitoring, I want to do something similar. Plan is from OFF, do one click followed quickly by a long hold. Instead of strobe it will blink out the voltage (ex: for 4.1v, 4 blinks, pause, then 1 blink).
The lock-out feature so far is working great. The SupFire M2-Z (from MtnE) is a great light to test this on, since it has a very easily activated side switch plus it has bare threads so can't easily be locked out by twisting the loose the tailcap.
Note that enabling the AVR brown-out detector can at least double your parasitic battery drain. My SRK driver draws around 6 microamps without brown-out, over 30 microamps with brown out.
Brown out detection can also be disabled in software just before going to sleep. So you can keep the benefit but lose the power drain. Not sure if software BOD disable is available in the non-V attinys though. I’ve read someone say it’s not available.
If it helps, the code I used is copy-able. Not sure if it fits into your code easily, but it’s available if you want it. The files are tk-voltage.h, tk-calibration.h, and bistro.c; look for “BATTCHECK_VpT” to find the relevant sections.
The method I used is a table listing the raw ADC value followed by a packed number of blinks. So, two bytes per entry — 8 bits of ADC value, 3 bits of 1.0V blinks, 5 bits of 0.1V blinks. It iterates over that table to find the correct entry, unpacks the blink values, then, um, blinks. This was the most compact way I could think of to do it without sacrificing accuracy.
A smaller but less accurate method is to assume that 0.1V equals exactly 5.0 ADC units. This eliminates the table. But in my testing, it’s usually in the range of 4.4 to 4.8 ADC units per 0.1V, so it will skew as it gets farther from its origin value. This effect could be reduced by using the full 10 bits of ADC measurement and doing everything in 16-bit math, but that takes extra room too.
Yes - I should be able to use it. Just dnld'ed it. Thanks!
Funny, because "I think" my brownout support isn't actually turning ON brown out detection. I'm using fuses: E2/DF/FF and it still works fine. So guess I should have called it simply NOINIT or something equivalent? I believe I tried it disabled and enabled at 1.8V and notice no difference.
Didn't realize (or forgot) bout the extra parasitic drain. Is there anything more to it? Any other initialization I'm unaware of? I'm thinking the extra parasitic drain is coming from enabling it via the fuses?
I use this var in my code:
// OFF Time Detection
volatile byte noinit_decay __attribute__ ((section (".noinit")));
and it seems to work fine. I don't think there's any other initialization needed. This is in my main start-up code:
if (OffTimeEnable)
{
if (!noinit_decay)
{
// Indicates they did a short press, go to the next mode
next_mode(); // Will handle wrap around's
SaveConfig();
}
}
else
modeIdx = 0;
if (modeIdx == 0)
{
TCCR0A = PHASE;
blink(2);
}
// set noinit data for next boot
noinit_decay = 0; // will decay to non-zero after being off for a while
Never sure how you guys measures amps and voltages at so low of levels. Obviously my DMM can't go that low, so what's the method?
HP-3458A multimeter :party:
I have other meters that can measure down to femtoamps…
Hhhhhmmmmmm......