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

Продолжаем игры. Появились очередные вопросы ) 1. При использовании стандартного вектора таки в некоторых случаях не хватает реализации `_sbrk_r': c:/espressif/xtensa-lx106-elf/bin/../lib/gcc/xtensa-lx106-elf/4.8.2/../../../../xtensa-lx106-elf/lib\libc.a(lib_a-mallocr.o):(.literal+0x24)...

Спасибо, работает! Будем играться дальше )

CHERTS, Скачал новую версию, поставил. Мои примеры скомпилились успешно! Ура! Теперь можно играться дальше ) Так же вижу - появилось много новых примеров, в том числе и отправка данных на thingspeak.com, который я тоже осваиваю ))) Спасибо большое! Ты делаешь хорошую и полезную работу!!!

Выше разбирали его. Компилятор собран без нужного ключа.

CHERTS, А из этого поста пример собирается? У меня именно с ним проблема.

Или не попробую, т.к., как я понял, через флаги компиляции я добавить его не могу?

Сейчас попробую добавить этот ключ.

где-то так: c:\Espressif\xtensa-lx106-elf\bin>"xtensa-lx106-elf-g++.exe" -v Using built-in specs. COLLECT_GCC=xtensa-lx106-elf-g++.exe COLLECT_LTO_WRAPPER=c:/espressif/xtensa-lx106-elf/bin/../libexec/gcc/xtensa-lx106-elf/4.8.2/lto-wrapper.exe Target: xtensa-lx106-elf Configured with...

Последний пример?

Продолжаем исследования. Проблема появляется даже не в стандартной библиотеке, а в случае, если глобальный объект имеет деструктор, объявленный явно. Ес-сно, вектор так же имеет деструкторы, поэтому и не компилится. Осталось понять как деструктор влияет на использование библиотечных функций...

Нашел закономерность. Такое происходит если объект вектора глобальный... Или находится в глобальном объекте. Вот еще одно подтверждение тому, что глобальные объекты - зло ))) Пример в аттаче. Если объект "а" объявить локально в функции user_main - то все собирается отлично...

void *operator new(size_t size) { return os_malloc(size); } void *operator new[](size_t size) { return os_malloc(size); } void operator delete(void * ptr) { os_free(ptr); } void operator delete[](void * ptr) { os_free(ptr); }

jcmvbkbc, есть еще одна непонятка при попытке использовать вектор... Линкер ругается: c:\espressif\xtensa-lx106-elf\xtensa-lx106-elf\include\c++\4.8.2\bits/vector.tcc:344: undefined reference to `__dso_handle' c:/Espressif/ESP8266_SDK/lib\libc.a(mallocr.o):(.literal+0x14): undefined reference...

Я не знаю как у него это внутри устроено, но знаю, что, подавая 0 на эту ногу, проц перестает работать. А после подачи снова 1 - работает как после сброса ). В программаторе я так же пользую эту ногу вместо ресета, и вижу правильный вход в режим программирования, и потом старт новой прошивки.

C++ Компилятор разве поставляется не в бинарном виде? Скрипт можешь выложить, посмотреть могу. Но будет ли это успешно - пока не уверен... Что нужно править: 1. Добавить компилятор G++, можно и C++. Я взял их из версии кита 1.0.4, где они еще были. 2. Положить либы и инклуды, которые лежат тут...

CHERTS, можешь в новой версии кита вернуть С++ компилятор? Правда, надо будет сделать несколько доработок, описанных тут, и подправить скрипт линковщика (eagle.app.v6.ld:), как это предложено тут. В результате тем, кто пользует С++, надо будет делать меньше действий для адаптации новых китов...

Я вместо ресета пользую пин CH_PD. Работает так же.

Попробуй нажимать Ctrl+J вместо Enter. Должно помочь ) Понимаю, что неудобно, но лучшего решения для путти пока не нашел. Сам пользую SecureCrt - он гораздо удобнее и функциональнее )))

Нет, в конструкторе я только инициализирую поля. Этот класс всего лишь для проверки инициализации глобальных объектов. Проверка показала, что таки, их надо инициализировать ручками. Вывод в нем только в методе print. Вот оно что... Об этом я не подумал.

jcmvbkbc, Спасибо за рекомендации! Под винду квест оказался непростой, но сейчас вроде компилирует нормально. В сборке от CHERTS компилятор и основные либы таки уже есть, добавил только libc, libhal, и инклуды для них отсюда: https://github.com/esp8266/esp8266-wiki/raw/master/libs/libc.a...