Тогда, я подозреваю, при попытке послать что-нибудь через последовательный интерфейс в направлении ESP с GPIO0 начнут происходить сюрпризы.Есть вот такой вариант
Тогда, я подозреваю, при попытке послать что-нибудь через последовательный интерфейс в направлении ESP с GPIO0 начнут происходить сюрпризы.Есть вот такой вариант
По идее - да, но пока не особо понятна возможная реализация. Дело в том что Sming использует нативный для LWIP подход - асинхронные callback вызовы (но при этом красиво оборачивает их чтобы пользователю не нужно было думать о внутренней части). Ардуино - напротив работает в loop модели с последовательным вводом-выводом.Да, это очень мощный функционал. Насколько я понимаю, всё это можно обернуть в библиотеки. При этом останется базовая совместимость с Arduino и совместимые API для работы с WiFi и TCP/IP, но также появится куча мощных функций. Внутри библиотек при этом можно делать все что угодно — использовать lwip напрямую, не использовать String и т.п.
Если мы сможем адаптировать ваши библиотеки (веб-сервер, http, ftp, spi, sleep modes и т.д.) для компиляции в составе Arduino, мне кажется, будет очень крутое решение.
Ещё не известно, не подхвачена ли в них "зараза" от espconn. Бегло смотрев исходники в данной библиотеке не нашел отличий алгоритмов обращений от espconn - всё те-же самые ошибки: нет проверки закрыто или нет соединение, если, к примеру идет обращение "со стороны" (таймер или ещё чаго) по старому указателю на pcb (которого уже нет или там разместился новый), а не отработка callback вызванной самой LwIP c выданным текущем указателем на pcb.Дело в том что Sming использует нативный для LWIP подход - асинхронные callback вызовы
В чем принципиальная разница с http://www.smartlx.ru/blackswift ?Омега сегодня вышли
Значит вы не поняли. callback вызывает LwIP. О вашей передаче данных в pcb LwIP ничего не знает и никак не может вызывать callback c передачей указателя на нужный вам и ещё активный у него pcb Он пока не умеет гадать,когда вы соизволите начать отправку. Та-же ошибка жила и в espconn. Но в поздних версиях её устранили, путем предварительного поиска в списках LwIP pcb на необходимое соединение (содрав методу из моего патча для неё), путем сравнения номера порта и ip host и remote, которые были заранее запомнены при открытии соединения. И теперь espconn всегда тупит и ищет pcb, перед почти любым действием...pvvx, Sming подразумевает что ведущая роль в работе сервера за ним. Т.е. он сам вызывает callback когда ждет фрагмент данных.
Такая же проблема, после распаковки ArduinoIDE любой скетч (даже пустой) компилится так:В чем может быть дело ?
void setup() {
// put your setup code here, to run once:
}
void loop() {
// put your main code here, to run repeatedly:
}
Думаю да мы не совсем поняли друг друга, а если точнее я неудачно выразился. Разумеется не Sming играет ведующую роль (точнее он играет но только по отношению к конечному разработчику), а по факту изначальная инциацива за LWIP. Поэтому отправка происходит только внутри callback вызовов LWIP, соответственно:Значит вы не поняли. callback вызывает LwIP. О вашей передаче данных в pcb LwIP ничего не знает и никак не может вызывать callback c передачей указателя на нужный вам и ещё активный у него pcb Он пока не умеет гадать,когда вы соизволите начать отправку. Та-же ошибка жила и в espconn. Но в поздних версиях её устранили, путем предварительного поиска в списках LwIP pcb на необходимое соединение (содрав методу из моего патча для неё), путем сравнения номера порта и ip host и remote, которые были заранее запомнены при открытии соединения. И теперь espconn всегда тупит и ищет pcb, перед почти любым действием...
В Sming, я наблюдал только вызов какой-то post-task в процедуре poll на активный pcb, которую вызывает LwIP. Но она вызывается не часто и между этими вызовами LwIP уже может грохнуть ту pcb, если на него придет FIN, ACK. Стеком TCP не вы управляете, а LwIP и он вызывает callback с указателем на активный pcb, если там что происходит... И при множестве активных соединений там тысячи перестановок в этих pcb в секунду
Тогда верно, но до уровня приоритетов прерываний всей цепочки WiFi-SDK-LwIP-UserПоэтому отправка происходит только внутри callback вызовов LWIP
Промежуточные буфера всё равно будут. Копаться в буферах LwIP не гуд. Их сегментированность не дает возможностей применения строковых поисков и т.д.Да в СДК много бед.. Вы кстати libpp разбирали?
Что касается похода основанного на callback, это было изначальной архитектурной задумкой чтобы избежать промежуточных буферов и потери памяти.
В Sming я реализовал специальные функции для строкого поиска/сравнения/копирования в цепочке буферов lwip. Но в других местах все равно конечно кок-какие буферы заводить пришлось, без них не удобно уже конечному пользователю (но они обычно поменьше чем для входных данных).применения строковых поисков и т.д.
Ошибка компиляции.
было аналогично, проблема описанная с библиотекой не решила проблемуТакая же проблема...
igrr, не все могут пересобрать Arduino IDE@lazy-fox
@alexhi
С компиляцией под windows проблема в криво собранном тулчейне — gcc зависит от libiconv, который прилинковался динамически. Нужно пересобрать, чтобы не требовалась дополнительная dll-ка.
Собственно я тоже не могу пересобрать правильно тулчейн, иначе уже давно бы починил И винды у меня вообще нет.igrr, не все могут пересобрать Arduino IDE
https://gist.github.com/fpoussin/7ae55b5a5bd9a28ce21d не?Если кто-нибдуь знает, как его правильно пересобрать под win x32, или где взять работающую сборку — welcome.
Его и использовал, получается зависимость на libiconv-2.dll.