stm32 и FatFs от Chan Опции

[Ioann_II]

Здравствуйте, Уважаемые коллеги.

Снова нуждаюсь в Ваших подсказках.

Наконец-то подключил файловую систему от Чана и решил её опробовать.
Версия R0.11 от 02-02-2015.
Пробую открыть файл и дописать в его конец данные:

Код

f_open(&MyFile, "stm32.txt", FA_WRITE | FA_OPEN_ALWAYS);
f_lseek(&MyFile, f_size(&MyFile));
f_write(&MyFile, wtext, strlen((char *)wtext), &wbytes);

По описанию, FA_OPEN_ALWAYS должна открывать файл, если он есть и создавать если его нет.
Код выполняется, но:
- если такой файл уже есть, то очень быстро, менее 1с.
- если файла нет, то f_open и f_lseek срабатывают быстро, а вот f_write - долго, примерно минута. файл с данными появляются.

С чем это может быть связано? Куда "копать"?

_FS_NORTC пробовал (время не организовывал).
портирование от Domen Puncer, немного переделал.

Спасибо.

[Genadi Zawidowsk...]

три вопроса:
0) почему не последняя версия?
1) почему потребовалось портироваоие а не оригинальный код
2) есть ли работа с DMA в diskio и учтены ли требования по выравниванию структур? Это пришлось делать.

Сообщение отредактировал Genadi Zawidowski - Mar 30 2017, 07:47

[MiklPolikov]

С чем это может быть связано? Куда "копать"?

Смотреть в Ваши низкоуровневые функции чтения/записи диска, к которым обращается FatFS, и пытаться понять, что в них происходит: либо чтение одного и того что с одной и той же ошибкой, или чтение всего FAT в поисках чего-то и т.п.

[Ioann_II]

0) почему не последняя версия?
Версия та, что была предложена в CubeMX. Полагаю, надо сначала её запустить, а потом уже и посвежее можно попробовать.
1) почему потребовалось портироваоие а не оригинальный код
Имею в виду под портированием реализацию низкоуровневых функций. Несколько разных вариантов из интернета пробовал - всё вообще тупо висло.
Поэтому (т.к. "с наскока" не вышло), стал разбираться последовательно. Чтение и запись секторов работают нормально, проверено. Регистр CSD тоже, из него берутся нужные параметры для ioctl. Таймауты сделаны без таймеров.
2) есть ли работа с DMA в diskio и учтены ли требования по выравниванию структур? Это пришлось делать.
DMA нет. Структур (кроме тех, которые в самой FatFs) не использую.

Ещё. Несколько дней назад на этот-же МК портировал систему FAT32. Там таких проблем не выявлено....
Да, ещё вот - на карте уже записано с пяток файлов, общим объёмом 80Мб.

Сейчас попробовал почистить карту - стало всё быстро....

Получается, что если карта заполнена, то новый файл будет создаваться очень долго??

[MiklPolikov]

Получается, что если карта заполнена, то новый файл будет создаваться очень долго??

Если на карте тысячи файлов, то возникают задержки в секунды.
У Вас кривое "портирование", низкоуровневые функции работы с диском нужно отлаживать либо писать заново.

Порядок действий при отладке такой:
1) Низкоуровневые функции запускаются сами по себе, без FATFS, измеряется их скорость работы.
2) В низкоуровневых функциях раскидываются команды дёргания ногой процессора, сигнал снимается осциллоскопом, таким образом выявляются места, где функция тормозит.
3) То же самое, что в п 2, но с FATFS
4) Читается моя тема про скорость работы карт памяти, https://electronix.ru/forum/index.php?showt...;hl=MiklPolikov , делаются выводы, низкоуровневые функции и fATfs перенастратваются, п 1-3 проходятся заново.
5) Принимается решение избавится от интерфейса SPI( я угадал ? ) и перейти на SDIO
6)П 1-4 проходятся заново

[jcxz]

Получается, что если карта заполнена, то новый файл будет создаваться очень долго??

Нет, это только означает что у Вас неправильные пчёлы кривой код.
Да вроде в той сборке FatFS, что когда скачивал уже были примеры портирования под разные МК. Наверняка там было и для STM32. Сам не пробовал ибо сразу написал свой low level diskio.

[Ioann_II]

Если на карте тысячи файлов, то возникают задержки в секунды.
У Вас кривое "портирование", низкоуровневые функции работы с диском нужно отлаживать либо писать заново.

Порядок действий при отладке такой:
1) Низкоуровневые функции запускаются сами по себе, без FATFS, измеряется их скорость работы.
2) В низкоуровневых функциях раскидываются команды дёргания ногой процессора, сигнал снимается осциллоскопом, таким образом выявляются места, где функция тормозит.
3) То же самое, что в п 2, но с FATFS
4) Читается моя тема про скорость работы карт памяти, https://electronix.ru/forum/index.php?showt...;hl=MiklPolikov , делаются выводы, низкоуровневые функции и fATfs перенастратваются, п 1-3 проходятся заново.
5) Принимается решение избавится от интерфейса SPI( я угадал ? ) и перейти на SDIO
6)П 1-4 проходятся заново

1. Файлов всего 5-6. Общий объём 80МБ.
2. Низкоуровневые функции писаны заново. Чтение и запись сектора - проблем не выявлено. Поскольку при малом использовании объёма карты операции проходят быстро, дело не в этих функциях. Похоже, что долго делается поиск свободных кластеров...
3. Дёргания ногой процессора нет - используется аппаратный интерфейс SPI. Кстати надо проверить, не забыл-ли я в этом проекте поднять скорость SPI после инициализации карты. Хотя это не принципиально.
4. За ссылку спасибо - буду изучать.
5. Не угадали. SDIO на МК нет, поэтому только SPI.... увы. С SDIO, наверное, проще - в CUBEMX есть поддержка его и в проект подключается просто.

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

[jcxz]

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

Если подозреваете что дело именно в этом - попробуйте отформатировать карту заново и с большим размером кластера и положить туда потом эти файлы.
И вроде там у Чана был кеш FAT-области. А если нет - его можно сделать. Там насколько помнится можно было выделить сколько-то памяти под буфер, можно было минимум, а можно было побольше. Может из-за нехватки буфера у Вас ПО постоянно перечитывает FAT и запись директории с карты?
Если Вы сами пишете low level IO, то несложно туда добавить печать в лог статистики вызовов - можете промониторить какие функции вызываются, насколько часто и каковы временные соотношения между этими вызовами.

Я пару лет назад использовал FatFS на LPC1788. И тоже через SPI. Писал сам низкий уровень (SSP с FIFO + DMA + достаточные буфера в ОЗУ). Так у меня скорость чтения приближалась к 1МБ/сек. Открытия/закрытия файлов тоже не тормозили.
Посмотрите всё что касается буферизации в FatFS и добавьте везде.

[Ioann_II]

Если подозреваете что дело именно в этом - попробуйте отформатировать карту заново и с большим размером кластера и положить туда потом эти файлы.
И вроде там у Чана был кеш FAT-области. А если нет - его можно сделать. Там насколько помнится можно было выделить сколько-то памяти под буфер, можно было минимум, а можно было побольше. Может из-за нехватки буфера у Вас ПО постоянно перечитывает FAT и запись директории с карты?
Если Вы сами пишете low level IO, то несложно туда добавить печать в лог статистики вызовов - можете промониторить какие функции вызываются, насколько часто и каковы временные соотношения между этими вызовами.

Я пару лет назад использовал FatFS на LPC1788. И тоже через SPI. Писал сам низкий уровень (SSP с FIFO + DMA + достаточные буфера в ОЗУ). Так у меня скорость чтения приближалась к 1МБ/сек. Открытия/закрытия файлов тоже не тормозили.
Посмотрите всё что касается буферизации в FatFS и добавьте везде.

Форматировать с другим размером кластера - попробую, должно помочь, но не решит кардинально ситуацию. Сейчас 80Мб занято, карта на 8ГБ, а если будет под завязку?... тогда как???

По этому пути (буферизации) тоже думаю идти, но пока что с другой реализацией FAT32, не от Чана. Идея от CC Dharmani, Chennai, переделанная сначала kontroler (http://forum.easyelectronics.ru/viewtopic.php?f=4&t=2460), затем мной... всё просто и прозрачно, но нет работы с каталогами, поддержки длинных имён и кодовых страниц.
Но с буферизацией не так всё гладко - мне надо, чтобы была поддержка "горячего" подключения карты (т.е. карту могут вынуть и вставить почти в любой момент времени). Поэтому думаю номер последнего задействованного кластера писать на карту, в зарезервированной области boot сектора. Чтобы тогда не перебирать все кластеры, которые уже заняты данными.

Именно поэтому и задал вопрос по FatFs от Чана - полагаю, что кто-то с этим уже сталкивался, решал и что-то может подсказать.

Нет, это только означает что у Вас неправильные пчёлы кривой код.
Да вроде в той сборке FatFS, что когда скачивал уже были примеры портирования под разные МК. Наверняка там было и для STM32. Сам не пробовал ибо сразу написал свой low level diskio.

Для уважаемого jcxz:
Может, конечно и "кривой" код... Мой код (точнее, не совсем мой, а переделанный из интернета) - только чтение и запись сектора, а также получение служебных данных (ioctl) и инициализация. Вот код: - покажете что тут криво? (вложение).

Пробовал несколько разных чужих примеров - ничего не "завелось". Все примеры "тупо висли". Это "завёл".

Сообщение отредактировал Ioann_II - Mar 31 2017, 12:13

Прикрепленные файлы

 sd.txt ( 8.93 килобайт ) Кол-во скачиваний: 37
 user_diskio.txt ( 6.39 килобайт ) Кол-во скачиваний: 33

 

[MiklPolikov]

Похоже, что долго делается поиск свободных кластеров...

вот-вот. Ищите где тормозит по тому алгоритму, что я описал. Без долгой скрупулёзной самостоятельной отладки, увы, не обойтись.
Время работы функций измеряется не в "достаточно быстро", а в микросекундах. Надо измерять.

5. Не угадали. SDIO на МК нет, поэтому только SPI.... увы.

Угадал. У Вас SPI.

Отписываюсь от темы.

[Ioann_II]

вот-вот. Ищите где тормозит по тому алгоритму, что я описал. Без долгой скрупулёзной самостоятельной отладки, увы, не обойтись.
Время работы функций измеряется не в "достаточно быстро", а в микросекундах. Надо измерять.


Угадал. У Вас SPI.

Отписываюсь от темы.

Буду искать, о результатах отпишусь. Также придётся разбираться "в дебрях" реализации FatFs....
С надобностью измерять согласен полностью, но только касательно низкоуровневых функций, т.к. время работы функций файловой системы сильно будет зависеть от содержимого диска - как в моём случае.

Да, в этом проекте всё-же забыл сделать переключение на максимальную частоту SPIпосле инициализации - стало работать быстро.
Заполню карту и проверю ещё раз. И попытаюсь время измерить.

Не угадали по решению избавиться от SPI - надеюсь, не обидел....

Сделал переключение на максимальную частоту SPI. И измерение времени:
При наличии файла:
open - 38мс
lseek - 387мс
write - 843мс (пишется 1000раз по 82 байта)
При отсутствии файла (создание)
open - 182мс
lseek - 0
write - 4531мс

Т.е. open почти в 5 раз! и write почти в 12раз!


Сообщение отредактировал Ioann_II - Mar 31 2017, 13:45

[Genadi Zawidowsk...]

Таймауты сделаны без таймеров.

Это где? Там же все по статусу карты делается...
Если что - мой вариант велосипеда. В файле sdcard.c вариант для SPI начинается со строки 2350.

Сообщение отредактировал Genadi Zawidowski - Mar 31 2017, 14:49

Прикрепленные файлы

 sdcard.rar ( 26.32 килобайт ) Кол-во скачиваний: 32

 

[Шаманъ]

При наличии файла:
open - 38мс
lseek - 387мс
write - 843мс (пишется 1000раз по 82 байта)
При отсутствии файла (создание)
open - 182мс
lseek - 0
write - 4531мс

Т.е. open почти в 5 раз! и write почти в 12раз!

По 82 байта писать не есть хорошо. Я бы писал хотя бы кратно секторам, организовав небольшой буфер.

[Rash]

Потеря скорости и времени будет, если писать по 82 байта. Скорость можно достичь если кратно секторам и то хотя бы начиная с 1024, а то и лучше 4096 байт, складывая нужные данные в свои буферы. Также есть задержка после записи/чтения данных. Задержка завесит от размера передаваемых данных. Для записи может длится 1-30 мсек. Причём самая длительная имеет одну и туже периодичность, скорее всего зависит при переходе между блоками.

Думал сделать буфер на низком уровне, но не получилось, т.к. есть перекрёстный вызов из FatFs функций Write и Read. Выход, вставить переключение задач пока идёт ожидание, что бы не терять время при частой записи на SD карту.

[Ioann_II]

Отформатировал карту.
Записал большой объём данных (мегабайт на 300).
Проверил ещё раз:
открытие - 185 мс
поиск конца файла - 0 мс
запись данных 10*82 байт - 81 мс.

Вывод: похоже, что FatFs от Чана тут не при чём... До этого на этой карте тестировал другую FAT32 - Похоже, что там что-то не так. А тут всё норм.

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

Но всё равно хорошо, что спросил - получил полезную информацию, советы и ссылки.

[jcxz]

Вывод: похоже, что FatFs от Чана тут не при чём... До этого на этой карте тестировал другую FAT32 - Похоже, что там что-то не так. А тут всё норм.

Ещё вроде желательно, чтобы все структуры (начала копий FAT, бутзапись, корневой каталог) были выровнены по границе блока стирания карты. Тогда вроде операции записи выполняются значительно быстрее. Размер блока стирания указан в CSD.
Может на той проблемной карте было невыровнено.

[Ioann_II]

Ещё вроде желательно, чтобы все структуры (начала копий FAT, бутзапись, корневой каталог) были выровнены по границе блока стирания карты. Тогда вроде операции записи выполняются значительно быстрее. Размер блока стирания указан в CSD.
Может на той проблемной карте было невыровнено.

Проверить теперь сложнее - карту уже отформатировал.... Но поковыряю FAT32, ту, что упоминал ранее, возможно найду причину... тогда напишу.
На этой карте читал регистр CSD - так кратность стирания там 1 байт (они называют это granularity).

[Hold]

На обычной SD 2 ГБ емкостью получал скорости записи 3.7 МБ/с, чтения 7.3 МБ/с. STM32F429, SDIO 4бит, DMA(тупое ожидание окончания записи), FatFs_R0.13. Писал файл размером 32 МБ из SDRAM и читал его же в SDRAM. Хочется большой скорости - нужно писать большими блоками, можно собирать предварительно в буфер в SDRAM, затем скопом писать. Если писать теже самые 32МБ но блоками по 512 байт, то скорость записи всего около 200КБ/с, на порядок меньше. Возможно не оптимальный драйвер, да и надо найти карточку SDHC классом повыше попроверять.

17/10/12 14:55:34->[EXT MEM: SDCARD]->Write end, speed: 3889 KB/s ( 33 554 432 (32.00 MB) in 8424 ms)
17/10/12 14:55:34->[EXT MEM: SDCARD]->Read end, speed: 7534 KB/s ( 33 554 432 (32.00 MB) in 4349 ms)

Сообщение отредактировал Hold - Oct 12 2017, 08:03

[mantech]

Если писать теже самые 32МБ но блоками по 512 байт, то скорость записи всего около 200КБ/с, на порядок меньше. Возможно не оптимальный драйвер, да и надо найти карточку SDHC классом повыше попроверять.

Это не проблема ФС, а карты памяти, ибо флеш не оптимизирован за запись мелкими кусками(менее 4К).

[Hold]

Нашел карту SDHC 4 класс 8 ГБ. Или что-то с картой не так, или с драйвером:

17/10/13 11:36:04->[EXT MEM: SDCARD]->Free: 7 833 767 936 (7.29 GB)
17/10/13 11:36:04->[EXT MEM: SDCARD]->Total: 7 846 363 136 (7.30 GB)
17/10/13 11:36:13->[EXT MEM: SDCARD]->Write end, speed: 557 KB/s ( 4 194 304 (4.00 MB) in 7345 ms)
17/10/13 11:36:13->[EXT MEM: SDCARD]->Read end, speed: 5165 KB/s ( 4 194 304 (4.00 MB) in 793 ms)

Читает/пишет без ошибок, однако скорость никуда не годится. На ПК показывает 4 МБ/с Надо поискать 10-й класс.

[Огурцов]

Это не проблема ФС, а карты памяти, ибо флеш не оптимизирован за запись мелкими кусками(менее 4К).

а там (в либе) ограничение на 512 может быть, так что (в некоторых случаях) никак


Сообщение отредактировал Огурцов - Oct 13 2017, 05:37

[mantech]

а там (в либе) ограничение на 512 может быть, так что (в некоторых случаях) никак

Дак ведь в настройках фатфса все прекрасно правиться

[Ruslan1]

Читает/пишет без ошибок, однако скорость никуда не годится. На ПК показывает 4 МБ/с Надо поискать 10-й класс.

Это не столько от класса карточки зависит, сколько от организации программы и от организации карточки.
Попробуйте разобраться, на что именно у Вас тратится основное время, например, при file append:
1) поиск первого кластера файла в FAT
2) прохождение по цепочке кластеров до последнего
3) чтение нужного сектора
3а) поиск свободного кластера (если нужен)
4) обновление сектора
5) запись сектора обратно
6) обновление FAT и всех копий FAT (изменение длины файла, добавка кластера в цепочку если нужно)

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

Тут гораздо больше чтения, чем записи. И очень часто этот бесконечный поиск-обновление FAT занимает много времени.
Я в критичной к времени записи задаче (запись кольцевого файла кэша определенной длины) делал при старте поиск цепочки кластеров нужной длины, объявлял их занятыми файлом, и далее напрямую пихал туда данные. Было значительно быстрее чем на каждый 200-байтовый чих проходить полную стандартную цепочку с поиском в FAT.

В общем случае помогает укорочение цепочки в FAT (использование длинного кластера), нахождение файла в начале карточки (первые кластеры) и несегментированность карточки (кластеры файла следуют друг за другом). Ну и расположение файлов в корневой директории, чтобы цепочка поиска была короче.

[Hold]

Да, дело было в размере кластера. Флешку не форматнул, проверял как есть. В итоге кластер был всего лишь 4КБ. Поставил кластер 64КБ, скорость выросла:

17/10/13 16:01:15->[EXT MEM: SDCARD]->Write end, speed: 3700 KB/s ( 33 554 432 (32.00 MB) in 8856 ms)
17/10/13 16:01:15->[EXT MEM: SDCARD]->Read end, speed: 7824 KB/s ( 33 554 432 (32.00 MB) in 4188 ms)

Понятно что с таким размером кластера, невыгодно хранить много мелких файлов, т.к. зарезервируется слишком много пустого места.
Для сравнения взял обычную SD на 2 гб, кластер также 64 КБ

17/10/13 16:03:52->[EXT MEM: SDCARD]->Write end, speed: 3666 KB/s ( 33 554 432 (32.00 MB) in 8937 ms)
17/10/13 16:03:52->[EXT MEM: SDCARD]->Read end, speed: 7814 KB/s ( 33 554 432 (32.00 MB) in 4193 ms)

Нашлась карта SDXC на 64 Гб, 10 класс. Кластер также выставил в 64 кбайта, стоит exFAT. Скорость уже куда интереснее:

17/10/13 16:11:20->[EXT MEM: SDCARD]->Free: 63 830 753 280 (59.44 GB)
17/10/13 16:11:20->[EXT MEM: SDCARD]->Total: 63 831 015 424 (59.44 GB)
17/10/13 16:11:27->[EXT MEM: SDCARD]->Write end, speed: 7063 KB/s ( 33 554 432 (32.00 MB) in 4639 ms)
17/10/13 16:11:27->[EXT MEM: SDCARD]->Read end, speed: 7813 KB/s ( 33 554 432 (32.00 MB) in 4194 ms)

Сообщение отредактировал Hold - Oct 13 2017, 09:22

[Ruslan1]

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

Думаете что-то сэкономить, взяв маленькую, но быструю SD-карточку? И не надейтесь. Сейчас уже не могу по нормальной цене найти Сандиск 10-й класс 8GB, только 16GB. Хотя еще прошлой зимой весь ебей был ими завален, но зато тогда уже закончились 4GB.
Так что или нужно оптимизироваться под низкоскоростные, либо не думать об объеме.

Кстати, у меня из нескольких сотен SD карточек (Сандиск), после агрессивной нон-стоп работы в течении нескольких лет уже штук 8 стали в странную позу (не битые сектора, а что-то в электронике- работают только первые пару секунд и отваливаются). Вот думаю, может потому что 10-й класс и нужно что-то низкоскоростное и более дубовое брать... Проблема в том, что пока удостоверюсь в их надежности (через годик-два), их уже перестанут выпускать.

[Hold]

У меня интерес по поводу скорости был скорее академический, да и скорости мне такие не нужны. Флешка нужна лишь в качестве логгера, объемы данных смешные, запись редкая. Отлаживал драйвер SDIO (DMA + выравнивание и прочие грабли), прикручивал к FatFs, решил глянуть а сколько вообще скорости можно достить (мало ли, вдруг задача будет).

[Ruslan1]

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

Проблема эту достигнутую скорость удержать.
Попробуйте повторить опыт в наиболее плохом режиме, возможном во время эксплуатации (кластер не меняется, меняется только содержимое карточки):
1) карточка почти полностью забита- то есть нужно дописывать в последние, например, 10% карточки
2) файлы сильно сегментированы и FAT целиком не вмещается в буфер RAM
3) файл "засунут" в глубину структуры папок, а не в лежит в корне диска.

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

[mantech]

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

Жесть какая-то

[jcxz]

В общем случае помогает укорочение цепочки в FAT (использование длинного кластера), нахождение файла в начале карточки (первые кластеры) и несегментированность карточки (кластеры файла следуют друг за другом). Ну и расположение файлов в корневой директории, чтобы цепочка поиска была короче.

У автора, судя из письма, имеется SDRAM. Простое и очевидное решение в этом случае - кеширование по чтению. Тогда описанные Вами проблемы минимизируются.
Кеширование на уровне ниже FatFS.

[Огурцов]

Дак ведь в настройках фатфса все прекрасно правиться

предполагается, что чен чем-то думал
а вообще, соглашусь - стоит просто проверить


Сообщение отредактировал Огурцов - Oct 13 2017, 17:19

[Hold]

У автора, судя из письма, имеется SDRAM. Простое и очевидное решение в этом случае - кеширование по чтению. Тогда описанные Вами проблемы минимизируются.
Кеширование на уровне ниже FatFS.

SDRAM не бесконечна, 64 Мбайта на всё. Там и так крутится кэш(зеркало на чтение) AT45DB641 и нескольких FM25V10, память GUI, куча lwIP и виртуальный диск в FatFs (помимо карточки). Как именно логичнее сделать кэш на чтение с карточки? В случае с небольшой AT45, достаточно хранить полную копию, для максимально быстрого чтения, а вот с задачей кэширования карточки не сталкивался.

[Ruslan1]

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

Минимум- это копия таблицы FAT. Оптимум- еще и кэш читаемого кластера целиком (а не сектора).
Ну и следующий шаг, что еще кэшировать- зависит от задачи.

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

Кстати, для AT45 я просто кэшировал в его же второй внутренний буфер RAM, там их два, и использовал их по очереди. Это уже сильно ускоряло процесс доступа.

[jcxz]

Как именно логичнее сделать кэш на чтение с карточки?

Стандартно: если при чтении сектор есть в кеше - обновляем его время последнего доступа; если нет (кеш-промах) - читаем с карты и копируем в кеш, присваивая текущее время; при записи также копируем в кеш, обновляя время. При копировании в кеш, если в нём нет свободных мест, удаляем из кеша наиболее старый сектор.
Пары мегабайт думаю вполне хватит (по минимуму).

Кстати, для AT45 я просто кэшировал в его же второй внутренний буфер RAM, там их два, и использовал их по очереди. Это уже сильно ускоряло процесс доступа.

Это не кеширование, это стандартный метод доступа к AT45, предусмотренный её интерфейсом.

[Hold]

На будущее запомню, однако не думаю что сейчас с наскоку решу эту задачку, надо лезть в дебри FatFs, не на один день вдумчивого ковыряния библиотеки. В случае с AT45 я читаю её лишь при включении, всё дальнейшее чтение идёт с кэша в SDRAM, там несложно. Хотя она и так относительно быстро читается, порядка 4 МБ/с при 45мгц клока.

[mantech]

Там и так крутится кэш(зеркало на чтение) AT45DB641 и нескольких FM25V10,

Если не секрет, зачем эти все ПЗУшки, если есть СД-карта???

[sadat]

Если не секрет, зачем эти все ПЗУшки, если есть СД-карта???

У ФМ-ки почти бесконечное количество циклов записи...

[mantech]

У ФМ-ки почти бесконечное количество циклов записи...

А AT45DB641??
Если уж такое дело, то у СД-рама еще больше, если устойство батарейное или есть возможность подключить к ИБП - то никаких доп. ПЗУшек не надо вообще.

[Огурцов]

Если не секрет, зачем эти все ПЗУшки, если есть СД-карта???

в нашем деле самое главное - контакт

[mantech]

в нашем деле самое главное - контакт

Хотите сказать, что нельзя поставить надежный холдер?? Или в устройстве вообще нет ни одного разъема? По-моему - бред

[Hold]

На FM25V10 в количестве 4х штук лежит критически важная инфа. Ее повреждение, либо ошибка, равносильно полной неработоспособности аппарата. Ресурс дичайший, если постоянно по кругу писать на максимальной скорости, то порядка 20 или 40 лет(не вспомню сейчас). Питание +3.3 зарезервировано ltc3226+lowESR ионистор типа HS230F. На AT45 часть размечена под ежедневные бэкапы всей FRAM памяти, другая часть под различные настройки, третья под образ текущей прошивки и заводской прошивки, гарантировано рабочей. Оставщаяся часть диск FatFs, который доступен через FTP, на нем лежат последние логи, которые пишутся по кругу, по своей сути -черный ящик, на случай отказа. На SD карту пишутся теже самые логи, с нее возможно обновление ПО( а также по сети со странички, либо через FTP), лежат тяжеловесные файлы. Если карта накроетмя, то логов на AT45 хватит на 2-3 суток, за это время сервис мен успеет поменять карту. Если не успевает, то логи пишутся в виртуалтный диск в SDRAM в 32 мбайта. Может показаться избыточно, поначалу всё было куда проще и понятнее.

[mantech]

На FM25V10 в количестве 4х штук лежит критически важная инфа. Ее повреждение, либо ошибка, равносильно полной неработоспособности аппарата.
На AT45 часть размечена под ежедневные бэкапы всей FRAM памяти, другая часть под различные настройки, третья под образ текущей прошивки и заводской прошивки, гарантировано рабочей.
На SD карту пишутся теже самые логи, с нее возможно обновление ПО( а также по сети со странички, либо через FTP), лежат тяжеловесные файлы.
Если не успевает, то логи пишутся в виртуалтный диск в SDRAM в 32 мбайта. Может показаться избыточно, поначалу всё было куда проще и понятнее.

Избыточно?? Это мягко сказано, практически четверное резервирование, это разве, что в космос или в "черный ящик" устанавливать. Только какой резерв, что программа не глюканет - неизвестно...

ЗЫ. Основной лог - на Ф-раме, резервный и с доступом из вне - на СД-карте, буфер в СДРАМ, думаю, этого больше, чем нужно.

Сообщение отредактировал mantech - Oct 16 2017, 18:24

[Hold]

Лог на sdram особо не в счет - питания нет 3 секунды, ионистор отрубаетмя, и лога тоже нет. А так вполне себе мажоритирование 2 из 3. Бывает и 4 из 5). На фраме не лог, а основная инфа, а логи-все действия извне, чтобы в случае отказа повторить/смоделировать ситуацию и внести правки. Потерять их очень нежелательно. Программа, конечно, может глюкпнуть, вон ракеты падают. Дтскутировать о методах оценки надежности ПО можно долго.

Сообщение отредактировал Hold - Oct 16 2017, 18:42

[mantech]

Лог на sdram особо не в счет - питания нет 3 секунды, ионистор отрубаетмя, и лога тоже нет. А так вполне себе мажоритирование 2 из 3. Бывает и 4 из 5). На фраме не лог, а основная инфа,

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

Из своего опыта - сделана куча автоматов с логом на единственную СД-карту - из сотни один, макс. 2 отказа и то, по причине банальной жадности, рекомендовали ставить "кингстон", а клиенты решили сэкономить и поставили "смартбай" или еще что-то.
В охранках дублирование на 24хх серии i2c епромах - ни одного отказа, даже на г..но картах.

[Огурцов]

Хотите сказать, что нельзя поставить надежный холдер??

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


Сообщение отредактировал Огурцов - Oct 16 2017, 20:40

[Hold]

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

Из своего опыта - сделана куча автоматов с логом на единственную СД-карту - из сотни один, макс. 2 отказа и то, по причине банальной жадности, рекомендовали ставить "кингстон", а клиенты решили сэкономить и поставили "смартбай" или еще что-то.
В охранках дублирование на 24хх серии i2c епромах - ни одного отказа, даже на г..но картах.

Основная инфа - данные, которые создаются в процессе работы, проходят сквозь аппарат. За день может пройти до 3-4 Гб. Флеш бы может выдержал какое-то время, но рано или поздно начнутся ошибки.

[mantech]

За день может пройти до 3-4 Гб. Флеш бы может выдержал какое-то время, но рано или поздно начнутся ошибки.

И все эти гигабайты каждый день должны скидываться на сд-карту, или только какой-то маленький "кусочек"??
Если первое - тут уж что-то надо на подобии SSD диска подключать..

[jcxz]

Основная инфа - данные, которые создаются в процессе работы, проходят сквозь аппарат. За день может пройти до 3-4 Гб. Флеш бы может выдержал какое-то время, но рано или поздно начнутся ошибки.

А какова природа этих данных? Что это? Для чего нужно столько гиг? Просто интересно....
И если действительно нужно по несколько гиг в день, то может реально лучше использовать SSD или HDD?

[Hold]

А какова природа этих данных? Что это? Для чего нужно столько гиг? Просто интересно....
И если действительно нужно по несколько гиг в день, то может реально лучше использовать SSD или HDD?

Фрам всего 512К, однако обновляться они могут по сотне и более раз на дню. На карту эти данные ВООБЩЕ не скидываются, только логи внешних воздействий.
Чтобы представить аналогию:
Загоняете машину в сервис. В лог пишется заказ-наряд - Иванов И.И. такого то числа, в такое то время загнал свой пепелац, с жалобами, что в машине что-то стучит, назад не едет, и не включается радио Радонеж. Мастер приемщий такой-то и прочая сопуствующая инфа, типа погода нелетная, слоны идут на север.
Передают машину сервис-менам, и они уже детально пишут во FRAM - заменя ремня ГРМ, роликов натяжителя, регулировки такие-то, замена радиоприемника и еще сотня другая различных технчиеских штук, которые полностью и детально описывают что делают и происходит, включая видео-запись всего процесса ремонта, хотя самому Иванову на это пофиг, ему важно знать когда забрать и сколько заплатить.
А теперь представим что таких Ивановых в день приходит пара тысяч, вместимость автосервиса(FRAM) десять тысяч и не все Ивановы сразу забирают авто, а некоторые так вообще забывают, и висят они во FRAM мертвым грузом, пока эвакуатор не увезет на штрафстоянку.
Затем в сервисе отключается свет, ИБП отрубается, и когда включается, оказывается что не все менеджеры успели сохранить открытый заказ наряд(лог), сервисмены сделали часть работ, но не успели внести изменения в сервис-лист(FRAM).
Под вечер приходит Иванов, забирать своё авто, а ему не могут внятно сказать что сделали, что не успели, и где вообще его авто, т.к. не успела сохраниться позиция рабочей станции. Иванов грустит, затем злится, и звонит руководителю, а тот нам, мол почему такая херня.
Иванову#2 повезло больше, свет не отрубался, менеджеры выставили счет, на основе реально проведенного списка работ (FRAM), закрыли заказ наряд (лог), однако тот отчего-то топчет ножкой и возмущается "чойтадорога". Ему на фирменном бланке с печатями и подписями выкладывают детальную секундно/поминутную отчетность по работам(FRAM), видео на котором чумазые работяги снимали колесо вместо 1 часа все 4, т.к. Иванов#2 не дал секретку. Иванов не верит, просит показать видео с другой камеры, и показания свидетелей (резервная копия FRAM). И такую информацию ему предоставляют. Иванов возмущается, но платит, т.к. против фактов не попрешь.
В какой-то момент менеджеры начинают думать - а давайте сделаем историю обслуживания каждого авто (вспоминаем про проходимость в количественных значениях). Директор, пожимая плечами говорит - а чего нет, вон вам комната(СД карта), делайте картотеку. Менеджеры радостно начинают таскать туда всю инфу об авто (вспоминаем про максимальную детализацию, включая видео). Приходится нанимать еще столько же менеджеров просто на доставку всей кипы бумаг, да и комната стремительно заполняется. Когда комната заполняется, приходится всю старую инфу просто выкидывать. Директор говорит - нафиг такое счастье, вся станция только и делает что таскает бумаги, храните только текущую инфу с рабочей станции, а при поступлении нового авто затирайте поверх.
В это время ген-дир всей сети, попивая кофеек на карибах, решает глянуть, как там дела в одном из его отделений. Заходит на страничку (FTP/HTTP), смотрит краткую инфу(логи), т.к. он не отличит карбюратор от кардана и дальше довольно нежится на лазурном бережке.
P.S. Прошу прощения за стиль, у дочки день рожденья)

[sadat]

Фрам всего 512К, однако обновляться они могут по сотне и более раз на дню. На карту эти данные ВООБЩЕ не скидываются, только логи внешних воздействий.
****

Чем мне нравятся мозги программистов - тем, что могут использовать аллегорию применимо к текущему процессу.

[jcxz]

В это время ген-дир всей сети, попивая кофеек на карибах, решает глянуть, как там дела в одном из его отделений. Заходит на страничку (FTP/HTTP), смотрит краткую инфу(логи), т.к. он не отличит карбюратор от кардана и дальше довольно нежится на лазурном бережке.

Всё описанное - это функции компа (сервера) этой СТО. И решается очень просто. Причём тут ваше устройство? Или вы такой сервер пытаетесь на STM32 реализовать? Но зачем???

[Огурцов]

Фрам всего 512К, однако обновляться они могут по сотне и более раз на дню. На карту эти данные ВООБЩЕ не скидываются, только логи внешних воздействий.

вы должны записывать всё, что есть данные
после утверждения документов заказчиком, да, некоторые данные можно удалить
но лучше перевести в weak, чтобы удалить не сразу, но при недостатке места в порядке очереди

Сообщение отредактировал Огурцов - Oct 17 2017, 18:56

[Hold]

Всё описанное - это функции компа (сервера) этой СТО. И решается очень просто. Причём тут ваше устройство? Или вы такой сервер пытаетесь на STM32 реализовать? Но зачем???

Не воспринимайте всё буквально) просто есть кучка важных данных, которые надо хранить, возможно несколько месяцев, но в некоторых случаях они могут часто перезаписываться вновь поступаемыми данными. Что бы вы выбрали в качестве энергонезависимого надежного носителя для часто обновляемых данных? Фрамка подходит как нельзя лучше. Вечный ресурс, мгновенная запись на скорости клока, побайтовый доступ.

[jcxz]

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

Для всего описанного Вами выше (манагеры, отчёты, СТО и т.п.) для чего именно нужна "мгновенная запись на скорости клока" или "побайтовый доступ"?
Для описанных Вами условий задачи я, естественно, выбрал бы HDD (или SSD). По всем параметрам для указанной задачи он подходит в разы лучше чем FRAM, а тем более - чем описанный вами зоопарк из FRAM+FLASH+SD.
Против FRAM ничего не имею. Не раз применял (и применяю) её в своих проектах. Только всему своё место.

[Hold]

Ставить серьезные диски ради 512К (по факту их там около 490к) данных?) Нет никакого зоопарка. На FRAM рабочие данные, на FLASH - резервная копия, на SD - логи. Всё в меру.

[mantech]

Ставить серьезные диски ради 512К (по факту их там около 490к) данных?) Нет никакого зоопарка. На FRAM рабочие данные, на FLASH - резервная копия, на SD - логи. Всё в меру.

Ну тут, как говорят, хозяин-барин, но если уж так, то зачем буферировать-то все это - "SDRAM не бесконечна, 64 Мбайта на всё. Там и так крутится кэш(зеркало на чтение) AT45DB641 и нескольких FM25V10, память GUI, куча lwIP и виртуальный диск в FatFs (помимо карточки)."???

Там и так крутится кэш(зеркало на чтение) AT45DB641 - особенно это, гда по вашим словам - резервная копия, или во т это "виртуальный диск в FatFs ", тоже непонятная шняга
Получается какой-то дисковый маниакализм, аля RAID5 в квадрате

Сообщение отредактировал mantech - Oct 18 2017, 13:17

[Hold]

Кэши(зеркало) удобнее читать чем тянуть байты из AT45. Проц меньше нагружается да и скорость чтения выше. Можно и без них, просто всё будет помедленнее, заметно медленнее. Если sdram позволяет, отчего нет? Хотел сделать кэш еще и на запись, но не стал, хотя тоже ничего сложного. FRAM читается чуть медленнее ( клок максимум 40мгц, spi настроен на 22.5мгц), но там и объемы меньше. Библиотечка из 4х микрух делает единое адресное пространство в 512к, удобно работать. Виртуальный диск это просто область памяти в sdram отформатированной в Fat32 на случай отказа карты памяти, чтобы спасти хотя бы часть логов. Написано много, однако реализация простая и логичная. Диск в sdram делается вообще за 5 минут : объявляется буфер нужного размера в sdram и функции чтения записи, хоть через memcpy.

Сообщение отредактировал Hold - Oct 18 2017, 17:10

[mantech]

Кэши удобнее читать чем тянуть байты из AT45. Проц меньше нагружается да и скорость чтения выше. Виртуальный диск это просто область памяти в sdram отформатированной в Fat32 на случай отказа карты памяти. Написано много, однако реализация простая и логичная. Диск в sdram делается вообще за 5 минут : объявляется буфер нужного размера в sdram и функции чтения записи, хоть через memcpy.

Это я в курсе, что РАМ диск проще простого, у самого такой в системе, но не для копий, а для быстрой загрузки картинок. Я писал про то, зачем делать в памяти буферизацию того, что у вас там в АТ45 й находится, по вашим словам там резервная копия, предполагается, что читаться она должна только в случае нештатной ситуации, а при нормальной работе туда только что-то редко когда записывается, или я что-то не так понимаю в понятии "резервная копия"??

[Hold]

Эти самые резервные копии через фтп верхнее ПО раз в сутки сливает себе. Там же прошивка, которую также можно закачать/ прочитать. В общем чтение присутствует.
Я понимаю ваш скепсис, я и сам, иногда оглядываясь, думаю - зачем так всё усложнять. Я привык рассчитывать на самые фиговые ситуации которые могут произойти. Всё что может отказать, когда нибудь откажет, невероятная ситуация, для которой должно сложиться вместе 100 разных факторов когда-нибудь обязательно произойдет.

Сообщение отредактировал Hold - Oct 18 2017, 17:24

[mantech]

Эти самые резервные копии через фтп верхнее ПО раз в сутки сливает себе. Там же прошивка, которую также можно закачать/ прочитать. В общем чтение присутствует.

"Верхнее ПО" - это ПО для компа? Тогда зачем оно хранится в МК вообще?
Т.е. каждые сутки вы сливаете по фтп прошивки, даже если они не были изменены? Зачем?

Сообщение отредактировал mantech - Oct 18 2017, 17:26

[Hold]

Сливаются копии FRAM а не прошивка. Но да, прошивку тоже можно слить, хотя штатно это не делается, т.к. как вы сказали - смысла нет, она не меняется. Бэкап fram хранится на случай ошибок fram и отсутствия связи с ПО компа, либо глюком ПО компа, чтобы восстановить работоспособность, откатиться на рабочую версию данных. Если ПО есть, то уже при серсисе вручную можно выбрать точку отката.

Сообщение отредактировал Hold - Oct 18 2017, 17:43

[sadat]

"Верхнее ПО" - это ПО для компа? Тогда зачем оно хранится в МК вообще?
Т.е. каждые сутки вы сливаете по фтп прошивки, даже если они не были изменены? Зачем?

mantech, вы неправильно поняли смысл сообщения. Думаю, что под "верхним ПО" - Hold подразумевал серверную часть на компе, которая тащит данные с устройства.
А прошивку просто есть возможность загнать в устройство, ну или проверить файл на флешке на актуальность.

[mantech]

Бэкап fram хранится на случай ошибок fram

И часто такое бывает? По какой причине?

[sadat]

И часто такое бывает? По какой причине?

Я так же юзаю эту же фрам и отвечу: бывает питание пропадает при записи, и, возможно, заряда ионистора не хватит дописать страницу.

[mantech]

Думаю, что под "верхним ПО" - Hold подразумевал серверную часть на компе, которая тащит данные с устройства.

Я все как раз так и понял, просто в моем понимании, ПО для компа должно храниться на компе, а резервная копия на отдельно выделенной флешке или компакт-диске. Кстати там же и резервную копию прошивки устройства нужно держать.

Я так же юзаю эту же фрам и отвечу: бывает питание пропадает при записи, и, возможно, заряда ионистора не хватит дописать страницу.

В случае питания и ионистора - это просчет проектирования устройства. Питания должно хватать при записи максимально возможного блока и еще +25-40% на деградирование ионистора.

[sadat]

В случае питания и ионистора - это просчет проектирования устройства. Питания должно хватать при записи максимально возможного блока и еще +25-40% на деградирование ионистора.

Иногда есть масса-габаритные ограничения, поэтому приходится применять то, что есть и перестраховываться.

[mantech]

Иногда есть масса-габаритные ограничения, поэтому приходится применять то, что есть и перестраховываться.

Лет надцать это наверно имело место быть, но сегодня и ионисторы и литиевые аккумы стали очень маленькие, и китайцы умудряются в спичечный коробок засунуть плату с МК и памятью, экранчик, камеру, динамик и литиевый аккум на 2 часа работы

[Hold]

Питания ионистора хватает на то, чтобы несколько раз перезаписать всю FRAM. У LTC3226 LDO на выходе, поэтому 3.3 держится до последнего. Точно не вспомню, но около 2-3 секунд есть. Плюс, имеет выходы, сигнализирующие о переключении на резерв, и тогда проц штатно завершает все операции и готовится отрубиться.
Верхнее ПО не хранится нигде в устройстве, это действительно бессмысленно. Возможно я несколько двусиысленно написал.
Насчет ошибок FRAM - никто не может дать гарантию, что их не может быть при штатной работе. За все время она была одна и бэкап спас. Причину её возникновения выяснить не удалось. Просто один битик записался не так и crc не сошлась.

Сообщение отредактировал Hold - Oct 18 2017, 18:33

[jcxz]

Эти самые резервные копии через фтп верхнее ПО раз в сутки сливает себе. Там же прошивка, которую также можно закачать/ прочитать. В общем чтение присутствует.

Видимо для этого и нужно держать в кеше в ОЗУ образы AT45. Чтобы (не дай бог!) не вызвать задержку с ответом верхнему ПО в целую миллисекунду(!!!) когда оно, раз в сутки, наконец-то решит обратиться.

Сливаются копии FRAM а не прошивка. Но да, прошивку тоже можно слить, хотя штатно это не делается, т.к. как вы сказали - смысла нет, она не меняется. Бэкап fram хранится на случай ошибок fram и отсутствия связи с ПО компа, либо глюком ПО компа, чтобы восстановить работоспособность, откатиться на рабочую версию данных. Если ПО есть, то уже при серсисе вручную можно выбрать точку отката.

Столько слов о неких мифических глюках в софте и компа и SD-карты и чего там ещё.... А когда эти самые "бэкапы FRAM" Вы у себя в AT45 пишете, то что при этом делается со штатной работой ПО, которое эти данные во FRAM пишет? Атомарность этих данных у Вас конечно поддерживается? И как Вы этого добиваетесь? Приостанавливаете всю работу устройства на время бэкапа FRAM?
А если при модификации любых рабочих данных во FRAM произойдёт сбой питания к примеру? Или сбой питания при записи всех этих бекапов/логов в AT45/SD?

И часто такое бывает? По какой причине?

Наверное каждый раз при взрывах сверхновых в соседней галактике. Вы разве не защищаетесь от этого??

Я так же юзаю эту же фрам и отвечу: бывает питание пропадает при записи, и, возможно, заряда ионистора не хватит дописать страницу.

А причём тут заряд ионистора и "не хватит дописать страницу"? Может всё-таки руки?
А если не выключение питания, а скажем мощная помеха по цепям питания? Или ещё хуже - пачка помех (что очень часто бывает в жизни).

У меня в проекте, где было много сложных и больших объектов данных во FRAM, вообще никакого ионистора или супервизора питания не было.
Записи/модификации этих объектов шли непрерывно каждые несколько десятков/сотен мсек, различными независимыми асинхронными процессами.
Изделие проверялось на воздействие пачек помех и сбоев питания при работе в штатном режиме.
Так вот - никаких разрушений данных не было. Были естественно только случаи, когда что-то не успевало записаться. Но вот чтобы "недописалось" - такого не было.
Потому что систему хранения надо строить с умом, а не городить зоопарк для мифической защиты от мифических космических частиц.

Питания должно хватать при записи максимально возможного блока и еще +25-40% на деградирование ионистора.

Это нужно только если все данные хранить и модифицировать в ОЗУ и скидывать их в энергонезависимую память только при аварии питания.
Если писать в энергонезависимую память при каждом изменении данных, то никаких ионисторов не нужно вообще.

Лет надцать это наверно имело место быть, но сегодня и ионисторы и литиевые аккумы стали очень маленькие, и китайцы умудряются в спичечный коробок засунуть плату с МК и памятью, экранчик, камеру, динамик и литиевый аккум на 2 часа работы

А если у автора его СТО находится где-нить зимой в ХМАО к примеру? И нерадивый слесарь не закрыл ворота? Что будет если на этот "спичечный коробок" дунет ветерком этак под минус 60 по Цельсию? Вот уж точно - ошибка FRAM будет обеспечена

Причину её возникновения выяснить не удалось. Просто один битик записался не так и crc не сошлась.

Причины "ошибок FRAM" как правило: либо баги ПО, управляющего этой самой FRAM; либо помехи по шине из-за плохой разводки.

[Hold]

Не буду особо ничего опровергать, скажу лишь, что подобный "зоопарк" был необходим.

[jcxz]

Не буду особо ничего опровергать, скажу лишь, что подобный "зоопарк" был необходим.

Ну ладно. Но атомарность записи блоков данных во FRAM к примеру обеспечиваете?
Что будет если во время записи такого блока в его середине отключится питание или произойдёт перезапуск МК по помехе?

[Hold]

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

[jcxz]

Атомарность, он же совместный доступ, обеспечивается мьютексами.

Атомарность != совместный доступ.
Атомарность - это непрерывность операции или неделимость данных. В данном случае я имел в виду, что любой записываемый функциональный блок данных на FRAM, должен записываться как единый неделимый объект. Т.е. - если стартовала операция записи объекта то в конце концов будет или записан новый объект или остался старый объект (до записи) и никаких промежуточных состояний (часть нового объекта успела записаться поверх старого, остальная часть - осталась от старого).

может быть, но пока с таким не сталкивался. В любом случае при старте память проверяется.

Т.е. - новые данные у Вас пишутся поверх старых и никакой защиты от внезапного прерывания записи и перезапуска устройства у вас нет?
Если перезапуск случится в момент записи некоего важного объекта данных, то и новый объект будет потерян и старый тоже.
В моих устройствах, где нужно ответственное хранение, я обеспечиваю атомарность модификации объектов (во FRAM/FLASH).
Вы пытаетесь защищаться от каких-то мифических проблем, нагромождая винегрет из разных типов памяти, при этом совершенно не решая очевидную проблему.
Если её корректно решите - больше никакие дублирования и троирования данных не нужны будут.

[mantech]

Т.е. - новые данные у Вас пишутся поверх старых и никакой защиты от внезапного прерывания записи и перезапуска устройства у вас нет?
Если перезапуск случится в момент записи некоего важного объекта данных, то и новый объект будет потерян и старый тоже.

Да там столько дублирований, ну произойдет...Продублируется еще раз и так до победы!

[uriy]

На STM32F407 сделал mass storage in ram. Выделил 64 КБайта. Мне нужно с компа писать файл на этот раздел и его использовать в микроконтроллере. Для чтения файла использую fatfs.
RAM не инициализирую поэтому после каждого включения винда просит отформатировать раздел.
Под Win10 все работает как надо. Форматирую раздел, записываю файл с нужным мне именем, читаю.
Под Win8 не хочет, говорит что файла не существует.
Для отладки добавил вывод содержимого раздела как здесь http://elm-chan.org/fsw/ff/doc/readdir.html
Под win10 все отлично, показывает имена папок и файлов которые я создаю на разделе.
Под win8 не видит ни файлов ни папок созданных на разделе. Файлы туда пишутся, в дебаггере вижу что в этих 64 КБ памяти появляется и имя файла и содержимое.
Что с этим делать?

[Hold]

Признаться да, такой защиты у меня нет, новые данные пишутся поверх старых. Единственный способ отследить ошибку - несоответствие crc. Выделять временный буфер в той же fram, туда писать новые данные, а затем перекидывать в рабочую область? Что помешает контроллеру сброситься в момент перезаписи?
Дублирование только одно - ежедневная копия fram во flash. Никаких других нет. Буду рад конструктивным советам. От внезапного прерывания по питанию спасает ионистор.

[jcxz]

Признаться да, такой защиты у меня нет, новые данные пишутся поверх старых. Единственный способ отследить ошибку - несоответствие crc. Выделять временный буфер в той же fram, туда писать новые данные, а затем перекидывать в рабочую область? Что помешает контроллеру сброситься в момент перезаписи?

Да пускай сбрасывается хоть 1000 раз - всё будет ок.
Атомарная модификация объектов во FRAM/FLASH у меня реализована примерно так:
Во FRAM имеется некая бэкап-область. При необходимости выполнить опасную операцию (перезапись объекта), в бэкап-область заносится полная инфа о планируемой операции (она журналируется): кто, куда, чего и сколько. Также, если операция планируется во flash и требуется модифицировать часть сектора (т.е. - выполнить стирание всего сектора, а потом запись новые данные + старые), то в бэкап-область заносится целевое содержимое всего сектора (новые записываемые данные + старые уже имеющиеся на странице). Потом в бэкап-области ставится флажок, что она содержит данные бэкапа (флаг валидности бэкапа). Далее - производится собственно сама опасная операция. Далее - стирается флаг валидности бэкапа.
Вот и всё - операция становится безопасной, атомарной.
При старте Службы хранения (старт МК), считывается флаг валидности бэкапа и, если он установлен, то выполняется указанная в бэкапе операция и после этого флаг сбрасывается.
МК может перезапуститься сколько угодно раз в любом месте этой процедуры - данные останутся атомарными и валидными.
Естественно область бэкапа должна иметь размер достаточный для хранения максимально возможного объекта хранения во FRAM/FLASH (вся инфа во FRAM/FLASH у меня разбита на независимые объекты хранения) и для хранения одного объекта стирания FLASH (сектор).
Для примера:
Если производится модификация объекта во FRAM, то в бэкап-области появится запись: "начиная с адреса XXXX записываются данные DD,DD,...DD".
Если производится модификация сектора во FLASH, то в бэкап-области появится запись: "производится стирание сектора SSSS, затем запись в него со смещения XXXX данных DD,DD,...DD".
Если производится дозапись (без стирания во FLASH), то в бэкап-области появится запись: "производится запись в сектор SSSS со смещения XXXX данных DD,DD,...DD".

CRC тут никакой почти не надо. Единственное в чём CRC может помочь - обнаружить начальное состояние бэкап-области до первого запуска firmware (мусор во FRAM). После первого запуска состояние бэкап-области однозначно определяется по флагу валидности бэкапа.

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