Результаты поиска

Конкретно в этом коде нет реализации чтения touchscreen, но в принципе, там тоже SPI, так что проблем с чтением из touch-контроллера быть не должно.

Создал интегрированный SDK для esp31b/32 под GNU/POSIX на основе такого же для esp8266 с модификациями для поддержки C++/STL. GitHub - Sermus/esp-open-sdk: Free and open (as much as possible) integrated SDK for ESP31b/32 chips

Ага, спасибо, ценное знание. Я создaл pull request в ветку xtensa-1.22.x с -DMALLOC_PROVIDED для newlib. Смысла в функциях управления памятью newlib, вроде, смысла нету, потому что у Espressif свои, а их сосуществование все равно невозможно. Я сделал маленькую либу с реализацией...

Заставил это добро работать, даже в UART выводит содержимое строкового стрима. Для этого пришлось сделать этакий корявый порт libgloss. Как водится, когда радость поулеглась, и настало подумать все ли в порядке, оказалось, что в порядке не все. А не в порядке вот почему. newlib собран так, что...

Написал скрипт, который визуализирует дерево зависимостей по выводу objdump. Видно, что abort дергается из нескольких мест. А вот другой грязи не видно из-за проблем, описанных в предыдущем посте. calls.svg

Чего-то я не понимаю в том, как дергаются функции. Если стабов нет, то оно ругается так: /opt/lx106/bin/../lib/gcc/xtensa-lx106-elf/4.8.5/../../../../xtensa-lx106-elf/lib/libc.a(lib_a-stdio.o): In function `__sread': /home/andrey/crosstool-NG/.build/src/newlib-2.0.0/newlib/libc/stdio/stdio.c:48...

Ну хорошо, что результаты сошлись, а то я уже начинал чувствовать себя некомфортно. А реализация функций менеджмента памяти в newlib для lx106 есть? В смысле она через pvPortAlloc/pvPortFree? Если так, то у Вас есть идеи кто может дергать stuff вроде malloc_extend_top?

Подумал, вдруг esp-open-sdk чего-нибудь оверрайдит в настройках или того паче патчит, поэтому собрал тулчейн из свежесклонированного crosstool-NG. Нет, результат тот же. До тех же функций недотягивается.

@jcmvbkbc А можно Ваши билдлоги для примера, попробую повторить и разобраться в чем же дело.

Нет, не помогли и эти стабы. Подумал еще, вдруг в esp-open-sdk какая грязь после предыдущей сборки осталась. Сделал чистый clone, переключил crosstool-ng на xtensa-1.22.x (по умолчанию он смотрит на lx106). Поправил makefile esp-open-sdk, чтобы он применял патчи к gcc 4.8.5, а не 4.8.2, который...

Да, Вы, конечно, правы, это не libstdc++, но я этот кусок билдлога привел только чтобы показать, что флаги передаются, прошу прощения, если ввел в заблуждение. На всякий случай вот еще Этот уже показывает сборку libstdc++ кросс-компилятором.

Хм, а у меня почему-то нет. Все равно до этого мусора не дотягивается. Я пересобирал в рамках esp-open-sdk, при этом на crosstool-ng, есс-но, ссылался на xtensa-1.22.x. Проверил билд лог для crosstool-ng, действительно libstdc++ собирает с -fno-exceptions -fno-rtti. Но при компиляции Все...

Не очень понятно зачем механизму обработки исключений понадобились функции работы с файлами. В любом случае, эксперимент - критерий истины. Вы можете поставить такой эксперимент? Если он завершится удачно, надо будет думать над технической этикой запрета исключений прямо в stdc++.

Да, собственно, пытался вот такой helloworld собрать: #include <string> #include <sstream> using namespace std; extern "C" void user_init(void) { stringstream ss; string str; str += "test"; ss << str; } extern "C" void user_rf_pre_init(void) { } Собирал с -fno-rtti...

А еще, чтобы заставить его линковаться (даже с символами libc в IRAM), нужно застабить кучу функций типа _write_r, _close_r, _open_r, _isatty, etc. Это я что-то не так делаю или их реально нужно застабить? Может тогда для lx106 их застабить прямо в newlib?

Или хотя бы выложить то, что получается as is.

Проверил, не собирается и в open sdk с фиксами. Так что задал вопрос jcmvbkbc.

Теперь оно не дотягивается до символов libcirom примерно вот так:

И еще хочу напомнить вопрос про libcirom. Добавить его генерацию по затратам - почти ноль, а вот польза весьма пользительна. На всякий случай, получается из libc вот так: xtensa-lx106-elf-objcopy --rename-section .text=.irom0.text --rename-section .literal=.irom0.literal libc.a libcirom.a

Это не собиралось на 2.0.9 потому что не должно было. Фиксы от Макса как раз и нужны для того, чтобы оно начало собираться. Поэтому вопрос не имеет особого смысла. По поводу полного примера - отправил в личку.