SD-kort kompatibilitet med enklare MCU?

[Marta]

Är här någon med egen praktisk erfarenhet av hur det fungerar med SD-kort vid användandet av SPI ihop med t.ex. PIC18 e.dyl.?

Korten är ju gjorda för i sammanhanget svindlande hastigheter så då inställer sig frågan om det brukar vara problem med t.e.x trötta flanker eller annat som följer en enkel MCU?

Accepteras långa uppehåll i signaleringen för att t.ex. hantera block större än tillgänglig RAM-buffer?

Skiljer det mellan olika tillverkares kort när det gäller lämplighet i dessa sammanhang?

Allt står säkert i en spec någonstans, men nu efterfrågas praktisk erfarenhet av hur det faktiskt är.

[TomasL]

Nja, SD är väl rätt långsamma, PIC16/4MHz borde inte vara några problem.

Litet tillägg, så här säger standarden

All registers in SDIO only cards and the SDIO portion of Combo cards must complete read and write data
transfer in less than 1 second.

, så det går att köra rätt långsamt.

[Glenn]

Ja, tycker man dryga 100MB/sec är långsamt så.. fast de flesta tycker nog det är väldigt snabbt.

Skämt å sido, jag vet att du brukar propagera för den värdelösa dinosauriestandarden CF, men moderna SD-kort är både snabba och samtidiga smidiga att prata med efterssom dom kan prata SPI om man inte behöver den hastigheten.

SDIO har för övrigt exakt ingenting med saken att göra, det är en standard för att låta andra prylar kopplas in över SD-interfacet, tex kameror.

Exakt hur petigt det är med flanker osv vet jag dessvärre inte.

[E85]

Säger kanske inte mycket men jag har använt SD-kort för att lagra och spela upp ljud på en Atmega168 utan problem.

[blueint]

SDHC/SDXC kan möjligtvis ställa till det ifråga om timing och elektrisk specifikation.

[grapetonix]

Har hört att det ska fungera, klockans hastighet är väl frivillig och kan variera.
Kan vara bökigt att hålla på med något som följer en filsystemsstandard på system med magert minne dock,
så det enklaste är väl att göra nån form av interface där man kan tanka ut datan som en textfil
i en terminal (zmodem eller likn.)

[bearing]

victor_passe använder SD-kort kopplad till en PIC18, som jag förstått. Dessutom med FAT-bibliotek.
http://elektronikforumet.com/forum/view ... =3&t=53000

[Marta]

Det är just de nyare korten, som skulle vara bra om de kunde användas eftersom båda de nu aktuella applikationerna kräver massor av minne, jag är tveksam på vad de kräver.

Det där med 1 sekund max för läs/skriv var inte bra. Får väl bli en 40taggare MCU och externt RAM om nu blockstorleken kommer att kräva detta. 1 eller möjligen 2k borde kunna fungera, men större så räcker inte minnet i MCU'n för att buffra.

FAT32 skall inte vara något problem att hantera. Den ena applikationen har en enda stor fil som växer från slutet hela tiden (loggning). Den andra är read-only och lagras filerna på blankt kort får jag hoppas de inte blir fragmenterade eller i varje fall så pass sammanhållna att RAM räcker till för att bygga en lista med längd och startpunkt för fragmenten i en fil. Det behöver knappast implementeras en komplett driver för FAT32.

[TomasL]

Öh, vad var det för fel på 1 sekund, det är ju den längsta tiden en transaktion får ta.

[jesse]

Man måste ju inte läsa/skriva all data i minnet samtidigt (alltså i en och samma läs- eller skrivinstruktion). Det går ju att ta i lagom långa sekvenser och köra flera sådana efter varandra. Då kan du ju se till att ingen enskild skrivning tar mer än t.ex 100 ms.

[zealotry]

en liten guide för att snacka med ett SD kort från en Atmega16. http://www.avrprojects.info/avr-interfa ... -atmega16/. Det ser rätt trevligt ut tycker jag!

Dom nämner att SPI-bussen ska gå i 400khz..

[jesper]

@Marta:
Om du ska köra med en liten CPU, då kör du väl i alla fall SPI och timeouten i SDIO mode är helt ointressant.
Det går alldelest utmärkt att läsa (eller skriva) lite i taget från en sektor, du måste inte hantera alla 512 bytes på en gång. (Detta gäller i alla fall på de lite tidigare kort, vet inte hur det är med SDHC).
Även om det skulle vara en timeout på sekundnivå spelar det väl ingen roll i alla fall, en läsning skrivning tar ju bara några ms, även för en liten slö CPU.

Jag har lite gammal enkel testkod för bl.a mega8 här, mindre CPU än så, blir det nästan inte : http://svn.redegg.net/websvn/listing.ph ... kout_Demo/

Ladda ned exemplet och se dokumentationen i /doc som är genererat från Doxygen, där finns en del extra information.

[Marta]

Är blockstorleken bara 512 bytes är det inga problem att buffra och givetvis inte hellre problem med timing i så fall. Är det däremot 32K block så skapas inte loggdata i en takt av 32K per sekund och då skulle det inte fungera med att pausa mitt i blocket om det finns en 1s gräns. I den andra applikationen är det ungefär 20K/s som skall läsas och då blir det också problem, men skulle kunna lösas genom att läsa elefantblocket flera gånger och bara utnyttja en del varje gång förutsatt att MCU hinner med en sådan ineffektiv metod.

[janno]

Har du tittat på de färdiga biblioteken som Microchip har?
Längst ner på sidan finns alla filer och dokument för att läsa skriva SD kort.
http://www.microchip.com/stellent/idcpl ... e=en537238
Om inte hela filsystemet får plats så finns det nått att utgå ifrån. Stöd för SDHC verkar finnas med numera också. Jag själv ännu inte prövat praktiskt utan mest läst dokumentation. Om jag har förstått rätt så innehåller MDD filsystemet både stöd för FAT16 och FAT32.
Det jag läst är att på en PIC18 om man använder hårdvaru SPI kan inte SPI-klockan gå under 400kHz vilket krävs för att initiera SD-kortet i SPI-mode så det måste göras med bitbang.

Hittade kommentaren.
Från SD-SPI.c (efter installation på min dator: C:\Microchip Solutions v2011-07-14\Microchip\MDD File System)

Kod: Markera allt

//During the media initialization sequence, it is
//necessary to clock the media at no more than 400kHz SPI speeds, since some
//media types power up in open drain output mode and cannot run fast initially.
//On PIC18 devices, when the CPU is run at full frequency, the standard SPI 
//prescalars cannot reach a low enough SPI frequency.  Therefore, we initialize
//the card at low speed using bit-banged SPI on PIC18 devices.

/J

[jesper]

Blockstorleken för läs/skriv är ALLTID max 512 bytes.
På SDSC kort kan man dock sätta den lägre (CMD16, SET_BLOCKLEN), men 512 är default (gäller endast read, för write måste man alltid sätta blocklängd till 512). På SDHC och SDXC är den fixed till 512 (påverkar dock CMD42).

Detta är altså storleken på de block som skickas till och från kortet, med t.ex. READ_BLOCK och WRITE_BLOCK.
Kortet kan ha en större intern blockstorlek, men det behöver man inte bry sig om.