pic SPI et mémoire MMC

[marmotte]

bonjour

J'ai lu attentivement ce forum, et je suis très intéresse par la FAT32!
Sur ma mémoire flash, quand je lit dessus, je trouve le MBR sur le secteur 0 ( entre 0 et 512 Octets), et je le retrouve sur les secteurs 3 et 6 (entre 512*3 et 512*4 Octets, et entre 512*6 et 512*7 Octets ).

Est-ce normal? Voulez vous que je détaille ? (bon sa va faire très long...)

Oui c'est normal, il y a des sauvegardes du MBR en cas de corruption du secteur 0
-----

[Olorin113]

Bon j'ai trouvé le fichier, mais je ne sais pas comment interprété ce que j'ai trouvé.
En effet je commence avec
04 00 00 00
05 00 00 00
(...)
FF 00 00 00
00 01 00 00
(...)
FF 01 00 00
00 02 00 00
(...)
FF 02 00 00
00 03 00 00
(...)
FF 03 00 00
00 04 00 00
(..)
02 04 00 00
FF FF FF 0F

La taille fait 4096 octets, et j'ai une incrémentation de 04 00 00 00 à 02 04 00 00. L'adresse de départ est à h480C (18444) à h580B (22539).
Block h4800 au block h5800 en fait. Je suis en FAT32.
Je me demande si ce n'est pas crypté...

[Olorin113]

J'ai peut être une piste, mes arguments d'envoie...

[morbak]

Bonjour,

Mon projet : pic18f4580 + SD sur spi
J'arrive a lire puis ecrire le csd, cid, et block , pas de pb si ce n'est que ecrire 2 block successif ne fonctionne pas, mais ça ne doit pas être grave, ce n'est pas là mon soucis actuel.

Je fais un test pour identifier mon type de fat, FAT32 en l'occurance. Le test fonctionne ss pb.
Cependant afin des lires les divers block, j'utilise un offset défini à 0x10A00. (sect 133).
Je voudrais pouvoir trouver cette valeur en lisant la bonne adresse, mais c'est là que ça se corce, je n'arrive pas à la trouver.
Je ne suis dit que en lisant la carte avec EditHexa j'allais pouvoir solutionner le truc, mais pareil, le soft arrive a extraire la valeur offset, mais je n'arrive pas à voir la veleur hexa .

D'ailleur je ne voit pas le MBR et c'est là qu'est l'info, une idée svp pour m'éclairer

merci,

[invite21a51bdd]

Bonjour a tous,

mon projet de fin d'année consiste a faire une gestion de carte SD. Pour le moment nous nous consacrons a lire un secteur sur la carte ( le 1er) mais pas moyen... j'ai pris les source de mircrochip: http://www.microchipc.com/sourcecode/index.php#mmc mais, questions :

1) faut il obligatoirement mettre le CS à 1 pour pouvoir reveiller la carte ? car comme je n'ai qu'une seule carte j'ai mis dans mon hard le CS a la masse via une pull down...

2) Ou peut on trouver les codes de commande de la carte ? (exempe 0x00 0x51 etc ) j'ai regarder dans plusieurs data-sheet de carte SD mais nothing...

Merci d'avance.

[morbak]

Bonjour,
J'ai résolu mes petits soucis d'offset et autres... voilà pr ma part.

Tout d'abord ne fige pas le cs en hard. Fo l'exploiter en soft.
Comment echanges-tu avec la Sd, en SPI? As tu réussi la phase d'init du spi? ( si c'est le cas).
En ce qui concerne les diverses commandes et caracteristiques fait une recherhce de ce doc : "productmanualsdcardV2.2 en pdf" Y'a tout dedans.

Je t'invite à faire une tour sur pic18.free.fr, y'a qq infos sur la fat32 (qq boullettes repérées et d'autres en cours d'ajouts).
Et des liens.

Voilà,

[invite21a51bdd]

salut,

oui j'utilise un bus SPI mais je dois avouer que nous e nsommes au début... mon maitre de stage m'a donner un test de carte SD, je vais l'essayer ojourd'hui en esperant que ca fonctionnera... Merci pour l'info du CS, nous avons bricoler le hard pour avoir le CS sur une pinoche de notre pic (18f2550).

Merci et a bientot pour d'autre question

fofo.

[morbak]

Bonjour,

J'ai bouclé mon code pour 18f4580, quartz 10Mhz avec PLL, avec une sd en spi.
l'ecriture d'un fichier et son remplissage en log se passe bien.

J'ai opté pour gérer le chaînage de fichier, car il me semblait un peu risqué d'utiliser une SD "clean" (fraîchement) formatée, de créer un fichier avec le pic, puis ensuite (par ex) de récupérer ce fichier sur un pc , de la déplacer, modifier, supprimer, le remettre...etc ....
visuellement et sur un pc, ça ne change rien, mais la FAT s'en trouve en peu bousculée et fragmentée.

Bref partant de ce constat, chaque fois que je rajoute des info dans mon fichier, via le pic, je lance une recherche de cluster de libre en FAT. Et c'est là que j'ai commencé à vérifier le temps necessaire à trouver un cluster de libre et surprise (enfin oui et non).

Ma sd fait 2Go, pratique pr stocker plein de log (...)
1/ Sur une sd "clean" avec 1 seul fichier de créé contenant 1 octets:
tps pour trouver le cluster vide : immédiat

2/ Sur une sd blindée quasi taquet (histoire d'avoir le prochain cluster de libre dans le fin fond de la FAT:
tps pour trouver le cluster vide : 2min et des poussière.

Je m'y attendait un peu car parcourir, à chaque ajout de log, les 3773 secteurs de la fat à raison de 128 possibilités, par secteur, à vérifier si la valeur de l'entrée est libre (cad si égale à 00 00 00 00), ... ben ça prend du temps, mais je ne pensait qd même pas autant.


Alors j'aurai voulu savoir si qq1 à déjà rencontré ce petit inconvénient et, si oui , comment améliorer le bouzin.

J'ai bien penser à :
- squizer le test de cluster libre et partir du principe que le prochain cluster libre est le suivant (ds la limite de la taille de la FAT) mais adieu le chaînage de fichiers, et ce qui veux dire plus de bidouille du fichier une fois sur le pc, ou alors un formatage avant d'y poser le (et l'unique) fichier fraîchement bidouillé, comme ça le chaînage de ce fichier sera continu.

- Pousser plus haut l'horloge, mais je ne vais pas gagner énormément, je pense.

- Changer de Micro..

merci,

[asmodyne]

Oui c'est normal, il y a des sauvegardes du MBR en cas de corruption du secteur 0

Ah, tiens ? Je croyais avoir lu marmotte précédemment, qui soutenait qu'un support formaté ne contenait qu'un seul master boot record...

Marmotte, le but de FS science est (était) d'aider son prochain, pas d'enfler son égo. *soupir*

C'est ce genre de dérives masturbatoires qui m'ont conduit à ne venir sur ce forum que lorsqu'un message privé m'y incite. *re-soupir*

[asmodyne]

La solution ? Changer de µC... La série 18F n'est qu'une série 8 bits... et les horloges de 48Mhz n'apportent pas d'amélioration significative (n'oubliez pas que la fréquence d'instruction est toujours divisée par 4).

FOSC = HSPLL_HS, PLLDIV = 5, CPUDIV = OSC1_PLL2, USBDIV=2

Donc, même avec un 18F4550 en USB -> PLL à 96Mhz (pour obtenir une fréquence maximale qui reste compatible avec le périphérique USB du µC), division par 2 pour obtenir Fosc (48Mhz) puis division par 4 pour obtenir Finstr (12Mhz).... Ouch ! C'est mou, c'est mou ! Surtout avec 8 bits par manip'.

morbak : Dans la mesure où la carte SD n'a pas été retirée (ce que tu dois surveiller) tu peux envisager de mémoriser les 4 octets de l'adresse du dernier cluster écrit pour ton "mégafichier" dans l'EEPROM du PIC. Les accès consécutifs sur une carte "blindée de données" s'en trouveraient alors grandement accélérés.
Tes 2 minutes d'attente ne serait alors nécéssaire que lors d'une réinsertion de la carte ou après une extinction du dispositif (car une fois l'alim coupée, impossible de savoir si les données présentent sur la carte sont indentiques à celle laissée lors du "power-off" de ton circuit.)

Pour ce qui est d'une carte SD utilisée telle une "EEPROM LBA" bien dodue, c'est le grand luxe dans la mastication des données... Les accès sont rapides, on fait ce que l'on veut... On implément son propre formatage... maiiiiiis...la connectivité dans tout ça ? Comment récuperer les données sur un ordi ? L'usb ?
lol...

Le périphérique USB d'un PIC18Fxx50 est semblable à un chameau nourri à l'ostie... échanger 1Mo de donnée ressemble à une croisade à bord du 5"1/4 express... On croirait voir revenir le temps des Atari à cassette chrome.
Le périph usb des PIC est utile à l'implémentation de périphériques HID, ou d'acquisition de statut physique du dispositif (usb en mode CDC), rien de mieux.

Travailler en 8 bits, c'est faire des concessions... mais c'est le pied !

[RISC]

Salut,

Une amélioration de la vitesse peut être obtenue en utilisant le PIC18FxxKxx qui fonctionnent à 64MHz c'est à dire 16MIPS au lieu de 12 MIPS.
Il existe par exemple les PIC18F13K50 / 14K50 avec l'USB à bord.
Attention les PIC18 "K" fonctionnent en 3.3V.
Je ne sais si l'interface SPI bénéficie aussi de l'augmentation de la vitesse.
Sur les PIC18 standards je crois que la vitesse max du SPI est de 10bits/s pour les "K" il faudrait vérifier...

a+

[asmodyne]

Ah oui, tiens ! Cette série de µC mériterait quelques bidouilles autour d'elle !

Merci pour ce rappel d'info, RISC !

[morbak]

Bonjour,

C'est vrai qu'en mémorisant l'adresse du dernier cluster ça gagnera qd même du temps dans ce cas là. Modif en cours alors !
Je surveille bien la présence de la sd, donc là y'aura pas de soucis.

sinon j'ai des DsPic33F... et le c qui va avec, faudrait que je tente la portabilité histoire d'effectuer une breve comparaison.
proichaine étape pt.

Je vs tiens au jus.

Thx,

[morbak]

Bonjour, et meilleurs voeux

Je me suis repenché sur mon petit bout de soft pour la FAT32 et cart SD.

Il se trouve que j'ai 1 ou 2 soucis et je n'arrive pas à mettre le doigt là où je fait erreur.

En résumé:
- J'écrits des fichiers en short contenant 1 octets, les infos de dates et heures sont fixée à 0, car le FF pose pb ss windows.
- J'en écris suffisement pour blinder le 1er lcuster de la Root directory (donc 128).
- Chaque fichier occupe donc 1 cluster de data (8 secteurs), bref.
- Je lit ma carte ss Windows, pas de soucis, mes 128 fichiers sont là.
- Je remet la carte sur mon 18F et récrit plusieurs fichiers en plus, afin que le prog trouve un cluster de libre en FAT pour continuer la Root Directory. Chose faite, je fait le chainnage du cluster de base de la RD (a savoir le 2 ds la FAT et je pointe cette valeur sur l'entrée du cluster trouvé précédement). Quant à l'entrée du cluster trouvé ell indique un EOF.
- Je met la carte ss Windows, je n'ai pas de message d'erreur, mais pas non plus les fichiers rajoutés.

J'ai beau scruter la structure de ma FAt, le chainnage Data et RD, je ne voit pas le soucis...
QQ1 aurait-il une idée?

Question 2:
- Qd je fait un formatage de la SD ss Windows avec l'explorateur, la FAT est bien RAZ, mais les noms de fichiers et leurs données restent présent. Ok, le 1er cluster de la RD est lui tout à 0, mais lorsque commence le chainnage de la RD sur un cluster de libre, il se peux que ce cluster soit bien indiqué libre par la FAT, mais qu'il y ait des data (anciennes) à cet emplacement et donc comment faire pour checker si l'entrée du fichier est potentiellement libre ou non, car le 1er octet de l'entrée de cet fichier peux prendre toutes les valeurs quasiement, donc adieu un test... j'ai loupé qqch?

En espérant avoir été suffisement clair?!

Merci d'avance.

[RISC]

Salut,

Je je connais pas la souce de tes librairies pour cartes SD.
Tu peux regarder celles de Microchip, elles fonctionnent sur les PIC18 et les 16 bits.

a+

[morbak]

Bonjour,

En faite j'ai pas utilisé de source particulière, la doc FAT32 de Microsoft et la doc de la sd et pis roule un peu de tps libre et voilà.

Pr ma 2e question je pense avoir trouvé la solution (en allant au boulot HeHe). En fait vu que je connait le prochain cluster de libre, il suffit (surement) de mettre à 0 tous ses secteurs, avant d'y mettre une entrée fichier et comme ça au prochain tour le 1er octet de l'entrée svte sera à 0, donc libre...

Pr mon soucis de chainnage de la RD, là j'ai pas d'idée pr le moment.

Merci,

[simequip]

Bonjour tout le monde.

Je me permet de relancer ce topic fort intéressant car je rencontre quelques problème pour causer avec ma carte SD.

En faisant des recherches sur le net j'ai trouvé plein d'exemple qui explique comment initialiser une carte SD. Comme pour Karl2mil1 j'ai commencé mes essais avec une MMC.
Maintenant tout marche sur cette carte, je l'initialise, j'écris et je lis.

Vu que tout fonctionne j'ai donc voulu tester avec une carte SD et la plus rien ne marche. Lorsque j'envoie la commande CMD0 la carte me retourne 0xFF. Je ne comprends pas pourquoi elle fait ça vu que j'ai lu qu'une carte CD se géré de la même manière qu'une MMC.

Avez vous déjà rencontré se problème?

Merci d'avance pour vos réponses.

[simequip]

C'est bon j'ai compris.

En fait ma carte SD ne faisait pas contact avec le support SD xD