Comments 17
Крутая работа. Будет здорово, когда распотрошите и выложите готовую схему для подключения исполнительных устройств или датчиков, чтобы можно было обходиться без ардуины.
Собственно, SDK уже сейчас позволяет писать прошивки с подключением любых устройств — библиотеки для работы с GPIO есть. Только в отличие от Arduino все пишется на С.
Из готовых проектов можно посмотреть nodeMCU или homes-smart.ru (с их автороми я никак не связан).
По поводу замены ардуины полностью согласен — функционал гораздо шире.
Из готовых проектов можно посмотреть nodeMCU или homes-smart.ru (с их автороми я никак не связан).
По поводу замены ардуины полностью согласен — функционал гораздо шире.
Только в отличие от Arduino все пишется на С.
Уже допилили arduino ide для поддержки eps8266 )
esp8266.ru/arduino-ide-esp8266/
Учитывая качество библиотек в SDK, я бы воздержался от дополнительной прослойки в виде arduino-совместимых библиотек качество которых, тоже часто вызывает вопросы. И так отлаживать креши, которые растут из блобов Espressif'а — то еще удовольствие. В последних SDK стало немного лучше, но все равно далеко не сахар.
Использую вышепредложенное nodeMCU. LUA мне кажется даже более приятным языком, чем предлагает Arduino. И подключать устройства можно уже сейчас.
Ещё есть frankenstein. Находится в стадии допиливания, предоставляет интерфейс командной строки по типу стандартной AT прошивки, но с чуть более широкими возможностями. К консоли так же можно цепляться по сети, обновления прошивки можно заливать по воздуху, есть поддержка нескольких популярных i2c датчиков.
TurboXIM – симулятор SoC. Теоретически, эта утилита могла бы быть полезной, но даже бесплатная версия требует лицензионных ключей, выдаваемых по запросу.
Xtensa core ISA поддерживается QEMU. Кое-какая моделька для esp8266 лежит здесь. А здесь соответствующий тред на esp8266.com.
Кроме того, здесь тред про адаптированный для gdb официальный JTAG-монитор xtensa, а здесь тред про адаптированный для 8266 OpenOCD.
Очень интересно услышать продолжение. Китайцы особо не торопятся выкладывать исходники SDK, а не смотря на версию 1.0.0, «Fatal exception» до сих пор случаются, и порой в самых неподходящих местах.
Создатель frankenstein'a в треде, сейчас будем критиковать ;)
Начнем с карты памяти, ибо указанная автором разбивка частично «предложенная Espressif организация памяти», которую я не могу считать удачной.
1. 40000000h — 4000FFFFh — Это масочное ПЗУ, заложенное при производстве чипа. Сюда нам ничего нельзя загрузить. В принципе. Оттуда можно только дернуть некоторые функции, адреса которых захардкожены в ld файлике из SDK. Скорость работы кода оттуда должна быть сравнима с работой из RAM.
2. 0x3FFE8000 — 0x3fffc000 — RAM. Для данных. Я не проверял может ли процессор делать оттуда фетч инструкций. Здесь у нас статические переменные (bss), .data и ВНЕЗАПНО .rodata. По каким-то причинам все начинает рандомно разваливаться (по крайней мере так было на 0.9.2 SDK), если попытаться переложить rodata в irom0_0, что на первый взгляд кажется логичным решением.
3. 0x40100000 — 0x40107FFF (насколько помню — именно 32k!) IRAM. Оперативная память с фетчем инструкций. Сюда кладется .text и .text.literal.Отсюда должна быть максимальная скорость исполнения кода. Cюда кладутся важные куски из блобов Espressif'а.
4. 0x40200000 — С этого адреса начинается линейный мэппинг всей SPI флешки. (aka irom0) Отсюда можно исполнять код, есть кеш инструкций неизвестного размера. Все, что не влезает в IRAM кладется сюда. Скорость исполнения отсюда в worst-case случае ниже чем из IRAM
То, как это все будет разложено задается ld файлом, и то что навязывает Espressif — не закон.
Благодаря такой «чудной» организации Espressif контузили lwip добавив к каждой функции ICACHE_FLASH_ATTR, который по сути кладет ф-цию в секцию .irom0.text и .irom0.literal.
Так как контузить свой код ICACHE_FLASH_ATTR'ами не хочется — я сделал вот такой вот хак.
Фактически, чтобы не добавлять ICACHE_FLASH_ATTR'ы мы
переименоввываем в собранных .o секции .text -> .irom0.text и .literal -> .irom0.literal.
Шаманство по ссылке сложнее, так как учитывает случай с -ffunction-sections и -gc-sections, когда у нас каждая функция в своей секции.
Соответственно, если хотим использовать newlib полноценно, то его тоже надо релоцировать в irom0, iram не резиновый. esp-open-sdk специально готовит нам irom версию libc. Линковаться надо только с -lcirom вместо -lc.
А вообще ждем полноценного реверс-инженеринга Espressif'овских блобов. В комментариях к их SDK они писали, что не открывают код, т.к. бояться что «people will make device that bring havoc to wireless networks» ©. А это значит, что там есть много любопытных сокрытых возможностей.
Начнем с карты памяти, ибо указанная автором разбивка частично «предложенная Espressif организация памяти», которую я не могу считать удачной.
1. 40000000h — 4000FFFFh — Это масочное ПЗУ, заложенное при производстве чипа. Сюда нам ничего нельзя загрузить. В принципе. Оттуда можно только дернуть некоторые функции, адреса которых захардкожены в ld файлике из SDK. Скорость работы кода оттуда должна быть сравнима с работой из RAM.
2. 0x3FFE8000 — 0x3fffc000 — RAM. Для данных. Я не проверял может ли процессор делать оттуда фетч инструкций. Здесь у нас статические переменные (bss), .data и ВНЕЗАПНО .rodata. По каким-то причинам все начинает рандомно разваливаться (по крайней мере так было на 0.9.2 SDK), если попытаться переложить rodata в irom0_0, что на первый взгляд кажется логичным решением.
3. 0x40100000 — 0x40107FFF (насколько помню — именно 32k!) IRAM. Оперативная память с фетчем инструкций. Сюда кладется .text и .text.literal.Отсюда должна быть максимальная скорость исполнения кода. Cюда кладутся важные куски из блобов Espressif'а.
4. 0x40200000 — С этого адреса начинается линейный мэппинг всей SPI флешки. (aka irom0) Отсюда можно исполнять код, есть кеш инструкций неизвестного размера. Все, что не влезает в IRAM кладется сюда. Скорость исполнения отсюда в worst-case случае ниже чем из IRAM
То, как это все будет разложено задается ld файлом, и то что навязывает Espressif — не закон.
Благодаря такой «чудной» организации Espressif контузили lwip добавив к каждой функции ICACHE_FLASH_ATTR, который по сути кладет ф-цию в секцию .irom0.text и .irom0.literal.
Так как контузить свой код ICACHE_FLASH_ATTR'ами не хочется — я сделал вот такой вот хак.
Фактически, чтобы не добавлять ICACHE_FLASH_ATTR'ы мы
переименоввываем в собранных .o секции .text -> .irom0.text и .literal -> .irom0.literal.
Шаманство по ссылке сложнее, так как учитывает случай с -ffunction-sections и -gc-sections, когда у нас каждая функция в своей секции.
Соответственно, если хотим использовать newlib полноценно, то его тоже надо релоцировать в irom0, iram не резиновый. esp-open-sdk специально готовит нам irom версию libc. Линковаться надо только с -lcirom вместо -lc.
А вообще ждем полноценного реверс-инженеринга Espressif'овских блобов. В комментариях к их SDK они писали, что не открывают код, т.к. бояться что «people will make device that bring havoc to wireless networks» ©. А это значит, что там есть много любопытных сокрытых возможностей.
0x40100000 — 0x40107FFF (насколько помню — именно 32k!) IRAM
64К, проверено через JTAG.
есть кеш инструкций неизвестного размера
32Кбайта, размер вычислен опытным путём.
Скорость исполнения отсюда в worst-case случае ниже чем из IRAM
Точнее, незакешированные инструкции выполняются в 13-14 раз медленнее, закешированные — так же как из IRAM. Проверено опытным путём.
Спасибо за дополнение, очень интересно!
> А это значит, что там есть много любопытных сокрытых возможностей.
Там даже крипта зашита и какие-то куски для SSL.
Там даже крипта зашита и какие-то куски для SSL.
Ну и, если кому надо, вот принципиальная схема и разводка моих ЛУТ-совместимых самодельных отладочных плат для игр с esp8266:
Фотография самоделок
А можно первую фотку с другой стороны? ))
Подскажите, а есть устройства с GPIO на подобии ESP8266, но исспользуещие BLE вместо WiFi?
Sign up to leave a comment.
Reverse Engineering ESP8266 — часть 1