Elapsed time counter - saving values on unscheduled power down

stocky6409

Senior Member
Hi All - its been a LONG time since I have been here with a query (marriage breakdown followed by a near nervous breakdown does that too you...)

Anyway - I'm back and happier than ever - all that is in the past now.

My query relates to the newer chips (that I seem to have missed due to my not being here - wow they look good!) - in particular the 20M2

I am working on an old project again and I *think* these will enable me to do a lot of what I failed to acheive with the older chips last time I looked at it

Note I havent got a chip to play with yet and I have ONLY JUST started looking at this seriously (inc reading the updated manuals again)

Slots/tasks - whatever they are called - should allow me to seperate a "user menu" to enable certain parameters to be set

Time - should allow me to implement an elapsed time counter to log a certain functions total run time (actually to log when it reaches a user set value to trigger a maintenace alarm)

What I am scratching my head about it recording this value. Its easy enough to read/write the value from eeprom when the function starts/stops in *NORMAL* operating conditions.

Where I am having the issue if working out how to handle an "ESTOP" shutdown - ie the user hits the BRB and kills ALL power to the cct.

Random thoughts include a super cap and monitoring the supply with an i/o pin and when supply is lost madly add the current val to the stored val and write to eeprom

Anyone looked at this in one of their apps?

Oh - FYI - the time period in question (for the alarm) will be in the range of 100 HOURS give or take maybe 50 hours. Min resolution 0.1 hours

Cheers

Stocky
 
Last edited:

nick12ab

Senior Member
What I am scratching my head about it recording this value. Its easy enough to read/write the value from eeprom when the function starts/stops in *NORMAL* operating conditions.

Where I am having the issue if working out how to handle an "ESTOP" shutdown - ie the user hits the BRB and kills ALL power to the cct.

Random thoughts include a super cap and monitoring the supply with an i/o pin and when supply is lot madly add the current vale to the stored val and write to eeprom
A super cap shouldn't be needed. A capacitor of around 470μF is enough. If you're using a regulator then you can use a potential divider to monitor the input voltage and the 470μF capacitor connected to the regulator output will allow enough time for the PICAXE to save all data to EEPROM. If you use an X2 part instead of an M2 part, you can set an interrupt to trigger in response to the chips' built in comparators thus eliminating the need for manual ADC polling. If you are also powering high current devices from the same 5V power supply and you don't want to provide a very beefy capacitor then you can power these devices with a switching regulator and use a linear regulator just for the PICAXE.

Writing to the EEPROM every few seconds or every time the value changes is a simpler way but if this will happen millions of times then the EEPROM will eventually fail so using an external FRAM would solve this - or using the extra SRAM provided by many battery-backed i2c RTCs.
 

MartinM57

Moderator
If you are also powering high current devices from the same 5V power supply and you don't want to provide a very beefy capacitor then you can power these devices with a switching regulator and use a linear regulator just for the PICAXE.
...or you can isolate the capacitor and the PICAXE supply pins from the rest of the circuit with a diode (schottky is best, for the lowest Vf) so that the capacitor doesn't have to supply any of the higher current devices when the power fails
 

stocky6409

Senior Member
Hmmmm - decisions decisions

M2 = fantastic timer function perfect for this app
X2 = more i/o and "slots" will make menu system easier for user params...


ARRGGHHHH!!
 

nick12ab

Senior Member
Hmmmm - decisions decisions

M2 = fantastic timer function perfect for this app
X2 = more i/o and "slots" will make menu system easier for user params...


ARRGGHHHH!!
M2 = single unreconfigurable timer
X2 = more i/o and "slots" and program memory and two reconfigurable timers and hardware comparators with interrupts and external resonator option and scratchpad.
 
Top