|ESP32 - WiFi + BLE

windalser

New member
Espressif готов отдать разработчикам на b-тестирование новый чип, который они назвали ESP32 :
http://www.cnx-software.com/tag/iot/
Основные особенности:
1. Более быстрый WiFi - 144 Mbps
2. Bluetooth Low Energy (BLE) на борту (а в позже обещают и Classic Bluetooth)
3. Два процессора Tensilica L108 на борту - 160 MHz
4. Низкое потребление в режиме Deep Sleep
5. Богатая периферия с поддержкой DMA: чувствительный к касанию вход (capacitive touch), нескоько АЦП, ЦАПы, I2C, UART, SPI, SDIO, I2S, RMII, PWM и др. (USB - нет)
6. RAM: SRAM ~400 KB !
7. Поддержка Security на аппаратном уровне (AES и SSL)
8. Упрощенные APIs
Пишут, что будет дороже ESP-8266, но не на много.
 

pvvx

Активный участник сообщества
И сколько лет ждать первого глюко-SDK?
Прошлый ещё Espressif не отладил, а чип продается более года...
С учетом, что 2 ядра и кол-во периферии раз в 5 больше, то по расчету и аналогии от Espressif, ESP8266 имеет память в 96+64=160 килобайт, но оф. SDK оставляет пользователю всего 50 кило. Из это ещё следует, что Espressif будет писать SDK до первого варианта имеющего тысячи ошибок (а не одну сплошную), но как-то работающего, не менее 5 лет, а памяти пользователю (не занимаемой SDK) из 400 кб останется менее чем 50 кило.
Но есть самый главный вопрос - кому нужен глюко-камень без документации и errata?
 
Последнее редактирование:

Tomahawk

New member
Думаю не стоит никому тратить время на это бета-тестирование, глючное будет 100%. Для начала бы предыдущую разработку закончили.
 

Victor

Administrator
Команда форума

pvvx

Активный участник сообщества
Судя по разметке в eagle.pro.v7.ld для ESP32_RTOS_SDK у ESP32 всего 144 килобайта памяти для данных. У ESP8266 аналогичный сегмент памяти 80 килобайт. У обоих дополнительная RAM в 16 килобайт для ROM-BIOS.
У ESP32 IRAM (для загрузки кода) 128 килобайт, а у ESP8266 - 64 килобайта.
 

Roman2344

New member
Кто как думает его можно будет прошить NODEMCU Flasher, а потом заливать свой код ESPLORER, и язык для него будет такой же как на ЛУА для 8266? Просто хотелось бы код с 8266 заливать и на ESP32, только переписать под нужные GPIO и прочее, а так же интересует совместимость библиотек? И ещё пока нигде в продаже не нашёл, хотя обсуждения идут на англоязычных форумах, видно тестовые образцы по рассылали?
Мне нравится
10 секунд назад
 

DarkByte

New member
Обещают
Simplified APIs – Not many details provided here, except WiFi APIs will be simplified, yet keep good flexibility and control.
Никакого особого упрощения я чёт не заметил. Такое же глючное SDK, такой же глючный чип, и ровно как и в прошлый раз, в SDK значительно меньше функционала, чем в анонсе возможностей чипа.

Кто как думает его можно будет прошить NODEMCU Flasher, а потом заливать свой код ESPLORER, и язык для него будет такой же как на ЛУА для 8266? Просто хотелось бы код с 8266 заливать и на ESP32, только переписать под нужные GPIO и прочее, а так же интересует совместимость библиотек? И ещё пока нигде в продаже не нашёл, хотя обсуждения идут на англоязычных форумах, видно тестовые образцы по рассылали?
Прямо так оно работать не будет, SDK поменялось, разработчикам NodeLUA для начала нужно будет допилить свой проект под новую версию модуля, ну а потом всё будет как и до этого, можно будет те же скрипты на LUA запускать. Если кто-нибудь из разработчиков получил тестовый модуль, то наверняка к выходу в продажу интерпретатор будет допилен.
 

pvvx

Активный участник сообщества
Чего ждать от двух процов тусующих с одной последовательной Flash?
Шина Flash 80 MHz 4 бита, максимальный пакет там вроде 32 байта с запросом адреса. Итого выходит кол-во считываний в кеш не более 34 мбайт в секунду. Размер команды у проца 2 или 3 байта.
Итоговая производительность не более 13 миллионов команд НА ОБА ЯДРА. А кеш у проца маленькая и всё не влезает, как китайцы пишут софт :)
Выходит, что у ESP8266 скорость выполнения кода не попадающего в кеш не меньше чем у ESP32 :p
Т.е. хваленые китайские 400MIPS выходят в 13. :D
 
Последнее редактирование:

DarkByte

New member
Чего ждать от двух процов тусующих с одной последовательной Flash?
Самое забавное, что если посмотреть в ESP32_RTOS_SDK, то там пока что никаких намёков на второе ядро нет.
И про блутуз тоже упоминается лишь вскользь. Если бы не bt_* функции в блобах, то наверное можно было бы подумать, что обманули.
Но скорее всего просто не успели :) Или опять показали самое новое только коммерческим партнёрам.
 

pvvx

Активный участник сообщества
Самое забавное, что если посмотреть в ESP32_RTOS_SDK, то там пока что никаких намёков на второе ядро нет.
И про блутуз тоже упоминается лишь вскользь. Если бы не bt_* функции в блобах, то наверное можно было бы подумать, что обманули.
Но скорее всего просто не успели :) Или опять показали самое новое только коммерческим партнёрам.
Да пусть там два ядра. Они будут работать попеременно из-за очереди к flash. Т.е. особого смысла во втором ядре нет, если не писать второму ядру код отдельно в IRAM. А не как в LUA, где на обработку одного байта из flash (все сообщения и прочие константы) уходит несколько сотен тактов, т.к. чтение сделано побайтовое и отрабатывает по вектору прерывания защиты обращения к шине 32 бит как к 8 битному операнду... :)
Короче, если отработают блоки аппартного шифрования и поднатужатся, то вполне смогут впихнуть основной код поддержки WiFi и BT в IRAM и внутреннюю ROM для одного ядра. Но думаю, что китайца не справятся с этим.:(

Насчет комерсов http://makezine.com/2015/12/09/meet-esp32-new-big-brother-to-iot-board-esp8266/ :
"Сообщество построило много инструментов и toolchains для ESP8266. Вы производили консультации с людьми строящих их, прежде чем приступать к разработке нового ESP32?

ESP8266 сообщество посылает много писем к нам. Мы постараемся удовлетворить все требования или требования хорошего дизайна. В некотором смысле, я обнаружил, что сообщество более опытные и эрудированные чем коммерческие клиенты, касающиеся инструментов и toolchains."
:)

А это ещё раз подтверждает, что никакой коммерческой реализации чипов у Espressif нет, кроме как россыпью на рынок "народного творчества". Тем более какая коммерция на глючащем ПО?
 
Последнее редактирование:

nikolz

Well-known member
Да пусть там два ядра. Они будут работать попеременно из-за очереди к flash. Т.е. особого смысла во втором ядре нет, если не писать второму ядру код отдельно в IRAM. А не как в LUA, где на обработку одного байта из flash (все сообщения и прочие константы) уходит несколько сотен тактов, т.к. чтение сделано побайтовое и отрабатывает по вектору прерывания защиты обращения к шине 32 бит как к 8 битному операнду... :)
а память в 400 кбайт разве не позволяет распараллелить вычисления?
 

igrr

Moderator
Команда форума
Описанная ситуация с чтением констант через обработчик исключения для ESP32 уже не должна быть характерна. В нем флэш-память отображается не только в адресное пространство кода (как в ESP8266), но и в адресное пространство данных. Поэтому спокойно хранить строки и прочие 8- и 16-битные константы во флэш-памяти.

Что касается производительности и простаивающих из-за очереди к памяти ядер, в типичных приложениях такая ситуация не наблюдается. Код конечно не влезает в кэш весь, но процент "горячего" кода, живущего в кэше, довольно велик.
Кстати, теперь можно измерить, сколько времени процессор простаивал, а сколько работал — добавилась соответствующая опция в ядре.
 

Roman2344

New member
И сколько флеш у ESP32 по сравнению с ESP8266? Потому как помню что я формировал веб-сервер на 8266 и нужно было там 16 кнопок и памяти 4мб 8266 не хватило, хватило только на 14 кнопок, это было для ЛУА, а в Arduino IDE пока сделал 4 кнопки и надписи и заняло 20% памяти, причем как я понимаю что в html коде основную память занимают формирование кнопок и прочих динамических объектов?
 
Сверху Снизу