EEPROM Question

All Material Referenced from the Arduino Mega Data Sheet:

From page 23 and on:

The examples assume that interrupts are controlled (for example by disabling interrupts
globally) so that no interrupts will occur during execution of these functions.

If I have hardware interrupts tied to some external pins, would it be bad if one of them fired during an EEPROM read/write sequence?

Second question, I was looking for a workaround of the EEPROM library, and I looked at the .cpp file, only to find EEPROM.read and EEPROM.write calling more functions, eeprom_read_byte, and eeprom_write_byte. However, if I just do something like the following (taken from the same page in the Data Sheet), would I need to import any libraries? Also, would this even be efficient or should I just continue with the EEPROM library:

void EEPROM_write(unsigned int uiAddress, unsigned char ucData)
{
/* Wait for completion of previous write */
while(EECR & (1<<EEPE))
;
/* Set up address and Data Registers */
EEAR = uiAddress;
EEDR = ucData;
/* Write logical one to EEMPE */
EECR |= (1<<EEMPE);
/* Start eeprom write by setting EEPE */
EECR |= (1<<EEPE);
}

First question, I think the paragraph right before the code you posted answers the question:
"The following code examples show one assembly and one C function for writing to the
EEPROM. The examples assume that interrupts are controlled (for example by disabling interrupts
globally) so that no interrupts will occur during execution of these functions. The examples
also assume that no Flash Boot Loader is present in the software. If such code is present, the
EEPROM write function must also wait for any ongoing SPM command to finish. "

The 2nd question:
You could run that code, be sure to control interrupts before calling it.

Don’t forget the mating Read code:
“The next code examples show assembly and C functions for reading the EEPROM. The examples
assume that interrupts are controlled so that no interrupts will occur during execution of
these functions.”

unsigned char EEPROM_read(unsigned int uiAddress)
{
/* Wait for completion of previous write */
while(EECR & (1<<EEPE))
;
/* Set up address register */
EEAR = uiAddress;
/* Start eeprom read by writing EERE */
EECR |= (1<<EERE);
/* Return data from Data Register */
return EEDR;
}

1) I apologize if I missed something, but I quoted from that paragraph, as it said to control the interrupts, but I didn't really see a part where it stated the side affects. I read in a later section that pretty much the only way to corrupt the EEPROM data was through various methods of low supply voltage or something, but I never saw anything related to these interrupts. It is enough for it to say, "Make sure you control your interrupts," but if I knew that the consequences of not doing so would be drastic, I would be a lot more careful. Otherwise, if the side affect is simply that the EEPROM.write doesn't work (a simple error or something), I would be more prone to experiment.

2) Is there any point to use that code instead of the library? Would you recommend it granted ideal circumstances?

  1. So don't control the interrupts. Worse case you get corrupted data. Not a big deal if you are just experimenting, not gonna brick the chip or anything.

  2. 6 of one, half dozen of the other. I don't know what constitutes ideal circumstances. Like anything in engineering, there are trade-offs: You could look at the assembly code created and select the shorter one if you were concerned about flash space used. Or use an oscilloscope or logic analyzer and make some timing measurements if you were concerned about speed. Writes will take 3.3mS to complete either way.

I didn't look at the library code, so I don't know what it does differently, or if it compiles differently.

This is EEPROM.cpp, it is fairly short…

/*
  EEPROM.cpp - EEPROM library
  Copyright (c) 2006 David A. Mellis.  All right reserved.

  This library is free software; you can redistribute it and/or
  modify it under the terms of the GNU Lesser General Public
  License as published by the Free Software Foundation; either
  version 2.1 of the License, or (at your option) any later version.

  This library is distributed in the hope that it will be useful,
  but WITHOUT ANY WARRANTY; without even the implied warranty of
  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
  Lesser General Public License for more details.

  You should have received a copy of the GNU Lesser General Public
  License along with this library; if not, write to the Free Software
  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
*/

/******************************************************************************
 * Includes
 ******************************************************************************/

#include <avr/eeprom.h>
#include "Arduino.h"
#include "EEPROM.h"

/******************************************************************************
 * Definitions
 ******************************************************************************/

/******************************************************************************
 * Constructors
 ******************************************************************************/

/******************************************************************************
 * User API
 ******************************************************************************/

uint8_t EEPROMClass::read(int address)
{
	return eeprom_read_byte((unsigned char *) address);
}

void EEPROMClass::write(int address, uint8_t value)
{
	eeprom_write_byte((unsigned char *) address, value);
}

EEPROMClass EEPROM;

When I said ideal circumstances I just meant you aren’t pressed by any immediate needs, the only thing you are focusing on is getting the job done. I guess that is pretty vague now that I think of it. The main reason I’m trying to find a way around the libraries is that I was trying to convert most of my code to direct control with the processor rather than making use of all the regular Arduino functions (using the functions they provide is easier at first, and that’s what I did, but now I want to optimize everything as much as possible even though it might not be as straightforward, but that is what documentation is for, also this is a great learning experience).