Запись в файл: println и обязательный close

Логгер погреба провёл в работе всю ночь: Serial каждые шесть секунд печатал свежую строку, скетч не падал, питание не мигало. Утром я вынул карту, вставил в ноутбук — файл log.csv нулевой длины. Ни одной строки из четырнадцати тысяч. С этой карты ещё вечером я читал конфиг, то есть карта живая, а файл — пустой. Виновник нашёлся в третьей строке скетча от «работает же»: я открыл файл в setup, всю ночь печатал в него print-ами и ни разу не вызвал close(). Все байты ночи просидели в буфере оперативной памяти, каталог FAT честно считал файл пустым, а утром питание выдернули — и буфер умер вместе с платой.

Это самая дорогая ошибка раздела: она не шумит, не роняет скетч и не зажигает ошибок в Serial — просто однажды вы остаётесь без данных, ради которых всё затевалось.

Разберём механику: куда попадает байт после println, зачем библиотеке буфер ровно на 512 байт, что делает close() и чем отличается от flush(), и как выбрать схему записи — открывать файл на каждую строку или держать открытым всю ночь.

println в объект File делает три вещи: превращает число в текст, добавляет перевод строки — два байта, \r\n, приплюсуйте их к любому подсчёту объёма, — и копирует байты в буфер. Буфер ровно 512 байт, потому что 512 байт — это один сектор карты, минимальная порция физической записи. Писать сектор карта может за единицы миллисекунд, а вот дешёвые и изношенные карты иногда затягивают один сектор записи до сотни миллисекунд — этот паразитный прыжок называется latency spike, и библиотека старается дёргать карту пореже: пока буфер не заполнен, карта вообще не трогается.

Заполнился буфер — сектор уехал на карту, буфер обнулился, печать продолжается. Прикинем на моей строке лога: sec,temp в формате 3661,24.7 — это 9 символов плюс два на перевод строки, итого 11 байт. В сектор влезает около 46 таких строк: первые 45 строк существуют только в оперативной памяти. Всё это время файл на карте с точки зрения компьютера пуст — размер в каталоге обновляется отдельно, и этим отдельно занимается close().

Задержки удобно измерить самому: оберните open-print-close в печать millis() до и после. На моей связке Uno с картой 8 ГБ Class 4 цикл занимает 12-18 мс, а раз в сотню записей прилетает прыжок до 90-110 мс — контроллер карты в этот момент внутри себя занимается выравниванием износа ячеек. Для записи раз в две секунды это незаметно, а для потока по каждому обороту loop — уже причина дырок: интервал между метками в логе прыгает со 100 мс до 200 мс без всякой причины в вашем коде.

close() делает два дела сразу. Первое: дожимает буфер — недозаполненный сектор всё равно уходит на карту, хоть там и три байта. Второе — и это то, что теряли мои ночные строки: close обновляет запись в каталоге FAT, где хранится размер файла и конец цепочки кластеров. До close файл для компьютера имеет ту длину, что была зафиксирована при прошлом закрытии; данные в недописанных секторах, может, и лежат физически, но никто не знает, что они принадлежат этому файлу. Поэтому файл ночной записи без close выглядел пустым, хотя байты в карте, возможно, остались.

Собрат close — метод flush(): сбрасывает буфер на карту, но файл оставляет открытым и каталог не трогает до следующего sync или close.Flush нужен в схеме с долго открытым файлом — как страховочный сброс каждые несколько секунд. А вот миф, что flush заменяет close, я проверял на себе: после flush файл всё ещё занят дескриптором, и повторный open вернёт ложь. Закрывать файл всё равно надо.

Теперь стратегии. Схема «открыл — записал — закрыл» на каждую порцию стоит денег: открытие, запись и закрытие занимают порядка 10-50 мс с учётом задержек карты. При записи раз в две секунды это ноль целых два процента времени — ничто. Зато при сбое питания вы теряете максимум одну строку: всё предыдущее уже зафиксировано каталогом. Для логгеров с частотой до примерно одной записи в секунду я выбираю всегда эту схему — она же стоит в коде выше, и каркас millis() для неё берите из урока про millis вместо delay.

Держать файл открытым имеет смысл, когда записей много: десять и больше в секунду, где 10-50 мс на открытие уже заметны. Тогда файл открывается один раз, а буфер подстёгивается flush() каждые 2-5 секунд — потеря при сбое ограничивается этими двумя-пятью секундами, зато каталог обновится только при финальном close. Второй риск этой схемы я уже проходил в первом уроке раздела: при сбое питания посреди физической записи FAT может повредиться, и пострадает весь файл, а не последний сектор. Watchdog из урока про таймеры и сторожевого пса подстрахует зависший скетч, но от потери буфера при выдёргивании питания он, увы, не спасает.

После симулятора проверьте свой логгер на прочность прямо на столе: запишите минуту данных, закройте файл, прочитайте его обратно скетчем из урока про режимы File и сверите size(). Затем уберите close — и увидите, как файл останется старого размера при полностью работающем скетче. Чтобы не таскать карту к компьютеру, выведите содержимое прямо в Serial Monitor тем же FILE_READ — там же, где мы выводили таблицы в уроке про таблицу данных в Serial: файл распечатается строка за строкой, и сразу видно, где дырки в интервале меток. Формат карты, на которой всё это живёт, мы разобрали в уроке про FAT16, FAT32 и размеры. Домашнее задание: посчитайте для своей строки CSV, сколько строк влезает в сектор 512 байт, и ответьте, сколько строк потеряет ваш скетч при выдёргивании питания без close — для схем с открытым файлом ответ редко бывает меньше сорока.