File и режимы открытия: чтение, запись, добавление

Конфиг теплицы жил на карте файлом settings.txt, и однажды мне понадобилось дописать туда строку с отладочным флагом. Я открыл файл FILE_WRITE, дописал — и файл стал длиннее, а порог вентилятора остался прежним. Вечером я сделал вторую ошибку, похуже: решил «затереть» первую строку через seek(0) и вписать новый порог поверх. В файле лежало threshold=2640 — кто-то вписал четыре цифры, я записал поверх threshold=26, и хвост из двух цифр никуда не делся: в настройках честно осталось 2640. Вентилятор молчал при любой жаре, потому что порог в 2640 градусов не наступит никогда.

Обе ошибки — из одного незнания: FILE_WRITE — это дозапись, а не «открыть и менять», а seek двигает курсор, но ничего не стирает. Режим перезаписи в библиотеке SD вообще отсутствует, и это надо знать до того, как устройство уедет на объект.

Разберёмся, что такое объект File и почему это не сам файл, а ручка от него; что делают FILE_READ и FILE_WRITE при каждом запуске; как честно перезаписать файл и как читать конфиг построчно. По ходу увидим таблицу режимов и скетч, который проживает все три сценария на одной карте.

SD.open() возвращает объект типа File — дескриптор, через который вы работаете с файлом на карте. Сам файл лежит в кластерах, а File — это запись о нём: где курсор, какой режим, куда ведёт цепочка кластеров. Пока дескриптор существует, файл считается занятым: правило одного открытого файла из первого урока раздела действует всегда, и повторный SD.open() того же имени при незакрытом первом вернёт «ложь» — второй ручки не дадут. Закрыли close() — карта свободна, можно открывать следующий.

Чтение устроено ровно как в Serial, и это не совпадение: File наследует тот же интерфейс потока. f.available() говорит, есть ли ещё байты, f.read() отдаёт следующий, f.peek() подглядывает без чтения — если вы проходили урок про available и read, тело цикла чтения узнаете с первого взгляда. Работает и f.readStringUntil('\n') — та же функция, которой мы ловили команды в уроке про команды из Serial. Служебные вопросы отвечают f.position() (где курсор), f.size() (размер файла в байтах) и f.seek(n) (переставить курсор на байт номер n).

Проверку if (f) я ставлю всегда: open возвращает «ложный» объект, если файла нет (при FILE_READ), карта не смонтирована или имя уже занято. Без проверки скетч молча пишет в никуда, и вы узнаете об этом по пустому файлу через неделю наблюдений.

Пара слов об именах. Файловая система FAT хранит короткие имена в формате восемь-точка-три: log.csv — идеально, а отчёт_за_январь уже требует длинного имени, которое ест несколько записей каталога. Мне хватает коротких: run.log, cfg.txt, d2512.csv (день и месяц прямо в имени). Вложенные папки SD.h умеет — SD.mkdir() и путь вида dir/file.txt — но я держу всё в корне: на карте в несколько гигабайтов навигация по папкам не окупается, зато меньше шансов ошибиться в пути.

FILE_WRITE — это «создай, если нет, и встань в конец». Хвостовая позиция курсора хранится в каталоге FAT, поэтому файл можно открывать и закрывать хоть сто раз за день — каждая дозапись продолжится ровно оттуда, где закончилась предыдущая. Так лог растёт между перезагрузками платы, и это то поведение, которое нужно в девяти случаях из десяти. Плате даже не важно, сколько времени прошло между дозаписями: час или трое суток — курсор ляжет на то же место, потому что позицию помнит каталог, а не переменная в RAM.

А в десятом случае — когда надо поменять содержимое — начинаются грабли, на которые я наступил с порогом 2640. seek(0) переставляет курсор записи в начало, но файл не обрезается: байты поверх, которые вы не переписали, остаются. Порог 26 поверх порога 2640 дал threshold=260 — ноль суровее нужного в десять раз, вентилятор включался бы при 260. Единственный честный способ перезаписи в SD.h: SD.remove(name) удалить файл и открыть его FILE_WRITE заново — создастся с чистого листа. Два обращения к карте вместо одного, зато ноль сюрпризов. Моё правило: seek я применяю только при чтении середины больших файлов, для перезаписи — никогда.

Почему хвост так коварен: числа в файле имеют переменную длину. Порог 26 и порог 2640 отличаются на два байта, и если новый короче старого, разница остаётся в хвосте и прилипает к концу числа. Если длиннее — вы затрёте начало следующей строки. Именно поэтому конфиги я переписываю целиком: один remove, один open, один блок println — и файл всегда представляет собой то, что вы только что в него положили. Для чтения seek наоборот удобен: например, перескочить шапку CSV, зная её длину в байтах.

Обратите внимание на структуру: каждый файл открылся и закрылся до того, как открылся следующий. Порядок «открыл — поработал — закрыл» я держу даже внутри setup, где соблазн оставить дескриптор открытым до конца скетча велик. В симуляторе ниже те же три запуска показаны как журнал: смотрите, куда встаёт курсор после каждого open и как растёт размер файла — это и есть поведение FILE_WRITE в чистом виде.

Теперь вы умеете открывать файл в любую сторону и не оставлять в нём хвостов. Отдельная развилка — где вообще хранить настройки: журнал измерений просится на карту, а вот пара чисел вроде порога и счётчика пусков честно живёт в EEPROM без всякой файловой системы — так это устроено в уроке про счётчик включений. Моё разделение: EEPROM — для флагов и чисел, файл — для всего, что хочется открыть глазами в блокноте. Осталось главное: понять, что происходит с байтами между println и картой — почему файл без close() выглядит пустым даже после сотни строк и как строить запись так, чтобы сбой питания отнимал у вас одну строку, а не весь ночной лог. Этим займётся следующий урок про запись и close. А если ваш конфиг уже читается построчно, взгляните, как тот же приём выглядит для CSV-лога с шапкой и столбцами — он разобран в уроке про CSV и чтение конфига.