Надо будет сравнить с SAM7. Описания у них не отличаются.
Впрочем, не припоминаю, чтобы мне приходилось использовать UP_RC с малым значением этого самого RC, а 0.01% мог и не заметить, конечно.

Да я бы тоже не заметил, в других чипах (от AVR до C-M3 разных производителей) никогда не сверял получаемые клоки, так как не использую их для точных измерений.
Только тут, раз уж взялся ковырять модуль и с наскоку заставить заработать как хотелось не удалось, стал проверять всё досконально...

Однако в моём случае ошибка в 2% через всего лишь час дала погрешность, легко заметную на глаз

Процессор, кстати, нормально прожорливый - на 96 МГц кушает почти 60 миллиампер, из периферии включены только TC0-TC2 и PIOA-PIOB.
Если включить всю остальную периферию (без её конфигурирования) - получается красивая циферка 100 ма

Проверил на SAM7: таки да, не доходит до RC, что совсем не вяжется ни с описанием, ни с картинками
Такое ощущение, что таймер сбрасывается по сравнению асинхронно (что можно было бы предположить, глядя на картинку), однако точно известно, что SWTRG таймер без клока не сбрасывает, а на картинке эти источники объединены. Ну и в тексте явно написано, что для любого источника сброс срабатывает на следующем клоке.

UPD:
Поэкспериментировал еще с внешним клоком.
В режиме WAVESEL_UP_AUTO сброс таймера происходит моментально по достижении им значения RC, т.е. первой ассемблерной командой даю последний фронт при CV = RC - 1, следующей считываю CV уже равным 0. Зато при установке дополнительно бита CPCSTOP таймер останавливается со значением CV = RC.
SWTRIG честно срабатывает только на следующем фронте. То есть врут мануалы уже десять лет.

И с I2C, как Вы говорили, проблемы есть, и вроде седьмыми сэмами пользуется прорва народу - почему нет прогресса, интересно?

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

Я вот пользуюсь отчасти по привычке, так как начинал с них тогда, когда никаких контроллеров у NXP, ST и прочих еще в помине не было. И далеко не всегда мой выбор бывает оправдан. Хотя есть огромное количество задач, где все равно какой контроллер поставить.

Начал разбираться с SDIO (MCI) контроллером.

У него есть фичи по предотвращению переполнения внутренних FIFO при чтении\записи, написано, что при заполнении фифо просто отключается клок контроллера.

Но если при чтении это понятно - приостановится обмен с картой памяти, то при записи?
Как вообще может возникнуть переполнение фифо при записи? Если только тупо кидать в него байты процессором, не глядя на флаг готовности?

Что-то не понял этот момент

При записи может возникнуть только underrun, если в FIFO нет данных. Тут мы видим очередной copy-paste.

P.S. Я, если честно, не забивал себе голову столь подробным разбирательством: назначение битов понятно? - устанавливаем и работаем.
На самом деле, вопрос, зачем надо было вообще выносить подобную опцию в конфигурацию - если биты установлены, то возможно снижение производительности при сильно занятой шине; если нет - получим ошибку на ровном месте. И зачем оно надо?

Понятно, тогда устанавливаю их и забываю про это

Дальше вопрос по регистру таймаутов (HSMCI_DTOR) между двумя блоками данных.

Максимальное значение таймаута получается равным (1048576 * 15) тактов мастер клока, который в моём случае равен 96 МГц.
Получается 163 миллисекунды, тогда как по спецификации допускается пауза до 250 мс (при записи).

Что-то не сходится. Может быть, мастер клок имеется ввиду MCCK (уже поделённый клок), а не MCK?

ЗЫ: при инициализации SD карты ширина шины данных устанавливается как один бит.
После инициализации надо бы включить четыре бита.
Можно ли это делать "на лету", при включенном интерфейсе (но при этом никакого обмена данными нет)?

Или необходимо отключать интерфейс битом MCIDIS?

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


Я запрещал, а вот есть ли в этом необходимость - не помню

Понятно, спасибо!

Млин, во всех этих упрощённых спецификациях нет растактовки, бит MAXLAT: Max Latency for Command to Response, наверное, тоже стоит установить в макс. значение - 64 такта?
ЗЫ: ага, вроде нашёл - 5 тактов для ACMD41, в остальных случаях - 64

Перед началом инициализации спецификация требует выдать 74 такта на карту.
Это может обеспечить поле SPCMD регистра HSMCI_CMDR, равное 1.

То есть выдать команду CMD0 с единичкой в SPCMD, получим 74 такта, а затем CMD0?

И CMD2.


Да, только у меня поле команды содержит все "1". Опять-таки не помню, принципиально ли это, или сделано просто для отделение кода инициализации от кодов других команд.

Прикольно, надо бы посмотреть осциллографом, как именно поведёт себя контроллер в этом случае

Я вводил поддержку SD за пару дней в страшной спешке, поэтому многих моментов не помню, к сожалению.
А документацию, думаю, Вы сами успели оценить по достоинству.

За пару дней - это мощно, конечно

В доке мне больше всего не нравятся грубые ошибки типа капи-пэйст где попало и откровенное враньё во многих местах - чего стоят только 9 таймеров
В точной технической документации такого быть не должно.

Ну да ладно, с Вашей помощью дело потихоньку идёт, спасибо!

Как то странно организован регистр статуса HSMCI_SR - многие биты ошибок сбрасываются после чтения этого регистра.
А если я жду завершения операции поллингом другого бита? К примеру, жду завершения мультисекторного чтения поллингом XFRDONE, а в это время может выставиться DCRCE: Data CRC Error, который я тогда благополучно проморгаю...
Мне что, после каждого чтения регистра статуса выдёргивать и сохранять биты ошибок?


В конечном итоге всё будет работать через DMA и прерывания, конечно, но осадочек остался...

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


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