Подъехало продолжение записи в EEPROM в сплошном адресном пространстве. Ну собсно после того как подъехала вторая микросхема EEPROM. Не сколько глупо, сколько не рационально писать, когда нет возможности проверить. Не рационально по схеме затраченное время — результат. Было внутренний EEPROM → внешний. Стало внутренний → внешний → внешний... Так же исправлена ошибка записи во внутренний EEPROM. Вроде все делаю исключительно по даташиту, но при ближайшем рассмотрении оказывается, что всё но не достаточно четко... При записи в EEPROM нельзя обрываться на прерывания, а тот же millis() в Ардуино заводит и счетчик и прерывание, по его переполнению. При очередной загрузке изображения пару пикселей оказываются не на своих местах... Ну да ладно, исправлено и исправлено.
Резонно возникает вопрос, а зачем вообще всё это нужно?
EEPROM, это в первую очередь адресуемая память, то есть она гораздо более предпочтительная чем flash когда идет речь о хранении константных значений, для тех же картинок. Для примера, функция написания текста, которая включает в себя русские и латинские символы и строчные и различные знаки имеет в своем составе константных значений всего на 1974 байта, и код функций, очень не большой, и с небольшим количеством так же констант. Но при добавлении скетч жиреет на более 15Кб! И это при условии что значения упаковываю в 16 битную переменную, а потом при чтении распаковываю. Это экономит 1.5-2Кб памяти. Запись в unsigned long сэкономит еще больше, но в рамках функции написания текста, данную переменную, не в полной мере рационально использовать. Хуже другое. Когда компилятор видит такой объем констант, он пытается их впихнуть после загрузки сразу в ОЗУ, поэтому и существует такое уточняющее слово в Arduino IDE как PROGMEM, которое гарантировано (или почти гарантированно) заставляет разместить массив только во flash. Так же помогает увеличить массив на +1 ячейку, чем фактически занято константными значениями.
Но при размерах flash современных микроконтроллеров, не убедительное преимущество. Даже в той же Меге, этих килобайт целых 256. А разница в цене, между более компактными МК, для самодельщика абсолютно не существенна. Да и для коммерческого исполнения, зачастую разница является крайне не существенной. Не столь давно наблюдал обзор дрон детекторов, стоимостью около 200 тысяч рублей. Люди там абсолютно не заморачивались, и вкорячили смартфон в свой корпус, который выводил достаточно скудную инфо на экран. И проц смартфона там явно не напрягался.
Основная идея здесь конечно более широкая. Это работа с данной памятью, как с обычной ОЗУ. То есть создаем переменные, и что гораздо более важнее создаем массивы, в том числе 16 и 32 битной разрядности, в том числе и float. А в базовой версии запись в EEPROM идет побайтно. В Си конечно же нет никакой сложности распотрошить даже float переменную, а при чтении склеить все обратно.
Но это уже экспериментальная часть, пока я её не выкладываю. Написано это на С++. То есть создаем объект, класс резервирует диапазон адресов. Запись и чтение выглядит как .read_array(index, value); То есть можно и цикл заряжать.
Но конечно, это не полноценное ОЗУ, потому что сложно реализовать удаление. Точнее само по себе удаление реализовать не сложно, сложно использовать освободившееся место. Но это уже начинается создание файловой системы. В случае с EEPROM такой надобности как мне кажется нет. То есть если мы создаем массив, то он нам необходим на протяжении работы всей программы, ну что-то типа глобальной переменной, без возможности удаления.
Хотел, железобетонно протестить работу. Загрузить картинку которая расположилась бы сразу во всех трех EEPROM, во внутреннем, и двух внешних. Но картинка получается порядка 64Kб, и из flash памяти (из скетча) её не загрузить, так как не возможно создать столь огромный массив. Тут нужно предусматривать загрузку картинки сразу в EEPROM из SD каррты. А я предполагал, что такое хорошо бы иметь, еще когда писал функции чтения картинок, но забил тогда допиливать функционал. Чтение идет из EEPROM построчное, тут проблем никаких нет.
Основная идея наверное звучит как: "Сперва делаем инструмент функциональным, потом удобным".