SparkFun ESP8266 Thing

[amatron]

https://www.sparkfun.com/products/13231

Features:

• All module pins broken out
• On-board LiPo charger/power supply
• 802.11 b/g/n
• Wi-Fi Direct (P2P), soft-AP
• Integrated TCP/IP protocol stack
• Integrated TR switch, balun, LNA, power amplifier and matching network
• Integrated PLLs, regulators, DCXO and power management units
• Integrated low power 32-bit CPU could be used as application processor
• +19.5dBm output power in 802.11b mode

 

[JustACat]

On-board LiPo charger/power supply

О, а вот это интересно! Глянуть бы схему, чтобы детальки оттуда передрать

All module pins broken out

А это враки, ну, RTC же не вывели Хотя может оно на питание корректно заведено? В общем - схему бы.

Update: о, а схема тама есть - отлично! Ща глянем.

 

[JustACat]

Посмотрел, понравилось!

1) У них и Reset и GPIO0 оба повешены на один DTR - интересное решение
2) RTC пин так и не подключен ни к чему. Мне все таки кажется, что так и задумано, иначе чего все производители его болтающимся оставляют?..
3) Подразумевается использование с FTDI, но на борту его нет! USB - только для питания/зарядки LiPo
В остальном - схематику, имхо, можно как референс для своих поделок использовать. Все вроде бы грамотно на мой неискушенный взгляд: где надо - подтянуто, номиналы все есть.

Чтобы не искать:
1) Схематика
2) Для Eagle
3) Исходники на GitHub
4) Подробная инструкция по ESP (их модулю в частности) правда на английском, с примерами, картинками, описанием пинов и т.п.

 

[amatron]

Eagle есть. Можно заказать платы у китайцев. Вот где бы достать подешевле чипы esp8266ex?

 

[pvvx]

А это враки, ну, RTC же не вывели Хотя может оно на питание корректно заведено? В общем - схему бы.

Без питания RTC теперь, с выходом SDK 1.1.0 ещё интереснее В часах сохраняется и устанавливается режим system_phy_set_rfoption(). Ранее он был назван deep_sleep_set_option() (эти процедуры полностью идентичны, но код system_phy_set_rfoption() немного длиннее и жрет больше стека ). Но при выключении питания или дергания ноги чипселекта у ESP8266 память в часиках становиться заполненной белибердой и при старте модуль WiFi не включается, т.к. там обычно случайное число и из 2 рабочих комбинаций оно имеет возможность в 63354 вариантов чтобы не правильно запустить WiFi Так задумали китайцы-программеры SDK - зарабатывают денежку на переименовании и дублировании процедур и увеличению глюка-кода...
Описание system_phy_set_rfoption() см. в доке "2C-ESP8266__SDK__Programming Guide__EN_v1.1.0.pdf"

 

[Victor]

при старте модуль WiFi не включается

я не совсем понял.
попробовал пример AT в функцию [inline]user_rf_pre_init[/inline] вставить [inline]system_phy_set_rfoption[/inline] с разными параметрами: 0,1,2,4
(в документации сказано, что [inline]system_phy_set_rfoption[/inline] можно вызывать только из [inline]user_rf_pre_init[/inline])

void user_rf_pre_init(void)
{
    system_phy_set_rfoption(2);
}

и все вроде ок, при каждом старте вижу в логах

ready
WIFI CONNECTED
WIFI GOT IP

IP адрес проверял, он в норме и после передергивания питания и после DEEP SLEEP
При параметре 4 wifi отключен. Вроде все как в документации.

 

[pvvx]

я не совсем понял.

После отключения питания или активации CH_PD значения в памяти часиков любые, т.к. VCC_RTC не включено к источнику 1.1В. А контрольная сумма установок для WiFi и других в ней считается путем OR слов - такой китай-метод расчета контрольки только у Espressif, т.к. он не является контролем и имеет бесчисленное множество совпадений со сбитыми данными Т.е. такая контролька лажает в большинстве случаев и можно утвердительно говорить о том, что контроля нет, а данные идут на исполнение...
system_phy_set_rfoption(x) абсолютна равна system_deep_sleep_set_option(x) (Коды функций для сравнения), с одним исключением - system_phy_set_rfoption(x) может нарушить контрольную сумму блока в 0x78 байт, находящемуся в начале памяти часиков и будет вызывать надпись "RTC MEM CHECK FAIL!!!\n" в следующей за user_rf_pre_init() процедуре register_chipv6_phy(). + если контролька нарушена, то опция установленная в system_phy_set_rfoption(x) сбрасывается в "0".
Я уже поставил system_deep_sleep_set_option(0) в тестовую прошивку AT для 512k, но это не совсем корректно - не позволяет сохранять предыдущий режим данной опции при deep-sleep и отключениях питания. Но с опцией "0" можно задать этот режим в esp_init_data_default.bin.

и все вроде ок, при каждом старте вижу в логах

ready
WIFI CONNECTED
WIFI GOT IP

Это ничего ещё не значит. Часто возникает рассогласование частоты и сказывается кривой китай-код части 802.11n, приводящий к ошибкам дальнейшей связи ST (модуль) <-> AP (роутер).

IP адрес проверял, он в норме и после передергивания питания и после DEEP SLEEP
При параметре 4 wifi отключен. Вроде все как в документации.

IP и всё остальное у Espressif сохраняется во flash (-2 и - 3 сектора от конца flash) для протирания дырки в последнем секторе, куда пишется контрольная их сумма. Он практически всегда стирается и переписывается 2 раза при любом действии...
Что вы хотите от шаракиной китай-конторы Espressif ? И исходных кодов для исправления они не дадут, а то весь мир будет смеяться над их программерами
В итоге без представления Sparkfun собственного SDK его плата никому не нужна. Ну если только лохам, обманутым Espressif. Espressif уже год скрывает данные по чипу, а сама не может выпилить SDK, предоставляя только полный глюко-дром использующий пару процентов возможностей чипа, но занимающий всю программную и оперативную память модуля

Ну и о главном - зачем "При параметре 4 wifi отключен" происходит инициализация Lwip и других модулей с захватом всей памяти чипа?

 

[CHERTS]

Если честно, то с user_rf_pre_init(void) я вообще не понял китайский прикол, в SDK 1.1.0 в каждый пример теперь нужно пихать пустышку

void user_rf_pre_init(void)
{
}

иначе при сборке будет выдаваться ошибка, я конечно свиснул идею с пустышкой у esp-open-sdk и сделал так, но блин простите - это изврат.

 

[pvvx]

Если честно, то с user_rf_pre_init(void) я вообще не понял китайский прикол, в SDK 1.1.0 в каждый пример теперь нужно пихать пустышку

void user_rf_pre_init(void)
{
}

иначе при сборке будет выдаваться ошибка, я конечно свиснул идею с пустышкой у esp-open-sdk и сделал так, но блин простите - это изврат.

Это не верно. Правильно вставлять такое,

void ICACHE_FLASH_ATTR user_rf_pre_init(void)
{
    /* volatile */ uint32 * ptr_reg_rtc_ram = (/* volatile */ uint32 *)0x60001000;
    if((ptr_reg_rtc_ram[24] >> 16) > 4) {
        ptr_reg_rtc_ram[24] &= 0xFFFF;
        ptr_reg_rtc_ram[30] = 0;
    }
}

из-за того, что нет своего питания у RTC. Это немного корректирует возникающие китай-баги.
В ptr_reg_rtc_ram[24], в младших 16 битах находится текущий режим старта, а в старших - эта багофича с номером deep_sleep mode. При отключении питания там всё что угодно и если значение не верно, то желательно сбрасывать и китай-контрольную сумму по OR байтов этой области - ptr_reg_rtc_ram[30] = 0; Тогда кривой-китай-SDK гарантированно понимает, что настройки в RTC RAM сбиты...
Всё равно он ставит данную настройку в нуль, далее в инициализации, после user_rf_pre_init(), если OR слов (китай-контролька) сбита...
Метод такой у китайцев - всунуть какую новую никчемную фичу куда не попадя, без связи с другим, и потом писать патчи-затычки по всем процедурам SDK. По этому им уже скоро не хватит и 2-х flash