У кого нибудь есть примеры реализации взаимодействия с SD Card? Хотелось бы взглянуть.

Желательно под EP93xx. Угадал?

Я делал полную реализацию работы с MMС карточками памяти.
MMC включена в режиме SPI. Поддерживается файловая система FAT16.
Для пользователя реализованы функции поиска файла по имени, чтения и записи файла.
Мои услуги будут платными.

А мои - бесплатными. Новый год, все-таки. .
Вот оно - Нажмите для просмотра прикрепленного файлаПишите, если будут вопросы.

вот еще докучи хорошая и бесплатная файловая система Embedded Filesystems Library

Уважаемые.
Я конечно извиняюсь, но подскажите ни разу не грамотному.

Я правильно понимаю, что если отформатировать при помощи этой файловой системы SD карточку,
то эту карточку можно будет прочитать в любом карт ридере в том же WinXP.

бесплатно
Interfacing Philips LPC2000 ARM7TDMI-S with memory-cards (SD/MMC)
и
Interfacing ATMEL AT91SAM7S ARM7TDMI with memory-cards (SD/MMC)
_http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/index.html

Посмотри
http://sourceforge.net/projects/efsl

В файле "sd_spi_ep93xx.rar ", присланном aaarrr нет файловой системы. Есть только
функции чтения и записи блока.

внимательно читаем топик:

Doka, подумай хотя бы на один ход вперёд.

^

Флеш File System от PRLLC. Есть в местных закромах. Файловая система + интерфейс с SD

спасибо за файлы, пытаюсь разобраться...как я понимаю у вас sd-карта переводится в spi-mode посредством последовательности команд CMD0,CMD1,CMD59 и далее происходит работа в этом режиме.
вопрос: изначально, при включении питания sd-карта ведь находится в sd-режиме? и я могу работать в нём? и инициализационная последовательность в этом случае будет ACMD41, CMD2, CMD3? я правильно понимаю?

Да, стартует карта в SD-режиме, и последовательность инициализации будет именно такой. А какое железо используется, на борту есть контроллер SD? С программной эмуляцией SD-режима я бы не связывался.

всё то же самое - ep9307, а с програмной реализацией я уже связался (D[0:3],CMD,CLK всё завёл на PortB), Да кстати, команда ACMD41 ведь состоит из последовательности CMD55, CMD41...поэтому на данном этапе я посылаю CMD55 и жду ответа r1...но карта ничего не отвечает.

Интересно будет узнать, что из этого получится.
CRC данных там шибко неудобно считать - нужно вычислить CRC16 для потока по каждой линии отдельно, если правильно помню. Можно все скопом, но придется написать извращенную функцию.


А CMD0 подать не забыли? Без нее ничего работать не будет.

вон оно что выясняется...никакое CMD0 не подаю, дак CMD0 же переводит в SPI-режим или в Idle State, а ведь изначально карта находится в Idle State, ну я ничего и не подаю - включил питание и CMD55 туда!

CMD0 переводит исключительно в Idle State
А вот CMD1 это уже SEND_OP_COND.

Откуда такая уверенность что карточка изначально в Idle State, может в sleep mode неходится

В SPI-режим карта переводится подачей CMD0 только при низком уровне CS. Кроме того, после включения карте нужно подать ~80 пустых циклов CLK.
В Вашем случае еще понадобится включить четырехбитный режим - ACMD6.


По спецификации это действительно так. Однако, жизнь порой преподносит сюрпризы.

Ещё раз посмотрел док-ию, после power up она действительно находится в idle state.
Кстати посылка сначала команды CMD0 не изменяет ситуацию. (на следущую за ней CMD55, по прежнему не отвечает, точнее я пока смотрю только стартовый 0-бит, линия CMD глухо висит в 1)

Должна сначала ответить на CMD0. "Пустые" клоки после старта подаются? Как долго ждете ответ на команду?

~80 пустых циклов CLK на полёт не повлияло...а до четырёхбитного режима надо ещё дожить )



СТОП!!! Команда CMD0 ведь без ответа!
А после CMD55 клок идёт постоянно (пока не возникнет стартовый бит ответа)... а может у меня чего то с полярностью клока, как я понимаю у CLK активный уровень 1, долно быть что типа такого:
#define SDCLK PBDR_bit.PxDATA0 /* PortB.0 */
#define SDCMD PBDR_bit.PxDATA1 /* PortB.1 */
...
SDCMD=cmd_bit;
SDCLK=1;
Sleep(10);
SDCLK=0;
Sleep(10);
...

Да немного запамятствовал я..


Это в режиме SD CMD0 без ответа, а вот в SPI ответ R1

А вы уверены что у вас CRC7 правильно рассчитывается, ведь если на карточки проверка не прошла то она ничего и не отвечает.

да, crc7 считается правильно, используется процедура любезно присланная aaarrr (сомневаться в правильности не приходится)

To aaarrr:

У вас присутствуют такие строки в примере:
...
SSP1CPSR = 0x02; // 7.3728MHz
SSP1CR0 = 0xc7; // SPI Mode 3
...
Это означает SSPCLKout=283kHz?

Да, это в SPI режиме есть ответ, как уже заметили.


Данные защелкиваются по фронту, а выставляются картой по спаду CLK.


Это ошибка - SSPCLKout будет 3.6864MHz.

Похоже всё заработало, запутка была в том что я байты не в той последовательности отправлял
Однако, возвращаясь к вопросу о ~80 пустых циклах, где сказано что их нужно отправлять (выяснилось что они влияют на полёт). Я так полагал, что достаточно поставить 8 clk перед отправкой любой команды, и это уже позволяеет выдержать все тайминги между командами и ответами.

Если быть точным то там сказано 74 такта. Раздел Power-Up

почему то на команду ACMD41 приходит бит busy=0 и на последущую команду CMD2 не отвечает.

Так надо дождаться, пока карта не будет готова, постоянно кидая ей ACMD41.

т.е даже несмотря на то что питание на неё было подано за пару минут до того как я послал первую команду ACMD41, она ещё не соизволила сбросить бит busy?

Да, мне такое часто встречалось..
А если за пару минут то может она перешла уже в automatic sleep режим
К примеру вот что сказано про SanDisk:
Upon completion of an operation, the SD Card will enter the sleep mode to conserve power if no further
commands are received within 5msec.

Только не сбросить, а установить - бит Busy в OCR инверсный, насколько я помню.

Понятно, это заработало. А что такое за BUSY посылается (к примеру на команду CMD7 и.т.п) по линии DAT0?

Сигнал BUSY посылается. Первый ненулевой бит - это END-бит ответа, как я понимаю.

Он посылается после CMD7? После команды смотрю DAT0 и там постоянно 1. Однако следущая команда уже не проходит (нет ответа).

Напишите, какую последовательность команд (с аргументами) Вы даете до CMD7, и какую команду - после.

До CMD7 всё нормально. Посылаю CMD7 c аргументом RCA (и она переходит в trans mode) и сразу за ней посылаю CMD7 с аргументом 0 (ожидая что она перейдёт в stand-by), вот на вторую CMD7 ответ и не приходит.

Ответ может быть только от выбранной карты, т.е. на CMD7 с RCA=0 ответа быть не должно.

Ах, ну да, логично. Возвращаясь к вопросу о вычислении контрольной суммы, действительно, как можно было бы попроще вычислить контрольную сумму (crc64) при четырёх линиях данных.

Хорошая задача, были идеи, подумаю и напишу потом. А пока можно решить в лоб - будет медленно, но для проверки работоспособности сгодится.

чего то в лоб не получилось...не сошлось, как я понимаю стартовый и стоповый бит в crc не входит, считаем только по данным?

Да, только по данным.

всё равно не сходится.

Любопытный момент: есть две SD карты (Transcend 512 и 256 Mb) на одной написано 80x На другой 45x, как я понимаю скоростные характеристики. Однако в CSD регистре как у первой, так и у второй в поле TRAN_SPEED вижу 25 Mbit/s. Т.е макс. скорости (по чтению) декларируются одинаковые. Вопрос в чём же разница между 80х и 45х?

25Мбит/линию - это скорость интерфейса, и, скорее всего, у всех так написано. А разница между картами 80х и 45х должна выражаться в большей скорости выполнения команд записи и чтения у первых.

Почему при чтении блоков с адресов близких к максимальной ёмкости карты она просто не отвечает, так задумано?

А у меня она вообще не отвечает на комманду чтения сектора.

Как и когда можно подавать комманду чтения блока?
Потому что у меня блок не читается.

Остановился на следующем:
Подал комманду CMD16 с аргументом 1024 (для проверки)
Карточка выдала 0x40 - неверный аргумент
Потом подаю CMD16 c аргументом 512.
Ответ - 0x00, т.е все ок.

Далее подаю комманду CMD17: и все виснет
получаю одни 0xFF, response r1 нету и в помине.
Не говоря уже о признаке начала блока 0xFE.