Как стать автором
Обновить

Сохраняем настройки и лог файл во внутренней памяти микроконтроллера

Время на прочтение 15 мин
Количество просмотров 7.3K
Всего голосов 15: ↑13 и ↓2 +11
Комментарии 12

Комментарии 12

Прочитал достаточно внимательно. Ощущение что сильно перемудрили.

Для хранения файловой системы в микроконтроллере можно поступать значительно проще.

Размещал файловую систему в 8ми битном МК + вывод на веб интерфейс. Поддержка FTP и uploud через веб интерфейс. всего то нужны указатели на структуру, где хранится название файла , начальный адрес в памяти , размер файла. Ограничения аналогчны вашим - отсутствие вложенных папок и каталогов. возможность удаления файлов , переименование файлов. После удаления файлов вызывается процедура сжатия для оптимизации незанятой памяти.

Вы уверены что внимательно прочитали? В статье же прямо сказано, что да можно и проще. И что файл это всего лишь поименованная последовательность байт. И про массивы в памяти как предлагает LwIP тоже сказано. Но идея в другом, полноценная файловая система позволяет существенно экономить время при разработке, поскольку не думаешь о том где и как храняться данные. Я накидал что описано в статье часа за 3-4. А вот Ваше решение, с удалением файлов напрямую, выглядит на мой взгляд запутанным. Посмотрите статью (https://habr.com/ru/company/embox/blog/541662/) там описано как избежать необходимость FTP в подобных устройствах. Но это конечно все мое личное мнение.

Посмотрите статью (https://habr.com/ru/company/embox/blog/541662/) там описано как избежать необходимость FTP в подобных устройствах. Но это конечно все мое личное мнение.

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

В 8ми битном МК файловая система располагается в МК , так была задача с минимальным количеством корпусов сделать устройство с веб интерфейсом настроек.

В 32 битном МК файловая система во внешней памяти, а минимальный веб настроек хранится в памяти МК. Получается две совмещенные системы. Такого решения я еще не видел в описаниях ни к STM32 ни к другим МК. Такой подход дает возможность иметь неубиваемый ВЕБ интерфейс в памяти МК, а во внешней памяти хранятся подгружаемые страницы. Такой подход позволяет паралельно работать двум специалистам - программисту МК и ВЕБ программисту. И каждый может отлаживать свою часть. ВЕБ программисту даже не приходится вникать в работу МК. Он работает с привычным для него набором файлов.

Все работает через стандартные вызовы файловой системы: открыть файл , закрыть файл, найти файл по имени и т.д. Работа с атрибутами файла. Поэтому и написал , что перемудрили.

Такого решения я еще не видел в описаниях ни к STM32 ни к другим МК. 

у нордиков nrf52/nrf53 в SDK есть примеры подключения Flash Data Storage - файловой системы, придуманной похоже нордиками (в подробности не вдавался, не было необходимости её использовать). По сути аналог того, что было в статье. Есть сборка мусора, есть равномерный износ и возможность писать "файлы" и если память не изменяет, поверх FDS можно ещё и FatFS поставить без проблем. Объем ограничен свободной флешкой самого МК.

Да примера использования, как Вы описали нет, но в целом возможность такая есть. Особенно если учесть, что рядом ещё на QSPI NAND память повесить можно (аж до 256 мегабайт, больший объем найти в этом корпусе не удалось), то вполне реально из двух примеров собрать то что Вы описали.

ИМХО, не видели в описании скорее всего потому, что гораздо проще рядом прилепить EEPROM или маленькую SPI флешку, чем заниматься кодингом.

Не понял. С одной стороны вы пишите о преимуществах работы через стандартные вызовы файловой системы, и использовании разных файловых систем для различных целей, что и описано в статье. А с другой говорите что практической пользы нет.

Наверное не понятно описали в стать, но поясню, в нашем подходе может быть гораздо больше файловых систем, чем одна внутри МК и одна снаружи. Внутри МК описана initFS, что там можно перемудрить я вообще не понимаю, строчек 200 кода.

пример перезаписываемой файловой системы размещен внутри МК, но он может быть размещен и вне на флешке, а может быть две три файловые системы как вне МК так и внутри. Еще если хочется монтируйте usb-флешку или sd карту.

Ну и отдельно хочется отметить

Такой подход позволяет паралельно работать двум специалистам - программисту МК и ВЕБ программисту.

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

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

Вот только для этого должен быть внешний флеш

Это все таки зависит от задачи. Но вообще то в статье написано, наверное не очень понятно, что можно использовать любое блочное устройство. В этом и прелесть файловой системы. Если логгер должен находиться вне МК то эту файловую систему монтируете не внешнюю флешку, ничего переписывать не нужно. Можно свою файловую систему организовать и так далее. Немного пояснил в конце статьи. Спасибо

Статья классная, но:

  • Не увидел тестов

  • Не увидел репозитория

  • Не увидел настроенного CI

  • Не увидел каких-то средств выравнивания износа

  • Не увидел поддержки записи логов "по кольцу"

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

Статья классная

Спасибо!

Не увидел репозитория

Репозитория чего? То же самое касается тестов и CI. В Embox это все есть

Не увидел каких-то средств выравнивания износа

Спасибо за комментарий. Этого действительно нет. Поскольку статья посвящена другому. Немного дописал в конце статьи.

Не увидел поддержки записи логов "по кольцу"

Что Вы имеете в виду? В разделе лог-файл описан логгер по кольцу.

Спасибо. Да, можно проще. Но мы показали общий подход.

Зарегистрируйтесь на Хабре , чтобы оставить комментарий