Log-файл на SD

[jump]

проще вообще без файловой системы обойтись. А данные передавать по USB

очень мудрое решение с учетом того, что усб от малейшего пука раком становится и без переинициализации (передергивания) не восстанавливается

[Easyrider83]

очень мудрое решение с учетом того, что усб от малейшего пука раком становится и без переинициализации (передергивания) не восстанавливается

Не замечал такого.
Данные в виде структуры лежат на карте. При запросе передаются в РС по USB HID. Очень удобно - размер пакета HID можно сделать равным одной структуре. Т.е. готовый пакет - с начала до конца. И программировать просто.
В этом случае даже карта памяти особо не нужна. Поставить SPI Flash на несколько мегабайт. Если мало не будет, конечно.

[jump]

Не замечал такого.
Данные в виде структуры лежат на карте. При запросе передаются в РС по USB HID

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

[Chudilo]

Сохраняемые на карту данные вообще не структурированы - это различные события с различным набором параметров. USB и COM не подойдёт. Нужна система типа "чёрного ящика". При аварии приехал на объект, забрал карту памяти из девайса, в офисе её прочитал, увидел причину аварии в лог файле, сделал необходимые изменения в проекте, приехал на объект, перешил девайс, вставил карту и уехал до следующей аварии.

- Где-нибудь на PC или еще где форматируется SD карта и на ней в root directory создается один Бааальшой файл (макс. 4Gb-1 размером). Имя файла можно сделать в формате DOS 8.3 большими(!!) буквами, типа FILE.LOG (для того, чтобы у файла была всего 1 directory entry, для простоты).

А как создать файл размером в размер карты?

[oleg110592]

Имхо я бы лучше прикрутил файловую систему - например FatFs. Если на карточке есть бэд блоки, при форматировании на пк будут отмечены. Файл писать в формате csv. Можно планшетом, телефоном, буком с экселеподобным софтом просмотреть.

[Красный Свин]

Имхо я бы лучше прикрутил файловую систему - например FatFs. Если на карточке есть бэд блоки, при форматировании на пк будут отмечены. Файл писать в формате csv. Можно планшетом, телефоном, буком с экселеподобным софтом просмотреть.

Если на SD карте или другом типе носителя со встроенным FTL (MMC) появляются BAD-блоки (на уровне файловой системы), значит такая карта уже протерта до дырок и подежит утилизации в мусорную корзину. На карточках такого типа всегда есть скрытый резерв NAND-памяти, который контроллер использует для ремапинга битых блоков. Это абсолютно прозрачно для пользователя. Если этот резерв исчерпан - все, надо выкидывать. Кроме того, из-за принципов работы NAND+FTL, однозначного соответствия между номером кластера файловой системы и физической страницей NAND нет, IMHO.

Ответ на предыдущий вопрос: совсем не обязательно создавать вайл во всю карточку, достаточно того размера, который нужен
FAT12,16,32 поддерживают файлы размерами до 4GB-1, (правда на FAT12/16) такой файл не влезет

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

[oleg110592]

файл нужного размера можно создать хекс редактором, например WinHex.

[ut1wpr]

Сама же embedded system пишет напрямую внутрь большого непрерываного файла, заранее созданного после форматирования.

Вы уж определитесь, будет ФС или не будет. А если она все-таки будет, то зачем создавать где-то какие-то огромные файлы? Программа МК с помощью ФС на камне должна смотреть, есть такой файл на карте или его нету, если есть писать методом append. Если нет - create file. Очищать ФС можно и на компе. К объекту приезжать с ведром чистых карт, изымать информационную, втыкать чистую.
При смене карты процедура: останов логирования -› замена карты -› запуск логирования. На время смены карты дампируем вовнутря МК, куда позволено писать и сколько позволено. После запуска логирования - определение наличия файла, далее как я написал, затем сброс дампа и работа в штатном режиме.
Наличие ФС в случае неструктурированных данных обязательно, т.к. никакого разговора о вычислении предварительных размеров блоков и резервировании под них места на карте не ведется. Petit FAT как минимальная вполне подойдет.

[Красный Свин]

Вы уж определитесь, будет ФС или не будет. А если она все-таки будет, то зачем создавать где-то какие-то огромные файлы? Программа МК с помощью ФС на камне должна смотреть, есть такой файл на карте или его нету, если есть писать методом append. Если нет - create file. Очищать ФС можно и на компе. К объекту приезжать с ведром чистых карт, изымать информационную, втыкать чистую.

[..]

Наличие ФС в случае неструктурированных данных обязательно, т.к. никакого разговора о вычислении предварительных размеров блоков и резервировании под них места на карте не ведется. Petit FAT как минимальная вполне подойдет.

Ну... оперирование объектами файловой системы подразумевает гораздо более сложные манипуляции с разными структурами данных в определенном порядке на карточке. Это усложнение вполне может порождать небольшой ворох проблем

этот Petit FAT он Fault-tolerant ? Если нет, то возможна ситуация повреждения файловой системы при внезапном пропадании питания. Это гораздо серьезнее, чем повреждение лога данных, который можно откатить до последней валидной записи (если реализовать правильно)..
Причем повреждения могут носить разный характер в зависимости от многих параметров - от потерянных кластеров до полного повреждения директории со всем содержимым.
Я знаю пару вариантов fault-tolerant FAT, но они закрытые, весьма сложны и страдают разными другими недостатками.

Так что боюсь, что автору придется начать с составления списка use cases & requirements Типа:

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

[ut1wpr]

Так что боюсь, что автору придется начать с составления списка use cases & requirements Типа:

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

Нет возражений! Если задаться целью, то можно убить практически любую ФС. А от каждуго чиха-перда не защитишься. Redudancy по питанию решает все проблемы. Шо в Виндах, шо в Линухах, шо в эмбеддинге. Важно знать степень значимости данных и цену их потери. Пожалуй, это главное.