• Уважаемые посетители сайта esp8266.ru!
    Мы отказались от размещения рекламы на страницах форума для большего комфорта пользователей.
    Вы можете оказать посильную поддержку администрации форума. Данные средства пойдут на оплату услуг облачных провайдеров для сайта esp8266.ru
  • Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram

Разработка ‘библиотеки’ малого webсервера на esp8266.

vad7

Active member
Ну и что я могу поделать?
Инициализация/настройка уартов сначала здесь:
esp8266web/app_main.c at master · pvvx/esp8266web · GitHub
потом здесь:
esp8266web/app_main.c at master · pvvx/esp8266web · GitHub
потом здесь:
esp8266web/app_main.c at master · pvvx/esp8266web · GitHub
потом здесь:
esp8266web/user_main.c at master · pvvx/esp8266web · GitHub

Плюс к этому при установке дефайнов везде, где только можно UART0_BAUD = 74880, а UART1_BAUD = 460800 все равно вылазит мусор, и при перезагрузке тоже.
Вообще не понятно, что поставить, чтобы не надо было постоянно менять скорость в терминале, хочется раз поставить и чтобы всегда было видно что он там вывел.

как преодолеть китайскую "no buf for action frame"
Может китайцам написать?
 

pvvx

Активный участник сообщества
Плюс к этому при установке дефайнов везде, где только можно UART0_BAUD = 74880, а UART1_BAUD = 460800 все равно вылазит мусор, и при перезагрузке тоже.
Вообще не понятно, что поставить, чтобы не надо было постоянно менять скорость в терминале, хочется раз поставить и чтобы всегда было видно что он там вывел.
Невозможно - перезагрузка идет по разным веткам и частота у CPU (общая PLL) то меняется, то нет. Легче выбрать фиксированную и так и прошить. Кварц же для ROM-BIOS был рассчитан на 40 MHz, а поставили 26 MHz. Очередная недоработка китайцев. Главное, что следующие версии чипов так и прописывают с ошибками в ROM-BIOS и с кварцем 40 MHz. С 40 MHz наверняка не пошло по потреблению и другим параметрам - китайцы...
Может китайцам написать?
Бесполезно и выйдет ещё хуже. Будет одно вредительство. Всё что описали и им дали они исправили так, что лучше бы не трогали.
Проще сменить алго и как-то обойти или запатчить, если уж сильно мешает...

Новая версия алго в TCP2UART уже в git. При скорости 1 мегабит у меня не выставляет RTS/CTS - успевает и так. При 3 Mегабита - только когда поток в две стороны, то не появляется RTS/CTS, но дырки есть - тоже какие-то китай задержки периодически происходят и ломают равномерность.
Все паузы наборов буферов выкинуты. Передает как приходит блок по UART - сразу после обнаружения паузы в 3 символа (при более 19200 - 1 ms, и так до 500000, потом аппаратного счетчика не хватает и пауза уменьшатся в пропорции от скорости UART). Если байты передаются типа постоянно по одному с паузами, то тут уж ничего не поделать и разбивка на пакеты убивается, но попытки это сделать остаются. Иначе не уложиться в трафик TCP.
 
Последнее редактирование:

al.kl

New member
задействовал аппаратный определитель паузы между символами (UART_RX_TOUT_THRHD)
Ув. pvvx, а можно поинтересоваться, для чего это ? Чисто в целях повешения образованности :) Начал заниматься этим неделю-две назад всего :)
Сам сейчас делаю (точнее почти сделал) модуль управление УАРТом. Открыл ихний uart.c и чуть со стула не упал. Перешёл полностью на прерывания (и по RX и по TX), сделал динамическую очередь на передачу, таймауты, каллбеки по окончании приёма и передачи, ушёл от ихних всяческих ужасных макросов (типа UART_INT_ST и UART_INT_ENA) переписав всё под нормального вида структуры, и т.д...
Привязка к китай-либам осталась только по таймерам (использую для таймаутов), по разрешению прерываний от модуля UART и приаттачивания isr-функции.
В перспективе - разобраться со всем, на более низком уровне, и не быть привязанным к каким то закрытым либам. Очень жаль, что на чип нет хорошей документации. А там же, по-любому, - хорошая периферия, всякие DMA и тому подобное, и много-много всяких вкусных плюшек...
 

PostLast

Member
При выборе esp8266web/wifi.h at master · pvvx/esp8266web · GitHub
PHY_MODE_11G модуль падает сразу после попытке создания точки доступа в режиме SOFTAP
если выбирать в WEB то точка не создается вывод отладки сообщает о закрытии старой точки. Это мой таракан или национальное достояние?

Где можно задать значение IP для клиента как значение по умолчанию в TCP2UART?

esp8266web/web_websocket.c at master · pvvx/esp8266web · GitHub
с окончанием esp8266web/web_websocket.c at master · pvvx/esp8266web · GitHub
при уровне отладки 0 вызовет ошибку. Надо перенести.
 
Последнее редактирование:

pvvx

Активный участник сообщества
При выборе esp8266web/wifi.h at master · pvvx/esp8266web · GitHub
PHY_MODE_11G модуль падает сразу после попытке создания точки доступа в режиме SOFTAP
если выбирать в WEB то точка не создается вывод отладки сообщает о закрытии старой точки. Это мой таракан или национальное достояние?
Не пробовал на 1.5.2. Но почему-то все модули плохо работают при "RF Tx Power: 82" - ставлю меньше и всё хорошо.
Надо перенести.
Перенесу...
 

pvvx

Активный участник сообщества
а можно поинтересоваться, для чего это ?
А как реализовать "таймауты, каллбеки по окончании приёма и передачи"? UART_RX_TOUT_THRHD - это аппаратный счетчик паузы... Кривой, но аппаратный.
Или вопрос зачем web-свалка? Описано многократно - чтобы показать, что можно сделать почти всё - как претендент. И далее всякое остальное ПО подтягивается, со временем. Как пример - она первая показала, что можно на ESP8266 сделать почти нормальный WEB со скоростями TCP потока к 1 мегабайту в сек с обработкой к 60..200 одновременных соединений в секунду. До этого у народу на ESP была только глючная espconn c пределом 4 соединения и отсылкой до 1 пакета (далее крах :))... Так постепенно всё и формируется, китайцам приходится выкладывать разное и менять подход... а я не проф.программист и не понимаю, по чему люди сами не хотят разгребать чип, делать на нем что-то, а требуют готовое :)
Перешёл полностью на прерывания (и по RX и по TX), сделал динамическую очередь на передачу, таймауты, каллбеки по окончании приёма и передачи, ушёл от ихних всяческих ужасных макросов (типа UART_INT_ST и UART_INT_ENA) переписав всё под нормального вида структуры, и т.д...
Это всё сделано уже в Modbus.
Очень жаль, что на чип нет хорошей документации. А там же, по-любому, - хорошая периферия, всякие DMA и тому подобное, и много-много всяких вкусных плюшек...
Ну вот постепенно и вскрываются всякие плюшки, по мере жизни web-свалки... Она обрастает и переростает. :)
 

al.kl

New member
Или вопрос зачем web-свалка?
Не, не... Вопрос был именно в определении времени между символами (байтами, как я понял ? ).
Таймаут и без них можно определить, например, зная скорость и необходмое кол-во байт для таймаута. Ну а каллбек - тут по вкусу.
По этому, никак у меня с этим всем не вяжется определение времени между байтами. Не успел девайс передать следующий байт за время таймаута - его проблемы.

по чему люди сами не хотят разгребать чип, делать на нем что-то, а требуют готовое
Я, например, не из таких :) Но пока мне ещё очень многое не понятно. И информации по этим всем делам очень мало. И пнуть некому в нужном направлении.
 

pvvx

Активный участник сообщества
Не, не... Вопрос был именно в определении времени между символами (байтами, как я понял ? ).
Таймаут и без них можно определить, например, зная скорость и необходмое кол-во байт для таймаута. Ну а каллбек - тут по вкусу.
По этому, никак у меня с этим всем не вяжется определение времени между байтами. Не успел девайс передать следующий байт за время таймаута - его проблемы.
И как же вы вычислите тайм-аут при скорости от 1 Мегабита? Пока проц входил в прерывание в UART уже пришел следующий символ и сидит в его FIFO. Пока вы считывали FIFO, туда ещё успевает приняться до трети его размера. Да и прерывание отрабатывает с задержкой, т.к. исполняется и код с запретом прерываний. И как отработать (проанализировать) тайм-аут для 2-х us и менее? Или как отследить выпадение в 1,5 символа в потоке, пусть на 1 Мегабит. Ну и как найти сколько было принято символов в FIFO до паузы в 3,5 символа, если при входе в прерывание уже получены новые символы в FIFO? Ваша версия - ? (подписать NDA с Espressif и вытребовать доп. документацию у них на slc register-ы и прочие для использования их с DMA к UART не годиться - это выйдет закрытый код).
Я пока прореверсил только TOUT_THRHD. Это счетчик паузы на линии RX по 8 тиков клоков UART и дающий сигнал прерывания. Он считает от перепаду в активное состояние на RX и не всё там линейно с ним... Т.е. он считает со своей дискретностью в 8 тиков и не от символа, а ведет счет от наличия последнего активного уровня на RX в свой период счета. Как это отражается на DMA - неизвестно, т.к. нет описания как подключить SLC к UART и вообще есть ли такая возможность - пока не копал. Раскопаете - опубликуйте - это обычно приводит к тому, что китайцы через время вынуждены дать ещё какие описания по этому делу, т.к. народ начинает требовать на основе "претендента".
 
Последнее редактирование:

al.kl

New member
Ну о таких скоростях при таймауте в 1.5 байта я и не думал :) Ибо какой смысл вызывать юзерский каллбек ровно через 3 мкс. после приёма пакета ? Ни у одного протокола нет таких требований - слать ответ через такой маленький промежуток времени после приёма. А если и есть, то это уже - безумство :) Посчитать, что после 1.5-байтовой тишины, пакет принялся - да, можно. Но никак не отвечать.
На данный момент, у меня таймауты измеряются в миллисекундах. Минимум = 2 мс.
 

pvvx

Активный участник сообщества
Ни у одного протокола нет таких требований - слать ответ через такой маленький промежуток времени после приёма.
В Modbus протоколе оф. паузы 750 us и 1750 us. Точнее по выбору: если оборудование позволяет, то 1.5 и 3.5 символа. 11/921600 = 0.000012 сек символ.
 

al.kl

New member
Т.е. , принимающий обязан в течении 750 us ответить, иначе ждущий примет это как его отсутствие ?
Кошмар...
Ну ладно хоть не 7.5 us :D
 

pvvx

Активный участник сообщества
Т.е. , принимающий обязан в течении 750 us ответить, иначе ждущий примет это как его отсутствие ?
Кошмар...
Ну ладно хоть не 7.5 us :D
Нет - если пауза больше 1.5 символа - значит фрейм в помойку. 11*1.5/921600 = 0.000018 сек.
А для 3Mbit/s это значит, что вы должны анализировать паузу в 5.5 us. :p
 

pvvx

Активный участник сообщества
Это по приёму. Пауза между символами.
А по ответу после приёма ? Обязан ответить не позднее 750 us ?

PS: Ща покурю протокол, заинтересовало... :)
Зависит от выбора пользователя :) Если установка при более 19200 паузы в 750us и 1750us, то ответ может быть послан через 1750 us. Если выбрана установка 1.5 и 3.5 символа - то соответственно, ответ может начинаться через 3.5 символа (символ в modbus = 11 клоков UART и пауза считается от конца символа - последнего стоп бита.)
На форуме есть тема: ModBus RTU (RS-485) и лучше продолжать про Modbus там.
Смысл в том, что проц тупой - особенно шина к переферии типа UART.
Как итог - (11/3000000)/(1/26000000) = за 95.333333 обращений к шине проходит символ на UART на 3Mbit/s. А считывание из FIFO равно 2-м обращениям к шине. Т.е. за считывание 128 символов из FIFO приходит не менее 3-х символов.
 
Последнее редактирование:

al.kl

New member
Пока про ответ ничего не нашёл. Но вычитал по 1.75 и 0.75 ms, что это - замена 1.5-символьной тишины при скоростях выше 19200. Так что, ловля одно-микросекундных межсимвольных пауз - фанатизм :)
 

pvvx

Активный участник сообщества
Пока про ответ ничего не нашёл. Но вычитал по 1.75 и 0.75 ms, что это - замена 1.5-символьной тишины при скоростях выше 19200. Так что, ловля одно-микросекундных межсимвольных пауз - фанатизм :)
Эти паузы написано что по выбору. :p Т.е. возможно использование 750 us при скоростях более 19200, но не обязательно, а обязательно 1.5 символа.
Время ответа нормируется в доп. ограничении.
Но есть такое - передача пакета всем устройствам. Это значит, что устройство обязано отработать принятые последовательно пакеты с паузами между ними в 3.5 символа. Вычислить там контрольку, поменять там свои переменные... :)
 

al.kl

New member
Ну да, ключевое слово "рекомендуется" :) По этому, ловить 1.5 символа на мегабодах - фанатизм :)
Не думаю, что какие-то фирмы будут выдерживать такие паузы. Можно 750 us ? - значит сделаем 750 us :)

Тут ещё нужно по ответам почитать. Если можно отвечать через, например, 10 ms, то зачем ловить окончание фрейма через 750 us ?
Видишь тишину 1 ms, значит кадр закончен. Проверяем CRC, паритет, всё в порядке - отвечаем.
 

pvvx

Активный участник сообщества
Ну да, ключевое слово "рекомендуется" :) По этому, ловить 1.5 символа на мегабодах - фанатизм :)
Не думаю, что какие-то фирмы будут выдерживать такие паузы. Можно 750 us ? - значит сделаем 750 us :)

Тут ещё нужно по ответам почитать. Если можно отвечать через, например, 10 ms, то зачем ловить окончание фрейма через 750 us ?
Чтобы определить, что фрейм битый и на него нельзя отвечать.
Фанатизм делать не по спецификации. Любимое дело в Ардуино. :)
Уберите из протокола слово "рекомендуется" - тогда и будет 750 us.
 

al.kl

New member
А если он просто окончен ? Нельзя же по паузе судить о корректности фрейма. На то есть другие средства.
 

pvvx

Активный участник сообщества
А если он просто окончен ? Нельзя же по паузе судить о корректности фрейма.
Блин - ну вникните в доку modbus. Фрейм - это последовательность символов с паузой от 3.5 символа в начале и без разрыва более 1.5 символа. Далее уже формат данных в нем - контролька и прочее.
Я туты не при чем. Это modbus :)
Если ваше устройство не поддерживает описанного - значит оно не совместимо с Modbus RTU. Так и пишите в инструкции. :)
В теме прошивки для Modbus эти нюансы указаны, что пауза в 1.5 символа не отслеживается, а применен другой алго... позволяющий работать на стандарте Modbus RTU до 19200 baud, максимально вписываясь в документацию на Modbus RTU.
 
Последнее редактирование:
Сверху Снизу