Последовательность функция для запуска передчи команды по SPI (для dataflash)

В качестве команды засылается запрос на статус регистр (0xD7) размер команды 2 (bCmdSize=2)
Глядя на диаграмму передачи со статус регистра видно, что статус регистр должен передаваться по MISO сразу же после 8го тика SCK. Судя по всему так и происходит. Но сам статус регист оказывается не в ((char*)pDataFlash->command) [1], а в ((char*)pDataFlash->command) [0] !!! Как будто датафлэш передаёт данные во время прохождения запроса. Как будто PDC для приёма курит один байт, перед тем как начать приём.
Что не учёл, где накосячил?
Процессор sam7s256 код из атмеловского апноута для sam7x.

Очевидно, что это проявляется не только с датафлэш, тк для АЦП запросы короткие то там я тупо подстроился под эту систему и заставил всё работать. Но это ведь может плохо кончиться!

Это куда?

это накосячил, когда постил.

AT91F_PDC_SetTx(pPdc, (char *) &(pDataFlash->command), bCmdSize);
так должно быть

Сообщение отредактировал Goofy - Feb 9 2008, 10:11

Да Вы и счас накосячили Я спрашивал про AT91F_PDC_SetRx(...), а Вы мне про Ерему

это опять же опечатка... спешил...
AT91F_PDC_SetRx(pPdc, (char *) &(pDataFlash->command), bCmdSize);

Я так понимаю command в pDataFlash определена как чтото типа

command[CMD_BUF_SIZE]. Если так, тогда зачем в функции AT91F_PDC_SetRx/Tx Вы подсовываете адрес указателя, а не сам указатель???

По моему надо так:

Структура на которую ссылается pDataFlash имеет вид
typedef struct _AT91S_DF
{
AT91PS_SPI pSpi;
AT91S_DF_SEM bSemaphore;
unsigned int command;
unsigned int commandS;
AT91S_DF_DESC dfDescription;
unsigned char chipSelect;
}

Я конечно не знаю, как там все у вас посылается, но почему команды имеют такой тип - unsigned int? Команды для DataFlash имеют размер от 1 до 8-и байт. Я, к примеру, их и объявляю, как массив 8-и битных элементов, ну а PDC уже сообщаю адрес массива-источника и адрес массива-приемника (обычно совпадают или приемник не указываю елси не читаю статус) и количество байт, которые хочу отправить и ожидаю принять

А можно попросить код? Именно с sam7s стыковали датафлэш?

Можно:-)

В приложении драйвер SPI под uc/OS-II и драйвер для AT45DB - думаю разберетесь. Драйвер SPI править не надо - достаточно подключить хедер для соответсвующего МК - он сам разберется, скока SPI у чипа на борту



там, правда, еще не совсем решенный вопрос по блокировке интерфейса - использовать как есть счас - с семафорами или использовать общую группу флагов. Думаю, в понедельник-вторник решится, когда будем испытывать на рабочем девайсе. Я думаю, что и с группой флагов работать будет - т.е. без семафоров

За код спасибо большое!


Но то что у меня происходит с SPI я вообще отказываюсь понимать. Процедура выполняющаяся при запуске:


буферы - глобальные переменные


результат на скриншоте. Мало того что помеха в первом байте, так ещё и порядок мягко говоря странный. По датащиту в ответе at45db161d должно быть 0xFF, потом повторяющееся содержание статус регистра, на остальные 24 тика SCK.
Даже если помеха и ловиться на старте, то должна поганить 0xFF. Битый DF ?

SPI инициализирован на 8бит.

Сообщение отредактировал Goofy - Feb 11 2008, 08:42

не зачто

А что, мой тоже не работает?

Возможно большая скорость передачи и некачественная разводка ПП. Кстати у меня в исходиках установлена скрость 10МГц

Драйвер Ваш нет смысла подключать, тк PDC сам по себе работает наистраннейшим образом. Весь код этой беды выше представлен. Скорость 4мгц, уменьшал до 500кГц, результат тот же. Чёрт с ней с помехой, плата там и правда вся в соплях из проводов, однако с АЦП на этой скорости SPI работает прекрасно. Но как понимать последовательность то такую ?

Goofy
Сдается мне проблема не с RX DMA.
Попробуйте настроить RX DMA на прием и в ручную (без TX DMA) передать 4 байта.


PDC сам по себе работает прекрасно.

Вообще без PDC, эффект тот же.
Какому либо объясненью вообще не поддаётся, что чаще всего говорит о банальности причины...




инициализация SPI