stm32f407 SPI обнаружил косяк Опции

[SasaVitebsk]

При инициализации с делителем на 64 (с другими не проверял). SPI3 (с другими не проверял). stm407 на 168МГц (с другими не проверял).
После записи в регистр DR необходимо выждать задержку до проверки флага BSY в регистре SR. Иначе байт может потерятся (затерется следующим).
То есть флаг занятости выскакивает с задержкой. Причём задержка приличная, успеваю выйти и войти в процедуру.
После установки задержки всё устаканилось.

[Flexz]

наверное не просто так в RM написано

Note: Do not use the BSY flag to handle each data transmission or reception. It is better to use the
TXE and RXNE flags instead.

[KnightIgor]

наверное не просто так в RM написано

Поддерживаю. Для полнодуплексного (даже если только передача нужна) SPI завершение передачи нужно проверять по... RXNE (и забыть о TXE или BSY, т.к. STM32F не поддерживает аппаратное формирование SS в режиме мастера!). Тогда будет абсолютная уверенность, что байт ушел, а следующий его не затрет по пути: ведь пока байт выдвигается по MOSI, входящий байт вдвигается по MISO тем же тактовым сигналом. Это означает, что флаг RXNE все равно возникнет, пусть позже TXE, зато наверняка после последнего такта. Нужно помнить чистить RXNE путем чтения DR перед записью туда:

1. Прочесть DR.
2. Записать в DR байт для передачи.
3. Ждать RXNE (будь-то тупо или путем реакции на прерывание).
4. Перейти к п.1., если еще есть данные для передачи.

Сообщение отредактировал KnightIgor - Nov 16 2012, 22:44

[AHTOXA]

Это означает, что флаг RXNE все равно возникнет, пусть позже TXE, зато наверняка после последнего такта.

Кстати, не факт, что после. В зависимости от режима SPI, RXNE может возникать на середине последнего такта (если данные на приёме защёлкиваются по переднему фронту). Вот тут-то наверное и может пригодиться BSY. (Хотя я лично просто делаю несколько nop-ов перед отпусканием CS)

[ViKo]

Кстати, не факт, что после. В зависимости от режима SPI, RXNE может возникать на середине последнего такта (если данные на приёме защёлкиваются по переднему фронту). Вот тут-то наверное и может пригодиться BSY. (Хотя я лично просто делаю несколько nop-ов перед отпусканием CS)

Пробую понять SPI от STM32. Действие битов SSM, SSI не соответствует описанным в документации. В Интернете фантазируют, кто во что горазд.
Насчет RXNE и BSY. Похоже, они переключаются одновременно в конце передачи.
Но задержка на полтакта для программного снятия CS не нужна. Потому что выборка (защелкивание) данных ведомым устройством как раз и произойдет в момент, когда возникнет RXNE. А дальше пусть такт заканчивается, все равно. Главное, чтобы время удержания данных на входе ведомого устройства не оказалось меньше нормы. Но это наносекунды. С учетом работы программы, беспокоиться не о чем.
Если же ведомое устройство - какой-нибудь регистр, то нужно правильно выбрать полярность тактов SCK.

[HHIMERA]

Пробую понять SPI от STM32. Действие битов SSM, SSI не соответствует описанным в документации.

Не совсем понял... что там не так???
Небольшие расхождения есть только в описании SPI STM32F0XX... но здесь простительно, сравнительно новый камень, "злокопипаст" и т.д. ...
По SPI STM32F3XX ничего не скажу, не мучал...
По остальным сериям - всё работает как положено...

В Интернете фантазируют, кто во что горазд.

Да и пусть... Кто не хочет читать даташит - пусть фантазирует...
В последнее время темы по SPI просто стараюсь игнорировать...

Насчет RXNE и BSY. Похоже, они переключаются одновременно в конце передачи.
Но задержка на полтакта для программного снятия CS не нужна. Потому что выборка (защелкивание) данных ведомым устройством как раз и произойдет в момент, когда возникнет RXNE. А дальше пусть такт заканчивается, все равно. Главное, чтобы время удержания данных на входе ведомого устройства не оказалось меньше нормы. Но это наносекунды. С учетом работы программы, беспокоиться не о чем.

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

[ViKo]

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

Непонятных глюков не бывает. Бывают не понятые.
Я проверяю RXNE. Это - то же самое. Микроконтроллер пользую STM32F207.

[HHIMERA]

Я проверяю RXNE. Это - то же самое.

Пусть будет "Это - то же самое."... )))
Сами подумайте... по вашему, STM прилепила в SPI "левый", никому не нужный, бит BSY...
Так поверьте, это не так... При всей своей кажущейся "простоте и непонятности" у STM получился SPI с довольно таки широкими возможностями...

[ViKo]

Пусть будет "Это - то же самое."... )))
Сами подумайте... по вашему, STM прилепила в SPI "левый", никому не нужный, бит BSY...
Так поверьте, это не так... При всей своей кажущейся "простоте и непонятности" у STM получился SPI с довольно таки широкими возможностями...

Вам надо разжевывать каждое выражение? "То же самое" с точки зрения обнаружения окончания передачи. На картинки в руководстве взгляните. Или мне для вас специально вырезать и запостить?

[HHIMERA]

Ещё раз... не то же самое!!!
Когда нарвётесь, тогда и поймёте о чём речь... референс мануал полистайте, в конце концов...
(Поэтому и стараюсь игнорировать темы по SPI... вечно "глюки" и "косяки" там, где их нет и никогда и не было... )
Когда начинал работать с STM32... меня тоже, местами, SPI шокировал...
Теперь это всё вспоминаю с улыбкой... а регистры и биты SPI "кручу как цыган солнце"... невзирая на даташит... он теперь мне вообще не нужен...
Просто пришло понимание, что и как работает... и только...

[ViKo]

Ещё раз... не то же самое!!!

Смотрим в книгу... Конец передачи - RXNE и BSY изменяются одновременно. То есть, при проверке окончания передачи можно использовать и тот, и другой биты, с одинаковым успехом. При передаче многобайтовых последовательностей для записи байтов в DR лучше проверять TXE, а конец передачи определять, как сказано выше. Хотя можно записывать байты и по и RXNE, можно и по BSY . Но тогда появятся задержки между передачами байтов. Поскольку CS мы формируем программно, не страшно.

Просто пришло понимание, что и как работает... и только...

Проверим? Для связи STM32F207 с M25PE40 (мастер и слейв, соответственно, пишу для полного понимания) мне пришлось программировать SPI следующим образом. Вывод NSS я прицепил на /S памяти, рассчитывая управлять аппаратно. Но не получилось. Пришлось использовать, как GPIO.

CODE

/* SPI1 -- связь с SFM M25PE40
8-bit, MSB first, SPEn, Fpclk2 / 4 (15 MHz), Master, CPOL=0, CPHA=0 */
SPI1->CR1 =
SPI_CR1_CPHA * 0 | // Clock Phase
SPI_CR1_CPOL * 0 | // Clock Polarity
SPI_CR1_MSTR * 1 | // Master Selection
SPI_CR1_BR_0 * 1 | // Baud Rate Control - fpclk2 / 4 = 15 MHz
SPI_CR1_BR_1 * 0 | //
SPI_CR1_BR_2 * 0 | //
SPI_CR1_SPE * 1 | // SPI Enable
SPI_CR1_LSBFIRST * 0 | // Frame Format
SPI_CR1_SSI * 1 | // Internal slave select
SPI_CR1_SSM * 1 | // Software slave management
SPI_CR1_RXONLY * 0 | // Receive only
SPI_CR1_DFF * 0 | // Data Frame Format
SPI_CR1_CRCNEXT * 0 | // Transmit CRC next
SPI_CR1_CRCEN * 0 | // Hardware CRC calculation enable
SPI_CR1_BIDIOE * 0 | // Output enable in bidirectional mode
SPI_CR1_BIDIMODE * 0; // Bidirectional data mode enable
SPI1->CR2 =
SPI_CR2_RXDMAEN * 0 | // Rx Buffer DMA Enable
SPI_CR2_TXDMAEN * 0 | // Tx Buffer DMA Enable
SPI_CR2_SSOE * 0 | // SS Output Enable
SPI_CR2_FRF * 0 | // Protocol format - 0: SPI Motorola mode, 1: SPI TI mode
SPI_CR2_ERRIE * 0 | // Error Interrupt Enable
SPI_CR2_RXNEIE * 0 | // RX buffer Not Empty Interrupt Enable
SPI_CR2_TXEIE * 0; // Tx buffer Empty Interrupt Enable

Обратите внимание на SSM и SSI. Ни при каких других комбинациях SPI не работал. В отличие от STM32F103, где была другая комбинация магических битов.
Объясните, зачем нужны эти биты, если ногой NSS я управляю, как GPIO. Покажите, в каком месте руководства это написано. Покажите, как работает у вас.

P.S. А мануал я листаю в начале начал, а не в конце концов.

[HHIMERA]

Покажите, как работает у вас.

Вытащил из "мусорника"...

Код

   do
             { 
// здесь то, что нужно                
             } while (--cnt);

            while(SPI2->SR & SPI_SR_BSY);        // Wait for SPI Rx Buffer Empty 

Ничего примечательного... вроде... кроме комента... "Wait for SPI Rx Buffer Empty"...
Он остался от проверки RXNE (неудачный копипаст)... Если вернуть проверку RXNE, то происходит потеря данных...

А это то, что реально работает... SPI 9bit на STM32F100...