View previous topic :: View next topic |
Author |
Message |
mhjccsinfo
Joined: 17 Oct 2011 Posts: 23 Location: Iran-tehran
|
Interrupt disabling while in eeprom writing |
Posted: Sun Apr 28, 2013 6:46 am |
|
|
hello all.
I'm writing a program for controlling a triac component.(a variable dc power supply).and I've used a zero cross circuit for understanding beginning of AC input signal. and I have connect this circuit to external interrupt.
also I have a timer for understanding machines life and I should save this time to the EEPROM every minute .
the problem is that : when program arrive to the eeprom writing line . it cause problem for the interrupt . and prevent it from working .
Is there any way for disabling this situation?
( I have used this code:"#device WRITE_EEPROM = NOINT" but there is still a stop of about 1 second in every minute of my program)
Thanks _________________ thanks and hope of success for you
Mohammad_Hosein |
|
![](templates/subSilver/images/spacer.gif) |
dyeatman
Joined: 06 Sep 2003 Posts: 1924 Location: Norman, OK
|
|
Posted: Sun Apr 28, 2013 8:00 am |
|
|
Your problem comes from the fact that EPROM writes take a lot of time from
the CPU cycle perspective and can't be interrupted.
Try FRAM. FRAM delay-less writes eliminate those issues and there are drop
in replacements for many EPROMs. Plus you get a longer memory life as a bonus! _________________ Google and Forum Search are some of your best tools!!!! |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19359
|
|
Posted: Sun Apr 28, 2013 8:21 am |
|
|
It'd help if you told us 'what chip'?.
On most modern chips, there are _parts_ of the EEPROM write cycle, that must have the interrupts disabled, but these are very brief. Basically the unlock sequence to the moment the write is started. If this is interrupted, the unlock won't work. However the long delay (wait for the write to occur), can have interrupts enabled.
However on most chips, you should not be writing to the EEPROM every minute. This will typically kill the chip in anything from ten days to a couple of years. You should either only update the data after power fails, or switch to an external memory without the write life limitations, like the FRAM.....
Best Wishes |
|
![](templates/subSilver/images/spacer.gif) |
mhjccsinfo
Joined: 17 Oct 2011 Posts: 23 Location: Iran-tehran
|
|
Posted: Sun Apr 28, 2013 8:55 am |
|
|
thanks for your help.
the MCU I'm using is "PIC16f877A" .
I may change it to "PIC18f452" if it has the ability.
-------
Quote: | Try FRAM. FRAM delay-less writes eliminate those issues and there are drop
in replacements for many EPROMs. Plus you get a longer memory life as a bonus! |
I have not used I2c or FRAM ever so I don't know how long will it take to work with it and also how much does it cost.
Quote: | You should either only update the data after power fails |
how is this ?
thanks _________________ thanks and hope of success for you
Mohammad_Hosein |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19359
|
|
Posted: Sun Apr 28, 2013 9:30 am |
|
|
On your chip, the write life of the EEPROM is only warranted for 100K cycles. About 3months.
The FRAM (in I2C versions), can be driven by the code in the library for the equivalent EEPROM's. Key though is that write is basically instantaneous. You finish sending the data, and it is written. Write life is also enormous (trillions of cycles...).
All you do is have enough capacitance on the supply rail to keep the chip running for enough mSec to write the data you want, and detection to say 'power has gone off'. Feed this to an interrupt, and when this fires write the data. Then have the code sit and wait, and if the supply doesn't go off, restart, or continue.
Best Wishes |
|
![](templates/subSilver/images/spacer.gif) |
mhjccsinfo
Joined: 17 Oct 2011 Posts: 23 Location: Iran-tehran
|
|
Posted: Sun Apr 28, 2013 10:16 am |
|
|
Ttelmah wrote: |
The FRAM (in I2C versions)
|
could you please introduce a part number of these FRAMs ?
Ttelmah wrote: |
All you do is have enough capacitance on the supply rail
|
I have many LEDs on the circuit so I think I should separate MCU power from other components ( for example by two 7805 ICs )
I have never done this . is this a common way ?does everyone who wants to have a real time clock must use this method ?there is another problem for me to design a circuit for understanding that power is going off[/list] _________________ thanks and hope of success for you
Mohammad_Hosein |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19359
|
|
Posted: Sun Apr 28, 2013 10:37 am |
|
|
Consider just using a real time clock chip. These have memories in them, that do not have the write life limitations of EEPROM. EEPROM is designed for things like configuration information, that changes rarely, not for things that need changes at repeated intervals. Most people doing something like this, probably use one of these.
FM24V02 for the smallest I2C FRAM, but for what you want, reconsider the approach.
Having the processor on a separate supply from anything drawing significant power is always good practice. Do the LED's really need a regulated supply?.
There is a potential problem with any approach writing the time like this, unless you have capacitance to cover the write. What would happen if you have written one byte of your 'time', and then the power failed?.
Best Wishes |
|
![](templates/subSilver/images/spacer.gif) |
dyeatman
Joined: 06 Sep 2003 Posts: 1924 Location: Norman, OK
|
|
![](templates/subSilver/images/spacer.gif) |
mhjccsinfo
Joined: 17 Oct 2011 Posts: 23 Location: Iran-tehran
|
|
Posted: Sun Apr 28, 2013 12:20 pm |
|
|
thanks a lot _________________ thanks and hope of success for you
Mohammad_Hosein |
|
![](templates/subSilver/images/spacer.gif) |
andrewg
Joined: 17 Aug 2005 Posts: 316 Location: Perth, Western Australia
|
|
Posted: Mon Apr 29, 2013 7:56 am |
|
|
Another alternative is to use Microchips NVSRAM series of chips. These are vastly cheaper than FRAM, but require a backup battery to maintain state. _________________ Andrew |
|
![](templates/subSilver/images/spacer.gif) |
|