Да перепахивать-то особо будет не нужно, просто "закидывать" на карточку с компа по USB MSC.

Вернее всего рулят большие блоки по 128 секторов в ридере. Хотя при увеличении кол-ва секторов с 32 до 64 получил прирост на запись всего около одного мегабайта в секунду.

А может быть "тормозит" мой драйвер или атмеловский контроллер MCI, а в ридере более оптимальная аппаратная реализация...

ЗЫ: ах да, загрузка процессора при этом составила 4-5% под scmRTOS (96 МГц).

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

В общем, я бы не стал убиваться за пару мегабайт в секунду

Согласен, тем более, пока не знаю, куда копать, вроде нигде нет лишних задержек...

Кстати, всё вроде нормально работает с XFRDONE, единственное, чтобы сигнал не проскакивал раньше времени, пришлось разрешать его прерывание только непосредственно после выдачи команды STOP_TRANSMISSION(CMD12).

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

С наступившим Новым годом всех!
Но работа продолжается.

Да, I2C у этого сэма привередливый, шумы ловит только так
Повесил на пины ёмкости по 150пф, вроде стабильно стало.

И вопрос - можно ли SSC сконфигурировать в режиме I2S мастера так, чтобы контроллер сам формировал все три сигнала - BCLK, WS и DATA?
Что-то не получается пока

Да, SSC можно заставить быть I2S-мастером. Вот пример (он, правда, от SAM7, да неважно):

Спасибо, вроде поехало!

Единственное, не понятно, что творится с пином TD, когда на нём нет данных.
Согласно полю DATDEF в TFMR, на пине должен быть 0.
Но его уровень плавно растёт до примерно половины напряжения питания. Явно работает пуллап.

Но почему, разве пин самопроизвольно переключается на вход? Попробовал сконфигурировать пины TK, TF, TD как выходы - на TF сигнал вообще пропал...

Думается мне, что фича DATDEF в SAM3U не работает.
DATDEF в регистре SSC_TFMR равно нулю (если записать единичку - ничего не поменяется):

Жёлтым - пин TF (WS с частотой 44.1 кГц), а зелёным - TD (данные).
Видно, что TD управляется, только когда на него непосредственно выставляются данные, в остальное время он "плавает" как вход, уровень подтягивается пуллапом...

Насколько я помню, на SAM7 в режиме I2S такая же картина. Но в каких-то других режимах DATDEF все-таки точно работает. Мутна вода, как водится.

Это точно

Всё, достал меня I2C
Я, конечно, понимаю - длинные провода и всё такое - но когда мастер в виде SAM3U4 при малейшем шорохе на стороне сыпет NACKами и ARBLOSTами...
Навешал на шину ёмкостей под 300пф, вроде заработало стабильно, но стоило одновременно с передачей по I2C поработать с картой памяти на 24 мегабита/сек - снова ошибки, причём именно со стороны мастера - NACK, ARBLOST (какой арбитрейшн лост, ты же единственный мастер на шине!) или просто тупой зависон всего модуля с подтянутыми к земле данными и/или клоком, из которого можно выйти только сняв с контроллера питание...

При этом если воткнуть другую карточку, более скоростную - на 48 мегабит/сек - всё снова стабильно.

Снижение скорости до черепашьего уровня никак не влияет на ситуацию.

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


Помнится, с LPC17xx тоже пришлось немного повозиться, но там были NACKи только от привередливого кодека (у которого, видимо, тоже по аналогии с сэмом отсутствовали фильтры на входе), но проблема быстро решилась а мастер работал безо всяких проблем.

Попробую тоже написать работу с I2C девайсами врукопашную, может, будет получше...

ЗЫ: так и хочется уже отказаться от неустойчивого I2C в пользу SPI, но подкупает малое кол-во проводников...

Забейте, батюшка, на I2C - заборете сейчас, так непременно сломается в будущем. Нервы дороже.

Это применительно к I2C вообще, или только к сэму?

Последнее время у меня с I2C частенько выскакивают проблемы, может быть, из-за наличия рядом с проводниками других цепей с частотами в десятки МГц?

Только к сэмам. Скажем, на AVR совершенно замечательный TWI, хотя и называется так же.
А что касается влияния высокочастотных цепей, то это вопрос к трассировке.

Вот ведь позор то какой, на крошке AVR хороший TWI, а на крупных камнях - совсем никакой
На девятых армах, интересно, как с этим дела?

Написал софтовый TWI, правда, пока без поддержки Clock Stretching и без фильтрации, и только в режиме мастера.
Но результат налицо - пока что ни одного глюка, убрал все кондёры с шины, и даже щупы осциллографа не мешают - ни одного чиха!

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