-
- По рекомендации Атмела : 1)не пользовать 0-ю ячейку EEPROM 2) после каждой операции чтения/записи обнулять регисрты EEARH, EEARL. если не соблюдать эти условия то велика вероятность порчи ячеек EEPROM адрес которых записан в EEARH:EEARL. - m16_home(11.01.2019 18:00)
- EARTH EARL? Типа "граф Земли"? Галактическая империя, йопта. - SciFi(11.01.2019 20:11)
- Ну вот я типа и намекаю топикстартеру, что если нет возможности прошить фьюз, то по крайней мере можно софтверными исправлениями снизить вероятность ошибки. Ну и постепенно перешить фьюзы. - LightElf(11.01.2019 18:27)
- память бьется одиночными байтами, в большинстве того что я видел. Троешник(310 знак., 11.01.2019 19:20)
- А что мешает программно сделать необходимую задержку перед чтением ЕЕПРОМ, если фусы недоступны? И перед выключением тоже запретить обращение к ЕЕПРОМ :-). - maleon(12.01.2019 19:10 - 19:52)
- Обращение к ЕЕПРОМ вообще должно быть запрещено всегда, кроме непосредственно обращения - MBedder(12.01.2019 19:41)
- А что будет, если МК не подозревая о предстоящем выключении, со всеми предосторожностями начал запись (необходимо несколько мсек), а тут его Brown-out сбросил через 1 мсек? Такое выключение теоретически можно спрогнозировать, если при помощи АЦП maleon(167 знак., 12.01.2019 20:12)
- Такие ситуации легко отлавливаются и исправляются при следующем включении с помощью CRC/КС. Не сошлась КС - заменяй данные на дефолтные. P.S. сносить не туда запощенное сообщение вовсе не нужно - есть функционал "прикрепить" - MBedder(12.01.2019 20:17 - 20:20)
- Правильные пацаны делают типа журнал, атомарность операций обеспечивается. Не записалось до конца - будет то, что было перед этим. - SciFi(12.01.2019 20:20)
- char RestoreSetupUntilSuccessful(void) VLLV(212 знак., 12.01.2019 20:25)
- А если 3, 4 и т.д.? :)) - MBedder(12.01.2019 20:27)
- А памяти больше нет :) - VLLV(12.01.2019 20:34)
- А если 3, 4 и т.д.? :)) - MBedder(12.01.2019 20:27)
- Именно поэтому Волга до сих пор и впадает в Каспийское море, а не куда-нибудь в Миссисипи :)) - MBedder(12.01.2019 20:22)
- char RestoreSetupUntilSuccessful(void) VLLV(212 знак., 12.01.2019 20:25)
- Правильные пацаны делают типа журнал, атомарность операций обеспечивается. Не записалось до конца - будет то, что было перед этим. - SciFi(12.01.2019 20:20)
- Такие ситуации легко отлавливаются и исправляются при следующем включении с помощью CRC/КС. Не сошлась КС - заменяй данные на дефолтные. P.S. сносить не туда запощенное сообщение вовсе не нужно - есть функционал "прикрепить" - MBedder(12.01.2019 20:17 - 20:20)
- А что будет, если МК не подозревая о предстоящем выключении, со всеми предосторожностями начал запись (необходимо несколько мсек), а тут его Brown-out сбросил через 1 мсек? Такое выключение теоретически можно спрогнозировать, если при помощи АЦП maleon(167 знак., 12.01.2019 20:12)
- Обращение к ЕЕПРОМ вообще должно быть запрещено всегда, кроме непосредственно обращения - MBedder(12.01.2019 19:41)
- Обычно память портится во время случайного старта функции записи из-за сбоя ядра при нештатном питании. - VLLV(11.01.2019 19:31)
- записи на старте нет. только чтение. одним блоком большим все вычитывается в озу - Троешник(11.01.2019 19:39)
- А что мешает программно сделать необходимую задержку перед чтением ЕЕПРОМ, если фусы недоступны? И перед выключением тоже запретить обращение к ЕЕПРОМ :-). - maleon(12.01.2019 19:10 - 19:52)
- память бьется одиночными байтами, в большинстве того что я видел. Троешник(310 знак., 11.01.2019 19:20)
- По рекомендации Атмела : 1)не пользовать 0-ю ячейку EEPROM 2) после каждой операции чтения/записи обнулять регисрты EEARH, EEARL. если не соблюдать эти условия то велика вероятность порчи ячеек EEPROM адрес которых записан в EEARH:EEARL. - m16_home(11.01.2019 18:00)