"Copia de seguridad de SRAM" frente a "registros de copia de seguridad"

Cuando vaya y mire los conjuntos de características para cada familia para todas las piezas STM32F, verá que muchas de las familias de piezas (por ejemplo, STM32F101xx, STM32F102xx y STM32F103xx, STM32F105xx y STM32F107xx, y familias más nuevas como STM32F2xx, STM32F3xx, etc. ) tienen registros de respaldo respaldados por batería (BKP) y están en el dominio de respaldo alimentado por batería, que también contiene el reloj en tiempo real (RTC). Los pines de suministro de batería han estado en los mismos pines en cada paquete. Algunas de esas familias tienen más de 10 años. Por lo tanto, ST está bastante centrado en mantener la compatibilidad dentro de las familias de piezas y entre generaciones de familias comparables.

Por lo tanto, los registros respaldados por batería son una característica de la familia de productos cruzados en muchos de los STM32F desde sus familias anteriores. Por lo tanto, el software puede depender en gran medida de que esté en familias más recientes si estuvo en generaciones anteriores. Por lo tanto, sería fácil portar el código entre familias, y la función probablemente se mantendría por ese motivo, incluso si se agregara otro almacenamiento respaldado por batería.

Sin embargo, el BKP es un área bastante pequeña (por ejemplo, STM32F101xx, STM32F102xx y STM32F103xx, STM32F105xx y STM32F107xx, etc.) tiene 42 registros de dieciséis bits almacenados en 42 palabras de 32 bits. Por lo tanto, ni siquiera son contiguos y, por eso, no son útiles para el almacenamiento de códigos o variables de propósito general. Entonces, para usarlo, necesitaría almacenar valores explícitamente en cada registro. Esto es aceptable si solo lo está utilizando para almacenar algún estado que debe sobrevivir después de un corte de energía. Sin embargo, no es tan flexible como nos gustaría.

Aumentar el tamaño de los registros de copia de seguridad no ayudará a la portabilidad del código, ya que el espacio adicional no estaba disponible en el código anterior. Tampoco hay mucho beneficio para mitigar el inconveniente de usar los registros de respaldo, ya que las aplicaciones existentes lo han resuelto.

La SRAM respaldada por batería no está disponible en todas las familias STM32F, es relativamente reciente. ST no tenía EEPROM en sus familias STM32F iniciales, por lo que el área BKP era bastante importante. Sin embargo, puedo imaginar fácilmente a una persona de marketing inteligente identificando un nicho de producto que se beneficiaría de mucha más memoria respaldada por batería que las cajas registradoras. Además, haz que sea un gran bloque de memoria 'adecuada'. Esto podría usarse para variables dentro de un programa al permitir que el enlazador lo use para variables. No necesitaría acciones explícitas para almacenar valores en la SRAM respaldada por batería, solo sucedería como un efecto secundario del funcionamiento normal del programa. Por lo tanto, es mucho más fácil de usar y puede contener mucha más información.

Resumen:
Los registros respaldados por batería han estado en las familias STM32F de algunas de las primeras familias. Era esencial ya que mitiga la falta de EEPROM. Creo que se mantiene por compatibilidad y para simplificar la transferencia de código y sistemas a familias STM32 más nuevas. En muchos casos, una aplicación antigua se puede volver a compilar y vincular con nuevas bibliotecas y "simplemente funcionará".

SRAM respaldado por batería es una innovación más reciente para STM32 y no está en familias más antiguas. Es más fácil de usar que los registros respaldados por batería, más flexible y mucho más grande. Sin embargo, requiere un cambio de código para usarlo, por lo que tiene sentido conservar los registros respaldados por batería.

Tener un consumo de energía diferente es un beneficio, pero en mi humilde opinión, no es la razón por la que hay dos enfoques técnicos diferentes. Son para compatibilidad o mejora significativa.

El bloque SRAM de respaldo y los registros de respaldo funcionan con Vbat. No se borran con un reinicio. Creo que la razón por la que tienen ambos es para darte la opción de un bloque pequeño (80 bytes) o un bloque más grande (4k) a costa de un mayor consumo de energía de la batería. Dependiendo de su aplicación, puede elegir lo que más le convenga. Por lo que puedo entender de la hoja de datos, tanto los registros de copia de seguridad como la SRAM baskup hacen lo mismo. Sin embargo, se accede a ellos de forma ligeramente diferente, no es que normalmente importe. El consumo de energía es probablemente el mismo pr byte. Entonces, tener la opción de apagar el bloque 4k si no lo usa parece algo bueno.