Well I'll be, it sure does. So actually you need to be below 0.2V to be guaranteed low. Not a normal logic signal at all.
So, yeah, you could do everything on one pin
Batt+ --------|
| |
R1 \ e-switch
| |
rest pin------------|------------|
|
R2
|
^ 1V diode
|
Case
The diode offsets the whole divider above 1.0V so the pin never sees less voltage than that. The divider sends something between say 1.5 and 2.5 related to battery voltage (but with an offset now, little software tweak).
< 1.5 is read as shutdown signal.
> 2.5 or better yet equal to Vcc as read using Vcc ref, is read as eswitch press.
Yes it's a bit crazy. But if someone just really wanted to do it, it could probably work. Given that it adds a component, it's hard to see it being worth that to save a pin in most cases. You could probably maybe get by with it without the diode too though.
Without the diode I'd worry that voltage drops to fast and reset hits before you get a chance to detect shutdown.
Yeah, the extra component does outweigh the free pin for the small boards anyways, I doubt you would fit it without going to 0402 resistors.
I could see a way with just resistors. I'd want to slow down the shutdown to make sure you detect it before reset hits. That means bigger C1. But of course that balances against saving power on C2, and it just starts to seem way more complicated and fine tuned than it's worth.
The real fact is, even with the diode, the voltage will still eventually drop below 1V. I just figured that would slow it down enough getting there.
EDIT: Shoot, no, it's got to hold it long enough to get the light back on, not just long enough to read shutdown. Yeah, definitely need the diode AND might have to balance C1. Maybe not impossible, but getting more complicated the more I think about it.
Mike - I suspect a similar problem in unrelated thread (Simon's clear C8 driver problems, post #673). Can't seem to flash the MCU with pin #5 grounded, but not 100% sure this is the problem. Would you know?
They're not shorted, there's a high resistance. A low resistance logic low should still be able to pull it down, probably.
Huh? Was this an answer to my Q?
Equal parts a response to the quote, that I hadn't noticed before you quoted it.
The flashing process uses the reset pin and it’s reset feature. As far as I know it’s a timed sequence in order to get the MCU to accept upload. I think shorting it with any other pin that the clip uses will result in not being able to flash. Maybe it’s OK with sorting with one of the IO pins, but GND and VCC are means the programmer can’t pulse anything on the reset pin, and therefor it won’t be able to flash.
Edit: Oh, wait… pin #5 is PBO. Well, in any case I’m assuming that all pins that the programmer uses all need to pulse in certain sequences. Shorting any to VCC or GND would eliminate the possibility for it to send anything on that pin… and that PBO is used by the programmer. So I’d say it’s the same reason.
Probably… I’ve got everything working on the same pin when it’s not the reset pin, that will free up enough pins, but still I think playing around with these things is interesting. I actually have room to squeeze in a small component or two in all my designs, but won’t make any board designs until it proves to be stable.
I’ve had enough issues getting it all working on one normal IO pin with the OTC less design. I do a lot of stress testing and have had issues with the MCU hanging and not waking up after cold start. It’s taken a while to weed out these issues. Using the reset pin will probably be even more challenging.
Why would you short any pin? I assume the reset pin is normally left disconnected and is internally "pulled" high, ie connect high by high resistance, which is normally about what we'd want to do also if we connected it to something. It is a good reminder that using reistances that are too low might cause problems with programming. Anyone know the impedance on the logic levels of the programmer? 50 ohm? less? For most logic levels though you don't need to pull it far. The tolerance is pretty loose. For reset though you need to pull it below 0.2V. If the programmer impedance is 50 ohm, and you start using 500 ohm dividers, that could become dicey. There are two pins that are not used at all during progamming. So anything that needs to badly break the rules could maybe be put on those?
I explained in post #1468 why I shorted reset with VCC and BAT+. It was just a quick and easy test that the reset pin can be used, that’s all. No long term plans to design a driver that way, just a quick and easy test because it was… quick and easy.
Sorry, I guess I missed some of the details. Anyway, yeah, just adding a resistor fixes it, but it's an added resistor unless doing voltage sensing there too. I was thinking internal pullup, but now I realize that probably doesn't work with adc readout.
I got my hands on some LDOs. Those LT3009s are way too small for me, I was unable to solder any wires onto those tiny pads so I couldn’t test them. They will surely work though, as I’ve tested out it’s larger cousin LT1761 (5 pin TSOT-23) which has the same description in regards to reverse current, and they work as advertised.
Personally I don’t yet need to go as small as the LT3009 because all my drivers can fit the LT1761, so I’m leaving the LT3009s untested for now but am assuming they’ll work just fine.
Anyone else done some testing with LDOs on an OTC less design?
Oh, and another tip on LDO for normal designs is the MCP1703. I tested one to destruction and they’re pretty solid little things. Won’t work for OTC less designs without a diode though, but if you just need a small cheap LDO, these things are pretty solid.
FYI:
I meanwhile completed a driver firmware for OTC-less design. It’s based on my momentary firmware, and it only uses two different switch timings: < 250 ms for short clicks, 250 ms to 700 ms for long clicks, longer than 700ms is recognized as off. Has stepless ramping, special functions on multiple short clicks, and switches mode groups when 1 to 4 short clicks are followed by a long click. It can even do stepless up/down ramping due to the exact timing: up starts with short click and down starts with long click, both stop with next click.
I loaded this firmware into an old BLF X6 FET+1 driver from banggood, only modifications were a 47 uF buffering cap, a 1k bleeder resistor and a connection from batt+ to pin 2. I recognize the voltage drop with pin change interrupt at pin 2, the voltage divider is still at pin 7. Someone mentioned we could still use BOD and switch it off only when sleeping. I did this, but it didn’t work with cells below 3 V, at least with the used cap size. No problems with BOD completely deactivated though.
The driver found place in a triple 219C Convoy S2+ with metal clicky button.
Works like a charm in real life usage, almost as good as a light with momentary switch.
The additional cap even helped with the known Attiny25 problem where spikes from the FET lead to a reset of the mcu at high currents. Not anymore, at least up to 14 amperes without other precautions.
Interesting that the LDO is too small, I could barely even fit it on the 17mm drivers I have been messing with. As long as it works and can be reflowed is all that matters I guess.
Very nice! Now to see if I can get TK or someone to pick through the code and inject the needed parts into bistro….
Edit: Wait so you have ramping working on a clicky light? Yet another thing we need to get on bistro, and when you say stepless ramping, what is that exactly?
Too small for me to solder on wires, but I don’t have the best of eye sight. I’m sure there are plenty who wouldn’t have an issue. Quite sure they’re as easy to mount and reflow as any other, but these aren’t easily available to me so I opted for a model that is.
As that firmware you are going to openly share? I’m using my own firmware, but would like test yours to see if it has tackled issues that took me a long time to sort out.
Well it’s stepless ramping, which means smooth transition from low to high and backwards over a couple of seconds. As in Narsil, for instance.
Not currently, sorry, but I’m thinking of making a version of this firmware publicly available in future.