For Atmega there is this excellent LowPower.h library from Rocketscream: defining an interrupt pin on an Atmega, attach an interrupt and define this as active-low, and program a DS3231 alarm to send an interrupt from SQW for example once every 24 hours.
The advantage of this method is that even after one year the maximum drift from the real time is less than a minute.
Using the internal ESP8266 RTC such accuracy is impossible.
Now I have been unsuccesfully looking for a method to send an ESP8266 in a "deep-sleep-forever" mode, use an input set as interrupt receive, or its RST pin to receive the active-low signal (and hence restart the ESP8266) when the alarm is triggered in the DS3231, and wake-up the ESP8266.
I suppose you could have the DS3231 connect to the CH_PD pin via some sort of circuit that is kept high while the ESP is running. (like GPIO16) check here (Thanx Google..)
Deva_Rishi:
I suppose you could have the DS3231 connect to the CH_PD pin via some sort of circuit that is kept high while the ESP is running. (like GPIO16) check here (Thanx Google..)
I had seen that thread too: this does not answer my question as it involves using the internal RTC of the ESP8266.
To recap: I need software instructions guidance to bring the ESP8266 in deep-sleep-forever, and with interrupt-handled wake-up.
Or even by using the DS3231 SQW interrupt active-low output to send a low pulse to the ESP8266 RST pin (instead of using interrupts), and hence reset and restart the ESP8266?
Waking from deep sleep on the ESP8266 requires the chips reset pin to be pulsed low. I'm not sure if the alarm output of the DS3231 pulses the pin low or holds it low until the alarm is acknowledged. If it holds the pin low then the ESP would not wake up.
Another option might be to connect GPIO16 of the ESP to it's own reset pin and then deep sleep the ESP for a period of time (max is about 70 minutes) and when it wakes up grab the time from the DS3231 and decide if it's time to perform some task.
Riva:
Waking from deep sleep on the ESP8266 requires the chips reset pin to be pulsed low. I'm not sure if the alarm output of the DS3231 pulses the pin low or holds it low until the alarm is acknowledged. If it holds the pin low then the ESP would not wake up.
Another option might be to connect GPIO16 of the ESP to it's own reset pin and then deep sleep the ESP for a period of time (max is about 70 minutes) and when it wakes up grab the time from the DS3231 and decide if it's time to perform some task.
The issue with using GPIO16 is that the internal RTC of the ESP8266 is far from accurate.
The DS3231 sets its INT/SQW output active low when an alarm clock matches its internal clock (which is accurate within one minute over one year) during one second ("When all the mask bits for each alarm are logic 0, an alarm only occurs when the values in the timekeeping registers match the corresponding values stored in the time-of-day/date alarm registers.", page 12 of DS3231 datasheet). So If I understand correctly: when an alarm is programmed to trigger INT/SQW at hh:mm:ss, then during one second the INT/SQW output is driven low.
So when this output is connected to the RST input of the ESP8266 this should wake him up from deep sleep?
when an alarm is programmed to trigger INT/SQW at hh:mm:ss, then during one second the INT/SQW output is driven low.
So when this output is connected to the RST input of the ESP8266 this should wake him up from deep sleep?
No the alarm flag and low interrupt need to be actively cleared with code, or the output remains low.
I would think that there might be some sort of hardware than can turn the 5v going low into a pulse, but I'm not a hardware guy and don't know what it could be.
cattledog:
No the alarm flag and low interrupt need to be actively cleared with code, or the output remains low.
I would think that there might be some sort of hardware than can turn the 5v going low into a pulse, but I'm not a hardware guy and don't know what it could be.
Thanks for that cattledog!
This saved me a wrong pcb design. A 100nF capacitor in series between INT/SQW and RST, with 10k pullup should give a low pulse on RST when INT/SQW goes low, and the recharge through the 10k will bring RST back high. More neater would be a monostable multivibrator but I don't have the space for that anymore on my pcb.
Meanwhile I found out that the only way to wake an ESP8266 from deep-sleep-forever is bu pulsing low the RST pin.
My goal however is to be able to do this with an interrupt to an input pin, but this can be done only when in light-sleep-forever mode: different topic.
Or even by using the DS3231 SQW interrupt active-low output to send a low pulse to the ESP8266 RST pin (instead of using interrupts), and hence reset and restart the ESP8266?
That was what i was thinking and as far as i know the only real difference between a wake-up from deep-sleep and a reset is the clock but as you are using an external one this should matter, the solution with the Cap and the 10k pullup is sort of what i had in mind, i just wasn't sure of the exact hardware you had going.
brice3010:
The issue with using GPIO16 is that the internal RTC of the ESP8266 is far from accurate.
Does it matter though? Can you code the system so when it wakes from internal RTC deepsleep it gets the real time from the DS3231 and adjusts the deepsleep time to better reflect the real sleep time.
You still won't be as accurate as the DS3231 as temperature will effect the internal RTC but it won't be much out if you sync every hour (71 minutes max)
Riva:
Does it matter though? Can you code the system so when it wakes from internal RTC deepsleep it gets the real time from the DS3231 and adjusts the deepsleep time to better reflect the real sleep time.
You still won't be as accurate as the DS3231 as temperature will effect the internal RTC but it won't be much out if you sync every hour (71 minutes max)
Yes this does matter:
using the DS3231 as an interrupt source makes for a clean solution: exact to the minute over one year, no messing around with adjustig RTC times,..
my hardware is already designed and made to accept INT/SQW form the DS3231 on a GPIO pin
brice3010:
Thanks for that cattledog!
This saved me a wrong pcb design. A 100nF capacitor in series between INT/SQW and RST, with 10k pullup should give a low pulse on RST when INT/SQW goes low, and the recharge through the 10k will bring RST back high. More neater would be a monostable multivibrator but I don't have the space for that anymore on my pcb.
Thanks for mentioning this issue, however i couldn't do the hardware setup, can you please elaborate on the wiring, cause it is not working with me.
If your incoming pulse is to low then a series cap of about 100nF or 470nF in series, and a 10k or 100k pull up resistor between the cap and the ESP8266 will pulse this input.
Depending on impedances you might have to add a transistor or mosfet with the cap at its base or gate or base.
You should have a scope to measure the signals.
brice3010:
If your incoming pulse is to low then a series cap of about 100nF or 470nF in series, and a 10k or 100k pull up resistor between the cap and the ESP8266 will pulse this input.
Depending on impedances you might have to add a transistor or mosfet with the cap at its base or gate or base.
You should have a scope to measure the signals.
Excuse my lack of hardware knowledge, but i managed to get the pulsed low signal after i supplied it with a high signal first.
The INT pin on pcf8563 is floating by default and when the alarm occurs, the pin become LOW, how can i fix that with your proposed solution.
Please check my schematic in the attachement and see if i am doing any mistakes.
If your incoming pulse is to low then a series cap of about 100nF or 470nF in series, and a 10k or 100k pull up resistor between the cap and the ESP8266 will pulse this input.
I'm not very hardware knowledgeable but I think that if L is the reset pin of the ESP8266 there needs to be a pullup on the ESP side of the cap. I'm not certain if there needs to be a pullup on the rtc side as well but I don't think so.
hhyari:
I am currently blocked by this issue and can't move on with my project, your help is really appreciated.
I am sorry for my late reply, the last few months I have so much on my plate I just barely login here.
If deep-sleep-forever needs to be interrupted then a low pulse on RST is needed.
Since cattledog in some earlier post rightfully reminded me that the RTC needs a software reset, subsequently the INT output (from high to low signal when alarm occurs) from the RTC needs to be fed into the RST as a low pulse then the best way to achieve this is with a high-pass filter: C (100nF...470nF ceramic) in series and behind that a 10k..100k or something pullup to keep RST happy.
A square high to low transition before the cap must give a low pulse after the cap.
Best would be to verify the result on a scope.
Depending on what else is connected to the RST pin it might be that the pulse does not go low enough; in that case either increase the cap size (stay with ceramics: best HF characteristics) or use a transistor or mosfet non-inverting amplifier.
brice3010:
I am sorry for my late reply, the last few months I have so much on my plate I just barely login here.
If deep-sleep-forever needs to be interrupted then a low pulse on RST is needed.
Since cattledog in some earlier post rightfully reminded me that the RTC needs a software reset, subsequently the INT output (from high to low signal when alarm occurs) from the RTC needs to be fed into the RST as a low pulse then the best way to achieve this is with a high-pass filter: C (100nF...470nF ceramic) in series and behind that a 10k..100k or something pullup to keep RST happy.
A square high to low transition before the cap must give a low pulse after the cap.
Best would be to verify the result on a scope.
Depending on what else is connected to the RST pin it might be that the pulse does not go low enough; in that case either increase the cap size (stay with ceramics: best HF characteristics) or use a transistor or mosfet non-inverting amplifier.
Thanks for your reply
For some reason i didn't manage to accomplish what i want
Can you please support your answer with a schematic in order to fully understand what you are saying.