Гарантия того, что по USART все данные ушли Опции

[admiral]

Здравствуйте, не могли бы вы разъяснить такую ситуацию?
Перед входом в спящий режим мне нужно убедиться, что все данные ушли в линию. Для этого есть флаг ТХС. В даташите сказано:
Флаг устанавливается в 1 после передачи всех битов посылки из сдвигового регистра передатчика при условии, что в регистр данных UDR не было загружено новое значение. Флаг сбрасывается аппаратно при выполнении подпрограммы обработки прерывания или программно, записью в него лог. 1

Прерываний я не активировал, т.е. получается что после первой передачи, когда данные ушли, и в буфер я данных для отсылки не заносил, этот флаг установится в 1 и больше никогда не сбросится?
Если да, то получается, что после каждой передачи мне нужно программно сбрасывать этот бит?

[Rst7]

Выкручивался из этой ситуации сбросом TХC после загрузки последнего байта в UDR при закрытых прерываниях (между загрузкой и сбросом), при условии малой скорости передачи.

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

[Палыч]

Но уж лучше подходить с позиций изначально правильного проектирования софта, дабы на такие грабли не наступать

Имхо, такие извращения - не результат неправильного проектирования софта, а результат неправильного проектирования аппаратуры USART: бит ТХС следовало бы, наверное, аппаратно сбрасывать при зазрузке байта в UDR.
Кстати, всегда интересовало: как другие разработчики определяют окончание передачи (это актуально при использовании RS-485: включение/отключение приёмника) при использовании прерываний и записи байта по освобождению UDR.

[defunct]

Кстати, всегда интересовало: как другие разработчики определяют окончание передачи (это актуально при использовании RS-485: включение/отключение приёмника) при использовании прерываний и записи байта по освобождению UDR.

Не знаю как другие, но я - исключительно по прерыванию TXC от USART. Потому что:

Флаг сбрасывается аппаратно при выполнении подпрограммы обработки прерывания

На кой ляд анализировать какой-то флаг, когда есть TXC event, который аппаратно управляет флагом.

[Палыч]

Не знаю как другие, но я - исключительно по прерыванию TXC от USART.

Это-то - понятно. Интересует: как у Вас устроена программа, что по этому прерыванию Вы гарантировано знаете, что все байты переданы? Поясню свой вопрос на примере "неправильного" софта (который такой гарантии не даёт, ну, или не во всех случаях):
1. Данные загружаются в UDR по прерыванию USART Data Register Empty
2. Перед загругкой последнего байта сбрасывается флаг TXC; последний байт загружается в UDR; разрешаются прерывания от USART Tx Complete
3. Наступает прерывание по TXC - считаем, что все байты переданы, что не всегда верно (см. выше - сообщение #5).

И вот вопрос: контроллеру нужно заснуть, как убедится, что все данные отосланы? Будет ли нормально, если я перед каждой посылкой байта (неважно последний он или нет) буду сбрасывать этот флаг?

Это - не повредит...

Не пойму почему они не сделали, что бы, к примеру, при записи данных в UDR флаг TXC сбрасывался аппаратно?

И я тоже этому в своё время был очень удивлён

[defunct]

Это-то - понятно. Интересует: как у Вас устроена программа, что по этому прерыванию Вы гарантировано знаете, что все байты переданы?

Ваш изначальный вопрос касался 485-го. Так вот в контексте 485-го все держится на модели "запрос-ответ". Драйверу UARTа попросту не дается следующий __пакет__ до тех пор пока нас об этот не попросят, либо до тех пор пока нам не ответят, либо до тех пор пока не завершится таймаут.

Из этого построение программы такое:
Есть кольцевой буфер и есть put() который пишет в этот буфер. TXC прерывание разрешено постоянно и управляет направлением трансивера 485-го. (По TXC драйвер переключается на прием.) Флаг TXC руками не трогается никогда.

В буфер помещается отправляемый пакет. Перед записью в UDR делается переключение трансивера 485 на передачу.. По UDRE - вычитка и отправка следующего байта из буфера.

В системе нет настолько тяжелых обработчиков прерываний чтобы UDRE прерывание откладывалось настолько долго, что за это время могло возникнуть TXC прерывание, (суммарная латентность всех прерываний не превышает интервала одного символа UART'а). Поэтому все прекрасно работает.

[Палыч]

В системе нет настолько тяжелых обработчиков прерываний чтобы UDRE прерывание откладывалось настолько долго, что за это время могло возникнуть TXC прерывание, (суммарная латентность всех прерываний не превышает интервала одного символа UART'а). Поэтому все прекрасно работает.

Это - хорошо, когда нет тяжелых прерываний... "Тяжесть" - штука относительная. Число "лёгких" прерываний с приоритетом выше чем у USART может быть достаточно для того, чтобы в сумме они составили "одно тяжелое". Да и "тяжелость" отпределяет ещё и скоростью передачи, особенно на очень высоких скоростях (тут уж - как не облегчай прерывания, а при некотором числе высокоприоритетных прерываний они всё равно превращаются в "тяжелое").

[defunct]

Да и "тяжелость" определяется ещё и скоростью передачи, особенно на очень высоких скоростях (тут уж - как не облегчай прерывания, а при некотором числе высокоприоритетных прерываний они всё равно превращаются в "тяжелое").

Да все так, только давайте посмотрим что может бегать по 485-му:

В Modbus RTU например, который бегает по 485-му, недопустимы какие-то непрогнозируемые паузы между символами. Пауза больше чем 1.5 символа по стандарту является поводом для отбраковки всего пакета!
Чтобы получить несвоевременный TXC, обработка UDRE должна опоздать аж на 2 символа! Т.е. межсимвольная пауза в системе где может случайно вылезти TXC посреди пакета - может достигать 2х символов. Как следствие этого - работа в Modbus RTU протоколе становится невозможной впринципе в такой системе.

Что делать? Отказаться от RTU? - нельзя, причины сами знаете.

Поэтому обработчики более выскоприоритетных прерываний строятся так, чтобы была гарантия отработки более низкоприоритетных во-время. Если не получается это сделать на одном AVR, тогда ставится еще один чип в помощь, либо берется другой МК, т.к. заранее известно, что система без этого захлебнется.

PS: С очень высокими скоростями по UART'у на AVRках не работаю - 115200 макс.
AVRки у меня всегда не ниже 11.059 тактируются, в основном 14.7456.

[demiurg_spb]

В Modbus RTU например, который бегает по 485-му, недопустимы какие-то непрогнозируемые паузы между символами. Пауза больше чем 1.5 символа по стандарту является поводом для отбраковки всего пакета!

Вы забыли упомянуть ещё о такой особенности таймаутов Modbus RTU:

Код

#define MB_MIN_15T_TIMEOUT              MB_SEC_TO_TCNT_TIC( 0.000750f ) // 750 us    if bps>19200
#define MB_MIN_35T_TIMEOUT              MB_SEC_TO_TCNT_TIC( 0.001750f ) // 1.750 ms  if bps>19200

Я её использую.
Раз уж пошёл разговор про Modbus RTU, то хочу спросить кто как обеспечивает гарантию паузы 3,5T меду пакетами?
Я всегда отправляю преамбулу из 4 dummy байтов с отключенным передатчиком драйвера RS485.
Какие у Вас соображения на сей счёт? Может это лишняя паранойя, ведь я и так отлавливаю конец посылки по паузе?

[_Pasha]

кто как обеспечивает гарантию паузы 3,5T между пакетами?

Никакая не паранойя - можно позволить УАРТУ за счет собственных средств не только разделять пакеты при передаче, но и обнаруживать паузу при приеме, отсылая также пустые фреймы.

[demiurg_spb]

Никакая не паранойя - можно позволить УАРТУ за счет собственных средств не только разделять пакеты при передаче, но и обнаруживать паузу при приеме, отсылая также пустые фреймы.

Поясните если не трудно про: "обнаруживать паузу при приеме, отсылая также пустые фреймы". Интересно...