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

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

pvvx

Активный участник сообщества
pvvx
Добрый день,
Запустил Ваш rapitloader.
Работает, но сообщает об ошибке параметров системы.
ets Jan 8 2013,rst cause:2, boot mode:(3,6)

load 0x40100000, len 104, room 16
tail 8
chksum 0xbf
csum 0xbf
system param error, use last saved param!
rf cal sector: 123
freq trace enable 0
rf[112] : 00
rf[113] : 00
rf[114] : 01

SDK ver: 2.1.0(116b762) compiled @ May 5 2017 16:08:55
phy ver: 1134_0, pp ver: 10.2

mode : null
Может быть что-то подскажите поправить? или так и должно быть?
Хотелось бы знать причину такого сообщения.
Спасибо
Лоадер тут не при чем. Это сохранение в последних секторах Flash в SDK дурит.
 

pvvx

Активный участник сообщества
Ошибка проявляется следующим образом.
.....
В него вставлена функция
uint32 system_relative_time(void) { return *((uint32*)0x3FF20C00); }
которая нигде не вызывается.
Но если оставить как есть, то получим аварийное исполнение:
Fatal exception (0):
epc1=0x40200080, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00000000, depc=0x00000000
Это первая тестовая версия. Все 4-ре последующие там-же, но на asm. В них во всех адреса стыковки частей необходимо вычислять вручную. Для автоматического расчета gcc не располагает средствами, а писать ради этого внешние - лень. Быстрее переправить при изменении.
Код:
    .text
    .align    4
    .literal_position
    .global    call_user_start
    .type    call_user_start, @function
call_user_start:
    movi    a4, rtc_    // IO_RTC_4 = 0
    movi.n    a2, 0      
    s32i.n    a2, a4, 16    // GPIO_MUX = VAL_MUX_GPIO0_SDK_DEF
    movi    a3, 0x80   
    s32i    a3, a4, 308
    movi    a3, spi0_  
    movi.n    a5, 0x20    // SPI0_USER |= SPI_CS_SETUP
    l32i.n    a6, a3, 28
    or        a5, a6, a5
    s32i.n    a5, a3, 28
    l32i    a6, a4, 256 // GPIO_MUX_CFG |= BIT(MUX_SPI0_CLK_BIT) // QSPI = 80 MHz
    movi    a5, 0x100
    or        a6, a6, a5
    s32i    a6, a4, 256
    l32i.n    a4, a3, 8    // SPI0_CTRL = (SPI0_CTRL & SPI_CTRL_F_MASK) | SPI_CTRL_F80MHZ;
    srli    a5, a4, 12
    movi    a4, 1
    or        a5, a4, a5
    slli    a4, a5, 12
    s32i.n    a4, a3, 8
    mov.n    a4, a2         // Cache_Read_Enable(0, 0, 0);
    mov.n    a3, a2
    call0    Cache_Read_Enable
    movi    a2, 0x40200070+0x40 // +0x40 size: addld.bin
    movi    a3,-0x40
    add        a0,a2,a3
    jx        a0
//    call0    0x40200070
    .byte    0x85
    .size    call_user_start, .-call_user_start
Код:
        .begin    literal_prefix    .loader
        .section    .loader.lit4, "ax"

        .align    4
        .global loader_flash_boot

loader_flash_boot:
        l32i.n    a3, a2, 0    // SPIFlashHeader.head : bit0..7: = 0xE9, bit8..15: Number of segments, ...  
        l32i.n    a7, a2, 4    // Entry point
        extui    a3, a3, 8, 4 // Number of segments & 0x0F
        addi.n    a2, a2, 8    // p SPIFlashHeadSegment
        j        4f
1:
        l32i.n    a5, a2, 0    // Memory offset
        addi.n    a4, a2, 8    // p start data
        l32i.n    a2, a2, 4    // Segment size
        srli    a2, a2, 2    // size >> 2
        addx4    a2, a2, a4    // + (size >> 2)
        j        3f
2:      
        l32i.n    a6, a4, 0    // flash data
        addi.n    a4, a4, 4
        s32i.n    a6, a5, 0    // Memory data
        addi.n    a5, a5, 4
3:      
        bne    a2, a4, 2b        // next SPIFlashHeadSegment != cur  
4:
        addi.n    a3, a3, -1    // Number of segments - 1
        bnei    a3, -1, 1b    // end segments ?
      
        movi.n    a2, 1
        slli    a1, a2, 30

        jx        a7             // callx0 a7

        .byte    'R'
        .byte    'L'
        .byte    'd'
        .byte    'r'
        .byte    'V'
        .byte    '5'
        .byte    ' '
        .byte    '8'
        .byte    '0'
        .byte    'M'
        .byte    'H'
        .byte    'z'
        .align    16
У него загружаемого кода в IARM уже 92 байта и ROM-BIOS пишет на 1 цифру меньше в UART.
 
Последнее редактирование:

pvvx

Активный участник сообщества
А разве нельзя зафиксировать эти области Например для лоудера 1 блок и далее все сметить статически?
------------------------------
И еще вопрос по ошибке
system param error, use last saved param!
--------------------

Почему без лоудера ее нет, а с ним -есть?
По тому что вы не читали инструкций на SDK :)
Размер flash указывается в заголовке - в первых байтах Flash, от него пляшут китайцы в китайском SDK где сидят их сохранения.
У меня "лоадер" сделан под мою сборку SDK и создает песочницу для SDK в первые 512 кило Flash, где ей разрешено что-либо, а для пользователя - вся Flash и размер определяется автоматически.
Вы пока копаетесь в информации 2014 года. Я уже всё забыл и вспоминать сложно и не охота, т.к. это больше никому не нужно - ESP8266 умер.
Никто уже не будет включать куда либо и это и то, что не смогли осилить всякие "портировщики". Та-же Arduino IDE имеет полуторагодовалый SDK с пачками ошибок...
Делать что-то с самой системой не будут, даже если это будет давать выигрыш во всем. На кривые алгоритмы и функции SDK/Arduino уже выросло целое поколение и они не дадут сменить ничего :)
Последние вопросы по ESP8266 в 90% : Дайте "скетч" на мою задачу - мне лень искать!
 
Последнее редактирование:

nikolz

Well-known member
Суперкондер - это имеется в виду ионистор? Если не секрет какой период зарядки ожидания получается?
Период зарядки в первых экспериментах получил не менее 20 секунд, конденсатор 1 фарада.
Результаты экспериментов я приводил на форуме.
Использовал две солнечные панельки 8x5.5 см2 ,
что теоретически дает в солнечный день максимум 0.8 вт.
Эксперименты ставил в пасмурный день и при искусственном свете в комнате.
Основная проблема в том, что когда напряжение питания становится меньше 2.2 вольт,ESP виснет в активном режиме и полностью разряжает кондер.
Сейчас сделал так что eSP контролирует питание по внутр ацп и при напряжении меньше 2.2 не включает wifi а ложиться спать до лучших времен. В результате потребление в этом режиме уменьшилось примерно в 3 раза по сравнению с режимом wifi.
--------
Кроме того, за счет управления током заряда получил амплитуду импульсов тока от источника не более 50 ма (вместо 250 по документации для ESP) в режиме WIFi.
---------------------
ожидаю сократить импульсы до 20 ма. Время заряда ожидаю порядка 30- 60 сек.
===============
Кроме того, суперкондера хватает примерно на 20 сеансов связи, т е ночью можно работать без зарядки.
 
Последнее редактирование:

pvvx

Активный участник сообщества
Да, я выкладывал результаты на форуме.
Но не выкладывали ни единого исходника для подтверждения или информации для проверки другими.
Для вас есть простое решение "зависания" ESP - поставить WDT при старте и удалить из SDK управление им. Что-бы он не делал, если не уложится в назначенный период, то по вектору WDT кидаете его в deep_sleep.
Всё равно вам уже пришлось бороться с китайским SDK - переделывать его, т.к. он не приспособлен для автономных устройств ни одной функцией и примененными в нем алгоритмами. На ESP вас сдерживают набранные на него ваши личные знания. У меня ситуация другая и мне надоело с ним возится, т.к. там надо делать всё вопреки закрытого кода его SDK и глюков. Проще взять более открытый SDK с исходниками и подправить на требуемую задачу. Тем более инструментов на ARM больше и другие чипы WiFi-SoC имеют больше нужных встроенных полнофункциональных контроллеров со стандартными и описанными моделями IP (дизайна на кристалле и регистров управления) при одинаковой цене.
 
Последнее редактирование:

pvvx

Активный участник сообщества
В общем Вы совершенно правы, но все даже еще проще.
-------------------------------
Вы профессионально этим занимаетесь, а я - в качестве хобби.
Профессионально я занимаюсь немного другим...
А с WiFi-SoC - это хобби, и цели и задачи которого - дать базовую возможность построения того, что именно вы используете. Как только базисы, которые сложно создать/решить/выудить начинающим даны для развития уже дальнейшего движения, то на этом моё хобби с данным WiFi-SoC закачивается.
Вольному- воля..
Про то и разговор.
Хочу копать RTL-ки - копаю. Но вы всегда против любого нового :)
Делиться полученным вы отказываетесь. "Верю-не верю" тут не при чем.
Результаты с лучшими показателями вам представлены с возможностью повтора и наличием необходимых для этого ингредиентов (на ESP и с ещё лучшими показателями на RTL-ках).
В частности для самого дешевого варианта подключения камеры для решения ваших задач.
 
Последнее редактирование:

pvvx

Активный участник сообщества
Вы наверное удивитесь, но я полагаю, что Вы оказываете медвежью услугу тем телепузикам, которым как бы помогаете.
Вы два года ковыряли SDK ESP, что в итоге?
Либо ардуино либо СИ с SDK ESP.
Ваша свалка - это кладбище утонувших кораблей.
И вместо того чтобы изучить библиотеку SDK горе телепузики иногда лезут на вашу свалку и громко кричат алилуя ее создателю. Но в результате лепять выключатели на дурине и тупо копируют примеры из инета.
Ну ка тут не вспомнить:
В час отлива, возле чайной
я лежал в ночи печальной,
говорил друзьям об Озе и величьи бытия,
но внезапно чёрный ворон
примешался к разговорам,
вспыхнув синими очами,
он сказал:
"А на фига?!"
Я тоже самое им говорю - сделать Web на ESP можно, поддерживать не желаю, задача как прецедента, что "можно web" у неё выполнена в первые месяцы 2015, до Arduino. Берите Arduino - там давно уже должно быть решение создания полноценного web на ESP8266. Но требуют поддержки тестовой версии Web-свалки.
Аналогично ждем решения для автономного применения ESP8266 от вас. Но проходят годы, а его нема :p Вы постоянно предлагаете этим вопросом озадачиться мне. Но оно уже выдано и рассмотрено со всех сторон с итогом невозможности реализации на текущих SDK с удовлетворительными итогами, а создавать полностью свои SDK на устаревший чип я не намерен - не вписывается в моё хобби или проф.деятельность.
В итоге вы опровергаете самого себя :)
 
Последнее редактирование:

pvvx

Активный участник сообщества
Добрый день,
Приступил к изучению Вашего SDKnoWIFI
Выкладываю две картинки.
первая - это полная диаграмма потребления тока при исполнении вашего теста.
Посмотреть вложение 4788
Вторая картинка - это deep-sleep в лоадере. Текс который из рома выводится, но полное время 83 ms.
А Вы говорите - не бывает.
Посмотреть вложение 4789
Так как же подавить вывод сообщения из ром?
Спасибо
Загрузиться нормально, с другой Flash. Прописать программу в IRAM. Уведомить ROM-BIOS о адресе старта в IRAM, вызвав определенную процедуру.
Затереть кол-во сегментов в заголовке другой Flash (пишу по памяти, может что ещё там) и включить её вместо основной. Это вызовет необходимую ошибку в ROM и ... :)
Далее внешним MCU поставить GPIO0 = "0", GPIO1 = "1", GPIO2 = "0" (boot mode:(2,x)) и сделать перезагрузку 'Jump Boot' со стартом прямо в IRAM.
Будет не более 30 ms на перезапуск ESP8266. При отключении питания IRAM - данные в ней потеряются. Предусмотрите её питание...
 
Последнее редактирование:

pvvx

Активный участник сообщества
Спасибо, порадовали.
Ваша инструкция напомнила мне историю с копированием компьютера макинтош малоизвестной фирмы эпл.
Помните как это было сделано благодаря нашим (то бишь советским кулибинам)
В результате половина доблестных умов программистов СССР трахались разрабатывая софт для почти копии макинтоша. А все потому, что кто-то из любителей ковырять чужие чипы и модернизировать их усовершенствовал графический чип макинтоша и все стало ПОЧТИ совместимо.
При чем тут кто-то и что-то?
Технически ваш вопрос решается? Решается. Ответ дан.
Если вы не в состоянии это проделать, то при чем тут другие?
Загрузить стартовый код в IRAM можно и по интерфейсу UART в режиме программирования внешним MCU.
Попытка сделать опрос датчика влажности SHT75 с засыпаниями (перезагрузкой ESP8266 ибоб только так он не жрет) не удалась. Минимальный цикл выхода опроса шины к 50 ms, пока датчик вычисляет. Но при 50 ms - ESP активен 30 ms - никакого понижения потребления. На RTL - это влет, в обычном sleep, без всяких перезагрузок с потреблением к 100 мкА.
Вот сча питался проверить сколько будет жрать RTL при выводе в UART значений ADC. Не вышло - гад питается от выводов UART. Надо отпаивать CH430 или делать другую макетку.
 
Последнее редактирование:

Elik

New member
Наблюдаю такую странную вещь: ранее странички грузились нормально без ошибок, оставил девайсину на время, сейчас включаю и то код сьедает, то картинки не грузит? от чего может быть такое поведение?
Аххх разобрался, низкое напряжение всему виной!
 

1801BM1

New member
Еspressif библиотеки свои обновила, в том числе касательно свежей уязвимости WPA. Библиотеки 2.1.x подойдут к выложенному киту Web-сервера или там надо дополнительно разбираться? Есть папка lib200, насколько оно беспроблемное по части собственно WiFi?
 

pvvx

Активный участник сообщества
Еspressif библиотеки свои обновила, в том числе касательно свежей уязвимости WPA. Библиотеки 2.1.x подойдут к выложенному киту Web-сервера или там надо дополнительно разбираться? Есть папка lib200, насколько оно беспроблемное по части собственно WiFi?
В Web-свалке используются переработанные библиотеки от SDK Еspressif до (включая) версию 2.0. Стартовая часть и инициализация переписана и даны исходники, что дает гибкость для оптимизации под задачи. Работа там ведется с закрытыми от пользователя переменными и для новой SDK требуется адаптация (реинженеренг новых введений, согласование хидеров внутренних данных SDK, выкидывание идиотских частей ненужного никому кода и прочее). Но тема развития web-свалки на ESP закрыта. Так-же новые версии SDK от Еspressif всё толстеют и их код уже не лезет в малые flash, а Еspressif не собирается давать возможность выбора включенных в проект компонентов SDK пользователям. Т.е. ESP8266 умер по причине самой Еspressif.
Отдельно чистого драйвера WiFi они не дают, а дают закрытый проприетарный SDK где все их никчемные навязанные причиндалы уже включены и изменить что-либо невозможно без затрат на полный "реверс". Такой SDK ныне никому не нужен, а заниматься "реверсом" на устаревший чип не имеет смысла.
 
Последнее редактирование:

1801BM1

New member
Такой SDK ныне никому не нужен, а заниматься "реверсом" на устаревший чип не имеет смысла.
Я не использую "причиндалы SDK". Два года назад написал на базе ESP8266 WiFi-UART (на 2 мегабитах, скорость мне особо не нужна), и использую 8266 как очень дешевый MAC к внешнему микроконтроллеру, где уже поднят свой сетевой стек. Беспроводные библиотеки и инициализация взяты еще от SDK 1.2.x, теперь вот появилось желание все это обновить. Ну попробую для начала 2.0.0, там видно будет что дальше.
 

pvvx

Активный участник сообщества
Я не использую "причиндалы SDK". Два года назад написал на базе ESP8266 WiFi-UART (на 2 мегабитах, скорость мне особо не нужна), и использую 8266 как очень дешевый MAC к внешнему микроконтроллеру, где уже поднят свой сетевой стек. Беспроводные библиотеки и инициализация взяты еще от SDK 1.2.x, теперь вот появилось желание все это обновить. Ну попробую для начала 2.0.0, там видно будет что дальше.
И как-же работал этот MAC, если нет возможности управления дровами WiFi?
Через дополнительные затычки и обходы вызовов никчемных функций SDK, таких как сохранение в flash конфигов и строгие последовательности вызовов процедур переключений реализуемые часто только через перезагрузку всего, а не одного драйвера WiFi?
Т.е. программа занятая исключительно только борьбой с идиотизмом SDK от Espressif?
Нет смысла такие вещи продолжать - есть другие, более современные WiFi-SoC с лучшими вариантами SDK и схожей ценой, где "закрытым" является только исходники самого драйвера WiFi. Туда лезть не и особо кому хочется, т.к. если есть драйвер, то и описание функций к нему приложены...
 
Последнее редактирование:

1801BM1

New member
И как-же работал этот MAC
Да отлично работает, несколько тысяч продано, клиенты особо не жалуются :)
Идея там простая и тупая - lwip выкинут полностью, все принимаемые пакеты из WiFi кидаются в UART по своему протоколу (там фрейминг свой + контролька на CRC), все что принимается из UART (тоже пакеты с фреймингом и контролем) кидается в WiFi. Пакеты формата raw. ARP, IP и прочее - все крутится на внешнем контроллере, там еще куча других сетевых интерфейсов обычно есть. Также по UART ходят еще служебные пакеты, позволяют настроить параметры беспроводного линка и получать нужную информацию о линке и сканирование сетей, для этого используется буквально несколько вызовов SDK. Также реализован Heartbeat, WDT, рестарт работы с модулем, но вроде как беспроводное соединение устойчивое, аптайм десятки часов - обычно едело. Работа с аппаратурой (ну кроме беспроводки) - UART, таймеры, WDT - свое, инициализация, конфигурация и прочая муть - подсмотрены у Вас. В-общем-то, тут ничего нового, ESP8266, в девичестве ESP8089 и был изначально MAC-ом. Это уже потом кетайцы на него софтовых извращений навертели.
 

1801BM1

New member
более современные WiFi-SoC
Да, RTL технически лучше. Но ESP - дешевле. Снабженцы мониторят RTL vs ESP, но пока ESP выигрывает по цене в пару раз. И ESP уже работает, удовлетворительно в моих изделиях, париться с новой разработкой на RTL будет иметь смысл если он станет существенно дешевле чем ESP :)
 
  • Like
Реакции: pvvx
Сверху Снизу