Trim internal RC Oscillator for fast EEPROM acess with Mega

Go To Last Post
8 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi everybody,

my problem describes as follow: The acess time for the internal EEPROM of my Mega8 is quite high (8ms). Now i have read about that cause the internal RC Oscilator. The default value of the OSCCAL Register causes a 1 MHz frequency, wich determines the acces time. Now iwant to set the value to 8 Mhz. But i don't know the valure of the OSCCAL register.

My board normally works with an external 8Mhz-crystal oscillator. This isn'tt involve with the problem, or?

Thank You

Marc

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Playing with the internal osc will not increase the write time for the EEprom as it always uses the internal 1Mhz clock.

You use the term access time this would suggest reading from the EEprom not writing to it. If it is a read time issue then it is not 8.5ms but a few cycles.
Mike

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes I mean the write time of the EEPROM. And Yes the internal Oscilator Frequency has no effect on th ewrite time. But in the user guide of the Mega8 is mentioned on page 29 that it has effect!!!!

I don't know! But in my application it last half an second to delete a part of the EEPROM.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

On the version I have at the bottom of page 19 there is a note stating that it always uses the 1Mhz.

Rather than waste time deleting a loctionthat could be blank read back from it first if already at FF then skip.
Mike

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, Marc, it is discouraging that the new AVRs have an 8ms. write time. But it sure is nice to have that byte-addressable, byte-readable, byte-writable storage around.

I am working on refining a set of EEPROM "drivers" that have EEPROM write (and read) "tasks" that use the interrupt feature of the EEPROM. Then I make a queue of writes that need to be done, and start the next out of the interrupt for the first. The queueing program cannot go ahead and use the stored data until the queue is empty.

The main app needs to be in some kind of a "hold current state" mode anyway during re-configuration or other lenthy operations (e.g., connection of a sensor).

Lee

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Lee

Take a look look at Atmel apps note AVR104, it's already been done.

Andy

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

if the EEPROM is to 'slow' use the SRAM, in the code let the EEPROM write right after the SRAM, program is continue running at hi speed. dunno if this trick works.

lee ? :)

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Andy--it's no trick to >>write<< to the EEPROM with interrupt-driven sequences. The trick is to introduce totally-reliable RTOS-like write queues, and structure an application so that it has a state such as WAITING_FOR_EEPROM_WRITE_COMPLETE and does not try to continue to operate with partial data or hangs in one placve for milliseconds waiting for the EEPROM write to complete.

noname--you still need the mechanism and checking. For example, what happens if you lose power before all the copies are synchronized? etc.

Lee