Resettable contact counter circuit

Hi all. I am looking for a simple circuit I can use to count contact closures. Periodically the Arduino would read the count of contact closures and reset it. I've seen some simple BCD examples but they only count up to 10 or 15, basically 4 bit. I'm looking for one that is 6 or 8 bit but haven't found it.

If you know of a simple way to do this that an Arduino can read and reset, and that is 3.3V or 5V, I'd love the advice :slight_smile: This will be used outdoors if that matters (but will be weatherproofed).

Why not just use an interrupt on switch closure (with debouncing) and increment a variable and read a digital input to look for a reset switch closure ? Why does it need to be an IC ?

What about a 74590 ?

This needs to be a low power project. The micro controller will be in deep sleep mode the majority of the time. I can't afford for it to wake up for every event. Hence I'd like a circuit to do the counting, saving power, and only when the micro controller needs to wake up will it read the value.

roadfun:
Periodically the Arduino would read the count of contact closures and reset it.

And how would it know when to do that?

A cunning idea for a counter was to get a cheap calculator, wire the contacts to the "=" key and start the counter by entering "1".

I'm sure there are purposed counter modules available.

A cunning idea for a counter was to get a cheap calculator, wire the contacts to the "=" key and start the counter by entering "1".

"cunning" is an adjective I wouldn't choose to describe that method.
I would probably use a dedicated IC or just an interrupt driven counter that increments a variable and reads a GPIO for RESET switch closure.

The controller will wake up from deep sleep using an event trigger on the Reset PIN (ESP8266 feature). This part is easy and works just fine. The device will wake up far too often if it wakes for every contact closure. I saw one post about someone using a step counter (fitness type device) but there were no details at all on what was compatible, how it was wired up, how to read it from the Arduino etc.

It really sounds like an application for an ATtiny85 or Pro-Mini. Is there any other Design Criteria you are not telling us ? (like total power consumption etc..?)

The ATtiny85 might be a good solution, that's a new one to me. I will need to find out how to read it and control it from a ESP8266.

My project requires WiFi, will be 'permanently' installed outdoors, must run indefinitely, will have a small solar panel which will charge a LiPo a few hours a day on a good day, but of course needs to survive a few cloudy days.

Overall with the ESP8266 prototype I have it works with no problem (ESP8266 software is running, deep sleep working, WiFI on wake working, LiPo working, Solar panel charging working). I just need a way to have something external take care of contact closures so the ESP8266 can sleep 99.9% of the time.

The ATtiny85 requires an UNO to program it or a dedicated ATtinyISP. I built my own programmer using a ZIFF socket for the ATmega328 and an ATtinyISP .

Or you could use something like the tiny85 and program it via USB.


Image links to aliexpress 1.39€ free shipping.

That must have it's own FTDI converter chip onboard.
Yes that would work.

I guess you can program it using an Uno as well: Box

So far I2C seems to be the way to interface a running Tiny to a 8266.

I guess you can program it using an Uno as well

That's the most popular method, used by almost everyone. I was not aware it could be programmed with I2C. What is the basis of that statement ?

Follow the link I posted, it has detailed instructions on programming from an Uno. I have not tried it myself.

Follow the link I posted, it has detailed instructions on programming from an Uno. I have not tried it myself.

Yes , as I said, that is how everyone has been doing it since the MIT link . It uses SPI , NOT I2C.

These are all SPI pins, NOT I2C. I2C uses A4 & A5.

SS
MISO
MOSI
SCK

Your comment here:

So far I2C seems to be the way to interface a running Tiny to a 8266.

Makes no sense since I2C is not how most people do it. They do it EXACTLY like the link you posted.

I have not seen anyone use I2C, which prompted me to say this:

" I was not aware it could be programmed with I2C. What is the basis of that statement ?"

to which you replied referring me to the link using SPI.

SPI != I2C