SD карта через SPI Опции

[justontime]

Вроде простой вопрос, а вот явного ответа на него пока не нашел - при работе с SD картой по SPI протоколу нужно ли как-то (паузами) разделять байты в пакете ?

В смысле, можно ли при выполнении, например, команды CMD17 послать на карту все 520 байт (естественно, одновременно при этом читая) одним равномерным потоком битов ?

Я понимаю, что с вероятностью практически 100% можно, но сбивают с толку картинки, на которых всегда нарисованы увеличенные паузы между отдельными байтам. Пытаюсь читать стандартную спецификацию, но даже сокращенный вариант с непривычки еще то чтиво...

Вопрос возник, так как после переделки моей схемы с побайтовой работы на поблочную что-то работать пока не желает, вот и пытаюсь понять, в каком направлении разбираться...

[smalcom]

посмотрите реализацию от ChaN'а. Там код не сложный и, в принципе, основные внутренности видно в одном-двух файлах.
ЕМНИП программные паузы не используются, но запрашивается состояние карты.

[justontime]

ЕМНИП программные паузы не используются, но запрашивается состояние карты.

Э-э... А как можно запросить состояние карты посредине процесса чтения блока ?

[_4afc_]

Вроде простой вопрос, а вот явного ответа на него пока не нашел - при работе с SD картой по SPI протоколу нужно ли как-то (паузами) разделять байты в пакете ?

Я байты не разделял ни паузами ни выбором кристалла.

В смысле, можно ли при выполнении, например, команды CMD17 послать на карту все 520 байт (естественно, одновременно при этом читая) одним равномерным потоком битов ?

Я команды посылал отдельно, 512 байт данных отдельно по ПДП - работало.

посмотрите реализацию от ChaN'а. Там код не сложный...

В некоторых МК паузы и подсветка байта при помощи выбора кристалла задаются режимами работы SPI так что код не всегда может помочь.

[justontime]

Я байты не разделял ни паузами ни выбором кристалла.

Я команды посылал отдельно, 512 байт данных отдельно по ПДП - работало.

Вообще я именно так и пытаюсь сделать. А у Вас ПДП сплошным потоком битов работал, или все-таки с паузами между байтами ?

[smalcom]

например так:
1. отправили данные сектора
2. в цикле проверяем статус

[justontime]

например так:
1. отправили данные сектора
2. в цикле проверяем статус

Т.е. шла речь о проверке статуса не при чтении/записи данных, а после засылки команды ?

Вообще интересует, в первую очередь, возможность посылки именно блока данных сплошным битовым потоком, без пауз между байтами.

[smalcom]

именно потоком это и делается
http://elm-chan.org/fsw/ff/en/dwrite.html

[justontime]

именно потоком это и делается
http://elm-chan.org/fsw/ff/en/dwrite.html

Я не вижу там ничего насчет физической организации процесса, а более высокий уровень меня никаким боком не интересует.

[_4afc_]

Вообще я именно так и пытаюсь сделать. А у Вас ПДП сплошным потоком битов работал, или все-таки с паузами между байтами ?

Я работал на AT91SAM7S64, насколько я понимаю он ставит паузы только при смене CS, а он у меня ручками переключался.
Запись по ПДП и посылка команд у меня тогда не получилась, а вот скоростное чтение - работало:

CODE

inline void if_spiOFF(void) {AT91C_BASE_PIOA->PIO_SODR = CS0;} // set high
inline void if_spiON(void) {AT91C_BASE_PIOA->PIO_CODR = CS0;} // set low

void if_spiInit(hwInterface_t *iface)
{
euint8 i;

AT91PS_SPI pSPI = AT91C_BASE_SPI;
AT91PS_PIO pPIOA = AT91C_BASE_PIOA;
AT91PS_PMC pPMC = AT91C_BASE_PMC;
pPIOA->PIO_PDR = AT91C_PA12_MISO | AT91C_PA13_MOSI | AT91C_PA14_SPCK; // | NCPS_PDR_BIT;
pPIOA->PIO_ASR = AT91C_PA12_MISO | AT91C_PA13_MOSI | AT91C_PA14_SPCK; /// not here: | NCPS_ASR_BIT;

pPIOA->PIO_SODR = CS0; // set high
pPMC->PMC_PCER = ( (euint32) 1 << AT91C_ID_SPI ); // n.b. IDs are just bit-numbers
pSPI->SPI_CR = AT91C_SPI_SPIEN | AT91C_SPI_SWRST;

pSPI->SPI_MR = AT91C_SPI_MSTR | AT91C_SPI_PS_FIXED | AT91C_SPI_MODFDIS;

pSPI->SPI_MR |= ( (SPI_MR_PCS<<16) & AT91C_SPI_PCS ); // set PCS

pSPI->SPI_CSR[0] = AT91C_SPI_CPOL | AT91C_SPI_BITS_8;
if_spiSetSpeed(0xFE); // slow during init


pSPI->SPI_CR = AT91C_SPI_SPIEN; // enable
for(i=0;i<21;i++) {if_spiSend(iface,0xFF);} // Send 20 spi commands with card not selected
pPIOA->PIO_CODR = CS0;// NCPS_PDR_BIT; // clear
}

void sd_spiPDC_RD512(hwInterface_t *iface,u08 *buf,u16 len)
{
u32 i;
u08 *p;

if (len==0) return;

p=&SpiMem[0]; for(i=0;i<514;i++) p[i]=0xFF;

while( !( AT91C_BASE_SPI->SPI_SR & AT91C_SPI_TDRE ) ); // transfer compl. wait

AT91C_BASE_SPI->SPI_PTCR=AT91C_PDC_TXTDIS|AT91C_PDC_RXTDIS;
AT91C_BASE_SPI->SPI_TPR=&SpiMem[0];
AT91C_BASE_SPI->SPI_RPR=&SpiMemR[0];
AT91C_BASE_SPI->SPI_RCR=514;
AT91C_BASE_SPI->SPI_TCR=514;
AT91C_BASE_SPI->SPI_PTCR=AT91C_PDC_TXTEN|AT91C_PDC_RXTEN;
while( !( AT91C_BASE_SPI->SPI_SR & AT91C_SPI_RXBUFF ) ); // transfer compl. wait

p=&SpiMemR[0];
for(i=0;i<len;i++) buf[i]=p[i];
//Wait(100);
//while(AT91C_BASE_SPI->SPI_RCR!=0 ); // transfer compl. wait
}

esint8 sd_readSectorM(hwInterface_t *iface,euint32 address, euint8* buf, euint16 len)
{
static u32 oldaddress=0xfffffff0;
u08 cardresp;
u08 firstblock;
u16 fb_timeout=0xffff;
u32 place;

if ((oldaddress+1)!=address)
{
sd_Command(iface,12, 0,0); //STOP_TRANSMISSION
cardresp=sd_Resp8b(iface); // Card response
place=512*address;

sd_Command(iface,18, (euint16) (place >> 16), (euint16) place); //READ_MULTIPLE_BLOCK
cardresp=sd_Resp8b(iface); // Card response
if(cardresp!=0x00) {sd_Resp8bError(iface,cardresp);return(-1);}
}

// Wait for startblock
do
firstblock=sd_Resp8b(iface);
while(firstblock==0xff && fb_timeout--);

if( firstblock!=0xfe) {sd_Resp8bError(iface,firstblock);return(-1);}
sd_spiPDC_RD512(iface,&buf[0],len);
oldaddress=address;
return(0);
}

[jcxz]

Вроде простой вопрос, а вот явного ответа на него пока не нашел - при работе с SD картой по SPI протоколу нужно ли как-то (паузами) разделять байты в пакете ?

Нет конечно.

Я понимаю, что с вероятностью практически 100% можно, но сбивают с толку картинки, на которых всегда нарисованы увеличенные паузы между отдельными байтам. Пытаюсь читать стандартную

На картинках может быть что угодно нарисовано. Если-бы были нужны паузы, об этом явно указано было-бы в тексте и указаны их длительности.
К тому-же - это бред полный, ибо не ложилось-бы никак на работу с DMA, были-бы жуткие тормоза и т.п.
Логическое мышление иногда полезно включать.

[ДЕЙЛ]

Недавно имел дело с SD-картой. Осциллографом смотрел картинку - после команды чтения никаких пауз не видел. Думаю, что если они и возможны, то только как вынужденные, когда выполняется обработка принятого байта или при заполнении буфера, если используется аппаратный интерфейс работы с картой. Частота тактирования начинается от 0 герц, поэтому ничего не случится, если будет приостановка. Для большей убедительности подпаяльте провода МГТФ к данным сигналом в заводском девайсе и полюбуйтесь картинкой на осциллографе.

[justontime]

Как и следовало ожидать, все заработало без всяких пауз, равномерным потоком битов...

[justontime]

А вот еще вопрос из этой серии - наоборот, можно ли произвольно поднимать CS и опускать его обратно между связанными командами ? В смысле, например, опустить CS, выдать команду чтения блока, поднять CS, опустить его обратно и после этого уже непомредственно прочитать блок ? Или же такое переключение CS сбросит весь процесс ?

[smalcom]

проверьте уже - это быстрее, чем прочитать то, что вам уже дали или дожидаться ответа от форума.

[justontime]

проверьте уже - это быстрее, чем прочитать то, что вам уже дали или дожидаться ответа от форума.

Я приблизительно 7000 км от своей конструкции, и должен вернуться только через неделю, а знать хочется сейчас

[smalcom]

значит у вас много времени. почитайте документацию на протокол.

[justontime]

значит у вас много времени. почитайте документацию на протокол.

Спасибо за такой "полезный" ответ... Если не знаете, то лучше помолчите, и все...

Во-первых, свободного времени как раз у меня еще меньше, чем обычно.

Во вторых, относительно документации - о какой документации идет речь ? Например, в "SD specifications Part 1 Physical Layer Simplified Specification" описание "железной" части SPI протокола ограничено следующим:

Every command or data block is built of 8-bit bytes and is byte aligned to the CS signal (i.e. the length is a multiple of 8 clock cycles).
The card starts to count SPI bus clock cycle at the assertion of the CS signal. Every command or data token shall be aligned to 8-clock cycle boundary.
Similar to the SD Memory Card protocol, the SPI messages consist of command, response and data-block tokens. All communication between host and cards is controlled by the host (master).

Ну и какую информацию по моему вопросу можно извлечь из этого описания ?

Можно (и нужно) читать также документацию по SPI (что я, кстати, также делал), но там описывается сугубо физический уровень, а как конкретное устройство логически интерпретирует различные посылки, это уже дело устройства, а не физического протокола.


Update:


Хотя и неофициальный стандарт, но нашел следующее:

The CS signal must be continuously active for the duration of the SPI transaction (command, response and data). The only exception occurs during card programming, when the host can deassert the CS signal without affecting the programming process.

Сообщение отредактировал justontime - Jan 31 2015, 13:43

[jukebox]

Возможно немного не по теме,но это тоже связано с взаимодействием по SPI с флешью.Принцип работы микрухи я допилил по такой схеме - в Протеусе нашел в библиотеке микросхем подобную интересующей,у меня это 25LC256(емкость и серия может быть другой,важен сам принцип SPI),вставил в форму эту микру,вставил паттерн генератор,вставил SPI анализатор,попарился пока вкурил как работает ггенератор и анализатор(1сутка) и вместе с даташитом начал тестировать микру.
В результате - на Протеус форме микра после многих вариантов тестов таки начала давать то что нужно.
На всякий случай опишу принцип,вдруг кому нибудь понадобится.На сайте инфы по ней не обнаружил.

Выводы микры HOLD,WP на плюс.
Далее - CS на 0.
даем 8 тактовых имп-са на SKC(CLK),параллельно на выводе MOSI выдаем цифру 6 (разрешение записи в микру) MSB - старшим битом вперед.
Далее CS на 1.
Пауза(микро,мили)
Далее - CS на 0.
Пишем 2 (запрос на запись)
Пишем 0 (старшая часть адреса)
Пишем х(5) (любая цифра младш адр,например 5)
Пишем Data (например 10)
Далее - CS на 1.
Пауза
Далее - CS на 0.
Пишем 3 (запрос на чтение из микры)
Пишем 0 (ст часть адр)
Пишем 5 (мл ч адр)
Пишем 0 (во время выхода этих 8 - ми тактов с ноги MISO микры вылезут данные,в нашем случае - 10)
Далее - CS на 1.

Вроде простой алгоритм,но чтобы до него созреть пришлось "километры" болот и топей пробуксовать в Протеусе. Удачи.

P.S. Это пример для EEPROM SPI, но этим способом можно быстро выяснить принцип работы и Flash SPI Memory.
Также в Протеусе в библиотеке микросхем есть компонент виртуальной SPI CD карты - MMC.

Сообщение отредактировал jukebox - May 9 2015, 07:45

[UDmitry]

Касательно записи на SD карту могу вам сказать, что когда мы тестировали получалась такая вещь, что время записи данных на карту все время варьировалось несмотря на то, что мы передавали все время один и тот же размер буфер, следовательно логично предположить, что поэтому на рисунках и изображены байты с различным временем задержки между ними. Возможно такое связано с какими-то внутренними процессами в работе карты. Правда работали мы с SDIO+DMA.

[jukebox]

Итак, позанимался с Flash AT25FD041A.Есть некоторое несовпадение с протеусом, хотя может не доглядел.

Для записи байта во флэш надо :
CS на 1;
Пишем 6;
далее
CS на 0;
и дальше по накатанной,опкод 2, адрес,байт данных.
CS на 1;
только адрес трехбайтный.

[jcxz]

CS на 1;
Пишем 6;

Во время CS=1 любые SPI-флешки игнорят любые данные на MOSI. Не надо ничего писать при CS=1.

[MiklPolikov]

Вроде простой вопрос, а вот явного ответа на него пока не нашел - при работе с SD картой по SPI протоколу нужно ли как-то (паузами) разделять байты в пакете ?

Не нужно. Интерфейс SPI вообще этих пауз не увидит. Он понимает только фронты CLK.
Но между длинными пакетами , для надёжности, можно дёргать в 1 CS , для того что бы быть увереным, что порядок бит не сбился, т.е. что 1й бит одного байта не начал попадать в 8й следующего.

[toweroff]

Не нужно. Интерфейс SPI вообще этих пауз не увидит. Он понимает только фронты CLK.
Но между длинными пакетами , для надёжности, можно дёргать в 1 CS , для того что бы быть увереным, что порядок бит не сбился, т.е. что 1й бит одного байта не начал попадать в 8й следующего.

а если аппаратно настроен пин и данные гонятся потоком, через DMA, например?
а потеря порядка битов - это, простите, к схемотехнику и разводчику платы

[MiklPolikov]

а если аппаратно настроен пин и данные гонятся потоком, через DMA, например?

Разумеется данные через DMA. Но между данными всё равно есть какие-то перерывы, вот в них, для верности, и надо дёргать CS .

а потеря порядка битов - это, простите, к схемотехнику и разводчику платы

Порядок бит не должен теряться. Но предусмотреть защиту от всего что может и не может случится - это как раз к программисту : )

[jcxz]

Порядок бит не должен теряться. Но предусмотреть защиту от всего что может и не может случится - это как раз к программисту : )

Не уверен что спецификация SD требует от контроллера SD-карты сброса битовой state-машины при переводе CS=high.

[jukebox]

Во время CS=1 любые SPI-флешки игнорят любые данные на MOSI. Не надо ничего писать при CS=1.

Действительно, неточность написал, сорри за порожняк.
Итак, после того как погонял микру через самопальную прогу имитации импульсов через LPT порт микра заработала.Только через резисторный делитель, чтобы 3В было на микре.
Работает все как и в протеусе с той лишь разницей что вначале надо разблокировать секторы последовательностью :
CS = 0
пишем 0х6
CS = 1
---
CS = 0
пишем 0х1 ;запись в status регистр
пишем 0х0 ; разблокирование
CS = 1
---
такой же комбинацией пишется любой opcod (|_0х6 _| |_0х1 opcod(например писать массивом или др команда) |
---
CS = 0
пишем 0х6
CS = 1
---
CS = 0
пишем 0х2 ; запрос на запись
ну и далее по тексту ...

Лично у меня флэшь работает как от нее и требуется.Без проги на одном даташите фиг бы разобрался даже если бы переведенный был бы.

Сообщение отредактировал jukebox - Jul 15 2015, 17:54