stm32, нужна нормальная библиотека эмуляции EEPROM через FLASH

Ну или может кто возьмется сделать нормально

Называйте цену.

100? Мыло на гитхабе в организациях.

https://github.com/speedcontrols/ac_sc_grinder/commit/79e04604fa69ed28583b163...

Пока наговнякал с копированием кода, как сумел.

Какая сейчас дефолтная валюта?

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

у.е. же, как всегда

Никак не связанные вещи. Эмулятор решает вопрос ресурса flash, остальное - как у обычного eeprom. Если нужны полные гарантии, это надо решать отдельно, как и для eeprom в том числе.

Я себе вот такую шнягу делал. Попробуй.

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

Я использую eeprom.{c,h} из примеров в каталоге EEPROM_Emulation.

Я в курсе про него. Но смысл в том, чтобы подключить библиотеку, а не коллекционировать в репе проекта посторонний понос.

Для libfixmath засылал PR, теперь его можно нормально в platformio втыкать. А для флеша нет (или не нашел) ничего вменяемого.

PS. Скорей бы в Rust... а с языками без пакетных менеджеров пусть долбятся самые упорные.

угу, работает. хотя по-хорошему там надо ее допатчить - ну к примеру чтобы нули (или FF) не писала и т.п., особенно если строки переменной длины будут храниться.

вот берете библиотеку и подключаете, в чем проблема?

или вы вместо STM32 HAL используете «посторонний понос»(тм)? ну так это ваши проблемы, а не библиотеки...

Ты из тех, кто вместо разработки любит часами настраивать МК? Может и объективные аргументы против использования HAL подвезёшь? Как HAL с кубом могут превратить твои мозги в опилки, а тебя самого в абдуринщика, например? Простота использования?

зачем эмулировать EEPROM через FLASH

В том как подключать. У меня такое впечатление, что для вас понятия пакетный менеджер и управление зависимостями - пустой звук.

У флеша лимит перезаписей сильно ниже, и удаление блочное. А приложениям надо модифицировать несколько байтиков, как в eeprom.

Короче, если пройти по ссылкам из первого поста, там можно найти доки, где подробно все изложено.

А чего бы нормальный внешний EEPROM не прицепить, он сотни нефти не стоит и 2 проводка для связи всего. Этот ваш STM дрочит вприсядку, а потом документацию ещё на это дело пишет

мысля про прицепить поиходит только когда натрахаешся вдоволь. а у тех кто ресурс считать умеет мыслей скрестить ужа с ежом совсем не возникает :)

или выбрать чип со встроенным EEPROM-ом

Форкни проект, создай отдельную тему, и научи всех на личном примере как надо жить.

но он черт возьми прав, поверь набитым шишкам

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

Простота использования?

Да, например. Всем известно, что мастдайку используют только [censored]. Аналогично было с бубунтой. Сейчас к ней добавляются новые дистрибутивы с анальными зондами, где поднасрал поцтеринг.

Если нет необходимости переписывать 100500 раз, а надо лишь раз в месяц-два пересохранять новые параметры, то эмуляция EEPROM через FLASH — очень даже ничего!

Как вариант, можно еще развить тему: в линкере автоматом вычислять свободное место и прописывать адрес там. Тогда все свободные страницы можно будет под эмуляцию использовать, т.е. перезаписывать флешь нужно будет реже. И, кстати, алгоритм тоже можно расширить: если вместо последовательного поиска использовать бинарный, считывание настроек при старте значительно ускорится!

Но жрущим кал это не понять.

В том как подключать

скопировать в каталог проекта и добавить в IDE/мейкфайл пути. в чем проблема-то?

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

в проекте на пару десятков килобайт кода - да, пустой звук. более того - нафиг не нужный «посторонний понос»(тм).

ну и да, у стм32 эмулятора флэши из «зависимостей» - только стандартный HAL. все.

скопировать в каталог проекта и добавить в IDE/мейкфайл пути. в чем проблема-то?

В том что подобный уровень разработки мне не интересен. Почему бы не прочитать внимательно первый пост и не допустить мысль, что я очень хорошо понимаю о чем спрашиваю?

Что ты понимаешь под «подключить библиотеку»? Тебе нужна статическая библиотека что ли?

Честно говоря, ни разу не встречал такого варианта распространения кода под микроконтроллеры. Все просто копируют нужные файлы ручками и правят потом. Нафига это оформлять как библиотеку, если в 99% случаев все равно придется что-то добавить, что-то выкинуть и что-то поменять?

И еще раз: бросай калокуб! А то у тебя будет воспаление гомосексуализма.

А вы еще не расте пишете? Что так отстало?

Он же только к концу года для эмбедов будет готов, а ждать нельзя.

Ну ждём успехов в эмбедеостве на расте. Особенно интересно будет посмотреть на работу с низким уровнем. На работу без динамической памяти итд.

Вот это особенно хорошо https://github.com/rust-lang/rfcs/issues/314

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

С практической точки зрения, я бы смотрел даты здесь https://github.com/rust-embedded/wg/milestones, ну и сами тикеты, если интересно.

А в чем конкретно вопрос? HAL есть, энтузиасты юзают, всякие крейты с альтернативными типам без аллокаторов - тоже.

У меня пока набегали вопросы совершенно другого рода:

- Нужен свежий RTFM (с поддержкой сообщений).
- Нет нормальной библиотеки GUI.

PS. Ну еще всякие нюансы из трекера WG, но их-то точно к релизу починят.