Сейчас внезапно окажется, что "разработка на SD" - это просто спёртый откуда-то кусок кода.
А вот для того, чтобы (по-человечески) начать работать с FRAM, код для этого надо снова откуда-то спереть.

VNS ясно... значит автоматизацию ты никогда не делал...

оно и понятно... потому что сидеть и ждать когда кто-то что-то предложит бесполезно...
это так не работает.
надо самому брать проект и работать. тогда получится.


abc я с флешками уже наигрался...
они действительно капризные и ненадёжные.

скажем так...
-если данные действительно важные то сбрасываем на сервер и делаем резервное копирование как положено.
-если данные не важные то и не стоит тогда заморачиваться))

Не "окажется", а так оно и есть. Вы что-ж думали - автор сам файловую систему писал?
Или - спёрнуть!

foton6, отформатируйте на компе свою карту и создайте там большой пустой файл. Определите с какого физического адреса в пространстве карты он начинается. В своей программе по мере появления событий, пишите их на карту поблочно сразу, начиная с этого адреса. Даже если питание пропадёт в неподходящий момент, не запишется или запишется с ошибкой всего один блок. Файловая система не пострадает. Конец журнала событий можно легко найти при последующем появлении питания. Если файл будет очень большой, то не придётся организовывать кольцевой буфер и соответственно не надо будет хранить его индекс, который может "протереть" память карты. Хотя есть хитроумные способы хранения индекса непосредственно в блоке данных. Ну или для индекса применить мелкую FRAM.
И не надо ни каких мутных танцев с ионисторами.

... а если мощности контроллера позволяют вкрячить нормальное ядро os, linux скажем, то можно взять какуюто журналирующую транзакции fs
напр ext3/ext4 или xfs и fs не будет повреждаться !, после аварии максимум будут недописаны открытые на запись файлы.

и так тоже делали...
и по всякому делали))

https://cxem.net/mc/mc435.php

а потом решили что нафиг не нужны эти заморочки.
проще писать блоками по 512 байт.
эффект тот же.

а если и пострадает то мы можем её восстановить.))

только в самой Файловой системе нет никакого смысла.
эффект тот же.

А чегож вы тогда строем не ходите не посоветовали это топикстартеру?


Смысл огромный: вставил карточку в ноутбук и легко, штатными средствами операционной системы скопировал весь журнал в виде файла, например .txt или .csv, который в любом текстовом редакторе или экселе можно открыть и проанализировать события. Или вы предлагаете этот гигабайтный журнал в виде простого дампа, накопленый за весь срок службы девайса, анализировать специально написанным приложением на компе? Или долго и печально тащить через узкий канал на любимый сервер? Или реализовать в коде гору функционала в самом МК, для анализа журнала на месте?

не знаю какое устройство у ТС... а у меня все устройства в труднодоступных местах))



поэтому мне проще скачать по сети на сервер чем каждый раз лезть за microSD.


а сама microSD используется только когда сервер "не в сети".
а как только сервер появляется "в сети" то устройство само передаёт на сервер данные. без моего участия))
в остальных случаях microSD не нужна. от слова совсем ))
такая была у меня идея.


а впрочем... сейчас мне microSD вообще не нужна. если один сервер "не в сети" то другой сервер "в сети".

О! Спапсибо, великолепная идея!
Да я номера блоков (кол-во записей) храню в блоке + CRC обязательно - так легко идентифицировать последнюю актуальную запись.

Добавлено after 6 minutes 4 seconds:

Верно! Я хочу ФС исключительно ради возможности открывать на ПК без спец ПО.

Добавлено after 8 minutes 27 seconds:
По поводу живучести карточек я не переживаю, у меня более десятка устройств на Orange PI, работают уже не первый год в разных условиях - пока все ОК, как минимум отрабатывают стандартную рабочую неделю постоянно. Я тоже переживал, думал будут отлетать каждые полгода или т.п. Хотел делать даже режим только для чтения или SLC флешки искать, но оно не потребовалось.

В текущем проекте тоже проблем быть не должно в ввиду то го что не будет производится перезаписи,
каких нибудь 8гб хватит на пожизненное ведение архива.

Добавлено after 3 minutes 39 seconds:

Мимо, FRAM имеет малые объемы в сравнении с карточками, а я хочу "пожизненный архив", как написал выше
У меня вообще обратная проблема, я всегда стремлюсь написать свой код в ущерб времени, редко использую библиотеки - никак не усвоится мысль что использование библиотек - это хорошо и быстро

Не нужна тебе там ФС! Просто последовательно данные пиши в текстовом виде. На компе при помощи less /dev/sdX посмотришь содержимое.
Никакого доп софта не нужно!

С FRAM тоже можно наловить проблем почти на ровном месте. Кому интересно почитать. В одном из устройств (логгер), пишу на microsd каждые 50ms. Поскольку устройство вспомогательное, сделал по началу просто, никаких мониторов питания, fatFS от Чена. Пишем по схеме - новое включение - новый файл, через заданный интервал (50ms) файл открывается на запись, добавляется строка лога, файл закрывается. Питание пропало да и хрен с ним. Так и оставил, как показала практика, все пишется нормально, лог разрастался до тысячи файлов общим размером сотни мегабайт. Ничего не терялось при отключении, даже при такой частой записи.

А устройство стационарное?

выше есть подсказка))

скорее всего стационарное...
вряд ли ТС будет таскать за собой штепсель или автомат))
хотя... всё может быть.))

Стационарное. А какое это имеет значение?

навсякий случай повторю:
если компьютер с линуксом и контроллер с линуксом то на флэшке можно держать ext3 (ext4) fs , которые по дизайну оочень устойчивы к аварийным прерываниям процессов записи.

Тогда, почему не поставить аккумулятор?
Я обычно ставлю, что-то в этом роде:
https://www.ozon.ru/product/akkumulyato ... 172396185/

Его ресурса года на три хватает

Вы похоже ничего не поняли что вам советовали...

FRAM советовали не для хранения вашего архива, а для сохранения критических данных при сбоях питания. "Критические данные": это накопленные, но ещё не записанные в архив данные (вы же в архив не каждую миллисекунду пишете, а наверное - какое-то время накапливаете, а потом записываете сразу блок?). А также - для сохранения индексов (позиций) записи в ту же SD-карту (чтобы при каждом запуске на сканировать её всю, что долго и приведёт к потерям данных во время такого сканирования). И большие объёмы FRAM для этого не нужны.
Применение FRAM обнуляет необходимость в сложных костылях с мониторингом питания, ионисторами и прочей такой громоздкой и ненадёжной тряхомудрией. Просто один дешёвый копеечный чип и все проблемы решены.

Добавлено after 12 minutes 59 seconds:
Как говорится: "Сдуру можно и х... сломать"
Если так, то с монитором питания пространство для ловления проблем ещё больше.
С FRAM/MRAM сделал уже кучу проектов. Серийных. Никаких проблем.

Интересно - как это вы умудряетесь делать, если SD-карта штатно может производить запись до нескольких сотен мсек??? Сказки не надо рассказывать. Скажите, правду - что не контролировали это время никогда.

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

Добавлено after 3 minutes 15 seconds:
А ресурса FRAM хватит на всё время жизни устройства ТС.

jcxz,
Да, действительно почему то в голове застряла мысль что FRAM предлагаете как замену SD
Так то дельная мысль буфер накапливать в FRAM. У меня на МК есть блок питаемый батарейкой, в нем часы и памяти 2kb, тут и планировал складировать до записи на SD.

да подключите уже своё устройство к ПК и не мучайтесь))
на ПК сотни гигов свободной памяти... и ниче не глючит.

Спойлер

Объясняю - устройство аналогово цифровой логгер для авто, сделал чтоб найти полтергейста в системе управления авто, записывало кучу параметров. Измерения проводились с определенным интервалом и писались на карту, при интервале 20мс я не успевал записывать, 35-40мс уже получалось, выбрал 50мс с запасом. При разборе лога количество измерений соответствовало времени поездки. Дальше было как-то фиолетово.

Бортовая сеть авто и включение/выключение девайса ключем вместе с зажиганием - достаточно стрессовые условия?