Avez-vous besoin d’un File System embarqué?
Avez-vous besoin d'un File System ?
Avec le File System adéquat, le concepteur d'un IoT embarqué va économiser du temps et des composants. Ceci grâce à des fonctionnalités qui améliorent la conception et utilise mieux les ressources.
Photo by ThisIsEngineering (Pexel.com )
Vous concevez donc un système embarqué, probablement pour l’Internet des objets. Une question que vous vous posez peut-être est la suivante : “Ai-je besoin d’un File System (système de fichiers) ?”.
Si le pilote ou le micrologiciel existant du périphérique gère un grand nombre de fonctions de gestion de la mémoire, un certain nombre de questions importantes restent en suspens. Qu’en est-il des routines dont vous aurez besoin pour tester ces fonctions ? Et que se passe-t-il si les données que vous enregistrez dépassent l’espace que vous avez alloué ? Vous devez maintenant écrire des routines pour gérer l’expansion de l’allocation. Peut-être pouvez-vous simplement créer deux zones distinctes et basculer vers la seconde lorsque la première se remplit – la liste est longue.
Tous les File Systems ne sont pas créés égaux.
Un autre problème: tous les File Systems ne sont pas créés égaux. Il y a aussi une limite que vous ne voulez pas franchir (ou être poussé au-delà). C’ est celle du nombre et du cout des composants à utiliser . Ceux-ci pourraient augmenter si vous êtes contraint par un système de fichiers que vous ne pouvez pas modifier ou adapter aux exigences de votre conception.
C’est un véritable casse-tête, mais plongeons-y.
Le cas des supports Flash
Concentrons-nous sur les supports flash pour l’instant. En fait, il s’agit du stockage le plus courant pour les systèmes embarqués. Ce type de support peut être dans un format brut (flash NAND ou NOR) ou intégré sous une forme quelconque. Par exemple, eMMC, support SD ou CompactFlash. Donc, les pilotes de supports Flash devront prendre en charge la détection et la correction des erreurs. Ainsi que la gestion des blocs défectueux, ce qui se traduit par un stockage simple basé sur des blocs.
Pour commencer, ce support de stockage peut être considéré comme un pool de mémoire. Le pilote ou le microprogramme du support flash s’occupera de l’ajustement de l’usure, ce qui signifie que le support peut être adressé directement (écrire dans le bloc 1, lire dans le bloc 2, etc.) sans dépasser les limites d’effacement dans une section particulière. Les premières implémentations du BIOS de PC utilisaient en fait la SRAM du CMOS pour stocker les paramètres du BIOS, bien qu’elle ne soit pas directement accessible en tant que pool de mémoire. Les implémentations ultérieures du BIOS ont utilisé des supports flash comme stockage standard à la fois pour les paramètres du BIOS et pour le code BIOS lui-même.
La journalisation des messages, qu’il s’agisse de débogage ou d’exécution, est une utilisation courante des supports de stockage. Une application peut écrire dans une zone de journalisation en gardant la trace d’un pointeur de journalisation actuel et en l’enveloppant lorsqu’il atteint la fin. Ces routines doivent être aussi solidement testées que le reste du système embarqué, bien sûr.
Considérations sur la complexité
Si plus d’une zone de journal doit être écrite, il faut maintenir deux pointeurs. Ceci , augmente de façon correspondante de la complexité des tests. Si chaque zone de journal doit être écrite à partir d’un thread différent, il faudra ajouter encore plus de code de surcharge. Ceci, car la plupart des mémoires flash ne permettent pas deux écritures simultanées.
Un autre usage des supports de stockage dans un dispositif embarqué est de conserver les paramètres de configuration. En supposant que ces derniers puissent être modifiés au moment de l’exécution, la gestion d’une coupure de courant devient plus complexe. Deux copies des paramètres peuvent être conservées, une mise à jour en cours d’exécution écrasant l’ancienne copie. Ce code doit également être testé de manière approfondie – une défaillance à ce niveau peut entraîner la perte des paramètres ou même le blocage de l’appareil.
L'argument en faveur d'un File System
Tout ce qui est plus complexe que les exemples cités précédemment est probablement mieux géré par un File System. De tels systèmes de gestion de fichier peuvent gérer plusieurs fichiers, plusieurs threads et une interruption de l’alimentation. De plus, l’utilisation d’un File System donne accès à des informations supplémentaires provenant des métadonnées – date et heure de création et/ou d’accès au fichier, taille du fichier et attributs.
Les attributs de fichiers permettent de contrôler qui a accès à un fichier, ce qui permet à un appareil d’avoir plusieurs utilisateurs et une certaine sécurité de base. Au-delà du File System FAT de base proposé par Tuxera, il existe des options telles que la famille Tuxera Reliance, avec des attributs OEM complets et la prise en charge de groupes et de permissions de style Linux.
Enfin, un File System est pratiquement indispensable si votre appareil embarqué doit être connecté à un ordinateur de bureau ou à une station de travail. Ces machines plus grandes accèdent à toutes leurs données par le biais de systèmes de fichiers ou d’abstractions. L’alternative est un pilote personnalisé pour copier une image média et aussi analyser en paquets de données significatifs. Ceux-ci peuvent ensuite être stockés dans des fichiers ou insérés dans une base de données locale.
Éviter les surcoûts de nomenclature avec le bon File System
Cependant, il y a plus important que l’ajout de toutes ces fonctionnalités. C’est la possibilité de décharger les tests supplémentaires à un tiers. Le développeur du File System peut effectuer des tests plus approfondis et fournir une base solide, ce qui permet à votre équipe de test de s’en tenir à ce qu’elle sait faire : tester votre conception et votre application particulières.
Bien sûr, la fonctionnalité du système de fichiers nécessite également des ressources supplémentaires pour votre conception. Travailler avec un paquetage de File System qui ne peut pas être modifié peut pousser vos ressources au-delà de la limite et augmenter le coût de votre nomenclature.
Une meilleure alternative est un système de fichiers prêt à l’emploi qui peut être facilement modifié ou adapté pour obtenir juste ce dont vous avez besoin pour la conception, et pas plus. Tuxera Reliance EdgeTM offre aux développeurs la flexibilité et le contrôle déterministe nécessaires pour maintenir les coûts de ressources inutiles au minimum, tout en réduisant les dépenses de temps liées aux tests.
Dernières réflexions
Avez-vous bien besoin d’un File System ? En bref, si vous souhaitez stocker des données sur le support, vous devez soit écrire vous-même un système de fichiers primitif (avec tout ce que cela implique), soit en utiliser un qui est déjà conçu avec précision pour une utilisation efficace des ressources et une personnalisation. Cette dernière option vous permet de réduire vos besoins en matière de tests logiciels, au prix d’une éventuelle fonctionnalité inutilisée.
La possibilité de modifier un système de fichiers pour l’adapter à vos besoins – en termes de taille, de performances et de fiabilité – peut s’avérer cruciale et vous faire économiser potentiellement plus de temps et d’efforts que l’écriture d’une alternative de base de journalisation à un système de fichiers.
En savoir plus
Voire notre page sur les File Systems.
Voir les produits Tuxera Reliance Edge.
0 commentaire