ESP8266 виснет

Maddoc

New member
Там 2 пары портов clock и data 2 штангеля работают с разными по длине пакета циклами, по этому код 2 раза написал. Так сколько точно максимум в прерывании сидеть можно?
 

nikolz

Well-known member
Там 2 пары портов clock и data 2 штангеля работают с разными по длине пакета циклами, по этому код 2 раза написал. Так сколько точно максимум в прерывании сидеть можно?
обычно есть регистр состояния внутри, либо сигнал готовности вне датчика.
а то как-то не серьезно получается. что-то выплевывают, а когда неизвестно.
 

Maddoc

New member
Ну да выплевывает, а esp2866 должна ловить и обрабатывать там не более 2600 бод примерно. Через 100 ms пакет 10ms.
 

Maddoc

New member
@nikolz
Это все уже пробовал, работает не стабильно. Если в середину пакета попадет будет ерунду показывать. Ладно сейчас поковыряемся.
 

nikolz

Well-known member
@nikolz
Это все уже пробовал, работает не стабильно. Если в середину пакета попадет будет ерунду показывать. Ладно сейчас поковыряемся.
поделюсь своим алгоритмом решения подобной задачи
1) делаем колбек который работает по фронтам. Но не на основе обнаружения скачков а на основе High Low.
2) при обнаружении Low рассчитываем длительность прошедшего интервала.
По его длительности во-первых обнаруживаем начало данных, а во -вторых обнаруживаем пропуск данных
При обнаружении начала заталкиваем биты в слово
-----------------------
Такой алгоритм не мешает работать wifi.
 

pvvx

Активный участник сообщества
@Maddoc - В прерывании delayMicroseconds(20);
Скорее всего оно всё и портит. Надо глядеть внутреннюю реализацию Arduino. При входе в прерывание, точнее при вызове процедуры прерывания стандартный диспетчер обработки других событий типа софт-таймерных прерываний и тасков не работает и не допускает некоторых повторных вхождений... А на всяких delay ранее стояли вызовы данного диспетчера..
 

pvvx

Активный участник сообщества
При delayMicroseconds(20); + остальной код в прерывании по пину = гарантированные пропуски Beacon (синхронизации WiFi). Стандартная точность метки в beacon для ширпотребовских устройств WiFi = +-1 us. Любой сдвиг приводит к увеличению потребления спящих устройств, т.к. они просыпаются и включают RF приемник перед приемом фрейма beacon, строго по таймеру. Если он задерживается = приемник ждет и жрет. Если в нем ещё будет сбита метка времени (она в us), то возможна потеря следующей синхронизации и уведомлений приемника о находящихся ему сообщениях у AP и т.д.
Несколько AP, работающих в одной зоне, синхронизируют и свои beacon. Смещение создает хаос, плохую связь и севший телефон за ночь. :p
 

Maddoc

New member
Оставил все как есть 20 us! в прерывании только завернул функцию handleClient(); в свободное от прерываний место и вызываю раз в пол секунды, да страница грузится чуть по дольше, на пол секунды, зато потом на полной скорости по websoket.loop() все данные хорошо идут.
Код:
#include <TickerScheduler.h>// Для контроля вызова HTTP.handleClient();
ts.add(1, 500, [&](void *) {
    detachInterrupt(clock_Master);
    HTTP.handleClient();
    attachInterrupt(digitalPinToInterrupt(clock_Master), read_bitM, FALLING);
    }, nullptr, true);
Рекомендация на данный момент следующая: при работе с
"ESP8266WebServer.h" и конкретно функцией "HTTP.handleClient()" ИСКЛЮЧИТЬ ВНЕШНИЕ ПРЕРЫВАНИЯ! не использовать "noInterrupts()" перед ней (ESP8266 виснет).
 

Maddoc

New member
Это конечно все очень не красиво, подумаю над тем как сделать нормально.
 
Сверху Снизу