Глюки UART0 в режиме приема

[=AK=]

ESP8266 работает в связке с внешним микроконтроллером, получает от него команды и обменивается данными. Все в общем-то работает, но иногда сообщения к приходят не целиком, а обрезанные.

Сообщения идут в бинарной форме с байт-стаффингом, в стиле SLIP. То есть, начало сообщения обозначается своей уникальной парой байт ("старт"), конец сообщения - своей уникальной парой ("стоп"). Сообщения имеют переменную длину, от 16 до 300 байт данных в пакете.

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

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

После того, как стал вычитывать блоками, проблема стала появляться реже:

  while (Serial.available() > 0)
  {
    ubuf_len = Serial.available();
   Serial.readBytes(ubuf, ubuf_len);
  ... etc
  }

Сейчас ре-организовал код при помощи TickerScheduler. Раз в 1 мс запускаю задачу, которая только читает блоками из , убирает байт-стаффинг и кладет данные в буфер, больше ничего не делает. Проблема стала появляться намного реже, но иногда все же возникает.

Чаще всего режутся пакеты длиной порядка 110 байт, обрезание происходит примерно на 90-м байте. Мне это удивительно, потому что аппаратный буфер у ESP имеет длину 128 байт, плюс к этому в драйвере есть буфер 256 байт. Что за фигня такая?

 

[Юрий Ботов]

Рассинхронизация, скорость передачи отличается от скорости приема на 1/90, а адаптация скорости не побайтная а только в начале как вариант

 

[=AK=]

Рассинхронизация, скорость передачи отличается от скорости приема на 1/90, а адаптация скорости не побайтная а только в начале как вариант

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

 

[Юрий Ботов]

По идее то да... но как реализован конкретный UART ... фиг его знает

 

[nikolz]

По идее то да... но как реализован конкретный UART ... фиг его знает

В драйвере UART есть контроль переполнения буфера. В некоторых вариантах есть ляпы.
Посмотрите, как там у Вас.
Я драйвер переписал.

 

[=AK=]

Организовал проверку. Пакеты покрыты CRC, каждый пришедший по UART небитый пакет ESP подверждает квитанцией, а микроконтроллер посылает пакет заново, если квитанция от ESP вовремя не пришла. Инoгда раза 3-4 приходится посылать одно и то же, пока достучишься до ESP.

Пока работал по ТСР в локальной сети, это было полбеды. А когда подключился через интернет к MQTT брокеру, стало совсем плохо. Теперь ESP не работает уже не десятки миллисекунд, а сотни. Иногда вплоть до секунды ESP живет своей жизнью и не реагирует на данные, приходящие по UART, теряет их напрочь.

Полное впечатление, что ESP выключает прерывание UART, пока обрабатывает TCP.