adnega

Проверил TCP2UART (v0.6.4). Потери ~44% для потока 128 кБ/с, причем снизил скорость UART до 2.5 Мбит/с. Современные китайские AT-прошивки хоть и теряют байты, но не половину потока.

Проще некоторый (или весь) функционал перенести в ESP. Была бы полная документация по ESP32, я бы выбрал их.

Прозрачный режим очень удобен, т.к. не требуется дорабатывать прошивку изделия, которое уже общается по UART. Обычно по такому каналу я гоняю текстовую консоль. Там трафик просто никудышный и никаких потерь не заметил. В крайнем случае, команды вернет "error" и можно переповторить. Нет такого смайлика, чтоб передать всю печаль по данной теме. Самое интересное, что кишки ESP без проблем гоняют трафик 16.7 Мбит/с (~2000 пакетов/с по 1024 байт в каждом) уже на протяжении 10 часов. Причем, и UDP, и TCP примерно одно и тоже, т.е. WiFi точно не является узким местом. Я думаю, проблема в UART и криворукости писателей AT-прошивки. Либо она не предназначена для передачи значительного потока без потерь. Из альтернативных пробовал только TCP2UART с форума esp8266.ru По сравнению с v0.25 она в свое время была значительно лучше, но тоже не без приколов - не мог задать свои SSID и пароль.

Вы в прерывании таймера (16129 раз в секунду) бодро записываете нужные регистры и как можно быстрее выходите из обработчика - единицы мкс. Если прерывание USB отложится или прервется на единицы мкс, то от этого ничего не должно теряться. Разве нет?

#define SET_PRIO(irq, prio) do{ NVIC->IP[(irq) >> 2] = \ (NVIC->IP[(irq) >> 2] & ~(0xFF << (((irq) & 3) << 3)))\ | ((prio) << (((irq) & 3) << 3)); } while(0) SCB->AIRCR = 0 | (PRI2_6 << SCB_AIRCR_PRIGROUP) // 5 - 2.6 | (SCB_AIRCR_KEY << SCB_AIRCR_VECTKEY); //--------------------------------------------------------------------------- // SYSTEM PRIO //--------------------------------------------------------------------------- SCB->SHP[0] = 0 | (PRIO2_6_NORMAL << 24); // SVCHandler SCB->SHP[1] = 0 | (PRIO2_6_NORMAL << 16) // PendSVC | (PRIO2_6_NORMAL << 24); // SysTickHandler //--------------------------------------------------------------------------- // HIGHEST (PRIO2_6_HIGH) //--------------------------------------------------------------------------- SET_PRIO(NVIC_ISER0_USART1, PRIO2_6_HIGH); // console SET_PRIO(NVIC_ISER0_CEC_CAN, PRIO2_6_LOW); // can

Просто сделайте приоритет прерывания таймера выше, чем у USB.

Максимум что получилось выдавить из ESP8266: - UDP пакеты по 1024 байта; - собственная прошивка; - данные предсгенеррированные; - отправка непрерывная, насколько позволяет функционал SDK. Получается 16.7 Мбит/с или 1955 пакетов/с.

У меня и так, и так используются ESP8266. Прозрачный режим в принципе должен экономить полосу и без того узкого UART. В прозрачном режиме допускаю потерю данных, несмотря, на TCP (обидно). В режиме AT-команд проблем не замечал, но и потоки большие не создавал. При использовании собственной прошивки ESP получается так: - TCP, пакеты по 1024 байта, 381 пакет в секунду, 381 кБ/с; - UDP, пакеты по 1024 байта, 420 пакетов в секунду, 420 кБ/с. ESP отправляет сгенерированный пакет на сервер. Сервер выдает эхо в ESP. ESP получает и анализирует ответ, если все Ок - тест продолжается. По-моему, результат не фонтан.

Отправляю пакет размером 2920 байт (1460 * 2) 25 раз/с = 71 кБ/с = 710 кб/с. Потерь нет. Скорость UART 5 Мбит/сек. Большие пакеты - благо. Кста, на ESP32 все ужасно - он переставляет блоки, полученные по UART!

В таком случае с выводами про FIFO/DMA вы поторопились. У меня UART работает на 5 Мбит/с. Отправляю пакеты по 32 байта 1000 раз/с. Итого 31.25 кБ/с. Потерь нет. Если пакетами по 64 байта, то потери есть, но очень мало 0.12% Причем, потери не сетевого плана. Сделал спецпоток, в котором очень легко видеть выпадающие куски. По-моему, данные теряются при приеме UART. Создается впечатление, что иногда срабатывает функция, блокирующая прерывания UART, что приводит к потере данных. Время блокировок в потоке 250 кБ/с (пакет 256 байт) доходит до 500 мс, потерь 5.5%.

Не понял. На этой скорости можно создать поток 180 кБ/с. Вы его создавали или удовлетворились 4 кБ/с (38kbps)?

Не замечал такого. Вы какую модель модуля используете? Нужно проверить питание и все подтяжки.

Попробуйте https://www.hw-group.com/software/hercules-setup-utility

Начиная с v1.7 в принципе нет варианта на 512 кБ.

Я пользуюсь v1.6.2 ESP8266_AT_Bin_V1.6.2_0.zip

Это очень старые прошивки. Рекомендую обновить. Они вообще после некоторого времени перестают даже на ARP-запросы отвечать (прописывал ARP вручную). Но, обращаю внимание, что современные обновления требуют 1 МБайт флеши, а старые обычно выпускались с 512 кБ.

А версия прошивки/SDK какая? Я такую использую. Доволен.

Ключевой момент не тайминги, а переполнение (OVR) при приеме данных. Там есть FIFO, но я не понял как его 128 байт распределяются между RX/TX и UART0/1.

Скорость получается путем целого деления частоты 80МГц. Т.е. 921600 точно не получить: либо /86 = 930232 (+1%), либо /87 = 919540 (-0.2%). Но дело не в этом, а в том, что без DMA на высоких скоростях байты могут потеряться. Вроде, в ESP32 уже есть DMA на прием по UART.

Если подразумевается AT-прошивки, то источником данных будет UART0 модуля. Я запускал порт на 3.3 Мбит/сек в прозрачном режиме - некоторые данные (~8%) терялись (вроде, у ESP8266 нет DMA на UART). По-моему, узким горлышком будет UART. Пример теста: rx_count = 97278080, // принято байт tx_count = 106877488, // отправлено байт tx_time = 320s, // время теста tx_speed = 326kB/s, rx_speed = 296kB/s, // скорости потока delta = 9599408B, delta% = 8 // потери

В тривиальном случае - да.

Да, каждый из двух конецов шины должен быть терминирован.

Я недавно плотно разбирался с CAN на высокой скорости и приличной дистанции. Термин "хоть один раз приняло" не работает в отношении CAN, т.к. там есть состояния активной и пассивной ошибки и т.п. Весь отчет выложить не могу, но вот кусочек:

Тогда задержка линии у вас небольшая. Можно считать, что каждые 10 метров кабеля вносят задержу в 50 нс. Дык, получилось изменить точку сэмплирования? Заработало?

А длина шины какая?