Je revisite certaines de mes habitudes de conception, et l'une d'entre elles est sérieusement examinée: le périphérique de stockage go-to SPI est des cartes (micro) SD, pour leur rapport prix / capacité et des vitesses généralement plus élevées.

Parmi les trois principaux types de dispositifs de stockage basés sur SPI - carte (micro) SD, DataFlash et 25CxxEEPROM SPI de série plus simple (et également en 24Cxxtenant compte de l' EEPROM intégrée sur les microcontrôleurs et de l' EEPROM I2C) qui est le support approprié pour les cas d'utilisation donnés au dessous de? Gardez à l'esprit que j'utilise tous les supports comme des périphériques de blocs bruts, donc l'argument "Les cartes SD ont besoin d'un système de fichiers" ne tient pas.

Cas d'utilisation:

• Configuration du système et données d'étalonnage. Exemples: adresse MAC pour l'interface Ethernet, tension mesurée de la référence de tension intégrée.
• Journaux. Exemple: données capturées à partir de capteurs.
• Code et ressources de code (trop gros pour tenir dans la mémoire du programme ou doivent être transportés de manière portable.) Exemple: mises à jour du système, chaînes d'internationalisation et de localisation, ressources d'interface utilisateur, polices.
• Sécurité et gestion des droits numériques. Exemple: clés numériques cryptographiques (publiques et / ou privées, symétriques et / ou asymétriques), signatures numériques.

Fondamentalement, le choix dépend principalement de deux critères: si les données à stocker sont grandes ou petites, et si elles sont réécrites souvent ou non:

• L'EEPROM est idéale pour les petites données qui changent souvent. La raison en est: il n'est vendu que pour les petites tailles, mais ils peuvent généralement être effacés d'un octet. De plus, l'endurance EEPROM est très élevée (millions de cycles).
• Flash est idéal pour les mégadonnées qui ne changent pas souvent. Il est disponible à bas prix pour les grandes tailles, mais lorsque vous devez écraser des données, vous ne pouvez le faire que pour une page entière, qui peut atteindre quelques ko. Et l'endurance est plus de l'ordre de 100 000 cycles.

Je n'entrerai pas dans plus de détails sur la différence entre les deux, elle a déjà été abordée:

• Quelle est la différence entre la mémoire Flash et l'EEPROM?
• Pourquoi utiliserait-on toujours une EEPROM normale au lieu du flash?

Concernant les cartes SD: La carte SD est un type de flash amovible, et en tant que tel, elle suit les mêmes contraintes qu'un flash ordinaire. Cependant, il utilise généralement un flash NAND alors que généralement, les puces flash série utilisent un flash NOR. Le flash NAND est plus pratique pour l'écriture (pages plus petites, effacement plus rapide) mais est moins fiable. Vous pouvez obtenir de mauvais blocs après un certain temps, si vous faites beaucoup d'écritures. Le niveau d'usure peut atténuer cela, mais il n'est pas toujours mis en œuvre dans les cartes SD bon marché ( est-il vrai qu'une carte SD / MMC porte le niveau avec son propre contrôleur? ). Vous pouvez l'implémenter dans un logiciel, mais ce n'est pas anodin.

Le choix de l'interface (I2C ou SPI) n'est cependant absolument pas lié. I2C est plus lent mais utilise moins de broches. L'EEPROM I2C est également généralement moins cher que le SPI, mais vous décidez généralement d'utiliser l'un ou l'autre en fonction de la façon dont vous avez attribué les broches MCU dans votre application.

Maintenant que vous avez donné des cas d'utilisation spécifiques, examinons-les un par un:

Configuration du système et données d'étalonnage

Eh bien, celui-ci ne met pas beaucoup de contraintes: ces données sont généralement très petites et ne changent pas souvent. Donc, ici, le plus simple est de le mettre là où ça coûte le moins:

• soit l'EEPROM MCU interne si vous en avez un
• ou un flash externe si vous en avez déjà besoin à d'autres fins
• ou éventuellement une carte SD si vous n'avez pas d'autre stockage persistant disponible. Notez cependant que, comme la carte SD peut éventuellement être retirée et insérée dans un autre appareil, les données d'étalonnage ne seraient plus cohérentes. Vous voudrez donc peut-être éviter cela.

S'il n'y a pas d'autres besoins de stockage persistant dans votre appareil et qu'il n'y a pas d'EEPROM interne dans le MCU, vous pouvez éventuellement utiliser une page flash spécifique dans le flash du MCU lui-même (si le MCU le permet). Sinon, vous pouvez vous rabattre sur une petite EEPROM externe.

Notez que dans le cas spécifique des adresses MAC, il existe des EEPROM qui sont vendues avec une adresse MAC préprogrammée, garantie d'être unique (par exemple Microchip 24AAxxx). Ce serait donc la voie à suivre, à moins que l'IEEE ne vous ait officiellement attribué un bloc d'adresse ou que vous soyez prêt à risquer d'utiliser des adresses attribuées localement.

Journaux

Ceci est généralement important et change souvent. Gros signifie flash, pas EEPROM. Vous pouvez donc utiliser une puce flash ou une carte SD, mais si les journaux sont vraiment réécrits souvent, vous feriez mieux d'utiliser une carte SD. Sinon, vous risquez d'user la puce flash, et si elle est soudée sur la carte, elle sera plus difficile à remplacer qu'une carte SD. Notez également que, lors de l'écriture de journaux en parcourant l'ensemble des pages flash, le nivellement de l'usure devient alors trivial à mettre en œuvre.

Dans le cas où ce sont de petits journaux, vous avez de la chance, optez pour l'EEPROM (tant que l'endurance est acceptable).

Notez que si l'endurance est un vrai problème, il existe des solutions supplémentaires avec une endurance pratiquement illimitée et une taille relativement grande: F-RAM et MRAM. Mais ceux-ci coûtent un bras et une jambe, et vous ne les avez pas mentionnés en option. Notez également que ces deux technologies plus récentes atteignent une vitesse d'effacement / écriture bien meilleure que le flash, donc pour la journalisation continue, cela peut être intéressant.

Code et ressources de code

Généralement gros, mais ne change pas souvent. Une puce flash externe (généralement un flash NOR) est idéale pour cela.

Sécurité et gestion des droits numériques

Celui-ci est plus délicat. S'il contient vraiment des données sensibles qui ne devraient jamais être extraites, vous feriez mieux d'utiliser une carte à puce au format SIM (éventuellement avec un firmware personnalisé). Mais cela complique bien sûr beaucoup la conception . Une solution alternative (plus facile et moins chère) peut être une puce de sécurité dédiée comme la série Atmel AT88SC, mais les commandes disponibles sur la puce doivent avoir un sens pour votre application spécifique. Que peut-on faire sur cette puce et dans quelles conditions doit-elle être soigneusement planifiée?

Si vous avez seulement besoin d'une sécurité "de base", le plus simple est d'utiliser l'EEPROM MCU interne. Il ne sera pas aussi sécurisé qu'une carte à puce ou une puce dédiée (qui contient des mesures de sécurité spécifiques, telles que la protection contre les attaques légères, les contre-mesures contre l'analyse de l'alimentation / des pannes au sein de la puce, etc.), mais c'est le mieux que vous puissiez faire.

Sinon, s'il n'y a pas d'EEPROM interne, vous vous retrouverez avec les mêmes options que pour les données de configuration / calibration. Cependant, l'utilisation d'une puce externe pour stocker des données sécurisées est un risque car les lignes de données peuvent être facilement surveillées avec un simple analyseur logique et les données sensibles extraites. Ainsi, même si l'EEPROM est considérée comme plus difficile à falsifier que le flash, le choix de l'un ou l'autre dans le cas d'une puce externe ne fait aucune différence du point de vue de la sécurité.

Enfin, la carte SD est certainement la pire idée ici, car elle est amovible. Les données sensibles pourraient alors être lues à partir d'un PC, sans même avoir besoin de matériel spécifique.