• Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram

FreeRTOS SDK

anakod

Moderator
Команда форума
Сегодня я хотел поэкспериментировать с FreeRTOS SDK, т.к. это направление мне кажется более правильным и перспективным чем дефолтные прошивки, но по факту столкнулся с рядом проблем:

1. На последнем UDK не компилируется пример esp_iot_rtos_sdk
Но если поменять путь в "XTENSA_TOOLS_ROOT" на старую версию, то все собирается. С чем это может быть связанно, разве там были какие-либо принципиальные изменения?
2. Думаю было бы хорошо обновить пример, взяв с ГИТа последнюю версию с поддержкой драйвера UART (и прописать его в мейкфайл, а то у меня получилось его завести только с дикими костылями)
3. Уже немного не к теме UDK, после запуска примера он ведет себя нормально только до времени соединения (как клиент так и сервер), а потом:
S > Client from 192.168.145.153 7457
C > connect fail!
S > read data success 128!
S > GET / HTTP/1.1
Host: 192.168.145.253
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,ima
S > read data success 128!
S > ge/webp,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.94 Sa
S > read data success 128!
S > fari/537.36 OPR/27.0.1689.66
DNT: 1
Accept-Encoding: gzip, deflate, lzma, sdch
Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.6,en
Fatal exception (9):
epc1=0x401011cc
epc2=0x00000000
epc3=0x401015ee
epcvaddr=0x2e303d71
depc=0x00000000
Падает всегда на разных местах, иногда похоже что уже по окончанию запроса. Есть ли варианты с чем это может быть связанно? В итоге FreeRTOS пока остается недосягаемым, к очень большому сожалению :(
 

pvvx

Активный участник сообщества
Сегодня я хотел поэкспериментировать с FreeRTOS SDK, т.к. это направление мне кажется более правильным и перспективным чем дефолтные прошивки, но по факту столкнулся с рядом проблем:
1. На последнем UDK не компилируется пример esp_iot_rtos_sdk
Но если поменять путь в "XTENSA_TOOLS_ROOT" на старую версию, то все собирается. С чем это может быть связанно, разве там были какие-либо принципиальные изменения?
Были изменены сборщики бинарников для прошивки и как раз эта часть не работает в makefile к esp_iot_rtos_sdk. Коды проекта компилируются до выходного elf.
3. Уже немного не к теме UDK, после запуска примера он ведет себя нормально только до времени соединения (как клиент так и сервер), а потом:
Fatal exception (9):
epc1=0x401011cc
epc3=0x401015ee
Падает всегда на разных местах, иногда похоже что уже по окончанию запроса. Есть ли варианты с чем это может быть связанно? В итоге FreeRTOS пока остается недосягаемым, к очень большому сожалению :(
Запустите в папке проекта:
C:\Espressif\xtensa-lx106-elf\bin\xtensa-lx106-elf-objdump -S .\app\.output\eagle\debug\image\eagle.app.v6.out > eagle.app.v6.asm
Получите листинг. В нем узнаете название процедуры, где происходит Fatal exception (9).
По коду esp_iot_rtos_sdk, который в UDK 0x401011cc - это что-то vPortInitialiseBlocks , а 0x401015ee - netbuf_new. Очень похоже на момент распределения памяти. Но, по моему мнению, у rtos_sdk болезнь с переключением процессов и неадекватным поведением всех функций в SDK, которые не адаптированы для многозадачности (не позволяют повторного вхождения) и беды с кешированием процедур в flash. Младенец рожден мертвым. :) Реанимируется путем полного переписывания с нуля всего.
 
Последнее редактирование:

anakod

Moderator
Команда форума
Думаете все так плохо? Неужели нет никого кому удавалось бы завести это SDK и заставить его работать, хотя бы со стабильностью уровня стандартных прошивок? Я уж не говорю о каком-нибудь высоком аптайме.
 

evh

New member
Очень жаль, что в новой сборке выпилили в примерах Makefile.linux :(
 

anakod

Moderator
Команда форума
Очень жаль, что в новой сборке выпилили в примерах Makefile.linux :(
А так ли они нужны? Там ведь вроде почти все тоже самое, надо просто пути поменять, разве нет?

Еще понял с чем связана проблема сборки примера esp_iot_rtos_sdk, в новой версии нужны дополнительные параметры в make файле, просто в обычных примерах их добавили а в файл RTOS нет.
 

evh

New member
А так ли они нужны? Там ведь вроде почти все тоже самое, надо просто пути поменять, разве нет?
просто переменные задать. но все же тогда для кроссплатформенности не помешала бы переменные в Mikefile для запуска программ с префиксом gen_.
 

pvvx

Активный участник сообщества
А так ли они нужны? Там ведь вроде почти все тоже самое, надо просто пути поменять, разве нет?

Еще понял с чем связана проблема сборки примера esp_iot_rtos_sdk, в новой версии нужны дополнительные параметры в make файле, просто в обычных примерах их добавили а в файл RTOS нет.
Нет единой системы создания бинарных файлов. Используемые программы на esptool.exe или esptool.py имеют ошибку (описана выше).
rtos работать не может, т.к. это многозадачная среда, а процедуры от Espressif к этому не адаптированы.
 

anakod

Moderator
Команда форума
В ветке про RTOS пишут что она не только может, но и весьма стабильно работает по результатам тестов. Так что я все же склоняюсь что это какие-то проблемы на этапе компиляции или сборки. Но к сожалению, пока даже не представляю с какой стороны можно подойти к решению этой проблемы. Неужели единственный вариант установить линукс и под него весь пакет компиляторов? :(
 

CHERTS

Moderator
Команда форума
По поводу RTOS - и то что в примерах есть esp_iot_rtos_sdk - это старые "обгрызки" от первого варианта RTOS от Espressif, я с ними поигрался, ничего путного не вышло, все криво и косо сделано, поэтому я на них махнул рукой, но почему-то не удалил из DevKit, а надо бы, но если у кого то есть желание довести их до более менее рабочего состояния, то присылайте, я обновлю их в DevKit, а так в 1.0.10 я их удалю.

По поводу Makefile.linux, т.к. DevKit для Windows, то и Makefile'ам для Linux тут не место, как было замечено, переделать Makefile с Windows на Linux достаточно просто - нужно только заменить пути XTENSA_TOOLS_ROOT, SDK_BASE, SDK_TOOLS, ESPTOOL и номер порта ESPPORT
 

amatron

New member
у меня простая задача на RTOS проработала в неотапливаемом помещении на протяжении 3-зимних месяцев
 

d946

New member
3. Уже немного не к теме UDK, после запуска примера он ведет себя нормально только до времени соединения (как клиент так и сервер)
Для корректной работы надо заменить
char *recv_buf = (char *)zalloc(128);
на
char *recv_buf = (char *)zalloc(129);
 

d946

New member
в коде
Код:
        char *recv_buf = (char *)zalloc(129);
        while ((recbytes = read(sta_socket , recv_buf, 128)) > 0) {
            recv_buf[recbytes] = 0;
            printf("C > read data success %d!\nC > %s\n", recbytes, recv_buf);
        }
в позицию 129 ставиться символ \0 для работы с буфером как со строкой, а буфер выделен только для 128 символов, и в результате обращения за диапазон переменной и вызывается Exception
 

d946

New member
Где же Вы были раньше?
Сам неделю назад нашел, когда пытался перенести свой проект с обычного SDK на FreeRtos SDK. Мне больше нравится терминология задач FreeRtos, чем запуск процедур через таймер, который не гарантирует реал тайм.
 

pvvx

Активный участник сообщества
Сам неделю назад нашел, когда пытался перенести свой проект с обычного SDK на FreeRtos SDK. Мне больше нравится терминология задач FreeRtos, чем запуск процедур через таймер, который не гарантирует реал тайм.
А короткий стек в RTOS, разбитый на кол-во процессов и изначальное "мало памяти" вас устраивает?
 
Последнее редактирование:

Meinframe

New member
В FreeRTOS старт задачи
Код:
//Start os task
    system_os_task(user_procTask, user_procTaskPrio,user_procTaskQueue, user_procTaskQueueLen);
А как остановить задачу? и можно ли делать это по команде с UART ?
и кто может пояснить что делают функции и как и где их следует использовать, а то описание на английском нашёл, но по русски было бы неплохо
Код:
void system_os_task(os_task_t task, uint8 prio, os_event_t *queue, uint8 qlen);
void system_os_post(uint8 prio, os_signal_t sig, os_param_t par);
 
Последнее редактирование:
Сверху Снизу