No me queda claro qué condición tiene la señal WP comienza en su código de ejemplo: no se muestra ningún ajuste de la señal WP antes de la escritura EEPROM I2C. Asumiré que ya ha deshabilitado WP (es decir, configure la señal de WP baja) antes de su código de ejemplo.
Incluso sin más aclaraciones, si usted realmente desea alternar la señal de protección contra escritura entre escrituras EEPROM, creo que hay suficiente información para demostrar que su código existente no funcionará, o puede ' No se confíe en que trabajemos consistentemente.
La Hoja de datos del Microchip 24AA512 dice en la sección 6.3: "El pin WP se muestrea en la Bit de parada para cada comando de escritura (Figura 1-1) ". y la figura 1-1 es vital para entender esto. Aquí he resaltado algunas partes de ese diagrama:
Lalínearojavertical(esnegraeneldiagramaoriginal)eslacondicióndeParadaI2C,dondeSDA(In)cambiadeBajoaAltocuandoSCLyaesAlto.MirelaseñalWPenlaparteinferiordeldiagramayespecíficamentelosparámetrosdetiemponumerados11y12.Aquíhayunaversiónabreviadadelatabladeparámetrosdetiempo,explicandoesosdosparámetros:
Suponiendounatensióndealimentaciónentre2.5Va5.5V(supongoqueestáusando3.3Vo3.6VconesaMCU),estatablamuestraque:
- laseñalWPdebeserestablepornomenosde600nsantesdelacondicióndeparadaI2C(parámetrodetiempo11),y
- laseñalWPdebeserestablepornomenosde1300nsdespuésdelacondicióndeparadaI2C(parámetrodetiempo12).
Comoejemplo,ensucódigo:
TM_I2C_Stop(I2Cx);GPIO_SetBits(GPIOC,GPIO_Pin_13);//SetWPpinhigh(PC13connectedtoWP)
...puedeestarconfigurandoWPHigh(esdecir,habilitado)demasiadorápidodespuésdelacondicióndeParadaI2C,enviolacióndelparámetrodetiempo12(consultelaactualizaciónacontinuaciónparaunanálisismásdetalladodeesto).ViolaresterequisitodetiempopodríacausarproblemasparalaescrituradeEEPROMqueseacabadeintentar.Elusodeunosciloscopioounanalizadorlógicoparamedireltiempodeamboseventosensuhardware,confirmaríarápidamentesisucódigocumplíaconesosrequisitos,especialmentesiestabacambiandolaseñalWPmásrápidamenteque1300nsdespuésdelacondicióndeParadaI2C.
IntentarcumplirconestasrestriccionesdetiempoparalaseñalWPobviamentecomplicarásucódigo.Asíquepararesponderasupregunta:
¿Esestorealmenteunproblema?
Creoquelarespuestaes"sí": debe considerar ambos parámetros de tiempo, en relación con la condición de Parada I2C. Sin embargo, espero que si está configurando WP Low antes de iniciar la escritura de EEPROM, entonces el problema principal es esperar lo suficiente después de la parada I2C, antes de configurar la señal WP en High (habilitada) nuevamente.
Se actualizó para agregar algunos análisis matemáticos en torno al parámetro de tiempo de reunión 12 ("WP hold time") después de la condición de Parada I2C, para mostrar el área de preocupación.
En el reloj de la CPU de 168MHz, el tiempo del ciclo es \ $ \ frac {1} {168 \ veces 10 ^ 6} \ approx 6 \; \ textrm {ns} \ $
Por lo tanto, existe el riesgo de violar el parámetro de tiempo 12 de la EEPROM, si el código MCU cambia el estado de la señal WP dentro de \ $ (1300 \; \ textrm {ns} \ div 6 \; \ textrm {ns} \ aprox) \ $ 217 ciclos de CPU de la condición de parada I2C.
Un ejemplo que encontré del código fuente TM_I2C_Stop() , es esto:
uint8_t TM_I2C_Stop(I2C_TypeDef* I2Cx) {
/* Wait till transmitter not empty */
TM_I2C_Timeout = TM_I2C_TIMEOUT;
while (((!(I2Cx->SR1 & I2C_SR1_TXE)) || (!(I2Cx->SR1 & I2C_SR1_BTF)))) {
if (--TM_I2C_Timeout == 0x00) {
return 1;
}
}
/* Generate stop */
I2Cx->CR1 |= I2C_CR1_STOP;
/* Return 0, everything ok */
return 0;
}
Y en stm32f4xx_gpio.c de una copia descargada del STM32F4 SPL es el código fuente de GPIO_SetBits() :
void GPIO_SetBits(GPIO_TypeDef* GPIOx, uint16_t GPIO_Pin)
{
/* Check the parameters */
assert_param(IS_GPIO_ALL_PERIPH(GPIOx));
assert_param(IS_GPIO_PIN(GPIO_Pin));
GPIOx->BSRR = GPIO_Pin;
}
Como vemos, hay muy pocas instrucciones entre comenzar a activar la condición de Parada I2C en I2Cx->CR1 |= I2C_CR1_STOP; y comenzar a cambiar el estado de la señal WP en GPIOx->BSRR = GPIO_Pin; .
Por supuesto, también hay instrucciones ocultas, por ejemplo. Función epílogo y prólogo para la configuración y desmontaje / desenrollado de la pila. Sin embargo, estos están diseñados para ser eficientes y requieren pocos ciclos de CPU. Es por eso que, en general, no me sorprendería si hubiera menos de 1300ns entre los dos eventos, en violación del parámetro 12 de tiempo de la EEPROM.
Para confirmar, puede revisar la salida del ensamblador del compilador de C y estimar el número de ciclos de CPU necesarios para las instrucciones entre las dos declaraciones de C que mencioné anteriormente, y / o medir el tiempo entre esos dos eventos, como mencioné anteriormente.