• Уважаемые посетители сайта esp8266.ru!
    Мы отказались от размещения рекламы на страницах форума для большего комфорта пользователей.
    Вы можете оказать посильную поддержку администрации форума. Данные средства пойдут на оплату услуг облачных провайдеров для сайта esp8266.ru
  • Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram

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
Это конечно все очень не красиво, подумаю над тем как сделать нормально.
 
Сверху Снизу