а если не лезть по ссылкам, то суть в том, что в примере для SD все эти функции заканчиваются вызовом процедуры file.close();, а вот в примере для SDMMC данная процедура не вызывается. Библиотека FS.h используется одинаково в обоих случаях. Почему тогда так?
автор вроде один - производитель ESP32 - espressif
примеры в одном репозитарие, в разных папках только
Вопрос тогда уточню, когда правильней использовать процедуру file.close(). Я так понимаю, что функции readfile и writefile выполняют действия с файлом и “отпускают” его, поэтому тут мы после выполнения всех действия используем file.close(). А функция appendfile подразумевает добавления данных в файл и пока мы туда что-то дописываем, можем не использовать file.close().
Да, Вы правы, авторы примеров разные, хотя библиотека FS.h одна и таже. Тогда как правильней делать? Пробовал оба варианта, вроде работает.
Но у моей тестовый программы логика простая - прибор включился, началось логирование данных в файл до его выключения. При новом включение начинается логирование в новый файл. И никаких действий с какими-либо файлами в процессе работы прибора не выполняется. Все остальное через ПК.
Я думаю, правильно открывать файл при попытке записи, и закрывать его, когда запись произведена. Существует ли возможность отключения прибора в момент записи данных? Если да, то не исключена возможность потери данных в этот момент и также возможна ситуация, что флешку можно больше не прочитать…
Есть вариант: писать ЛОГ в память, а потом при достижении некоторого объема данных, записать сразу одним блоком. И снова писать в память. итак далее.
Для эктренно-важного сохранения данных - писать EEPROM, потом на SD, если записалось на SD, снова писать в EEPROM и так далее.
Однако ресурс EEPROM предположительно ограничен. Но насколько много надо вести статистику? Вариантов масса.
Опять же… насколько важна в данном вопросе скорость записи на SD?
“немного в сторону” :
При важности, можно посылать данные статистики внешнему компьютеру, например по Ethernet или через COM-port.
… но как обычно бывает, когда всё хорошо работает, надобность в логах не особо нужна. А если не работает - надо просто разбираться с проблемой :s)
Функция readfile не предполагает изменения файла. Именно этим она отличается от двух других.
А функции writefile и appendfile выполняют одно и то же - пишут в файл. Только, начиная с разных позиций.
В любом случае, мы работаем с блочным устройством. То есть информация на нем хранится кусками по 512 байт и меньшая порция информации записана быть не может. Никак.
То есть процесс записи может быть организован одним из двух способов:
Данные накапливаются в буфере. По заполнении буфер сбрасывается целиком на блочное устройство, после чего заполнение буфера возобновляется.
Данные точно так же накапливаются в буфере. Но блок пишется на блочное устройство после каждого обновления буфера. Опять же, целиком. В начале блока при этом находятся накопленные денные, а в хвосте - мусор, который также записывается.
Недостаток первого варианта - потеря последних накопленных данных из неполного блока.
Недостаток второго - намного более медленная работа (предположительно в 512 раз) и быстрое “протирание” ресурса flash-памяти.
Но ни в том, ни в другом случае не сохраняется длина файла. Собственно, функция close предназначена именно для ее сохранения, причем пишет информацию она не в тело файла, а в каталог. В общем, все это будет работать еще раза в три медленнее (в лучшем случае).
Впрочем, алгоритмы работы с файловой системой на устройстве с явным дефицитом оперативной памяти могут быть весьма причудливы и довольно медлительны.
Причем, разные авторы могут отдавать предпочтение разным подходом к балансу между скоростью и надежностью. Особенно учитывая, что надежность сама по себе имеет более одного аспекта, т.к. ресурс имеет склонность к износу.