Тут некоторая путаница в понятиях получается. Чисто гипотетически предположим, что хост считывает 16 байт, а на деле карта возвращает 8.
В этом случае будут нормально приняты старт, первые 8 байт, а вместо остальных будут приняты 0xff, что повлечет ошибку CRC.
Понятно, что хост не знает, сколько на самом деле было передано картой.


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

Эмм... дошёл до конфигурирования DMA применительно к HSMCI.
Поставил в тупик регистр DMAC_CFGx, конкретно - его поля DST_PER и SRC_PER.
Где искать эти идентификаторы?

Как понимаю, нужны ID для HSMCI и для MEMORY.
Нашёл только табличку с ID на 43 странице мануала, но это по ходу не то ...

А, все, нашел, в другом разделе было

И имеет ли смысл что-то записывать в поле AHB_PROT? Так и не понял, для чего оно и чем отличаются его значения.

Табличка есть на странице 28 (7.6 DMA Controller).


Ну, как минимум младший бит должен стоять, как я понимаю.

Спасибо! Усиленно искал таблицу в разделе DMAC, к которому она и относится, а они ее почему-то засунули в общий DMA...

Поэкспериментирую с различными по ширине режимами доступа (WORD/BYTE), может, получится что нибудь интересное

В мануале в примерах программирования DMA под HSMCI присутствуют поля регистров DMAC, такие, как:



которые отсутствуют в описании самих регистров.
Очередной copy\paste, на который стоит забить?

Ага. Просто у некоторых атмелов есть DMAC с двумя AHB-интерфейсами. Эти поля относятся к нему.

Попробовал запрограммировать DMAC на чтение из HSMCI 512 байтового сектора с доступом BYTE для записи в не выравненный буфер:

Ничего не получилось
В память записалась 1/4 часть данных (128 байт, вместо 512), всё вперемешку, флаги окончания передачи DMA не выставились.
Видимо, читать из фифо побайтно оно не может, хватает сразу слово и получается мешанина...

Получилось так:

Целостность данных в порядке, всё ровненько, флаги окончания установлены

По поводу мультисекторной записи - в примерах в мануале обрабатываются три флага готовности: окончание обработки цепочки буферов DMA CBTC, проверка FIFO на пусто FIFOEMPTY и XFRDONE.
Думается, про фифо это совершенно лишнее?
Зачем ждать его опустошения, когда есть флаг XFRDONE?

Мутный момент. Я смотрю DMADONE при чтении и BLKE при записи.

XFRDONE относится к командам, а не к данным.

Разве к командам?
Это комплексный флаг, который сбрасывается при подаче команды и устанавливается только после того, как все данные прошли и выставился NOTBUSY.
Если верить мануалу

Хм, и правда. Возможно, с ним какая-то засада, раз уж пришлось изворачиваться с DMADONE/BLKE. Не помню уже

Односекторное чтение у меня работает вроде без проблем с XFRDONE.

А BLKE/DMADONE, устанавливаются после каждого сектора?

Имхо, будет оптимальнее дергать проц по CBTC, когда не один сектор, а сразу цепочка обработалась, а на финише уже подождать XFRDONE.
Попробую...

Я и работаю только с одним сектором.


Попробуйте. Только нужно еще учитывать, что внутри цепочки могут возникнуть ошибки. С одиночной передачей несколько удобнее.
Посмотрел, как организована передача у меня: после инициализации ждем CBTC или тайм-аут данных (DTOE) + есть еще программный тайм-аут. После CBTC разрешаются DMADONE/BLKE.

Вроде доделал драйвер HSMCI для FatFS.

Надо же, не все карточки MicroSD спецификации 2.0 поддерживают High Speed режим!
SanDisk 1GB в ответ на CMD6 вернула как поддерживаемую только default function для группы 1!
Function 1 (HS) не поддерживается...

Скорости получились такие, при чтении\записи блоков по 64 сектора, Kingston SDHC 4GB Class 4:
Чтение: 18 MB/Sec, запись: 8,5 MB/Sec.

При этом кардридер с этой же карточкой показал более высокий результат:
Чтение: 19,6 MB/Sec, запись: 11,3 MB/Sec.

Если по чтению практически одинаково, то вот с записью большое отставание.
Возможно, ридер работает с блоками секторов гораздо большего размера, или используется какая-то оптимизация, вроде PRE-ERASE?

Ну, не такая уж большая разница (особенно если учесть, что контроллеру вообще затруднительно будет "перепахивать" такие потоки). Возможно, используют большие блоки. С PRE-ERASE в свое время экспериментировал, но сколько-нибудь значимого влияния на скорость записи никогда не наблюдал.