Имеем контроллер, управляющий неким устройством. Сейчас по всем событиям, происходящим в процессе работы, в терминальный последовательный порт выдается информация о событии и реакции на него в текстовом виде (просматривается на подключенном ноутбуке-терминале). Теперь необходимо этот журнал работы вести на имеющимся в системе флеш-диске с файловой системой (FAT16 - все под DOSом). Ни как на ум не приходит красивое решение по ведению этого журнала.
В предыдущем устройстве аналогичное делал - но там был сеансный режим работы (короткие сеансы с большими перерывами) и поэтому создавался каталог для журнала ("/LOG"), в нем каталог с текущей датой ("/LOG/070828/" для 28 августа 2007) и далее для текущего сеанса текстовый файл с именем, сформированным по времени начала сеанса ("/LOG/070828/13-25.log"). По окончании сеанса файл закрывался (fclose). Все было хорошо - и искать удобно, и при пропадании питания и других сбоях в худшем случае терялась информация только по последненму сеансу.
Здесь же работа ведется непрерывно, хотя и события возникают не чаще 1 раза в секунду, даже в несколько секунд), поэтому вроде как нужен один файл, но тогда при пропадании питания (допустимая ситуация) файл будет не закрыт и вероятно потеряна записанная в него ранее информация. Да и при заполнении диска непонятно как с работать - нужно будет как-то удалять устаревшие записи, т.е. вести "перелопачивание" всего файла. Да скачивание такого файла по медленному порту терминала и ручной поиск информации по какому либо событию (оператором в случае разбора журнала работы) затруднен в текстовом файле в 16 МБайт (объем флеш-диска). Значит разбивать на "короткие" файлы за небольшие промежутки времени? Но это как-то нелогично, ведь процесс работы устройства непрерывен. Да и индексироваться для поиска тоже надо как-то будет.
Да - формат сообщений в журнале (логе) менять нельзя - это текстовые строки (ASCIIZ) различной длины (но начинаются они всегда с даты-времени, одно сообщение не может занимать более одной строки), т.е. построить что-то двоичное структуроподбное нельзя.
Кто как поступал в аналогичных ситуациях, и вообще, есть ли какие-нибудь правила по ведению логов?

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

Хорошо, спрошу немного конкретнее - как организовать циклический буфер записей в файле? Т.е. я должен отслеживать переполнение диска при записи нового собщения в журнал и удалять самые "старые" сообщения? Если это возможно простым способом - то вопросов в ведении журнала не возникнет.

Может быть заводить по одному файлу на каждый день?
А слишком старые файлы удалять. Пусть буферами, свободныи местом и т.д. ОС занимается.

Возможно, я уже думал, только день - многовато. При возможном (и допустимом выключении) пропадет журнал за целый день. Я думал минут по 5 делать, тогда надо как-то осмысленно файлы именовать, что бы была возможность поиска по дате/времени как оператором (при "разборе полетов"), так и контроллером. Правда что делать при корректировке времени - переименовывать все файлы? Как-то все сложно и запутанно получается.

Если вас так беспокоит выключение, то FAT - далеко не лучший выбор. При выключении в процессе записи можно потерять всю информацию. Поэтому нужно либо делать контролируемое отключение, либо ставить другую файловую систему.
Кроме того, при слишком частой перезаписи быстро кончится ресурс флеш-диска. Я бы больше чем на 100 000 записей не закладывался. Поэтому данные надо где-то буферизировать. При гарантированном питании - в ОЗУ, при негарантированном - либо в ОЗУ с подпиткой, либо в FRAM от Ramtron. Если делаем буферизацию, то данные можно сбрасывать на диск либо по заполнению буфера, либо при смене даты по алгоритму - открыли файл на дозапись fopen(name, "ab"), записали данные, закрыли файл, сбросили кеш.

Как с решением задачки? Много времени прошло Если подобные задачи есть еще - у Рамтрона появились FRAM c большим объемом массива - и параллельные и последовательные. И одно из типичных массовых применений FRAM - как раз кольцевой энергонезависимый буфер. Самая большая, правда, всего 4 мегабита (FM22L16, 512кбайт, 8 или 16 разрядов шина данных), зато количество перезаписей не ограничено.

Пока никак - эту задачу буду решать в последнюю очедь. А поменять файловую систему или применить что-либо другое нельзя - это ГОТОВЫЙ контроллер Octagon 6225, и что в нем есть, то есть, не добавить не отнять

Не очень понятно, почему нельзя поменять файловую систему, если флешка в полном Вашем распоряжении. Этот вариант - наилучший, имхо.
Другой способ - создать fault tolerant хранилище поверх фат16. Это довольно трудоемкая задача, если делать "как надо" Облегченный вариант - это создавать файлы по n записей или по m кб, писАть в них нужно как сказал vmp - открыть, записать, закрыть, сбросить кеш если нужно. Индексация - по имени или дате модификации (если есть источник абсолютного времени). В идеале, потеряется только текущий файл лога, поэтому остается подобрать нужное значение n или m. Однако, если реализация драйвера фат16 и самой флешки "кривая", то можно потерять все

Лучший вариант - организовать подхват питания. В нормальном режиме файлы писать в ОЗУ (RAM диск). При сигнале отключения питания сбрасывать все на диск (FLASH) и контроллером отключать питание. Иначе диск убить можно, и никакая система распределения записей не спасет.
Вели журнал на контроллере FASTWELL (стоял DiskOnChip) писали файл раз в менуту и через 3 месяца получали отказ диска, дважды. Первый раз списали на дефект, второй раз отключили журнал.

Время не нужно корректировать. Никогда. Корректируется только поправка к этому времени: поправка для коррекции хода "набортных" часов, поправка на летнее/зимнее время, поправка для отображения пользовательского (поясного) времени и т.д. В таком случае никакой проблемы поиска по времени создания/редактирования не будет.

Грамотно подхват питания для лога организовать довольно сложно, особенно, если лог сбрасывается на флешку.

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

Еще весьма интересно куда заведен этот сигнал по питанию, т.к. в зависимости от приоритета прерывания (ведь скорее всего это будет прерывание) возникает ряд не менее чудных задач.
К тому же, при другом сбое (например, программном) весь лог в РАМ потеряется.

При нормальном wear leaving'е флешка должна жить довольно долго. Чтобы окончательно решить эту проблему, нужно, как уже говорили, ставить FRAM без ограничения циклов перезаписи.

Все зависит от конкретной системы.
Если это тумблер на приборе, то при подаче питания паралельно ему замыкать реле (или контактор)
а при отключении (определяется опросом) размыкать реле контроллером после записи данных.
Если же это внешний рубильник тогда сложнее. Тjгда FRAM.

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