So it reliably detects e-switch, tailswitch and LVP off of a single pin? That is fantastic!
Who knows what we may come up with to put all of those uses to use but it opens possibilities thats for sure.
I’ve only been testing for a few minutes, but yes, it reliably detects e-switch, off switch and LVP on the same pin. I’ve been fiddling with the voltage up and down and so on, and so far it’s 100%.
It certainly helps me. I was happy when I figured out how to put the OTC, Esw and LVP on the same pin because I used 4 channels for my drivers. The OTC proved to be unreliable so I was forced to put the OTC on a dedicated pin and start mucking around with the reset pin as the 4th channel. I’ve made a HVSP device to reset my MCUs, but it’s still a PITA. I’m pretty happy now that it looks like I can go back to 4 channels without mucking about with that darn reset pin.
High voltage is just what I was thinking. Well, there was nothing else left. Ok not quite true if using 1.1 ADC
0 to 0.5V : Off signal, non tailcap light is zero. Tailcap light is a bit higher, must check resistance values
0.5 to 1.0: Battery level
LVP(minus a tolerance) to 4.2V: eswtich pressed. This range is probably a little more flexible. Technically the vcc can occupy anything in this range when on but if the measurement is made relative to Vcc, then other signals that are relative to Vcc can also occupy this range. They should be viewed as a fraction of vcc then not as an absolute voltage. To use this if you see 255 with 1.1 reference, you'd switch to Vcc reference or possibly 2.56 reference.
So there's still room between 1.1 and LVP if using absolute voltage, or between about 0.6 to say 0.9 Vcc if using relative voltage.
edited for clarity.
So I put together some OTSM test code together with ADC interrupts and all… only to find out the hard way I have no hardware to test it with 
The MTN-17DDm has its voltage divider after the diode and the BLF A6 driver has no cap after the diode! I tried hooking up a large (4700 uf) electrolytic cap through my programming clip but that is for some reason insufficient to run the MCU.
I’m out of hardware options so if someone else wants to try the code, it’s over here . I’m not entirely confident this works but it makes one large flash on boot and it’s supposed to flash multiple times after a short press (one flash for every WDT tick of 125ms in OTSM). I inlined some includes I reused from my firmware, which is why it’s a little verbose. You may need to edit the voltage divider values around line 104-105. The whole thing is fairly complex so there are likely bugs, unfortunately.
I’ve grabbed it and will do some tests. However, I’ll just pick out the bits of interest and test them in my test routine.
@fixed it,
http://www.mtnelectronics.com/image/cache/data/OSH/MTN17DD-V1.1-TOP-750x750.png
That R1 sure looks to me like it attaches straight to the battery. Because you said otherwise I was following the path through the diode and trying to find where it led to the battery and couldn't. Then I realized there's a trace straight from the right side of the diode up to the battery vias in the middle of the board.
The only real differences between what we are doing is that you have set up the ADC interrupt, which I haven’t, and you are running prescaler 64 under normal operation (power on) where I am running 128.
Switching to 64 might give me a little more time as it should drain the cap a little less before detecting the power is off.
I haven’t used the ADC interrupt. I have my ADC_read() function which I call from the watchdog interrupt. It starts the ADC, reads it, turns it off and then returns a voltage value. I wouldn’t think that running the ADC interrupt instead would make much difference. I can give it a go though.
To be precise... if you start at the top of R1 in that image.. Head northwest (10:30) to the right D1 pad, then go straight up, that's your path from R1 to battery.
He might be talking about the new version of the mtn17dd, the red one.
Oh well, that's different then. Maybe it can be bypassed with a through hole resistor though.
Come to think of it, and I just checked, it looks like the attiny pins are only specced for -0.5V negative. If they changed it, it might have been for a good reason. Any experience around here with putting batteries in backwards? Could be related to them using 2.56V vref too though. If you keep the divider large so the pin voltage is in the 1.1V range, maybe it violates spec but still survives a reversal where at 2.5V maybe it doesn't.
That’s not the one I have. I have the one with a through-hole for the + wire. This isn’t a random guess: I’ve actually measured the resistors, the drop from the diode and incorporated all that in firmware so it does LVP with high accuracy.
I actually think it’s a good choice as otherwise a reversed cell will put reverse polarity between the MCU ground and voltage divider pin. Probably not the worst thing that’s been done to those poor ATtiny but still…
Edit: didn’t read the whole thing before replying and I see you guys beat me to it 
The point of that is keeping the MCU idle instead of active in an infinite loop while the ADC does its thing. According to the spec sheets, there’s about a 4x difference in current used between both states. So I’m hoping it might actually help a lot.
Ah, I see. It’s the “while (ADCSRA & (1 << ADSC))” loop that you would be avoiding. In my case the MCU is draining cap power while waiting for this to complete, in your case the MCU is still sleeping.
Is that correct?
Yes, that’s exactly where I was trying to save power.
It is still possible to protect the voltage divider in this design. You need a separate diode in series just with R1 after it splits off. It will affect the divider calculations and give the calibrations an offset term (true in mtn version too). It's adding a component, but a couple have been removed so I wouldn't think it would kill the design if it turns out better to have it. If protecting a $3 part with a $2 part and there's a 99% chance it won't fry even without it though, then it's not really worth it.
So I did say the one difference between using a bleeder or not is input impedance. In a reverse battery situation that might actually matter. It might be an argument for keeping R1 high and for keeping TA's bleeder. On the other hand, even at 500ohms there may already be just nothing to worry about. It's outside the "absolute max" voltage spec when reversed, but still stays under the current spec which likely matters more.
Batt+ Batt-
|--| |-----|
| |--------*<-----| (tail cap LED, shorted by switch)
| |---------/ ----| (tailcap switch)
| |
| |
|---------BR----------------| (case ground plane, not equal to batt- when tailcap led is on)
| |
R5 |
| C1 |
|---------------||----------|
| |
|------->|--R1---R2---------| new diode here
| | |
| Vsense pin |
(Schottky or LDO) V |
|--------------mcu----------|
| |
Vcc |--------------||-----------|
C2
page 166 of the attiny 24/45/85 manual:
"1. VBOT may be below nominal minimum operating voltage for some devices. For devices where this is the case, the device is tested down to VCC = VBOT during the production test. This guarantees that a Brown-out Reset will occur before VCC drops to a voltage where correct operation of the microcontroller is no longer guaranteed. "
This is printed below brown-out-threshold (BOT) fuse table, which shows fuse bit values to achieve different BOT levels, down to 1.7V.
Does that say.. "'nominally' this device only works down to 2.7 V, but it's guaranteed and tested down to 1.7V anyway, just like the more expensive one?" Hmm.. very hard to interpret that.
The way I always read it is that devices for which the reference voltage is lower than 1.1V are tested at the voltage where the BOD actually kicks in. So a 2.7V part could be validated down to 2.5V and a 1.8V part down to 1.7V, more or less. This guarantees that the BOD gives safe MCU operation even if the voltage reference is near the bottom of its allowable range.
I have no idea what the 1.1V reference has to do with any of it.
"1. VBOT may be below nominal minimum operating voltage for some devices."
There is no indication I saw of what the allowed values of VBOT are for different chips. There is only a table of how to set it, anywhere from 1.7V (actually the lowest setting is somewhere between 1.7 and 2.0) up to much higher, for all the chips documented. What does "may" mean though. It sure likes yes, it may be if for example you set it to 1.7V for a 2.7V chip.
Or do you think if you set the 2.7 chip to 1.7V BOT that a minium (undocumented) BOT of 2.5V will apply for that chip anyway? Or just that you shouldn't set it lower than 2.5V? (also not documented).
Ok, so I guess what I am realizing is basically there are two choices 1.8V and 2.7V . Maybe fixed what you're saying is you assume for the 2.7V chip we should choose the 2.7V. But it also states there's some variation, could end up anywhere from 2.5 to 2.9, so ok, they're saying we're covered for that, but not covered for selecting the 1.8V threshold?