ESP8285 (ESP8266)

balmerdx — 05.08.2021 Внутри Sipeed M1W есть Wi-Fi модуль на основе ESP8285. Собственно говоря это полностью автономная микросхема, которая делает всё внутри. А общаться надо с ней по UART посредством AT команд.


Так как протокол простой, решил написать сам простенький драйвер для UDP сервера. UDP - потому как данные с меньшим ping по нему передаются и пакеты не фрагментируются.

Пробрался достаточно быстро через тонкости протокола. Стало коннектится к WiFi и даже что-то передавать/принимать. Правда медленно-медленно. Через раз. И фигню часто всякую.

Вот набор граблей, на которые наступил.

Так как микроконтроллёр двухядерный, то какбы хорошо знать, на каком ядре происходит прерывание, а на каком выполняется код нашего драйвера, чтобы синхронизироваться. В конце концов - остановился на том, чтобы драйвер и прерывание выполнялись на одном ядре, с синхронизацией посредством sysctl_disable_irq/sysctl_enable_irq. Заодно пока всё это копал, вспомнил почему примитив spinlock такой дешевый. Потому как spinlock_trylock состоит буквально из одного int res = atomic_swap(&lock->lock, -1); а spinlock_unlock из atomic_set(&lock->lock, 0);

Вторая грабля - решил увеличить частоту uart для общения K210 и ESP8285. После этого стал глючить Jtag. Он и так не особо стабильно работал, хотя провода короткие, по 10 см. Подивился такому поведению. Приходится отлаживаться на скорости 115200. Вобщем нежный Jtag на K210, сломать его можно любым чихом. Причем по кнопке Reset он не перегружается. Надо обязательно обесточить устройство, а потом подключить его обратно.

С обесточиванием устройства вышла очередная грабля. Дело в том, что ESP8285 при отключении устройства от USB всё равно работал!!! Оказывается ему хватало того напряжения, что каким-то образом поступало через JTag программатор, хотя там напряжение было менее 1 Вольта.

Ещё на одном косяке чуть не сдался. Данные время от времени бились. Дело в том, что в устройстве используется 2 UART. Один для gets/printf дебагового интерфейса. Другой для общения с ESP8285. Так вот, если часто проверять while(uart[channel]->LSR & (1u << 5)) на предмет, не пришёл ли новый симвой для gets, то другой UART начинает сбоить и принимать не все символы! Вобщем ограничел количество обращений к этому регистру. Хотя то, что один UART влияет на другой - это не радует. Возможно вообще к регистрам периферии нельзя слишком часто обращаться.

Третий косяк - отвратительная чувствительность ESP8285. Как оказалось отправляет сигнал она более-менее нормально, а вот принимает сигнал с трудом. Поэтому оочень долго не мог понять, почему с железки на компьютер UDP пакет приходит стабильно, а вот с компьютера на железку UDP пакет приходит очень иногда. Потом глянул на ping, который был 300-500 ms и понял, что "Что-то тут не то!". Поставил WiFi точку доступа на тот-же стол, и после этого ping уменьшился до 5-10 ms. И UDP пакеты перестали теряться. Впрочем всё равно запрос-ответ занимает цельных 100 ms. На этом фоне NRF24L01 выглядит прям монстром. Она за одну милисекунду успевает не только принять/отослать данные, но и проснуться/заснуть. Да и расстояние, на котором работает NRF24L01 вразы больше, чем у ESP8285.

В заключение - картинка. Так сказать, как можно писать на Си. Лично я не знал такой конструкции.

Оставить комментарий

Популярные посты:

• Архив