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

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

pvvx

Активный участник сообщества
Обнаружил неприятный момент в сборке от pvvx.
В какой версии и при каких настройках WiFi?
(Борьба с новыми SDK и их глюками идет постоянно и всё время что-то меняется :) )
С последней версией из git :
test_9600_1.gif
Но сканирование станций одновременно с соединением с версий SDK 1.1.x разрывает всё - китайцы что-то натворили и не понятно что...

Посмотрите:
1) При заполнении буфера передачи, что при 9600 явно происходит через несколько секунд, соединения типа "закрыто" (нулевое приемное окно у TCP) и нового не откроется, при "обрыве" (некорректном завершении TCP соединения), пока буфер не выйдет в uart.
2) Большинство программ и всевозможных реализаций TCP соединений имеют тайм-аут на длительность соединения как раз на 1..2 минуты.
3) При установке LIGTH sleep вообще сплошной глюк связанный с китай частью wifi sdk. Причина описана, но "лечение" заброшено, т.к. надоело - эту часть китайцы меняют каждую новую версию и каждый патч.
В связи с общим бардаком, держать постоянно открытое соединение TCP2UART не стоит. Используйте тайм-ауты и передавайте/принимайте c периодическим закрытием/открытием соединения. Это позволит избавиться от всевозможных глюков всего подряд, включая и роутеры и сети и стороннее ПО.
 
Последнее редактирование:

aloika

Active member
В какой версии и при каких настройках WiFi?
С "Текущая свалка ver 0.3.3 (24.05.15) на PvSDK version: 0.0.1 + огрызки от SDK 1.1.0 Espressif."
Wi-Fi - точка доступа без пароля.

А какой Вы программой пользуетесь для тестирования TCP?

По поводу других замечаний: лично мне TCP вообще не нужно, мне просто нужно получать данные из UART и анализировать их, далее что-нибудь в UART слать. Поэтому часть с TCP я из конечной реализации убираю (может там что криво я наделал). Итог: наблюдается падение WiFi после приема сотни-другой байт если при этом поллить web.

Тогда я взял последнюю версию сборки, залил ее, открыл TCP-соединение, начал слать туда те же байты. Результат - не так часто, но тоже падает, и падает также (те же симптомы). Теперь надо выяснить, или это у меня здесь локальный глюк, или это какой-то дефект в сборке.
 

pvvx

Активный участник сообщества
А какой Вы программой пользуетесь для тестирования TCP?
Разными. У них у всех разные глюки :)
На скрине - у неё бяда с перекодированием символов и не умеет RTS/CTS, беда с буфером UART, беда с TCP - нет поддержки полного стандарта TCP. Китайская программа - см. вложение.
Тогда я взял последнюю версию сборки, залил ее, открыл TCP-соединение, начал слать туда те же байты. Результат - не так часто, но тоже падает, и падает также (те же симптомы). Теперь надо выяснить, или это у меня здесь локальный глюк, или это какой-то дефект в сборке.
Без RTS/CTS будет падать, т.к. тестирование UART2TCP без RTS/CTS я не провожу и не рассматриваю как рабочее решение.
 

Вложения

aloika

Active member
pvvx, сегодня целый день тестировал с приложенной Вами программой - падений нет. Ну т.е. падений модуля нет (для меня это самое главное), а передача иногда прерывалась/подглючивала, но это, наверное, потому, что нет RTS/CTS.
 

pvvx

Активный участник сообщества
сегодня целый день тестировал с приложенной Вами программой - падений нет. Ну т.е. падений модуля нет (для меня это самое главное), а передача иногда прерывалась/подглючивала, но это, наверное, потому, что нет RTS/CTS.
Перезагрузки модуля нет, но глюков ещё много с SDK 1.1.2. Git обновляю часто... Только вчера была достигнута полная коррекция https://github.com/pvvx/esp8266web/blob/master/app/main/eagle_lwip_if.c к SDK1.1.2 для использования OpenLwIP.
Модуль включаю с входами установленными на выход в режим программирования при перезагрузке. Т.е. если произойдет перезагрузка, то модуль встанет в режим программирования чтобы явно отследить перезагрузку. В таком состоянии он работает сутками включенным в глобальный инет (к нему там лезут разные поисковики и т.д.) и при других тестах.
Но этого всё равно мало - описанная беда со сканированием станций всё ещё не решена... ещё нет полной стыковки с WDT и другими фичами, которые в SDK 1.1.x возникли от китайского переноса векторов процессора и их обработки из ROM-BIOS в SDK (в IRAM) - могут некорректно работать некоторые функции в SDK, связанные с этим.
 
Последнее редактирование:

aloika

Active member
pvvx, подскажите, пожалуйста.
Когда я пишу вот это
Код:
UART0_INT_ENA |= UART_RXFIFO_FULL_INT_ENA;
- это я включаю прерывание по приему символа, или по заполнению какого-нибудь буфера RXFIFO (судя по названию)?

Далее, кроме этого прерывания никакие не включаю и оставляю void uart_intr_handler(void *para) просто пустой, типа
Код:
void uart_intr_handler(void *para)
{
}
И по приему нескольких символов модуль падает. Если прерывание отключить, то не падает. Такого же по идее не должно происходить? ну прерывание, ну пустое. С чего падать-то?
 

aloika

Active member
Andy Korg, это я не к тому, что "вот, написано же" :)
я пытаюсь сборку от pvvx адаптировать под свою задачу, поэтому всё выкладывать проблематично. Вообще какие-то проблемы есть, и самое неприятное, что они то возникнут, то пропадут, и не удается точно определить условия, когда эти глюки возникают. Сейчас выяснилось, что те глюки, про которые я писал pvvx, возникают только дома, где много сетей, а на работе все работает. Сейчас еще буду тестировать по-всякому...
С прерыванием этим тоже не все понятно - так-то оно работает, но из-за него модуль с разной вероятностью валится. Сейчас я уже взял просто последнюю версию сборки, и просто ее тестирую, без изменений каких-либо. И тоже есть глюки.
 

pvvx

Активный участник сообщества
прикольно. А что еще написано? :) А если серьезно то лучше наверно весь коды выложить, а то тяжело понять что написано, а что нет.
А ещё надо подтверждать прерывание в функции прерывания, бывает что и в самом блоке и ещё в контроллере прерываний и в спец регистрах CPU :p Иначе будет вечный цикл входа в процедуру прерывания и WDT, а может и стек переполнить... В спец регистрах CPU прерывание за вас сбрасывает обработчик, вызывающий вашу процедуру...
UART0_INT_CLR = UART0_INT_ST; // подтвердить/сбросить почти все триггеры событий прерываний в UART0. Не сбрасывает все триггеры событий, т.к. они опять выставятся если не опустошить FIFO или произвести другие необходимые действия с UART для сброса необходимых событий перед сбросом защелки UART0_INT_CLR...
Если не представляете как это всё работает - наловитесь глюков до чертиков :)
В текущей реализации с UART всё там нормально.
Сейчас я уже взял просто последнюю версию сборки, и просто ее тестирую, без изменений каких-либо. И тоже есть глюки.
Какие глюки?
 
Последнее редактирование:

pvvx

Активный участник сообщества
То. Помогло. Но нет патча для SDK с описанием в хидерах новых объявленных функций :) Ждем следующий патч :) А то зачастили китайцы с новыми версиями = будет много патчей, т.к. на каждую новую вписанную функцию у них в среднем по десятку ошибок :) Новых версий навыпускали, а даже старые ошибки ещё не исправили (и не знают какие там они есть = хорошо! Баунтей больше нет :) Только сегодня ещё пару нашел и исправил, но у себя, а им фиг.)
 
Последнее редактирование:

aloika

Active member
А ещё надо подтверждать прерывание в функции прерывания, бывает что и в самом блоке и ещё в контроллере прерываний и в спец регистрах CPU :p Иначе будет вечный цикл входа в процедуру прерывания и WDT, а может и стек переполнить... В спец регистрах CPU прерывание за вас сбрасывает обработчик, вызывающий вашу процедуру...
UART0_INT_CLR = UART0_INT_ST; // подтвердить/сбросить почти все триггеры событий прерываний в UART0. Не сбрасывает все триггеры событий, т.к. они опять выставятся если не опустошить FIFO или произвести другие необходимые действия с UART для сброса необходимых событий перед сбросом защелки UART0_INT_CLR...
Если не представляете как это всё работает - наловитесь глюков до чертиков :)
Это все есть, я то, чего не понимаю, не трогаю :) А глюки вот:
1. На работе все работает. Там Windows 7 и мало wi-fi сетей.
2. Дома - глюки (тут Windows 8 и много сетей). На 9600 минуты две работает и модуль как бы подвисает на пару секунд, в уарты кидает немного мусора, потом отвисает и дальше работает снова секунд 30 и опять то же самое. Не перегружается. На 115200 (на самом деле на 123200) работает, но через некоторое время комп перестает отображать Web-интерфейс. Прямо даже писать такое неудобно :) На телефоне Web-интерфейс отображается... После этого комп вообще не отображает веб-интерфейс, перегружать его надо (комп!). В то же время связь по TCP какое-то время еще есть, а потом она пропадает вместе с вай-фаем.
Так. Пока писал, на компе вай-фай от модуля пропал, а на телефоне есть и все отображается. Может, у меня сетевуха на компе глючная?! Основной-то инет по кабелю идет...
 

Victor

Administrator
Команда форума
Только сегодня ещё пару нашел и исправил, но у себя, а им фиг.)
ну если что-то существенное, что реально приводит к wdt reset или wifi отваливается, то можно еще попробовать заход сделать. пишите если что.
[off]кстати жду от вас ответ в этой теме[/off]
 

pvvx

Активный участник сообщества
ну если что-то существенное, что реально приводит к wdt reset или wifi отваливается, то можно еще попробовать заход сделать. пишите если что.
Да там всё криво - либо не работает, либо делает не то что надо :) Ну как со "сканированием станций" - отваливается на неопределенное время WiFi и типа.
В последней версии SDK+path очередная бага при старте - долго думает до соединения ST к AP, плюет всякую белиберду в UART - всё идентично как и в версии без патча для ремонта аналогичного глюка после "сканированием станций" :)
Им писать буду, когда сумму объявят более 10 тысч $ и четкие условия.

-----------

В версии Web 0.3.4 включил клиента на TCP2UART. Пока задается IP и port, писано кое как, т.к. надо дописывать на задание и url...
Включение TCP2UART и SNTP теперь по событиям GOT_IP и/или после подключения к AP модуля клиента. Тоже не всё доделано - надо всё переводить на события....
Код:
WiFi event 3 - ST WiFi модуля подключилась к AP и получила IP (GOT_IP)
Station ip:192.168.1.50, mask:255.255.255.0, gw:192.168.1.1

SNTP: start - врубаем SNTP
TCP2UART client ip:192.168.1.2, port: 12345 - врубаем и TCP2UART

TCP Client service init Ok
Max retry connection 7, time waits 0 & 0, min heap size 14528
srv[4097] 192.168.1.2:12345 [0] start client - Ok
ip:192.168.1.50,mask:255.255.255.0,gw:192.168.1.1
srv[4097] 192.168.1.2:12345 [1] error -8
Waiting next connection 5000 ms...
SNTP: Set time: 0x5581ebaa
srv[4098] 192.168.1.2:12345 [1] start client - Ok
srv[4098] 192.168.1.2:12345 [1] error -8
Waiting next connection 5000 ms...
srv[4099] 192.168.1.2:12345 [1] start client - Ok
srv[4099] 192.168.1.2:12345 [1] listen - тут включил cервер на компе и он соединился.
add 1
aid 1
station: 00:0f:54:10:6a:b5 join, AID = 1
WiFi event 4 - к AP подключился клиент.
Station[1]: 00:0f:54:10:6a:b5 join, AID = 1
TCP2UART client ip:192.168.1.2, port: 12345 - проверилось, включен ли TCP2UART
 
Последнее редактирование:

pvvx

Активный участник сообщества
Покрутил TCP2UART client - модуль с модулем соединяются, непосредственно без посторонних и через роутер.
Сил соединить RX-TX в кольцо у модулей для вечной передачи запущенной в них цепочки байт - нет :)
 

aloika

Active member
pvvx, все-таки есть глюки. Версия сборки 0.3.2b (на версии 0.3.3 тоже).

Если вообще никак не модифицировать сборку, то надо сделать следующее:

1. Устанавливаем скорость 9600 (на 115200 тоже есть эффект, но реже).
2. Отображаем поллющую страничку (обязательное условие).
3. Подключаем к UART что-нибудь, что туда шлет символы. У меня микроконтроллер, шлет по 10 байт 3 раза в секунду. RTS/CTS нет.
3. Запускаем TCP-соединение и ждем.

По приему где-то 9000 (+-3000) символов происходит перезагрузка модуля, а именно: uptime не сбрасывается, но в остальном - перезагрузка, в отладочный уарт высыпается вся информация, как при загрузке, в рабочий уарт тоже что-то высыпается, связь по Wi-Fi теряется, но тут же восстанавливается.

Далее. Модифицируем сборку следующим образом.
1. Отключаем запуск TCP-сервера в user_main.c: [inline]// if(syscfg.tcp2uart_port) tcp2uart_init(syscfg.tcp2uart_port); [/inline]
2. В uart_tcp.c функцию uart_init дополняем:
Код:
void ICACHE_FLASH_ATTR uart_init(void)
{
    struct  UartxCfg ux;
        //disable all UARTs interrupt
        ets_isr_mask(1 << ETS_UART_INUM);
        //tcp2uart_int_rxtx_disable();
// UART0
        if(flash_read_cfg(&ux, ID_CFG_UART0, sizeof(ux)) != sizeof(ux)) {
            ux.baud = UART0_DEFBAUD;
            ux.cfg.dw = UART0_REGCONFIG0DEF;
        };
        uart0_flow_ctrl_flg = ux.cfg.b.flow_en;
        ux.cfg.dw &= UART0_REGCONFIG0MASK;
        UART0_INT_ENA = 0;
        UART0_CONF0 = ux.cfg.dw;
            //set rx fifo trigger
        UART0_CONF1 = ((0x01 & UART_RXFIFO_FULL_THRHD) << UART_RXFIFO_FULL_THRHD_S)
            | ((0x10 & UART_TXFIFO_EMPTY_THRHD) << UART_TXFIFO_EMPTY_THRHD_S)
            | (((128 - RST_FIFO_CNT_SET) & UART_RX_FLOW_THRHD) << UART_RX_FLOW_THRHD_S)
            | ((0x01 & UART_RX_TOUT_THRHD) << UART_RX_TOUT_THRHD_S)// | UART_RX_TOUT_EN
        ;
        update_mux_uart0();
        uart_div_modify(UART0, UART_CLK_FREQ / ux.baud); // WRITE_PERI_REG(UART_CLKDIV(num), ux.baud) + clear rx and tx fifo, not ready =
        // clear all interrupt UART0
        UART0_INT_CLR &= ~0xffff;
// добавил МК
        uart0_set_flow(false);
         //clear rx and tx fifo, not ready
            uint32 conf0 = UART0_CONF0;
            UART0_CONF0 = conf0 | UART_RXFIFO_RST | UART_TXFIFO_RST;
            UART0_CONF0 = conf0 & (~ (UART_RXFIFO_RST | UART_TXFIFO_RST));
            update_rts0(); // вот это зачем? ну ладно...
            UART0_INT_ENA &= ~UART_TXFIFO_EMPTY_INT_ENA; // отключаем прерывание по опустошению буфера TX
            UART0_INT_ENA |= UART_RXFIFO_FULL_INT_ENA; // включаем прерывание по приходу символа в RX
            ets_intr_unlock(); // ETS_UART_INTR_ENABLE();


// *** //

// UART1
        if(flash_read_cfg(&ux, ID_CFG_UART1, sizeof(ux)) != sizeof(ux)) {
            ux.baud = UART1_DEFBAUD;
            ux.cfg.dw = UART1_REGCONFIG0DEF;
        };
        ux.cfg.dw &= UART1_REGCONFIG0MASK;
        UART1_INT_ENA = 0;
        UART1_CONF0 = ux.cfg.dw;
        UART1_CONF1 = 0x01707070;
        update_mux_txd1();
        uart_div_modify(UART1, UART_CLK_FREQ / ux.baud); // WRITE_PERI_REG(UART_CLKDIV(num), ux.baud) + clear rx and tx fifo, not ready =
        // clear all interrupt
        UART1_INT_CLR &= ~0xffff;

        MEMW();

        os_install_putc1((void *)uart1_write_char); // install uart1 putc callback
        ets_isr_attach(ETS_UART_INUM, uart_intr_handler, NULL);
        ets_isr_unmask(1 << ETS_UART_INUM);


}
3. В этом же файле функцию - обработчик прерывания UARTов модифицируем:
Код:
void uart_intr_handler(void *para)
{
    // uart0 and uart1 intr combine togther, when interrupt occur, see reg 0x3ff20020, bit2, bit0 represents
    // uart1 and uart0 respectively
    MEMW();
    uint32 ints = UART0_INT_ST;
    if(ints) {
        if (ints & UART_RXFIFO_FULL_INT_ST) { // прерывание по приему символов? да
            UART0_INT_ENA &= ~UART_RXFIFO_FULL_INT_ENA;
            ets_intr_lock(); //    ETS_UART_INTR_DISABLE();


            //parse_rx_buf(); // функция-парсер. пока закомментирована

                os_printf("Symbol!\n"); // в отладку пишем что-нить, чтобы видеть, что прерывание срабатывает

             //clear rx and tx fifo, not ready Интересно, что если этого не делать, модуль перезагружается после нескольких принятых символов.
                        uint32 conf0 = UART0_CONF0;
                        UART0_CONF0 = conf0 | UART_RXFIFO_RST | UART_TXFIFO_RST;
                        UART0_CONF0 = conf0 & (~ (UART_RXFIFO_RST | UART_TXFIFO_RST));



            UART0_INT_ENA |= UART_RXFIFO_FULL_INT_ENA; // зарядить прерывание UART rx
            ets_intr_unlock(); // ETS_UART_INTR_ENABLE();
        };
        UART0_INT_CLR = ints;
    }
    else {
        UART1_INT_ENA = 0;
        UART1_INT_CLR = UART1_INT_ST;
    }
}
4. Компилируем, запускаем, загружаем поллющую страничку, льем в уарт, ждем. Видим - каждые 30-40 секунд - перезагрузка модуля, uptime сбрасывается (иногда нет)...
 
Последнее редактирование:

pvvx

Активный участник сообщества
3. В этом же файле функцию - обработчик прерывания UARTов модифицируем:
os_printf("Symbol!\n"); // в отладку пишем что-нить, чтобы видеть, что прерывание срабатывает
Нельзя вставлять в прерывание os_printf и подобные.
В старых версиях, при использовании TCP2UART рекомендую отключать вывод в отладку. В новых вроде везде убрал вывод отладки из всех ветвей TCP2UART при минимальном уровне DEBUGSOO.
Ещё вывод отладки в UART создает большую задержку на вывод символов и нарушает время-зависимые процессы.
По приему где-то 9000 (+-3000) символов происходит перезагрузка модуля, а именно: uptime не сбрасывается, но в остальном - перезагрузка, в отладочный уарт высыпается вся информация, как при загрузке, в рабочий уарт тоже что-то высыпается, связь по Wi-Fi теряется, но тут же восстанавливается.
Не повторить. Вчера соединял два модуля. Один AP-ST ip 192.168.4.1, на нем включено LoopBack enable и TCP2UART:127.0.0.1: 12345 (сервер) 115200 baud, без Flow, ST соединена с роутером для управления по WEB. На втором модуле AP-ST ip 192.168.3.1, TCP2UART:192.168.4.1: 12345 (клиент) 115200 baud, без Flow, к AP присоединен комп клиентом для управления по WEB, ST модуля соединена к AP другого модуля.
Ко всем UART подключены USB2COM - 4 шт COM пота с терминалами.
Передаю символы и тестовый файл в UART модуля соединенного по WiFi с другим, у которого LoopBack enable. Данные уходят в RX и приходят из TX, пройдя путь передачи другому модулю и обратно, через LoopBack UART второго модуля.
Падений и описанного нет.
При том-же тесте на модуле ESP-01, включенном по питанию к USB с FT2232 (2COM порта + стабилизатор AIC1734-33XXA (SOT-89) на 3.3В 300mA от 5В USB), если не отключить flow, то чип ESP8266 раскаляется и часто падает - у модулей ESP-01 нога RTS закорочена на GND проводником под чипом(!). В связи с этим, в последней версии, по умолчанию отключен flow
 
Последнее редактирование:
Сверху Снизу