• Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram

Как узанть что передатчик UART закончил передачу данных?

Vovka

Member
К ножкам UART подключена MAX485. Прием/передачу переключаю ногой GP0.
Осталось узнать, когда есп закончит передачу, чтоб перключить GP0 для приема.
Т.е. когда физически данные уши в линию
 

Vovka

Member
Не пойдет - лишняя задержка ожидания.
А у ecp8266 есть прерывание по окончании передачи буфера? Или флаг какой...
 

Vovka

Member
uart_wait_tx_done() проверит состояние аппаратного Tx FIFO и вернется, когда он пуст или истекло время ожидания.
не пойдет, надо без ожидания
 

Сергей_Ф

Moderator
Команда форума
uart_wait_tx_done() проверит состояние аппаратного Tx FIFO и вернется, когда он пуст или истекло время ожидания.
не пойдет, надо без ожидания
тогда копайте core на предмет реализации uart_wait_tx_done(), может там что найдёте
 

nikolz

Well-known member
 

pvvx

Активный участник сообщества
тогда копайте core на предмет реализации uart_wait_tx_done(), может там что найдёте
Там только проверка "состояние аппаратного Tx FIFO", но не окончания полного физического вывода символа на пине TX UART.
Обнуление счетчика Tx FIFO указывает что последний символ ушел в передатчик UART и далее будет передаваться.
Прерывание тоже есть, если его включить. Но оно так-же дает только информацию о том, что последний символ поступил в передатчик, но ещё не передался.
Событие окончания передачи в ESP8266 можно определить таймером после этих событий или если переключить UART в диагностический режим внутреннего замыкания TX-RX и в приемнике назначить отрабатывание прерывания тишины приема в установленные тики в спец. регистре.
 

pvvx

Активный участник сообщества
Для переключения направления приемо-передатчика драйвера RS-485 при реализации modbus rtu в соответствии со спецификацией требуется отключить WiFi. Иначе драйвер WiFi занимает CPU с запретом прерываний на периоды не совместимые с реализацией правильных таймингов modbus rtu. Т.е. вы не впишитесь в спецификацию, но сделать что-то похожее на modbus rtu возможно.
 

Vovka

Member
Итак варианты:
1. Serial.flush(); - WiFi начинает жутко тормозить, простую страничку отдает в течение 5-10 сек!
2. Прерывание по окончании ухода последнего символа в передатчик. Тут можно передавать на один байт больше, а по этому прерыванию сразу переключать ногу на чтение.
3. Это доработка схемы: добавить один транзистор и два резистора - тогда не нужна будет нога для управлением приемом/передачей
 

pvvx

Активный участник сообщества
Итак варианты:
1. Serial.flush(); - WiFi начинает жутко тормозить, простую страничку отдает в течение 5-10 сек!
Использование C++ связано с постоянными запросами Heap памяти, а поиск свободного куска производиться при запрете прерываний и поиск этот с выделением не маленький по времени. По этому что линейный опрос, что прерывания от UART всегда будут подтормаживать и бить во времени исполнения - концепция Arduinо не предусматривает не рассчитана на выполнение множественных задач, тем более с аппаратной завязкой.
Тем более в либах и самой части кода Arduino на каждое обращение вписан множественный лог для отладки, а это вызов printf и ожидание вывода сообщения лога в UART. Отключите все логи и отладку.
2. Прерывание по окончании ухода последнего символа в передатчик. Тут можно передавать на один байт больше, а по этому прерыванию сразу переключать ногу на чтение.
И этот байт пойдет в линию - зачем?
И что такое - "сразу". Выполнение вашей задачи прерывается исполнениями назначенных по прерываниям задач драйвера WiFi и его прерывание имеет больший приоритет.
3. Это доработка схемы: добавить один транзистор и два резистора - тогда не нужна будет нога для управлением приемом/передачей
Эта доработка создает условия для повышения уровня помех на линии RS485. Драйвер при передаче выводит ток в линию и со сменной полярностью для разряда емкостей линии и прочего, а "доработка" отключает передатчик, тем самым создает дополнительную возможность для проявления помех в линии.
Детский сад.
 

Vovka

Member
И этот байт пойдет в линию - зачем?
И что такое - "сразу". Выполнение вашей задачи прерывается исполнениями назначенных по прерываниям задач драйвера WiFi и его прерывание имеет больший приоритет.
Не уйдет, не успеет, проверено.

Эта доработка создает условия для повышения уровня помех на линии RS485
Это как? Т.е. если есп ногой переключает прием/передачу, то помех нет, а если доработка, то есть?
 

pvvx

Активный участник сообщества
Работа драйвера при передаче "1" и "0":
1642759876330.png
А это эквивалентно работе схемы из двух транзисторов - один через сопротивление на вход, второй на выход в линию с сопротивлением к 5В.
1642759950122.png
Зачем там ADM485?
 

pvvx

Активный участник сообщества
я проверил - в линию не уходит!
Тогда - ура!
Ранее, многими годами, был написан драйвер для работы c RS485 для работы с SDK без какого C++.
Были произведены замеры - какие прерывания и заминки исходят от драйвера WiFi. Всё описано и неоднократно представлено на форуме.
Самая большая задержка выполнения любых ваших задач, кроме немаскируемого прерывания, происходит при соединении и разъединении WiFi и в некоторых случаях достигает более одной секунды. Вы на это влиять не можете, т.к. либы закрыты.
А в процессе работы всегда идут прерывания WiFi с длительностями от 150 мкс - это минимум, иногда оно сильно более, но их много и на это время прерывания запрещены.
Интересно посмотреть схему из двух транзисторов для линии RS485 без ADM485
А с этой "доработкой" у вас уже не RS485, т.к. драйвер дает только половину выхода, а на другой бит отпускает линию. Это для того, что линия имеет индуктивную составляющую и после каждого отключения тока на ней образовывался выброс с затухающей бородой. :p

PS: Желаю благ в построение своего чуда с RS485, на чем из этой темы отчаливаю.
 
Сверху Снизу