Существует ли с++ среда для esp8266?

[Alex_S]

Собственно, сам компилятор для него есть в SDK. Но либы, похоже, есть только для С.
Кто-то заморачивался с написанием кода на С++?

 

[CHERTS]

Кто-то заморачивался с написанием кода на С++?

А зачем? У ESP итак с памятью беда (RAM), её мало, а если писать на C++ то расход памяти увеличиться => сами угадайте что будет.

 

[CHERTS]

Собственно, сам компилятор для него есть в SDK. Но либы, похоже, есть только для С.

И компилятора C++ нет, он был у меня в X64 сборки DevKit v1.0.4, но сейчас я x64 не буду собирать и как следствие с++ компилятора не будет. Да и не нужен он, см. выше почему.

 

[Alex_S]

Насчет расхода памяти - не такая и большая разница что по флешу, что по оперативке. Зато писать на плюсах гораздо проще и приятнее.

 

[CHERTS]

Насчет расхода памяти - не такая и большая разница что по флешу, что по оперативке. Зато писать на плюсах гораздо проще и приятнее.

Возможно, но китайские разработчики иного мнения, как следствие сидим на том что есть.

 

[jcmvbkbc]

Собственно, сам компилятор для него есть в SDK. Но либы, похоже, есть только для С.
Кто-то заморачивался с написанием кода на С++?

Я заморачивался. igrr заморачивался.
Тут есть следующие моменты:
- исключения: поддержки в g++ сейчас нет, а когда появится вы сами не захотите ими пользоваться Потому что даже hello world с единственным исключением в память не лезет;
- хедеры SDK: прототипов функций мало и они не всегда соответствуют действительности;
- нужно править скрипт линковщика и руками вызывать глобальные конструкторы/деструкторы; см. http://www.esp8266.com/viewtopic.php?f=9&t=478
- нужно определить операторы new/delete для работы с API espressif, см. http://www.esp8266.com/viewtopic.php?f=9&t=1136

Про либы не понял: если собирать тулчейн crosstool-NG вы получите всю стандартную библиотеку с++.

 

[Alex_S]

- исключения в ембеддед редко встречаются.
- либы - я имел в виду SDK.
- определить new/delete - нужно во многих ембеддед средах.
Пасиба за линки - почитаю и попробую!

П.с. Оказывается, и на русскоязычном форуме и на иностранном живут одни и те же лица )))

 

[Alex_S]

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

Ну и ес-сно, в своем проекте определил новые new, delete, и прочие необходимые методы, добавил инициализацию глобальных объектов, адаптировал makefile.
Все вводные взяты в указанных темах.
Спасибо!

Результирующий hello_world_cpp - в аттаче.
Непоняток пока две:
1. Почему-то вывод в последовательный порт в функции user_init происходит на неправильной скорости. Возможно, уарт не успевает перестроить скорость. Но через секунду по таймеру все выводится правильно.
2. Не хватает хедеров для библиотечных функций, таких как os_timer_disarm, os_timer_setfn, ets_timer_arm_new, и т.д. Так же непонятно откуда компилятор берет их определения в исходном примере hello_world. Ведь пример компилируется успешно...

 

[jcmvbkbc]

1. Почему-то вывод в последовательный порт в функции user_init происходит на неправильной скорости. Возможно, уарт не успевает перестроить скорость. Но через секунду по таймеру все выводится правильно.

Я вижу, что вы в конструкторе A::A() статического объекта a выводите в UART, до вызова uart_init.

2. Не хватает хедеров для библиотечных функций, таких как os_timer_disarm, os_timer_setfn, ets_timer_arm_new, и т.д. Так же непонятно откуда компилятор берет их определения в исходном примере hello_world. Ведь пример компилируется успешно...

А вы включите -W -Wall и увидите, что ниоткуда он их не берёт и ругается тихонько. Для С++ прототипы придётся писать, да. В крайнем случае можно седом сделать затычки вида void f(...) из файла eagle.rom.addr.v6.ld

 

[Alex_S]

Я вижу, что вы в конструкторе A::A() статического объекта a выводите в UART, до вызова uart_init.

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

А вы включите -W -Wall и увидите, что ниоткуда он их не берёт и ругается тихонько. Для С++ прототипы придётся писать, да. В крайнем случае можно седом сделать затычки вида void f(...) из файла eagle.rom.addr.v6.ld

Вот оно что... Об этом я не подумал.

 

[jcmvbkbc]

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

М... Точняк
В любом случае, это не может быть "уарт не успевает перестроить скорость", скорость перестраивается синхронно при записи в регистр делителя.

 

[Alex_S]

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 to `_sbrk_r'
c:/Espressif/ESP8266_SDK/lib\libc.a(mallocr.o): In function `_malloc_r':
\build\tree\RC-2010.1_kuma\p4root\Xtensa\Target-libs\newlib\newlib\libc\stdlib/mallocr.c:2152: undefined reference to `_sbrk_r'
\build\tree\RC-2010.1_kuma\p4root\Xtensa\Target-libs\newlib\newlib\libc\stdlib/mallocr.c:2189: undefined reference to `_sbrk_r'
c:/Espressif/ESP8266_SDK/lib\libc.a(freer.o): In function `_malloc_trim_r':
\build\tree\RC-2010.1_kuma\p4root\Xtensa\Target-libs\newlib\newlib\libc\stdlib/mallocr.c:3309: undefined reference to `_sbrk_r'
\build\tree\RC-2010.1_kuma\p4root\Xtensa\Target-libs\newlib\newlib\libc\stdlib/mallocr.c:3351: undefined reference to `_sbrk_r'
c:/Espressif/ESP8266_SDK/lib\libc.a(freer.o):\build\tree\RC-2010.1_kuma\p4root\Xtensa\Target-libs\newlib\newlib\libc\stdlib/mallocr.c:3327: more undefined references to `_sbrk_r' follow
c:/espressif/xtensa-lx106-elf/bin/../lib/gcc/xtensa-lx106-elf/4.8.2/../../../../xtensa-lx106-elf/bin/ld.exe: build/httpd.out: hidden symbol `__dso_handle' isn't defined
c:/espressif/xtensa-lx106-elf/bin/../lib/gcc/xtensa-lx106-elf/4.8.2/../../../../xtensa-lx106-elf/bin/ld.exe: final link failed: Bad value

.
По идее вектор для выделения памяти должен использовать new. New и delete у меня определены в одном из cpp файлов. По идее линковщик должен найти их и использовать, но зачем-то он лезет через _maloc_r.
Попробовал переопределить и его - но не помогает.

И непонятно откуда вылезло __dso_handle...
Что я мог сделать не так?

 

[jcmvbkbc]

New и delete у меня определены в одном из cpp файлов.

И они определены как?

И непонятно откуда вылезло __dso_handle...

DSO == Dynamic Shared Object. Похоже, что кто-то неправильно собрал компилятор.

 

[Alex_S]

И они определены как?

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]

У меня с такими определениями простой пример использующий std::vector собирается. Покажите ваш код, что ли.
Прямые обращения к malloc есть, например, в коде поддержки исключений. Возможно нужно указать -fno-exceptions при сборке libstdc++, пока не понял.

 

[Alex_S]

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

Пример в аттаче.
Если объект "а" объявить локально в функции user_main - то все собирается отлично...

 

[Alex_S]

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

 

[jcmvbkbc]

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

Пример в аттаче.
Если объект "а" объявить локально в функции user_main - то все собирается отлично...

У меня под линуксом ваш пример и так отлично собирается.

 

[Alex_S]

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

 

[jcmvbkbc]

Продолжаем исследования. ... Осталось понять как деструктор влияет на использование библиотечных функций _malloc_r, _malloc_trim_r, _sbrk_r и __dso_handle

Пока у вас вылезает __dso_handle большого смысла разбираться со всем остальным нет. Что вам выводит xtensa-lx106-elf-g++ -v ?