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

А мои сообщения не видно что-ль? :confused:

Шина I2C у меня длиной максимум до 10см. А один из слэйвов вообще - меньше 1см от проца. В то время как провода до ESP - около 10см. Снижение частоты SCLK тоже не помогает.

Сталкивался с подобной проблемой на ESP8266. Есть устройство (на EVB). В нём одна шина I2C и на ней 3 слэйва. При отключенном ESP устройство работает без сбоев часами (запускал на сутки). Написал даже тест, который грузит I2C на 100% непрерывным обменом поочерёдно со всеми слэйвами на макс...

Вы как читаете что я писал?? :confused: С чего это ERROR - асинхронное сообщение? См. выше что я имею в виду под асинхронными сообщениями. ERROR - это синхронное сообщение, так как это всегда - ответ на команду. Затесаться оно не может. Я ничего не предполагаю. Я это видел многократно, когда...

Да любая команда с многострочным ответом, например +CIPSENDBUF - в ответ на неё приходит несколько строк синхронного ответа, но между ними может затесаться любое асинхронное сообщение - например сообщение о разрыве другого сокета.

пример чего?

Блин, опять 25!.... :eek: Перечитайте мои посты выше. Свет клином не сошёлся на этом вашем RTL или ESP.

Но ведь это API недоступно через внешний интерфейс (UART или SPI)? Чтобы пользоваться этим API с внешнего МК. Или доступно?

Ну да, без, как же o_O Чтобы с ШИМ получить что-то более-менее приемлемого качества звучания, а не хрипения, нужно ещё фильтр навесить да пару операционников. А сигнал с 12-битного DAC можно напрямую на УМЗЧ подавать.

Любой блютуз модуль - это тоже МК с готовой прошивкой. Вот мне и нужен такой WiFi-модуль управляемый через внешний интерфейсом. Но с протоколом лучше чем у ESP8266 (не АТ-командным) и с бОльшим функционалом. PS: Вобщем - вопрос закрыт. Как я понял - такого не существует. Придётся пользоваться...

Это не так для ESP8266, да и для других АТ-командных устройств. Ответом на команду может быть как одно так и несколько синхронных сообщений от модуля. Каждое сообщение - это отдельная строка. Вот она - должна быть атомарна. А количество строк ответа на команду - различно в зависимости от команды...

Так бывает когда пишут прошивку безграмотные школьники. Я сам сталкивался с таким багом в Bluetooth-модуле WT12 (от Bluegiga). По идее для AT-командного протокола сообщения ограничены кодами "\r" или "\n". Т.е. - всё, что между первым символом строки и ближайшим "\r" или "\n" следует считать...

Наличие JTAG и GPIO в модулях мне безразлично - как я уже писал - меня интересует только законченный модуль с готовой прошивкой позволяющей доступ к её функционалу через некий протокол. Желательно не AT-командным и с бОльшим функционалом чем у ESP8266. Но получается, что доступные подобные...

Я знаю почему. Не потому что выбирают худшее. Это политика STM32. Если просмотреть реализацию их периферии и сравнить с конкурентами в своём классе (LPC17 и LPC43, Tiva, Infineon и т.п.), то видно что STM32 сделали ставку на низкий порог вхождения для новичков - сделать периферию как можно...

И чем же она подходит? ;) Дохлым АЦП на несколько MS/s? Для творчества гораздо лучше подходит например OM13054 - и характеристиками и ценой. Но все почему-то топят за STM32F4, не знаете почему? :D Во-во... :D Во-во! Прям в точку! :cool: Где-то я уже это слышал.... :D

IAR грузит готовый образ прошивки. Из чего он был собран - из SDK или из просто исходников - по барабану. Берётся код рабочей инициализации PLL+SDRAM+ещё чего надо, перегоняется в формат *.mac, а IAR перед загрузкой образа выполняет этот *.mac, программируя регистры МК и дальше грузит в SDRAM...

Эти EVB для меня бесплатны. Дать хочу, но у меня их не хватит на всех ;)

О, вот это уже полезнее! Вроде там и прошивки есть. Как я пониманию - опять АТ-командный интерфейс? Бинарного протокола и тут нет? :( Ну ладно - буду иметь в виду как альтернативу.

А это Вы кому? Опять меня с кем-то путаете.

Я сравнивал? Где??? :confused: И нет у меня никакого "поделия на ESP8266". Моё поделие - как раз на Cortex, а ESP8266 там - сбоку припёку. Вы что-то совсем запутались в показаниях... o_O