STM32F103 - не явно документированные особенности USART, Изучаем поведение TXE и прерываний на железе. Опции

[Serj78]

Натолкнулся сегодня на странное поведение передатчика USART. исследуя работу в реалтайме.
Когда-то давно написал функции putchar() и обработчик прерывания для работы передатчика USART с софтовым с буфером, ( для приемника тоже, но пока так детально его не исследовал)



Реализация, собственно, традиционная: есть общий массив, функция putchar() в него по кольцу пишет, обработчик прерывания по кольцу в обратном направлении- читает. для количества выводимых бит используется переменная tx_counter/ в прерывании она декрементируется, в функции putchar()- инкрементируется. В принципе все работает без ошибок, но с временной точки зрения есть особенности.

В обработчике прерывания использует бит TXE для определения того, свободен регистр данных или нет ( так как прерывание общее, оно может вызываться и приходом данных) . в прерывании проверяется, TXE==1, и если это так и tx_counter>0 то делается вывод из массива буфера в регистр данных (DR). В противном случае, если выводить нечего, прерывание по TXE запрещается.


В функции putchar перед инкрементацией Tx_counter и записи очередного элемента буфера я запрещаю прерывание от TXE, после инкрементации-разрешаю.

( Код будет завтра !! )

Найденные "глюки" .
1. в документации на рисунке 241 (стр 660) есть замечательная надпись на графике TXE что он, дескать, может быть set by hardware
cleared by software. - это - Ошибка! он никак не может быть стерт руками, только записью в DR ( Стирал, проверял тут же- не стирается. косвенно это подтверждает буква "r" в поле описания статус регистра).

Дальше еще интересная особенность. Вывожу в буфер putchar() 120 символов и решаю посмотреть, сколько времени операция займет при каждем putcar дергаю ножкой, меряю. Cмотрю- расстояние между импульсами иногда сильно гуляет. Дергаю другой ножкой в прерывании usarta - вот оно, родимое. Cтоит после записи в DR ( начать пользоваться функцией putchar() как после каждой (не всегда!) возникает прерывание по USART.
Возникает оно если перезаписывать единицей бит разрешения прерывания по TXE. В результате параллельно цепочке импульсов, отмечающую вызовы Putchar() получаю массированную цепочку пустых прерываний, вывод буфера происходит корректно, ничего не теряется!

В документации такого нет...

Кто сталкивался?

[MALLOY2]

НЕ знаю где вы это прочитали у меня написано так:

Bit 7 TXE: Transmit data register empty
This bit is set by hardware when the content of the TDR register has been transferred into
the shift register. An interrupt is generated if the TXEIE bit =1 in the USART_CR1 register. It
is cleared by a write to the USART_DR register.
0: Data is not transferred to the shift register
1: Data is transferred to the shift register)
Note: This bit is used during single buffer transmission.

Да и работал много с уартом на этом камне глюков никаких не замечено.

[Serj78]

"Глюки" я не зря взял в кавычки.
Претензий к работе в общем-то нет- работа документации не противоречит. только вот фразу на рисунке 241. на странице 660 Reference manual.
"cleared by software " я понимаю так , что пользователь может стереть этот флаг. ну, не может реально, ну и хрен с ним. достаточно событий чтобы описать процесс и разобраться что в каком состоянии.

Вызванные прерывания обработчик обрабатывает корректно.
Пока решил проблему тем, что не разрешаю прерывание по TXE если оно уже разрешено.

Как вы осуществляете буферизацию вывода? Интересует момент одновременного доступа к переменной количества выводимых символов.

Сам работаю с Usart-om на этом камне практически год. проблем с корректностью работы нет. Просто выявил момент, который НЕ ОПИСАН в документации.


[quote name='Serj78' post='825726' date='Oct 18 2010, 20:40']"Глюки" я не зря взял в кавычки.
Претензий к работе в общем-то нет- работа документации не противоречит. только вот фразу на рисунке 241. на странице 660 Reference manual.
"cleared by software " я понимаю так , что пользователь может стереть этот флаг. ну, не может реально, ну и хрен с ним. достаточно событий чтобы описать процесс и разобраться что в каком состоянии.

Вызванные прерывания обработчик обрабатывает корректно.
Пока решил проблему тем, что не разрешаю прерывание по TXE если оно уже разрешено.

Как вы осуществляете буферизацию вывода? Интересует момент одновременного доступа к переменной количества выводимых символов.

Сам работаю с Usart-om на этом камне практически год. проблем с корректностью работы нет. Просто выявил момент, который НЕ ОПИСАН в документации. Если бы не было задачи до сотни наносекунд знать все времянки, так и не заметил бы.

[halfdoom]

Претензий к работе в общем-то нет- работа документации не противоречит. только вот фразу на рисунке 241. на странице 660 Reference manual.
"cleared by software " я понимаю так , что пользователь может стереть этот флаг. ну, не может реально, ну и хрен с ним. достаточно событий чтобы описать процесс и разобраться что в каком состоянии.

Все там правильно нарисовано: "The TXE bit is always cleared by a write to the data register". Иными словами, бит управляется косвенно. Если посмотреть на подписи внизу рисунка, то увидим: "software waits until TXE=1 and writes F2 into DR".