Cuando vaya y mire los conjuntos de características para cada familia para todas las partes de STM32F, verá que muchas de las familias de partes (por ejemplo, STM32F101xx, STM32F102xx y STM32F103xx, STM32F105xx y STM32F107xx y STM32F103xx, y STM32F210) STM32F3xx etc.) tienen un registro de respaldo respaldado por batería (BKP), y se encuentran en el dominio de respaldo alimentado por batería, que también contiene el reloj en tiempo real (RTC). Las clavijas de suministro de batería han estado en las mismas clavijas en cada paquete. Algunas de esas familias tienen más de 10 años. Por lo tanto, los ST están bastante enfocados en mantener la compatibilidad dentro de las familias de las partes y en 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 confiar en que sea en familias más recientes si se trata de generaciones anteriores. Por lo tanto, sería fácil transferir el código entre familias y la función probablemente se retendrí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 debido a eso, no son útiles para el almacenamiento de códigos o variables de propósito general. Entonces, para usarlo, necesitarías almacenar explícitamente los valores en cada registro. Esto es aceptable si solo lo está utilizando para almacenar algún estado que debe sobrevivir en el apagado. Sin embargo, no es tan flexible como nos gustaría.
Aumentar el tamaño de los registros de copia de seguridad no ayudará a portar el código, ya que el espacio adicional no estaba disponible en el código anterior. Tampoco tienen mucho beneficio para mitigar el inconveniente de usar los registros de copia de seguridad, ya que las aplicaciones existentes lo han resuelto.
La SRAM con respaldo de batería no está disponible en todas las familias STM32F, es relativamente reciente. ST no ha tenido EEPROM en sus familias iniciales de STM32F, por lo que el área de BKP fue bastante importante. Sin embargo, puedo imaginar fácilmente a una persona de marketing inteligente que identifica un nicho de producto que se beneficiaría de una memoria mucho más respaldada por batería que los registros. Además, haz que sea un gran bloque de memoria "apropiada". 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 memoria SRAM con respaldo de batería, simplemente sucedería como un efecto secundario del funcionamiento del programa como normal. 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ías han estado en familias STM32F de algunas de las primeras familias. Fue esencial ya que mitiga la falta de EEPROM. Creo que se conserva por compatibilidad y para simplificar la transferencia de código y sistemas a las nuevas familias STM32. En muchos casos, una aplicación antigua se puede compilar y vincular con nuevas bibliotecas y "simplemente funcionará"
La SRAM con respaldo de batería es una innovación más nueva para STM32 y no está en las familias más viejas. Es más fácil de usar que los registros con respaldo de 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 mantener registros respaldados por batería.
Tener un consumo de energía diferente es un beneficio, pero IMHO, no es la razón por la que hay dos enfoques técnicos diferentes. Son su compatibilidad o mejora significativa.
