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

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

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


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

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

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

Спасибо.

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

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

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

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

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

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

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

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

Порядок действий при отладке такой:
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 проходятся заново

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

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

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

Если подозреваете что дело именно в этом - попробуйте отформатировать карту заново и с большим размером кластера и положить туда потом эти файлы.
И вроде там у Чана был кеш 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 от Чана - полагаю, что кто-то с этим уже сталкивался, решал и что-то может подсказать.


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

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

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

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


Угадал. У Вас 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

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

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

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

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

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

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

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

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

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