EEBoom - arduino библиотека для эмуляции EEPROM на ESP32 ESP8266

А мне кажется, самое полезное в этой теме - появление нового члена сообщества. Надеюсь @x-radio Никита тут приживется

6 лайков

Спасибо на добром слове

Неделя - это ни о чем: проекты делаются месяцами и годами.
Но вообще, присоединяюсь к @Estorsky .

А кто говорит, что библиотека готовая. Она еще сырая на уровне интерфейса. Все наверно наблюдали самокаты, велосипеды,автомобили. Все они предназначены для перевозки людей. А интерфейсы у них разные. Вот и здесь интерфейс такой же. Вроде сделан, а непонятно. Самокат это или велосипед.

Что конкретно вам не понятно? Вы установили, пример запустили, нашли несостыковки? Что-то работает не так, как вы ожидали?

Видите ли, @x-radio, проект - это не “я тоже так могу”, проект - это “я сделал то, что никто до меня не делал”.

То-есть автомобиля Жигули быть не может )))

Именно так! Я лет 8 назад это всё написал и до сих пор ничего подобного не нашел ни под non-framework ни под arduino…
Вы же не просто так говорите? Вы же посмотрели хотя бы примеры? Вы работали когда-нибудь с EEPROM.h, например?
Меня не покидает ощущение, возможно это закономерно, что много людей здесь просто увидело “'эмуляция eeprom” - и не особо вчитываясь начали мне рассказывать, что такое уже есть…

В первом посте я рассказываю о том, что в EEBoom такого, что я решил это отдельно организовать.

Расслабьтесь. Просто ваша библиотека здесь никого не заинтересовала. О ее качестве это ничего не говорит. Примите это как данность ))

а меня, мне эта задача как раз нужна

Вот ты и будешь тестировщиком ))

ты мегу научись прошивать, двоечник :sweat_smile:

1 лайк

у нас в ауле двойки не ставили, минимальная оценка 3, если ты вообще не пришёл, а сено косил

Меня тоже заинтересовала. Но больше как пример проверить себя и библиотеку, а так же поиск неправильности.
Техническая неправильность:
1- все же ресурс памяти достаточен. И если все же он закончился, то можно сдуть с платы старую микросхему и надуть новую с такой-же программой. Сам производитель программы может предоставить дополнительный чип, что бы не угнали программу.
2- ограничение перезаписи в паспорте это просто пожелание от проектантов, что бы не рассказывать сложные вещи. Память состоит из конденсаторов и проволочек подводящим к ним заряд. Ограничение перезаписи связано скорее всего с разрушением проволочек от излишних токов. Так что если регулярно переписывать данные которые там находятся на том же месте, то ресурс не поменяется. Меняется если переписывать с 0 в 1 и 1 в 0, от токов перезаписи.
неисправность в интефейсе:
1 отсутствие стратегии для использования.
2 наличие команды группиовой записи, а группового считывания я не нашел.

1 лайк

Как-то писал уже выше, что обычно прошел бы мимо комментария, который недостаточно формализован или просто мне не нравится. Но я здесь TC и по формату подразумевается ответ на вопросы по сабжу. Плюс комментарий носит негативный характер. Теперь, если я просто проигнорирую сообщение, случайный посетитель темы в будущем может подумать, что я согласен с автором поста по всем пунктам… Что ж я вынужден отвечать.
Сорян за долгое вступление.

Техническая неправильность с 2 пунктами - это вообще про что? Типа про то, что всё таки лучше к nodemcu проволочками припаять дополнительную микросхему и несколько резисторов?
Первое - не заставляйте пожалуйста людей угадывать, о чем вы думали, когда писали комментарий. Это очень неприятно.
Второе - о каких проволочках и конденсаторах вы говорите и где они должны износиться (esp? внешняя микросхема?) Это про то, что может быть не 1000, а 9000 например? Что от этого меняется?

Про неисправность - также непонятно, о чем речь? И почему именно неисправность. Как связана стратегия использования и интерфейс?
Вы пример Basic открывали ведь? Как бы вы видели присутствие стратегии в интерфейсе для этого продукта. Чем по вашему стоит дополнить репозиторий, чтобы восполнить этот пробел?

Про групповую запись - единственный четкий вопрос. Отвечу. Фактически командой группового чтения является begin(). При выполнении этого метода происходит поиск последней валидной копии данных в указанных секторах и загрузка её в копию в оперативную память. На протяжении всей работы программы эта копия доступна для чтения и записи в RAM через поле data. Например ee.data.var = 0x55. Эта команда изменит данные в копии в RAM. Для того чтобы зафиксировать их в flash нужно вызывать ee.commit(). После выполнения данные будут сохранены в постоянную память и доступны после перезагрузки устройства.

Возможно именно описание такой последовательности вы подразумевали под стратегией Мне как купающемуся в этом очень долго это неочевидно. И если это подтвердится, возможно сделаю дополнительное описание.

Ну вот вы команду группового чтения обозвали begin() , команду групповой записи обозвали commit(). Какой СТРАТЕГИЕЙ вы пользовались. Если это у вас стек, то PUSH/POP , Если работа с памятью то вроде LOAD/SAVE Можно READ/WRITE

Я, честно сказать, про групповое чтение и запись от вас впервые слышу… из название просто понятно, о чем речь, поэтому в ответе и применил.
begin() - потому что arduino. Мне самому не нравятся эти лупы, сетапы и бегины. Но такова реальность. Большинство объектов в этой парадигме начинаются именно методом begin(). Можно потерпеть.
Касаемо чтения - мы больше НИГДЕ не читаем данные из flash. Вся работа идет с копией в RAM. Кроме того - это ни стек и ни очередь - мы работаем всегда только с одной последней копией данных. Как будто пользователю доступен в памяти только объем его структуры.
Между commit() и write() долго выбирал - выбрал первое, так как мне показалось, что для простого arduino пользователя так будет привычнее и понятнее. У меня же изначально это да, было write(). Еще write() семантически можно спутать с записью в RAM, а commit() - довольно необычно, что подтолкнет к мысли, что именно это та самая запись во flash.
Примерно такие рассуждения.

А как же dump() ? ))

Ну я думал что begin(адрес) нужен для прописывания адреса страницы. Тогда просто begin() 'это самое начало. Создается объект а ОЗУ, потом связывается с копией в EEPROM и дальше просто записываются текущие копии. А почему групповое, так все кучей/страницей пишется
Как по мне всегда нужно пользоваться СТРАТЕГИЕЙ написания программы. Это как СТРАТЕГИЯ битвы. Надо победить в битве, а для этого надо найти сильные и слабые стороны родов войск. Причем не надо показать, как красиво идут пехотинцы, а как далеко стреляют арбалетчики, и как кавалерия красиво подпрыгивает.
Вот и Вы решите роль EEPROM в программе.

Вот! вот человек посмотрел, что там еще есть)
dump() - это уже техническая вспомогательная функция, которая позволяет вывалить в порт состояние сектора - как в hex редакторе. Там много настроек, но так же есть режим по умолчанию. Вы можете смотреть, как физически меняются данные во флеш байт за байтом. В процессе разработки я пользовался этим функционалом для отладки, потом немного причесал, чтобы это было красиво и информативно.
С помощью параметров line и column вы можете вывести необходимые строки и колонки. Всего сектор состоит из 128 строк по 32 байта каждая (4096). Вы можете вывести строки с 5 по 10 и колонки с 2 по 16 - к примеру. То есть фактически задаете размер окошка, через которое будет смотреть на сектор. Это окошко нужно для того, чтобы не вываливать за раз весь сектор - это очень долго и тормозит и контроллер и хост.
К тому же есть вариант выводить текущий сектор и текущую линию - смотрите документацию. То есть задать вывод только того, где сейчас идет запись данных - самый кипиш) Очень удобно.
В принципе никто не мешает посмотреть на кишки других секторов - например, последних 5, где орудует ядро фреймворка или область прошивки.