Bonjour,
Je viens de lire le sujet : http://arduino.cc/forum/index.php/topic,119257.0.html
Et je me dis que pour le stockage externe on a l'habitude de penser carte SD mais que dans bien des cas elle me parait sur-dimentionnée.
J'ai failli répondre dans le sujet mais je me suis dit que ce serait le polluer et j'ouvre une nouvelle discussion.
En inconvénient à la carte SD je vois l'utilisation du bus ISP (nombre de broches : ISP + 1 broche par composant sur le bus) et de librairies lourdes et à problèmes.
En avantage leur capacité et elles sont lisibles directement par un ordinateur (si formatée en fat).
Question : sont-elles plus simples à manipuler si elle ne sont pas formatées "fat" mais utilisées comme un moyen brut de stockage comme une eeprom ?
L'EEprom externe utilise l' I2C (twi) soit 2 broches seulement quelque soit le nombre de composants sur le bus.
Les bibliothèques pour piloter l' I2C sont validées, fiables et simples d'emploi (voir la réalisation d'Icare : http://arduino.cc/forum/index.php/topic,112496.0.html. -> code source très clair).
On trouve couramment des capacités allant jusqu'à 32k, 64k et 256kbits. On peut trouver moins facilement 1M et au delà.
Par contre il faut écrire un programme pour les lire.
J'ai mis la programmation de ces deux composants à mon programme de rentrée, si vous avez des remarques et conseils à prodiguer je suis preneur.
68tjs:
En inconvénient à la carte SD je vois l'utilisation du bus ISP (nombre de broches : ISP + 1 broche par composant sur le bus) et de librairies lourdes et à problèmes.
En avantage leur capacité et elles sont lisibles directement par un ordinateur (si formatée en fat).
Si tu as déja un périphérique SPI (shield ethernet par exemple) tu ne "perd" qu'une broche au final (broche SS).
68tjs:
Question : sont-elles plus simples à manipuler si elle ne sont pas formatées "fat" mais utilisées comme un moyen brut de stockage comme une eeprom ?
Oui, utiliser une carte sd non formaté avec un systéme de fichier demande beaucoup moins de ram / code
Tu as juste à envoyer les commandes d'initialisation et aprés tu travaille en page de n octets en lecture/écriture.
68tjs:
On trouve couramment des capacités allant jusqu'à 32k, 64k et 256kbits. On peut trouver moins facilement 1M et au delà.
Par contre il faut écrire un programme pour les lire.
ça peut suffire pour certain projet, mais pour d'autre même 4Mbits c'est pas assez
sont-elles plus simples à manipuler si elle ne sont pas formatées "fat" mais utilisées comme un moyen brut de stockage comme une eeprom ?
. Plus simple, oui , mais pas aussi simples et 'directes' à utiliser que les EEPROM s'il s'agit de modifier individuellement des octets.
L'écriture sur SD, même en 'brut' ('raw', sans systeme de fichier) nécessite me semble-t-il de travailler par blocs de 512 octets.
Un buffer de 512 octets en ram reste donc indipensable pour pouvoir écrire par secteurs.
68tjs:
...
J'ai mis la programmation de ces deux composants à mon programme de rentrée, si vous avez des remarques et conseils à prodiguer je suis preneur.
pas de conseils particuliers, mais plus du choix à faire toujours en fonction de l'objectif à atteindre
si tu pars de rien (pas de "compos mem" dans la manche en telle ou telle techno) )
al1fch:
Un buffer de 512 octets en ram reste donc indipensable pour pouvoir écrire par secteurs.
Pas forcément
Tu peut très bien faire des écritures en temps réels sans utiliser de buffer.
Pour la lecture pareil, tu peut récupérer juste ce qui t'intéresse en ignorant les octets avant et aprés la zone en question.
