Arduino.ru

При записи - прочитать записанное. Запись с верификацией. 

а если во время записи девайс перезагрузится?

+ CRC

мне надо, чтобы в EEPROM однозначно были сохранены правильные данные, чтобы их оттуда взять, с надёжностью 100500 )))

Отслеживай, значить, синусоиду перед мостом, и при её прекращении, срочно пиши всё в епром, пока конденсатор держит напряжение выше BOD. Несколько десятков миллисекунд у тебя есть.  Если времени надо больше - ставь литиевую подпорку на время записи, если так критичны данные.  Тут надо выбирать, что важнее. 

Да мне кажется можно следить за напряжением и после моста, перед стабилизатором.

Конечно зависит от емкости кондера и потребления устройства.

Но главное BOD, чтобы правильно был настроен. Пока напряжение выше BOD, EEPROM должен писаться корректно.

Данные дублируются - пишутся в два слота по очереди. После проверки ставится флаг, указывающий на последнее корректное значение.

+ чек-сумма. Иначе как понять где правильные данные, если они будут отличаться?

Попробуй прочитать оба предложения.

Писать с CRC, читать сравнивая. 

Флаг флагом, а если не успел прочесть? Хотя это всего лишь мысли вслух.

Если питание пропадает при записи никакая сумма или дублирование не поможет. Эти методы пригодны когда память глючная, а если она глючная, то ее нужно менять :)

Использую на ESP8266 ватчдог по этому примеру, конфликт с записью в EEPROM, девайс проработал три месяца и вчера впервые его словил, что-то не придумаю как обойти перезагрузку пока идёт запись в EEPROM...

unsigned long lwdTime = 0;
unsigned long lwdTimeout = LWD_TIMEOUT;

void ICACHE_RAM_ATTR lwdtcb(void) 
{
  if ((millis() - lwdTime > LWD_TIMEOUT) || (lwdTimeout - lwdTime != LWD_TIMEOUT))
  {
    ESP.restart();  
  }
}

void lwdtFeed(void) {
  lwdTime = millis();
  lwdTimeout = lwdTime + LWD_TIMEOUT;
}

void loop() {
  lwdtFeed();

  ...
// Запись в EEPROM 
// пишем структуру

  eep.flag = 1;  
  eep.number = hash_isok;
  EEPROM.put(0,eep);
  EEPROM.commit();

// если цикл длится более 60 секунд (к примеру), вызывается процедура перезагрузки

}

А где в приведённом коде запись EEprom ? Где схема подключения? Новичков ругаете, а сами нарушаете по полной. :(

чуток поправил, в рамках минимальной достаточности, зависание в цикле из-за того, что время получения данных (с удалённого сервера по TCP) может быть более установленного в программе, по разным причинам от меня не зависящим, лечу перезагрузкой девайса )))

Сколько раз Евгений Петрович говорил - весь код нужен! Может зависание не из-за того куска, что ты приложил.

мне не надо искать зависание в коде, надо придумать алгоритм такой записи в EEPROM, чтобы не терялись данные...

1. писать два блока - думаю правильное решение, может быть два блока в два циклических буфера с проверкой CRC, для равномерности износа EEPROM...
2. Думаю, как обойти перезагрузку по таймеру если идёт запись в EEPROM, флаг?
3. Есть уверенность, что аналогичную проблему уже решали

Не искать решение проблемы, а искать новые костыли?)) Или что?

там нет костылей, проблема на удалённом сервере, не решаемая, так что это просто "фича" )))

А в чем проблема то с удалённым сервером, опиши словами (я не до конца понял её суть).

У любого сервера отдающего «что-либо» есть время тайм-аута. Если превышено это время - ничего не делаем. Почему у тебя там что-то виснет непонятно. А ребут - это костыли.

По крайней мере сейчас это так выглядит (для меня лично). Не претендую на истину в первой инстанции )))

А что мешает использовать семафор ? Поднимай флаг в перед началом записи, опускай по окончании. Контролируй перед перезагрузкой, если поднят не перегружайся. Более того, судя по всему у тебя запись в епром (которого у есп нет :))) и перезагрузка происходит в разных потоках. Поэтому, конечно я и предложил семафор от RTOS, ну или накрайняк флаг должен быть volatile.

Так а что так долго обрабатывается, что срабатывает собака? 

Может можно разбить на части обработку и отдать управление ядру между ними?

можно прикрутить 24С04 к примеру, на стадии экспериментов не хотелось раздувать ограничившись одной платой nodemcu...
О потоках не в курсе, где почитать? RTOS?

Почитал статейку по ссылке, ИМХО - третий watchdog - это уже перебор.

ESP и так очень стабильно работают, да и на крайний случай watchdog и так есть.

Не было у меня проблем с ESP совсем. 

ESP8266 в работе с 2015-го, с 2016-го все перевел под Ардуино ИДЕ, до этого LUA.

Сейчас работает уже боле 20 штук (подключены по MQTT к домашнему брокеру на москито).

При старте инкрементируют счетчик стартов, сохраняют в "EEPROM", передают его по MQTT.

Аналогично со счетчиками подключений по WiFi, MQTT.

Счетчики все время по нулям, инкрементируются только после пропаданий питания 220В.

Нет никаких проблем, причем совсем.

это не в esp, на сервере, может и миллион запросов в секунду, там править не вариант...