Прошивка TCP2UART переходника с настройкой по Web

Evgeniy932

New member
И не справится. Для нормальной работы только TCP сокета вам потребуется от пол мегабайта статических буферов и ещё сколько-то для буферизации потока.
Хм, с вебсокетами не теряются пакеты даже по 64 кб. Странно это. Видимо за счет передачи чанками по 1024 байт - это работает нормально в условиях ESP32.
WebSockets считается неликвидным по безопасности.
Есть WSS.
Like HTTPS, WSS (WebSockets over SSL/TLS) is encrypted, thus protecting against man-in-the-middle attacks. A variety of attacks against WebSockets become impossible if the transport is secured.
 

Evgeniy932

New member
Кто вам мешает? Встройте в него скоростную DRAM, не тормозную SPI RAM, и всё в статике, без heap и будет вам счастье и безотказность, если остальные части чипа позволят :)
Эти ребята из Espressif новые сюрпризы преподносят:
Код:
// Workaround for RS485: If the RS485 half duplex mode is active
                // and transmitter is in idle state then reset received buffer and reset RTS pin
                // skip this behavior for other UART modes
                UART_ENTER_CRITICAL_ISR(&(uart_context[uart_num].spinlock));
                uart_hal_disable_intr_mask(&(uart_context[uart_num].hal), UART_INTR_TX_DONE);
                if (UART_IS_MODE_SET(uart_num, UART_MODE_RS485_HALF_DUPLEX)) {
                    uart_hal_rxfifo_rst(&(uart_context[uart_num].hal));
                    uart_hal_set_rts(&(uart_context[uart_num].hal), 1);
                }
Вот откуда возьмется лишний байт в приемном буфере, если на линии RX в режиме передачи, да и в режиме приема - уровень не менялся, т.к. подтянут к +3.3В.
Вот на ESP8266 такой проблемы не было. Видимо UART лучше вообще наружу вынести, в отдельный проц, для надежности.
Программно решается эта проблема.
 

pvvx

Активный участник сообщества
Вот откуда возьмется лишний байт в приемном буфере, если на линии RX в режиме передачи, да и в режиме приема - уровень не менялся, т.к. подтянут к +3.3В.
Этот кусок кода ни о чем не говорит.
У UART есть такое - loopback, да прерывание по тишине по установленному кол-ву тиков на RX.
Установив регистр счетчика тишины и задав loopback, выводим в TX и по прерыванию тишины на RX отключаем вами не понятый "DEN" и переключаемся в режим приема...
По остальному - вам пора представить сообществу новую глюко-версию на ESP32 :)
Или пройти платное обучение...
 

Evgeniy932

New member
По остальному - вам пора представить сообществу новую глюко-версию на ESP32 :)
Или пройти платное обучение...
Похоже пора с ESP32 тоже переходить на что-то другое, есть там нерешенные проблемы: https://github.com/espressif/esp-idf/issues/7315

Установив регистр счетчика тишины и задав loopback, выводим в TX и по прерыванию тишины на RX отключаем вами не понятый "DEN" и переключаемся в режим приема...
Вот именно здесь тайминг и не подошел. Все равно на 921600 позднее, чем нужно отключался DEN.
 

pvvx

Активный участник сообщества
Вот именно здесь тайминг и не подошел. Все равно на 921600 позднее, чем нужно отключался DEN.
Я этого не заметил, т.к. успешно работает и за пару мегабит, учитывая джиттер прерывания.
Это не относится к С++, т.к. там идут запросы памяти в heap, происходящие с запретом прерываний.
 

pvvx

Активный участник сообщества
Это не относится к С++, т.к. там идут запросы памяти в heap, происходящие с запретом прерываний. И у ESP32 два ядра и система имеет массу дополнительного кода для меж-ядерного распределения памяти и ресурсов с запретом прерываний, а SPI-Flash имеет те-же скоростные показатели для считывания кода для CPU, плюс более длинный код исполнения, который давно уже не лезет в кэш...
По этому ESP32 аутсайдер = кривая разработка.
 

pvvx

Активный участник сообщества
Даже с UART вы всё равно упретесь в распределение времени в блобах закрытых либ WiFi и прочего, не имея возможности что-то там подправить. Это не говоря уже о аппаратных зависимостях и глюков в самих чипах. Как итог - ESP не используется ни в одном пром. контроллере. Это чипы подходили для начального обучения программированию и на сегодня уже не выполняют и эту роль из-за устаревания поддержки современных стандартов и алгоритмов. Оставьте их использование “самоделкиным” – пусть маются.
 

pvvx

Активный участник сообщества
Какой смысл изучать и пытаться впихнуть ‘невпихуемое’ в чип десятилетней давности, имеющий ужасное распределение ресурсов и общей модели, да ещё изготовленных по древней технологии приводящей к дикому потреблению? На сегодня это могут себе позволить только мазохисты и некромансеры. Для современной электроники таких чипов пара лет = полное устаревание. А архитектура ESP не менялась уже более 7 лет. Только раздули и извратили, не решив основные проблемы известные уже до первоначальной разработки… С этими проблемами и борются в ESP по сей день, да бестолку, т.к. они заложены в основу первоначальной модели и решения у них нет и не будет в данных чипах.
 

pvvx

Активный участник сообщества
Если рассматривать применимость для поддержки сетевых протоколов, то первое что необходимо обеспечить – быструю буферизацию и распределение малого физического размера RAM на кусочки, которые можно представить в линейную область для динамических запросов памяти приложением. Для этого был создан механизм MMU (и не только для этого). Но его в ESP нет. В итоге имеет неизбежную дефрагментацию динамической памяти и отказ работы, включая системные вызовы. А тот-же древний MIPS запросто работает и по сей день, полностью обеспечивая сетевые протоколы при малой физической RAM. Попробуйте это исправить в ESP :p
 

pvvx

Активный участник сообщества
Но Ардуинщики влепили в ESP С++ с вариантом реализации основанным на heap модели подверженной дефрагментации. Этого уже достаточно, чтобы ESP стал нестабильным и не смог применяться в рабочих устройствах, а для игры в тамагочи – подходит.
 

Evgeniy932

New member
Удалось получить стабильную передачу данных UART 921600 -> TCP через разделение по разным таскам чтение из порта и запись в сокет, через StreamBuffer.
Порог при котором аппаратный FIFO UART'a сбрасывается в FIFO в RAM (размер 8192 байта, не принципиально) уменьшил с 120 байт до 30 байт.
Это на ESP32, но общий принцип одинаков для любых SoC.
Прекрасно работает с посылками по 73 кб, принимаемых по UART.
 
Сверху Снизу