Bonjour,
En espérant ne pas déclencher de guerre ARM/PIC, je voulais savoir si certains µC proposent directement des drivers permettant de gérer une interface pour carte SD ou SDD??
Je dois faire une étude des différents µC pour un projet et je voulais savoir si on doit s'attendre à acheter ce pilote ou non.
Merci d'avance,
En fait la care SD dispose de deux modes de fonctionnement, en pur SPI ou en mode 4 bits de donnée. Les micros sans port dédié vont utiliser le SPI, qui est plus simple à mettre en oeuvre, mais moins rapide. Ceux avec port dédié incluront généralement les 4 bits de donnée.Envoyé par scoobi
En dernier recours, le SPI est un protocole très simple qui s'apparente au fonctionnement des registres à décalage et peut être implémenté en soft, mais là, ne compte pas sur des performances....
L'accès hardware n'est que la partie immergée de l'iceberg. Il faut aussi gérer le système de fichier sur ta SD, certainement du FAT. En ce moment, la référence, c'est FatFS:
http://elm-chan.org/fsw/ff/00index_e.html
PS: comparer les ARM aux PICs, c'est un peu comme comparer les forces allemandes et polonaises en 40
Salut,
Pour les PICs il existe des librairies officielles pour les carte SD et uSD qui gèrent les FAT16 et FAT32 que tu peux trouver en téléchargeant le package des librairies gratuites.
Ces librairies sont disponibles en source et libres de droit (pas de royalties) et fonctionnent sur les PIC18, tous les 16 bits (PIC24 et dsPIC) ainsi que les PIC32.
Attention au FAT32...voir le site Microsoft : license nécessaire si utilisation des noms > 8.3 ....
a+
La belle affaire, c'est vrai que j'ai proposé une solution gratuite et universelle, mais tu ne l'as sans doute pas vue
ok, merci pour votre aide car jusque là je n'avais trouvé qu'une seule lib :elfs... Je pense que de ce côté là c'est bon; reste "plus qu'à" choisir un µC.
Pour ce qui est du système de fichiers, sur beaucoup de forum il ressort que c'est une étape difficile, nous verrons bien!
regarde mon lien au-dessus sur FatFS
oui j'ai régardé et c'est une solution qui mérite de s'y intéresser. Il y a un même un tuto concernant les cartes SD qui va m'être fort utile!
RISC -> je n'ai pas trouvé de restriction pour le fat32 concernant la régle de nommage.
Salut,
Je confirme pour les FAT32 (noms longs) : http://www.microsoft.com/presspass/p...nasonicpr.mspx
a+
Ah ok c'est toujours bon à savoir....
Sinon j'ai une dernière question: j'ai regardé les sources pour FatFS et je n'ai pas trouvé de fonction faisant appel à la liaison SPI, cela implique-t-il que ça sera à moi de les développer?
Tu as l'implémentation dans les exemples en bas de page
Bonjour!
Si le logiciel est bien écrit, la partie FATFS ne doit avoir aucun
rapport avec la partie SPI. Donc il n'est pas étonnant que FATFS
ne fasse pas appel à SPI.
Pascal
donc donc FATFS s'appuie sur le mode 4 bits de données, c'est bien cela? dans ce cas par quel protocole passe les données?
Bonjour!
Non, ce n'est pas ce que je voulais dire. Ce que je voulais dire,
c'est que FATFS n'a rien à voir avec SPI ou avec le mode 4 bits
ou avec le bus PCI comme sur les PCs.
Donc l'implémentation de FATFS doit être indépendante de
l'implémentation de SPI ou bus 4bits, ou PCI, etc.
Ce qui veut dire que FATFS n'appellera jamais directement
des commandes SPI ou des commandes PCI.
Pascal
Désolé d'insister mais je trouve cela bizzare... Il suffit de compiler FATFS pour mon µC et "tirer 9 fils" pour que cela fonctionne?
Parceque j'ai regardé hier cette partie: http://www.siwawi.arubi.uni-kl.de/av...rds/index.html
et dans tous les cas, il parle d'une interface SPI...
Tu es sur d'avoir lu le document?
Donc pour faire le lien entre ton micro et ta SD, tu es censé écrire ces 6 fonctions. Seulement, elles sont dans les exemples et les ressources.....Since the FatFs module is completely separated from disk I/O layer, it requires following functions at least to access the physical media. When O/S related feature is enabled, it will require process/memory functions in addition. However the low level disk I/O module is not a part of FatFs module so that it must be provided by user. The sample drivers are also available in the resources.
disk_initialize - Initialize disk drive
disk_status - Get disk status
disk_read - Read sector(s)
disk_write - Write sector(s)
disk_ioctl - Control device dependent features
get_fattime - Get current time
Oui j'ai du mal m'exprimé, car je parlais justement de ces fonctions, voulant savoir s'il fallait les écrire soit même ( en fait c'est logique car dépend des µC...). et ces fonctions utilisent la liaison SPI comme par exemple celle-ci:
DRESULT disk_write (
BYTE drv, /* Physical drive number (0) */
const BYTE *buff, /* Pointer to the data to be written */
DWORD sector, /* Start sector number (LBA) */
BYTE count /* Sector count (1..255) */
)
{
if (drv || !count) return RES_PARERR;
if (Stat & STA_NOINIT) return RES_NOTRDY;
if (Stat & STA_PROTECT) return RES_WRPRT;
if (!(CardType & CT_BLOCK)) sector *= 512; /* Convert to byte address if needed */
if (count == 1) { /* Single block write */
if ((send_cmd(CMD24, sector) == 0) /* WRITE_BLOCK */
&& xmit_datablock(buff, 0xFE))
count = 0;
}
else { /* Multiple block write */
if (CardType & CT_SDC) send_cmd(ACMD23, count);
if (send_cmd(CMD25, sector) == 0) { /* WRITE_MULTIPLE_BLOCK */
do {
if (!xmit_datablock(buff, 0xFC)) break;
buff += 512;
} while (--count);
if (!xmit_datablock(0, 0xFD)) /* STOP_TRAN token */
count = 1;
}
}
release_spi();
return count ? RES_ERROR : RES_OK;
}
Bonsoir!
En fait dans l'exemple ci-dessus, le FATFS appelle des fonctions
du driver. J'ai réécrit un FAT complet en plusieurs versions qui
dépendent de ce que l'on veut faire avec. Ce que j'ai fait:
j'ai défini des fonctions similaires à celles ci-dessus. Il n'y
en a que 4.
FatDevInit
FatDevReadBlock
FatDevWriteBlock
FatDevClose
et le FATFS les appelle. J'ai appelé cela Dev plutôt que disk parce
qu'il faut vivre avec son temps: sur les systèmes embarqués,
il n'y a jamais de disque. Ou presque. Et Dev est plus général
et ne sera donc jamais démodé.
Maintenant, si je veux utiliser une SD, j'écris son driver SD(.h, .c)
avec les fonctions suivantes
SDInit
SDReadBlock
SDWriteBlock
SDClose
Et dans un fichier config.h (qui est inclus dans FATFS.c), je définis:
#define FatDevInit SDInit
#define FatDevReadBlock SDReadBlock
#define FatDevWriteBlock SDWriteBlock
#define FatDevClose SDClose
Avantage: je n'ai jamais à édite FATFS sauf bien sûr quand je trouve
un problème dedans. Et je peux réutiliser le même fichier pour
une carte SD, une compact flash, etc…
Autre chose: le programme ci-dessus montre un exemple
d'écriture multiblock. Dans le cas d'un système avec peu de
mémoire (quelques kO), on ne peut pas avoir de buffers
suffisamment grands pour écrire beaucoup de données.
Donc je ne serais pas étonné que le code ci-dessus soit
inutilisable tel quel.
Pascal
Ok merci, ça s'éclairci de plus en plus... je n'en suis qu'a la phase d'étude, on n'a même pas encore choisi d'architecture, c'est pour cela que c'est vague. Vivement que je commence...
si j'ai bien regardé, je n'ai pas vu de fonction de formatage pour FATFS, est ce que c'est du à coder?
Bonjour!
Non, ce n'est pas bien difficile.
Il faut juste (de mémoire):
1. Écrire un MBR;
2. Effacer les tables;
3. Effacer le folder ROOT.
Je suppose que c'est un système embarqué et que vous n'avez
pas besoin de hiérarchie de répertoires…
Pascal
oui effectivement, ce sera pour un système embarqué. Dans le même esprit, quant est il des fonction des check disk? je n'en ai pas trouvé pour FATFS, mais est-ce vraiment utilie? là je suppose que c'est un peu plus dur à implémenter.Je suppose que c'est un système embarqué et que vous n'avez
pas besoin de hiérarchie de répertoires…
En tout merci à tous pour les réponses.
Bonjour!
Je ne sais pas ce que fait check disk (du moins je me doute, mais je
ne sais pas dans le détail), mais à mon avis, ça n'a aucun intérêt
pour un système embarqué dont le programme n'est pas dans la
carte SD mais dans la flash du processeur.
Pascal
ok merci pour l info!
