Почему EEPROM "кривится"?

Тогда в чём?

Под Win проверялось? У меня 10-ка.

В неправильной методике тестирования.

В случае второго кода вы видите результат повторного запуска кода.

При первом запуске ваш Маркер = OxFFFF , условие

if (eeReadDefMarker() != DEF_MARKER) {

истинно и запускается функция

eeWriteROM();

При втором запуске условие УЖЕ ЛОЖНО, поэтому вы не видите процедуры записи, но контент-то в ЕЕПРОМ УЖЕ ЗАПИСАН.

Думаю, что когда вы прошиваете код - он успевает выполнится до того, как вы подключите Монитор. И поэтому вы видите только ВТОРОЙ ЗАПУСК Для первого кода это не имеет значения, а вот для второго критично.

Я добавил к Ардуино кнопку, чтобы управлять запуском кода - и вижу именно первый проход, а не второй.

Собственно, я нашел это, потому что сразу знал, где искать.

Пояснения, как проверить - нужны? Или сами справитесь?

Монитор не закрываю/не выключаю ни в IDE 2.3.2, ни в VSCode. Он постоянно запущен, чтобы не пропустить именно первый запуск. В выложенном видео это заметно.

после setup я ставил delay(3000) для случаев, когда пропускалось часть кода

Но это жуткий костыль, на мой взгляд

это только поймать глюк, правда его уже поймали

ОК, зайдем с другой стороны.

Вы понимаете, что такого, что ЕЕПРОМ прошивается “сама”, причем не мусором, а нужными данными - быть не может? - это же просто бред

Не спорьте, добавьте к ардуине кнопку - и поставьте такой же опыт, как у меня.
Вы увидите, что при первом запуске (второго кода) вывод такой, как у меня в сообщении 38, а при втором и всех последующих - как в ваших тестах ранее.

Отсюда вывод - вы видите второй запуск. ПОЧЕМУ - это уже другой вопрос, вы можете его исследовать без меня, мне это не интересно.

Может @Дим-мычъ проверит? Ему вы поверите?

1 лайк

Аппаратный выбор путем замыкания какого-то пина на “ноль” - это стандартная практика при инициализации ЕЕПРОМ.
Я ей много раз пользовался, и потому, как написал выше - знал где искать ответ вашей “загадки”.

Не понял. Подробнее, если можно.

Дело в том , что EEPROM успевает записаться раньше, чем законнектится COM порт. Отсюда и чудеса. Задержка 3-5 сек, и всё в норме.

Спойлер

if (eeReadDefMarker() != DEF_MARKER) {
Serial.println(F(“Erase…”));
eeClearROM(); //Во всех примерах так.

1.Читаем и убеждаемся , что Маркер == DEF_MARKER

Go… short
eeReadDefMarker() = 1812
DEF_MARKER = 1812

eeReadROM:
14 Marker 0x1812
16 key_01_ 01:01:01:01:01:00:00:1A
32 key_02_ 02:02:02:02:02:00:00:2A
48 key_03_ 03:03:03:03:03:00:00:3A
64 key_04_ 04:04:04:04:04:00:00:4A
0 FF:FF:FF:FF:FF:FF:12:18 FF:FF:FF:FF:FF:FF:FF:FF
16 6B:65:79:5F:30:31:5F:00 01:01:01:01:01:00:00:1A
32 6B:65:79:5F:30:32:5F:00 02:02:02:02:02:00:00:2A
48 6B:65:79:5F:30:33:5F:00 03:03:03:03:03:00:00:3A
64 6B:65:79:5F:30:34:5F:00 04:04:04:04:04:00:00:4A

2.Изменяем const uint16_t DEF_MARKER = 0x1813;//!!! было 1812
Чудеса, без записи в ЕЕPROM маркер изменился!

Go… short
eeReadDefMarker() = 1813
DEF_MARKER = 1813

eeReadROM:
14 Marker 0x1813
16 key_01_ 01:01:01:01:01:00:00:1A
32 key_02_ 02:02:02:02:02:00:00:2A
48 key_03_ 03:03:03:03:03:00:00:3A
64 key_04_ 04:04:04:04:04:00:00:4A
0 FF:FF:FF:FF:FF:FF:13:18 FF:FF:FF:FF:FF:FF:FF:FF
16 6B:65:79:5F:30:31:5F:00 01:01:01:01:01:00:00:1A
32 6B:65:79:5F:30:32:5F:00 02:02:02:02:02:00:00:2A
48 6B:65:79:5F:30:33:5F:00 03:03:03:03:03:00:00:3A
64 6B:65:79:5F:30:34:5F:00 04:04:04:04:04:00:00:4A

  1. Изменяем маркер опять, на 1812, но уже с делэй 5 сек

Теперь всё как и положено

Go… short
eeReadDefMarker() = 1813
DEF_MARKER = 1812

Erase…
eeClearROM:
0 0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF
16 0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF
32 0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF
48 0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF
64 0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF
write Marker:
14 0x1812
eeWriteROM:
16 key_01_ 01:01:01:01:01:00:00:1A
32 key_02_ 02:02:02:02:02:00:00:2A
48 key_03_ 03:03:03:03:03:00:00:3A
64 key_04_ 04:04:04:04:04:00:00:4A
eeReadROM:
14 Marker 0x1812
16 key_01_ 01:01:01:01:01:00:00:1A
32 key_02_ 02:02:02:02:02:00:00:2A
48 key_03_ 03:03:03:03:03:00:00:3A
64 key_04_ 04:04:04:04:04:00:00:4A
0 FF:FF:FF:FF:FF:FF:12:18 FF:FF:FF:FF:FF:FF:FF:FF
16 6B:65:79:5F:30:31:5F:00 01:01:01:01:01:00:00:1A
32 6B:65:79:5F:30:32:5F:00 02:02:02:02:02:00:00:2A
48 6B:65:79:5F:30:33:5F:00 03:03:03:03:03:00:00:3A
64 6B:65:79:5F:30:34:5F:00 04:04:04:04:04:00:00:4A

Извиняюсь, делал на примере из #24 мало времени сейчас, дописал только вывод значения маркера в началк скетча

2 лайка

Да, но это только для тестирования вариант.
Для реального использования только аппаратный переключатель.

@Feofan не забудьте поставить отметку “Решение” на один из моих постов.

Можно ресет снять в нужный момент

Тогда это объясняет “половинчатые” искажения в eeprom - код начал выполняться, в какой-то момент времени стартует COM-порт и дёргает reset.

Типа такого
---- Открыт последовательный порт COM3 ----

Go... short
eeReadROM:
14 Marker  0xFFFF
16 ÿÿÿÿÿÿÿÿFF:FF:FF:FF:FF:FF:FF:FF
32 ÿÿÿÿÿÿ_ FF:FF:FF:FF:FF:FF:FF:FF
48 key_03_ 03:03:03:03:03:00:00:3A
64 key_04_ 04:04:04:04:04:00:00:4A
---- Закрыт последовательный порт COM3 ----

Вопрос решён. Спасибо БОЛЬШОЕ всем участвовавшим. Претендентов на решение два, им отдельное спасибо:
MMM
Дим-мычъ
А двоих нельзя. Отметил самый простой и доходчивый ответ.

P.S.

  1. Не в интересах истины, а в интересах правды, МММ всё же ответил первый.
  2. Спасибо за интересную задачку, побольше бы таких - для обучения полезно.

Бесспорно. Но несколько туманно. Потому я и отметил

Но… как скажете. Поправил.

1 лайк