[admiral 0]

Здравствуйте, не могли бы вы разъяснить такую ситуацию?

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

Флаг устанавливается в 1 после передачи всех битов посылки из сдвигового регистра передатчика при условии, что в регистр данных UDR не было загружено новое значение. Флаг сбрасывается аппаратно при выполнении подпрограммы обработки прерывания или программно, записью в него лог. 1

 

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

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

[Rst7 5]

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

 

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

[admiral 0]

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

Спасибо, а если неизвестно последний это байт или нет? Тогда придется каждый раз сбрасывать этот бит перед посылкой очередного байта?

[Rst7 5]

Спасибо, а если неизвестно последний это байт или нет?

 

Если неизвестно, то смысл тогда знания, что байт отправлен и можно спать?

[Палыч 10]

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

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

 

Спасибо, а если неизвестно последний это байт или нет? Тогда придется каждый раз сбрасывать этот бит перед посылкой очередного байта?

Вам, ведь, нужно убедиться, что все данные ушли в линию, значит - Вы знаете: последний байт или нет.

[Rst7 5]

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

 

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

[Палыч 10]

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

Имхо, такие извращения - не результат неправильного проектирования софта, а результат неправильного проектирования аппаратуры USART: бит ТХС следовало бы, наверное, аппаратно сбрасывать при зазрузке байта в UDR.

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

[defunct 0]

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

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

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

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

[V_G 11]

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

В данном случае при передаче последнего символа в обработке прерывания DRE я запрещаю прерывание DRE и разрешаю TXC, а по приходу последнего окончательно завершаю передачу (иногда и запрещаю для перевода ноги в высокий импеданс)

Изменено 14 января, 2010 пользователем V_G

[Rst7 5]

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

 

Тут немного не в том дело. Если задумана непрерывная передача пакета, а, например, процессор может оказаться занят в интервале между передачей двух байт чем-то другим и не успеет записать в UDR, то зопа произойдет в любом случае, хоть прерывание, хоть poll. Вот что я имею в виду под неправильным проектированием.

[admiral 0]

Объясню ситуацию:

делаю устройство, т.к. питаться оно будет от батарей, то приходится экономить энергию вводя в спящий режим контроллер.

Для отладки использую usart, по нему контроллер передает в комп информацию что он в данный момент делает.

И вот была у меня беда - контроллер в ком-порт выдавал какой-то мусор вместо членораздельных фраз. Бился я бился над этим пока не попробовал отрубить вход в спяшщий режим.

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

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

Прерывания я не использую, поэтому флаг TXC сам не сбросится. Придется его сбрасывать программно.

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

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

[Палыч 10]

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

Это-то - понятно. Интересует: как у Вас устроена программа, что по этому прерыванию Вы гарантировано знаете, что все байты переданы? Поясню свой вопрос на примере "неправильного" софта (который такой гарантии не даёт, ну, или не во всех случаях):

1. Данные загружаются в UDR по прерыванию USART Data Register Empty

2. Перед загругкой последнего байта сбрасывается флаг TXC; последний байт загружается в UDR; разрешаются прерывания от USART Tx Complete

3. Наступает прерывание по TXC - считаем, что все байты переданы, что не всегда верно (см. выше - сообщение #5).

 

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

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

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

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

[V_G 11]

Посмотрел на симуляторе - у меня флаг TXC сброшен ПОСТОЯННО. Возможно, потому, что передатчик запрещен постоянно и разрешается только, когда надо что-то передать. При разрешении передачи (и прерываний DRE, TXC) сразу возникает прерывание DRE, а TXC дергаться и не думает, и никогда в жизни я его программно не сбрасывал.

 

А передавать байты с большими паузами, что TXC успевает дернуться - это что за задача такая? Я формирую передающий буфер до начала передачи, в результате передача посылки идет непрерывно. И медленно в масштабе времени процессора, так что паузам просто неоткуда взяться!

 

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

[Qwertty 0]

Поясню свой вопрос на примере "неправильного" софта (который такой гарантии не даёт, ну, или не во всех случаях):

1. Данные загружаются в UDR по прерыванию USART Data Register Empty

2. Перед загругкой последнего байта сбрасывается флаг TXC; последний байт загружается в UDR; разрешаются прерывания от USART Tx Complete

3. Наступает прерывание по TXC - считаем, что все байты переданы, что не всегда верно (см. выше - сообщение #5).

Поменяйте в пункте 2 "Перед загрузкой" на "сразу после загрузки" и получите свою гарантию.

Я не то что сбрасываю TXC, но и само это прерывание разрешаю именно внутри прерывания от UDRIE после загрузки последнего байта.

[Палыч 10]

Тут немного не в том дело. Если задумана непрерывная передача пакета, а, например, процессор может оказаться занят в интервале между передачей двух байт чем-то другим и не успеет записать в UDR, то зопа произойдет в любом случае, хоть прерывание, хоть poll. Вот что я имею в виду под неправильным проектированием.

А передавать байты с большими паузами, что TXC успевает дернуться - это что за задача такая? Я формирую передающий буфер до начала передачи, в результате передача посылки идет непрерывно. И медленно в масштабе времени процессора, так что паузам просто неоткуда взяться!

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

Задача, на которой у меня возникли такие проблемы - простая: передавать данные по RS-485 со скоростью 2Мбод (конечно, не только передавать, но и снимать информацию с датчиков, отрабатывать..). Даже с минимумом действий внутри обработчиков прерываний - не всегда можно успеть положить вовремя байт в UDR (прерывание по UDRE имеет невысокий приоритет, а механизма изменить приоритет в AVR - нет).

Как уже выше писал: решил проблему сбросом TXC после выдачи байта в UDR.

 

Поменяйте в пункте 2 "Перед загрузкой" на "сразу после загрузки" и получите свою гарантию. Я не то что сбрасываю TXC, но и само это прерывание разрешаю именно внутри прерывания от UDRIE после загрузки последнего байта.

Значит, не один я так делаю. Почему же советы: "перед выдачей - сбросьте ТХС"?