Я два поля упомянул. Чтобы выравнивание работало, надо и саму структуру (структуры) выровнять. И секцию соответственно в скрипье линкера вырповнять.
Я не боролся с выравниванием для DMA, я решал поблемы с DCache.

Детский сад... fatfs в исходниках, ловится и дебажится, я без дебагера полдня возился.

Сообщение отредактировал Genadi Zawidowski - Jul 28 2017, 22:11

Так на 4 я выравниваю, я имел ввиду что если нет барста то не надо на 512 выравнивать.
Вообще, когда-то делал на Ф4 с FatFs R0.11 и драйвром от Nemui Trinomius (http://nemuisan.blog.bai.ne.jp)
Проблем не замечал.
А вот с L4 тут напарник занимается, я сильно не влазил, так он уже неделю ковыряется. То что калокуб нагенерил было вообще сразу снесено, им только проверили что железо работает, потом переделали под драйвер от EVAL - хоть поллинг нормально заработал, а с ДМА пока засада, даже на чтении -пишет блоками до 1023 байта, дальше дикс эррор, если дать блок 8К или 16К, как задумывалось изначально, то эррор сразу (это я все пишу со слов напарника).
Мое личное мнение (проверю на след. неделе), что он не делает, илиделает не правильно, какую-нибудь из проверок.

У меня disk_read выглядел так:



а у него:

Да хоть обвыравнивайся. Раз вы не хотите читать по ссылке, я здесь повторю.
Итак. Пишем в в файл последовательно два раза блок размером 971байт. (Блок выровнен).
При этом будут следующие вызовы:
для первого раза:

для второго раза:

Видите, в четвёртом вызове в функцию disk_write() передан адрес block[53], который, очевидно, не выровнен. (Хотя сам блок выровнен).


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

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

Народ, может просто сделать RTFM?

Отсюда и дальше во ссылке:
http://elm-chan.org/fsw/ff/doc/dread.html

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


А вот не всегда там все будет выровнено. Так будет только если выполняется условие (((UINT)data & 3) == (f_tell(fp) & 3)).

У меня большие объемы пишутся вообще посекторно (с соответствующим выравниванием), маленькие через внутренний буфер FatFs вот собственно и все. Ничего править в FatFs надобности нет.

Включишь кэш данных процессора - появится.

Обмен с картой идет из буфера. Она же не умеет (HS, XS) частями сектора переписывать... понял, о чем ты... Все буферы что я отдаю f_write и f_read, тоже выровнены. Во избежание...

Ну давайте, сделаем RTFM Открываем ссылку: disk_write(), читаем:

Ещё вопросы есть?

Давайте ещё раз на пальцах объясню, как получается невыровненный адрес.

1. Пишем 511 байт. Они записываются в файловый буфер, буфер записывается в сектор.
2. Пишем 10К (неважно сколько, просто больше 513 байтов).
2.1 FatFs дописывает 1 байт в файловый буфер, скидывает его в сектор;
2.2 FatFs видит, что следующий сектор записывается целиком, и пишет его напрямую, минуя файловый буфер. В качестве адреса в функцию записи сектора передаётся указатель на второй байт массива в 10К (потому что первый байт ушёл в предыдущий сектор).
Ч. Т. Д.

ЗЫ. Версия, на которой я это проверял - 0.09b. Возможно, с тех пор что-то поменялось, буду рад это узнать.

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


У меня вопросов и не было, и если Вы внимательно прочитаете мое сообщение, то я не возражал, что в общем случае доступ может быть невыровненный. Однако там же описано, что сделать, чтобы он всегда был выровненный. Про это я тоже написал в том же сообщении.

Вы в Вашем примере пишите как попало, отсюда и невыровненный доступ. Никакого откровения здесь нет - все есть в мануале на FatFS, почему я и посоветовал сделать RTFM.

Джентельмены, мы пишем стрим строго по 8К или 16К блоками, так что проблемы с выравниваниями думаю нет.
А вот остальное - может кто что сказать по поводу того, что я постил выше?

Первым пунктом там идёт:

На что, собственно, я и напираю уже который пост. И это наиболее универсальное решение.

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


Прошу прощения, что увёл тему несколько в сторону. Но вопрос, я считаю, важный.

Для текстовых логов писать их кусками менее 512байт каждый. Как правило оно само собой так и получается. По крайней мере я не могу припомнить, чтобы в текстовый лог я писал за раз более 0.5К...

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

В общем случае, если хочется ни о чем не париться, то функции обмена с картой должны уметь работать с невыровненными данными. Как вариант написать "надстройки" над функциями чтения/записи, которые будут дробить вызовы записи/чтения фатфс, чтобы фрагменты были менее 512байт, и использовать эти функции там, где может быть проблема с невыровненными данными. Хотя проще в случае невыровненных данных обработать ситуацию прямо в disk_read/disk_write.


В disk_read/disk_write в случае невыровненного адреса данных переписываем данные во временный буфер (выровненный, на 512байт) и пишем посекторно из него (при чтении делаем также - читаем в буфер, копируем в память). Это так сказать по методу "чайника" подход Более правильно конечно разобраться с ДМА и, если он умеет работать с невыровненными адресами, просто правильно "приготовить" его (но у меня никогда такой надобности не возникало, потому здесь ничего не подскажу).


Могу сказать одно, чем неделю (!) переделывать чужой код лучше написать свое строго по мануалу. Вы ведь не знаете какие грабли припрятаны в чужом коде?

Сообщение отредактировал Шаманъ - Jul 30 2017, 08:46

Вот, вот оно! Я ведь как раз и советую настроить DMA на доступ по байтам, и тогда всё работает как часы! Собственно, с чего я и влез в эту тему: вы спросили, зачем у Геннадия доступ к памяти побайтный, и я привёл пример, когда это может быть важно.

Кстати, я проводил замеры скорости, и у меня побайтный оказался даже немного быстрее, чем доступ по 32 бита.

Так меня смутило что в одну сторону побайтно, а в другую пословно. Если бы в обоих случаях было побайтно, то было бы простое объяснение.


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

Сообщение отредактировал Шаманъ - Jul 30 2017, 09:25

Теперь понятно .


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

Ну и универсальность. В таком виде мой драйвер FatFs я могу смело включать в любой проект, не вспоминая про выравнивание.

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