Доброго времени суток!
Помогите разобраться с работой USART в tiny2313. Немогу понять как работает флаг TXC. В даташите написано что он выставляется по окончании передачи. Но там есть буферизация в 2 байта. Он выставляется если передал 1 байт или если передал всё?
Передаю сразу 2 байта, и жду прерывания, для переключения драйвера 485 на приём. Приёма на другом конце не происходит. Работает только если после передачи первого байта проверять флаг вручную и передавать второй байт после его установки. Соответственно так же переключаю на приём.
ЗЫ. В прерывании сбрасывал флаг записью в него 1. При передаче 2х байт запрещал прерывания для неразрывности, всё равно ничего не добился. Смотрел по осцылу время нахождения в режиме передача, но ничего непонял. Сколько реально времени (включая служебные биты 1-четности и 1-стоп 9-ый) будет передавать 2 байта усарт?

Честно говоря никогда не испольвал этот флаг. Использую вместо него UDRE, он выставляется если регистр данных передатчика пуст и готов к отправке следующего байта. Рекомендую воспользоваться этим прерыванием.

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

Вообще для отладки всего воспользуйтесь терминальной программой и подключите USART МК через MAX232 к com порту компьютера. Так Вы сумеете устранить все ошибки без особого усилия.

Заслали Вы в буфер байт или 2 байта.
начинается передача. если буфер пуст, то выставляется UDRE. Но передача еще идет и в случаее RS485 нельзя переключаться на прием. Когда буфер будет пуст и будет отправлен последний бит, то выставиться TXC.


Я использую оба флага. По UDRE подкачиваю данные в буфер, а поTXC перехожу на прием.

Прошу прощения, не учел особенностей RS485

Для 485 я пользую следующие конструкции:


Перед передачей отключаю приемник и переключаю драйвер. По прерыванию переключаю драйвер и включаю приемник.

Тоесть флаг TXC выставляется только по окончании передачи ВСЕГО? Но у меня почемуто не работает! Вечером заменю камень и перепроверю.

Зависит от скорости передачи Ftx (Бод -> бит в секуду )
Ttx = 1/Ftx - передача одного бита данных в секундах.

Не совсем понял Ваш код в прерывании. Зачем нужна проверка флага?

ВСЕГО байта, который был отправлен в буфер, т.е. после передачи стопового бита!!!

Тоесть если Я отослал в буфер 2 байта то и прерываний будет 2?


Спасибо! Незнал длинну битов "старт" и "стоп". По привычке считал её отличающейся от длинны обычных бит.

Длина старт бита "по привычке" всегда была один бит. А длина стопа может быть 1-1.5-2 бита и задаётся вами же при инициализации УСАРТА. Смотрите внимательнее описалово.

Если вы отослали 2 байта, то вы получите 2 прерывания: сначала UDRE потом TXC. Если передадите по первому UDRE третий байт, то получите 2 UDRE и один TXC.



Если хотите получить максимальную скорость обмена, то правильно будет использовать оба флага и при работе с RS232. По-моему это очевидно.

Не надо ничего проверять.
Сделайте очередь.
В прерывании TXC посылайте следующий байт - если нечего слать - то переключайте линию на прием.

PS: вы на чем пишете программу? asm/c?


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

Пишу на асме. Вот и Я этот бонус захотел. Всётаки наверное камень глючит. Походу 2 прерывания даёт.
Посылаю сразу 2 байта. И получаю 2 прерывания по TXC! К сожалению новый будет только в четверг!

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

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

Я где-то приводил пример работы с UART на asm'e..
Искать долго, поэтому просто прикляю его еще раз.
смотрите в атаче.

Пример написан под AT90S2313, чтобы переделать под Tiny2313 надо будет поменять таблицу векторов и возможно пару штрихов с настройкой UART'a. Так же надо будет выставить константы Fosc и BaudRate согласно вашим потребностям.

константа
.equ PD7 = 7 ; // объявим константу которая не прописана в .inc файле

используется как флажек (прием/передачи)
поменяйте ее на Pin которым у вас меняется направление (прием/передача) 485-го.


Согласен. Камень тут не причем.
2 TXC на 2 переданных байта - абсолютно нормальное поведение чипа.

Вот именно такой прямой ответ я и хотел получить! Огромное спасибо! Ибо "Атмеловский английский" неразумею. Им наверное построчно плотют. Ка-кто смутно и коротко у них там описана работа буферизации USART. Было бы логично если бы флаг TXC устанавливался по ОПУСТОШЕНИЮ буфера. Но похоже он устанавливается по окончанию передачи одного байта из двух что в буфере. Соответственно возникают 2 прерывания вместо ожидаемого 1го. То-есть не получится сделать совсем красиво. Досадно.
Спасибо за исходники.



Впоне возможно что глючу Я. А камень продам по сходящей тк. он уже в 2 раза питался 12 вольтами.

Что вы понимаете под словом "отладчик"?

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

и таких вещей у меня не было

JTAGICE

А AVRSTUDIO че не пользуете?Такие вещи там нормально симулируются.

А разве там есть окно COM порта? У меня 4,12 с обработкой прерываний там туго.

Я выложил свои дровишки. Там у меня передача и прем идет через кольцевые буфера. По прерыванию передатчика при загрузке последнего байта в уарт, выставляется флаг окончания передачи. Далее по прерыванию TXC, которое свидетельствует о опустошении сдвигового регистра, при выставленном упомянутом флаге снова разрешается прием данных и переключение драйвера 485. То есть прием будет включен только после полной передачи пакета.

Безусловно. Прямо так и написано:





Ну в принципе даже разрешение TXC можно не дергать, если вы можете дать гарантию, что время реакции на UDRE не превысит времени передачи символа. Тогда TXC придет ТОЛЬКО ОДИН в конце пакета. Как раз, чтобы выключить передатчик на ADM485

Вообщем-то все культурно и правильно в камне. Работать в принципе по UDRE и надо, чтобы не было дырок между символами (они только уменьшают общую скорость передачи).

Они (всмысле межсимвольные интервалы) добавляют стабильности передачи. В Modbus - межсимвольный интервал is a MUST.
А скорость, кому она нужна в 485?


Потому что отправляется два символа. После отправки каждого генерится TXC, если игнорировать UDRE.

Обоснуйте?



Межпакетный да, а вот межсимвольный??? Можно цитату?



Ну не скажите... Разные случаи есть..

Оно то может и так, но привычка с 51 осталась. Там аналога UDRE нет.
Да и немного неудобно. UDRE устанавливается всегда, когда буфер на передачу пуст (срабатывание по состоянию). А если я не хочу передавать, надо прерывание запрещать.
Прерывание ТХС устанавливается по событию, сбросил после передачи последнего байта и свободен до следующей передачи.

Чойто туго??! Там можешь руками поднять бит прерывания - и вот оно, появилось. Или маску. Или ещё что, всё работает. Наоборот, оч. хорошо там с прерываниями вручную. Приём только так и отлаживал - включаешь RXC - сразу прерываание, побежал обрабатывать байт...
По поводу TXC/UDRE. Пользую их оба, для 485, ага. Чтобы отправить строку байтов, переключаю интерфейс на выход и записываю байт в UDR. Всё! дальше прерывания сами. Тут же байт из UDR проваливается в регистр сдвига и возникает прерывание UDRI. Обработчик смотрит: все байты передал? нет: следующий в UDR; да: ничего. Когда последний байт передан, возникает TXCI. Его обработчик переключает RS485 на приём. Всё.

Ну например - передатчик работает 8-1-N, а приемник включили 8-2-N.
С отправкой "по TXC" с большой долей вероятности ошибок приема не будет.


Таки действительно органичение "снизу" только на межпакетный - "Character gap interval".

На межсимвольный "silent interval" ограничение "сверху":

источник:
http://www.sena.com/download/tutorial/tech_Modbus_v1r0c0.pdf (150k)
cм. секцию 5.2


Может быть, но мне что-то такие случаи в сетях 485 не подворачивались.

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

А я был очень рад увидеть два флага. Наверное после х51. Да и в 4414 только один байт буферизовался. Иногда для RS232 при высокой скорости и плотности передачи Именно чтобы избежать межбайтовых интервалов очень необходимы оба флага. В идеале конечно можно было бы и байт 16 впихнуть в аппаратный буфер. Но два лучше чем один. Короче использовать или нет - это программисту решать, а вот наличие - это замечательно. Использую 2 флага и в 485 и в 232.

Так включите и в передатчике 9 бит с установленным девятым битом... А ручные задержки для добавления бита - это моветон... А задержки, которые еще и неизвестно какой длительности (ну сколько времени там будет от TXC до записи в UDR) - как говорится, это ваще



Посему оптимально будет посылка именно без интервалов.



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

Согласен. Я удивился, как он этих флагов не видел. Или мышой не ткнул?
А что нового в периферии в 4.13? У меня только нумерацию битов приходится всё время включать, больше новостей не заметил. Проц М16.

Ещё можно тупо в прерывании UDRE - если производится запись очередного байта в UDR, то не глядя заодно сбрасывать флаг TXC. В суме это даёт меньше кода, чем разрешение/запрещение TXCIE и защищает от задержки отработки UDRE.
Так как если были запрещены прерывания и UDRE не отработало своевременно, успел установиться флаг TXC, то при разрешении прерываний (выходе из другого прерывания) первым будет передано управление на UDRE_vect.

To defunct. Посмотрел на ваш код.

Одно место меня озадачило, в теле подпрограммы PutChar вы снова вызываете PutChar. Это что, такая рекурсия заложена, или как? Вроде не должно работать.

Спасибо что проявили интерес ;>
Да - там рекурсия.
посылаем строку "hello\n"
putchar автоматически добавит возврат каретки и терминал примет "hello\r\n".


Попробуйте код. ;>
Какой резон мне выкладывать что-то нерабочее?

Посмотрел попристальнее - нет там никакой рекурсии. И вообще, проще было бы вызывать не rcall PutChar, a rcall __skip_add_cr (ну и названьице(:-)). И выполнение было бы быстрее, ведь рутина у вас и в прерывании вызывается...


А чего его пробовать, и так видно, что тяжеловесно и неоптимально. Например, фрагмент с кольцевым буфером можно написать в два раза короче. А что там за пляски с бубнами в PutChar: in AH,SREG cli + out SREG,AH? Не проще ли обойтись связкой cli/sei. Или вот: зачем стоит tst AL перед rcall PutChar в рутине Print?

Смотрите пристальнее сразу. Ок?
Есть там рекурсия, коль скоро функция вызывает сама себя.


Не сомневаюсь что вы именно так и поступаете, у меня же все метки начинающиеся с "__" внутренние и я стараюсь их не вызывать, чтобы было меньше путаницы.


Не проще. Потому что вызывается эта функция еще и в прерывании.

И вообще прежде чем хаить хамоватым тоном - разберитесь с кодом.


опечатка.

Ну-ну, tell it your sailors(:-). Рекурсии там нет. Рекурсия – это сведение вычисления задачи некоторой размерности N к вычислению аналогичных задач меньшей размерности. Вот пример классической рекурсии.

Кстати, цикл является частным видом рекурсии. У вас ни того, ни другого.

Дорогой мой, зачем метки тогда вообще писать. Я пишу программы так, чтобы они были эффективные и красивые, а не какие-то там крокозябры (это не вам).

Ну хорошо, не проще, так не проще. Сейчас я вам покажу как ваш код работает. Выполняется программа Print, перед brne возникает прерывание по приему с rx. Программа прерывания запишет принятый байт внутрь строки, которую программа Print собирается поместить в кольцевой буфер. В результате вы получите не ту строку, которую копировали из флеши, а несколько другую. Я бы назвал сиё скрытым (неявным) багом.

Прошу прощения, если кого-то обидел, но я никому не хамил и никого не хаял. Была выложена программа, идёт её обсуждение, ничего личного.

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

рекурсия — частичное определение объекта через себя, определение объекта с использованием ранее определённых. Рекурсия используется, когда можно выделить самоподобие задачи.

В программировании рекурсия — вызов функции или процедуры из неё же самой

источник:
http://ru.wikipedia.org/wiki/Рекурсия





Теоретически возможно. Атомарность Print я не организовывал.
Но конструкция реализованная в PutChar не препятствует организации атомарности Print.

тем же самым in Rr, SREG - cli - out SREG, Rr


Во-первых выбирайте выражения. Своему бойфренду можете говорить "дорогой мой".
Во-вторых, я не виноват что русский язык порождает неоднозначность ("не вызывать" - имелось в виду "call" не делать. )
в третьих - это такой стиль - для обозначения внутренних меток (локальных для функций) на которые осуществяется условный переход я применю "тэг" - "__".

=GM=, при всём уважении к Вашим знаниям давайте будем добрее друг к другу. Так вы отобъёте всякое желание выложить свою прогу, чтобы кому-то помочь.
Любая маломальски приличная прога содержит ошибки. Иногда их вылавливаешь годами. Плюс различные предпочтения у каждого программиста. Это как аккорды на гитаре. Один пользуется чаще такими а другой другими. Но если оба музыканта, то музыка всё равно звучит.

А откуда такое определение рекурмии,ссылку можно?


Вот с этим не поспоришь.
И чего-вы к обозначению внутренних меток прицепились?По моему,нормальная идея визуально разделять локальные и глобальные метки.
З.Ы. вы кодер,не знающий ошибок?

Мой пример классический, не я его выдумал, взгляните на него непредвзято (заменил там рекурсивную функцию F на более заметную RECURRENCE).

Напишите ваш код PutChar на си в таком же виде, тогда и будем говорить, что верно, а что неверно. Интересно, что у вас будет параметром рекурсии?

Так я и сказал. что все эти примочки внутри PutChar не нужны, не решают они задачу до конца, а снаружи атомарность передачи строки вы не обеспечили. И не теоретически, а сугубо практически, поверьте.

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



Знаний как раз маловато, спасибо форуму, много даёт в плане самообразования. Да я...белый и пушистый, defunct'а почти люблю (как брата, а то опять поймет не в той плоскости(:-)). Что касается проги, не собирался я её критиковать, с первого взгляда она мне понравилась, посмотрел по диагонали - в подпрограмме вывода символа вроде используется рекурсия, вот думаю, люди рекурсию применяют, а я от неё как чёрт от ладана, ну я и спросил спроста, а потом уж стал смотреть, а он мне отвечает, да, там рекурсия, да какая рекурсия, курам на смех

Согласен. Ошибок в любой программе полно, у самого так. Смотришь на программу годичной давности, и думаешь, неужели это я написал такое гуано? Ну посмотрел я его программу, ну высказал замечания, будь благодарен, что кто-то потратил своё время, разобрался, принял участие, ответил, что плохого? Почему сразу надо воспринимать как наезд, которого и в помине не было. Дефункту не надо было говорить, чтоб код испытал(:-). Да если б все мои программы так критиковали, это было бы здорово, и программы были бы в стократ лучше...

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


отправляемый char, а что еще может быть параметром?
функциональный аналог ассемблерной функции:





Это вам так кажется.
Примочки внутри putchar решают свои задачи:
- атомарность выгрузки символа в очередь
- добавление символа CR


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

поменять Print так:

и будет обеспечиваться атомарность.
push/pop конечно же можно сократить если использовать какой-либо другой регистр для хранения SREG вместо AH, но поставил специально для наглядности.


Маленькая простенькая - но рекурсия, т.к. функция вызывает сама себя.
Прочитайте определение рекурсии на wiki.



Я выразил вам благодарность и попытался нормально ответить на ваши вопросы вначале.

PS: я и сейчас пытаюсь отвечать на ваши вопросы по-сущесту, с приведением ссылок и примеров. Может вы просто не замечаете?

Ну, это другое дело. Но тогда сохранение/восстановление статус-регистра в PutChar не нужно, о чём я и толкую последние две страницы.

Кстати, неплохо бы добавить проверку на переполнение буфера в подпрограмме обработки прерываний по приему. UART_RX_ISR так и будет писать по кругу, никаких ограничений у вас нет, возможен скрытый баг.

Нужно! Т.к. PutChar автономная функция, и кроме Print может быть использована где угодно.
"Лучше перебдеть чем "недобдеть" ;>


Это так и было задумано..
Практика показывает что для консольных приложений (а пример относился как раз консоли) много лучше допускать опустошение Tx (при переполнении) чем притормаживать CPU ожиданием освобождения места.


RX_ISR в идеале должен работать со входной очередью.
Вывод "Эхо" по скорости заполнения не быстрее TX, переполнений по вине RX потока быть не должно. Ну а в случае когда полный overload, то деваться некуда или сбросить TX очередь или ждать окончания TX. Но мы не можем торчать в прерывании и ждать когда освободится место в очереди..

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

С новым камнем всё заработало. Проблема была не с USART а с подпаленными ногами.
Да, действительно флаг TXC появляется только по опустошению буфера. А не на каждый байт.
В авр студио флаг UDRE появляется если оба байта буфера пусты. В прерывании по UDRE передаю байт и прерывание повторяется ещё раз. Тоесть по флагу UDRE можно передавать сразу 2 байта! Передачу сразу 2х байт по UDRE в железе не проверял(нет времени, чуть позже проверю), всё остальное работает прекрасно!

2 раза сразу только ПЕРВЫЙ раз. UDRE уже выставлен, передачи еще нет. Первый байт сразу влетает в сдвиговый регистр и буфер опустошается, выставляется сразу опять UDRE. А вот следующий будет только тогда, когда вытолкнется самый первый.

Именно так! А не "передавать сразу 2 байта"... И АВРстудио честно всё показывает. Не "флаг UDRE появляется если оба байта буфера пусты", а если пуст только UDR. Тщательнее надо, тов. Достоевский!