Пытаюсь использовать USART в синхронном режиме, т.е. сделать из него SPI .
Но вот беда : бит 0 передаётся первым, а мне нужно в противоположном порядке.
Я правильно понимаю, что этой настройки в USART нету ?

Заранее спасибо за ответ !


Отвечу сам на свой вопрос :

Действительно, настройки нет.
Вот тут http://forum.micromouseonline.com/index.php?topic=460.0 приведён ответ из службы поддержки STM.
Но есть быстрый способ перекодировать MSB в LSB

uint32_t __RBIT(uint32_t value)
{
__ASM("rbit r0, r0");
__ASM("bx lr");
}

Так можно байтик кувырнуть.

не понятно что такое rev, особенно если уже в начале есть rbit.

http://infocenter.arm.com/help/index.jsp?t...g/Cihfddaf.html

здесь еще предлагают
unsigned int __rbit(unsigned int val);

ну понятно что он тоже самое делает, что и в первом посте. только надо понимать что когда вы 32 битное слово реверсируете, ваши 8 бит улетают из начала в конец, то есть после такой реверсии еще надо посылать в другом формате little endian сменить на big endian

rev меняет порядок байт в слове - типа rbit, но для байтов. Т.е. rbit8 как бы реверсит биты внутри байта.

Кто-нибудь может подсказать, почему программа изредка повисает при передаче байта по USART в режиме spi ?
Точно такое же зависание я когда-то наблюдал и в асинхронном режиме. В обеих случаях режим MASTER
Уже мозг сломал

Иногда мешает противный битик OVR. Вы его обрабатываете?

Нет. Но я несколько раз , под отладкой, убедился в том что когда повисло этот бит не стоит.
Как и в каком место кода его обрабатываете вы ?

while(!(USART2->SR & USART_SR_RXNE))

почему вы завершение передачи ожидаете по заполнению приемника, а не по опустошению передатчика?

Потому что USART в синхронном режиме , как SPI. Передача байта происходит одновременно с приёмом.

Может, нарушение кадра имеет место быть. Типа, нет стоп-бита. Или какой-то бит считался с ошибкой. Нужно следить за ORE, NF, FE.
Я работаю по прерываниям, поэтому если байт принят с ошибкой, то он просто будет потерян. В вашем же случае потеря байта не допустима.
UART это не SPI - можно ведь и не принять))

ну то есть у вас все хорошо работает?

if RXNE=0, then it means that the last valid data has already been read and thus there
is nothing to be read in the RDR. This case can occur when the last valid data is read in
the RDR at the same time as the new (and lost) data is received. It may also occur
when the new data is received during the reading sequence (between the USART_SR
register read access and the USART_DR read access).

вижу много причин пропадания этого флага... кстати если у вас в отладке где то просматривается RDR, то это тоже наверняка может сбросить флаг....


Почему не использовать идеологически более правильный флаг TC - Transmission complete?

Golikov A, огромное спасибо, с флагом TC висеть перестало !

Может ещё подскажете :
Почему при работе USART+DMA иногда не происходит прерывание конца передачи DMA TC ( Transmission complete) ?

А кто-нибудь может объяснить, зачем флаг USART_SR_RXNE сбрасывают вручную, хотя он сбрасывается при чтении регистра данных?

The RXNE flag can also be
cleared by writing a zero to it. This clearing sequence is recommended only for multibuffer
communication.

Как я понимаю, рекомендуется. Очищать. Но не понимаю, что значит "multibuffer"

ну блин, а я то откуда знаю это к стешникам. ДМА надо читать, механизм сложный, много сложностей бывает.


Я так понимаю это как дополнительная опция для более простого для понимания кода.
К примеру если у вас несколько обменов с 1 2 3 устройством, по прерыванию или полингом у вас идет чтения, в котором проверяется адрес ответа. И вы отключаете обработку 2 устройства, чтобы это место в коде было более читабельно, делаете вместо чтения при адресе равном 2, просто сброс. Операция равносильна, но идеологически более верная.

вторая вещь которая приходит в голову, это для процов с FIFO на входе, в LPC1768 к примеру это востребовано. У него очередь по 16(8) байт на входе, можно либо сделать 16(8) чтений чтобы очередь была гарантированна пуста, либо 1 раз сбросить через спец регистр. Думаю что механизм от подобного блока тянется

А вы смотрели что в DMA_CNDTRx? если до нуля не декрементирует, то прерывание не произойдет.

"Иногда" - это насколько часто? Недавно переносил проект на F103, так не заметил такого - UART-DMA работает без единого сбоя.

Нет, не смотрел. Ну наверно, если посмотреть, то так и окажется.



Раз в несколько ч непрерывной передачи.

Когда у меня SD карты висели на SPI , всё было без сучка без задоринки. А сейчас перевесил на USART в синхронном режиме, и началась эта нестабильная работа. И в другом проекте USART то же глючит, нет-нет да и не пройдёт передача.

Я так понимаю, что это специфика USART. Успех передачи почему-то не гарантирован, и надо обрабатывать не успех. Но непонятно, что ему мешает работать стабильно ? В асинхронном режиме ещё бы можно было понять, но в синхронном-то почему ? Видимо он и в синхронном режиме не до конца превращается в SPI

А он в синхронном режиме старт, стоп, четность проверяет?
SPI имеет меньше проверок, потому какие-то не совсем корректные обмены проходили, просто не было критерия ошибки. Может косвенно это касается и вашей первоначальной проблемы. Что-то не проходит, и потому не происходит декремент счетчика. Проверяйте все флаги ошибок что есть...

По идее - не должно быть такого.