Странный баг управления драйвером RS-485

[индюк]

Переписывание байта из регистра данных в регистр передачи не говорит о завершении передачи

угу. в этом и есть ошибка начинающих

[jump]

я тогда перешел на lpc17xx lpc13xx

ну, наверно, несколько позжее
In October 2008, NXP announced the LPC1700 series In May 2009, NXP announced the LPC1300 seriesда до нас дошли через год, примерно + освоение

да хоть все дам

так шо - челюсти на стол! живо! живо, я сказал!

[bdn62]

Спасибо всем откликнувшимся!
Но контроль последнего отправленного бита выполняется в строке
while(!( UCSR0A & (1 ‹‹ TXC0)));//
а переключение в режим приема выполняется после этой строки.
Что и обеспечивает штатную работу (осциллограмма 2).
Но именно иногда происходит зависание, иллюстрируемое осциллограммой 1, которая и вызывает у меня оторопь. Причем в этом зависании устройство сидит "вечно", до аппаратной инициализации МК.
А функция ModBus1k_init не может прервать выполнение функции RS485_U0_send, ибо обе не в прерывании, а в основном цикле.
Так что глюк пока не ясен.
Я надеялся, что кто-то сталкивался с чем то похожим, ибо хочется придумать "таблетку".
Перевод передачи ответа на прерывания я уже пробовал, но с ходу не получилось, мешал второй канал ModBus2k и собственная рукожопость…
Да и глюк в этом случае тоже может проявиться...

[akegor]

Но контроль последнего отправленного бита выполняется в строке
while(!( UCSR0A & (1 ‹‹ TXC0)));//

Попробуйте тут же проверять наличие/отсутствие байта в регистре данных.

[vit66work]

Не пробовали поставить небольшую задержку перед переключением на приём?

[индюк]

так шо - челюсти на стол! живо! живо, я сказал!

да на на....
я еще потом куплю

все равно последнее что я использовал из авр были 8535

Нажмите, чтобы открыть спойлер

[bdn62]

Попробуйте тут же проверять наличие/отсутствие байта в регистре данных.

Вот такая проверка не работает:
while(!( UCSR0A & (1 ‹‹ UDRE0)));
UCSR0A |= (1 ‹‹ UDRE0);
while(!( UCSR0A & (1 ‹‹ TXC0)));//
UCSR0A |= (1 ‹‹ TXC0);//cleared

[AR_Favorit]

Господа программисты жгутъ.

PB4 падает, когда не передано еще 2 (прописью: два) байта. Фифо в атмеге вроде как не присуцтвует. Вывод - проблема точно не в том месте, которое определяет конец передачи последнего байта. Ибо проблема возникает еще до передачи предпоследнего. Когда до проверки, определяющей, не пора ли ронять ли PB4, еще целый байт слать.

[akegor]

UCSR0A |= (1 ‹‹ UDRE0);

Это зачем? Бит сбрасывается аппаратно при записи байта в регистр данных.

Вот такая проверка не работает:

Что значит "не работает"? Что делает и что не делает?
Условием переключения с передачи на прием должно быть "последний бит ушел И передавать больше нечего".

проблема точно не в том месте

Насчет "точно" Вы погорячились. Лучше заменить на "может быть". Почему? Да просто потому, что при нечетком критерии определения конца посылки и переключении на прием может быть то же самое. Сначала четко отработать "хвост", а потом уже (по нужде) чесать репу дальше.

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

[AR_Favorit]

Насчет "точно" Вы погорячились. Лучше заменить на "может быть". Почему? Да просто потому, что при нечетком критерии определения конца посылки и переключении на прием может быть то же самое. Сначала четко отработать "хвост", а потом уже (по нужде) чесать репу дальше.

Я человек простой, вижу обрисованную проблему - про неё и говорю. Опускание PB4 за два байта до окончания посылки происходит не в приведенной процедуре отправки пакета, даже если бы определение окончания передачи было неправильным... Это же мега. Нет фифо, нет перестановки команд в конвейере. Из while не выйдет, пока не запихает в буфер последний байт - а PB4 падает раньше, перед предпоследним. Что там где-то ещё наворочено - надо смотреть, конечно...