На microSD карту пишется поток данных. Поток непрерывный, буфера RAM нет, карта периодически останавливает обмен на доли секунды.
Интерфейс SDIO 48МГц , на карте FAT32 , библиотека для работы c FAT FATFS.

Вопрос:
Можно ли избавится от задержек в обмене ? Может быть, в современных картах появились какие-то хитрые настройки для этого ? Может быть, есть карты со встроенным буфером RAM ?

Заранее спасибо !

Нет, никак нельзя избавиться. Или организуйте буфер, или используйте менее "интеллектуальный" носитель.

Ну неужели время идёт, а карты работают с задержками как 10 лет назад ? Неужели не появилось ничего нового ?

Наблюдал такое на STM32. Решилось переходом на DMA и буферезированной передачей.

Как раз 10 лет назад задержки были меньше.

Скорость записи может зависеть от того, как карта была отформатирована. Внутри карты действует понятие Allocation Unit (AU) и лучшая скорость записи достигается когда AU записывается один за другим, не пересекая при этом границу AU. Это связано с работой внутренних механизмов выравнивания износа и трансляции номеров блоков, которые в большинстве карт оперируют AU и могут поддерживать лишь небольшое количество одновременно "открытых" AU.
При этом с точки зрения FatFS, чем больше кластер - тем меньше накладных расходов на запись FAT и т.п. Т.е. выше скорость.

По части форматирования, см. статью. Есть и аналогичные статьи, которые можно найти по ключевым словам "sd card formatting for optimal performance".

Можно. https://geektimes.ru/post/274416/

Средняя скорость - да, может зависеть. Но задержки никуда не исчезнут.

UPD. Посмотрел сслылку - это просто цирк: автор измеряет скорости работы кэша, и делает при этом выводы о размерах блока стирания и страниц карты.


Да ну, "увидеть и оценить" == "избавиться"?

В смысле как блондинка, если чего не знаю, то вероятность 50 на 50?

На одной карте одни задержки, на другой - другие. В чем ценность "знания"?

Знание в том, что точно есть карты без задержек.

А выравнивание износа они когда должны делать, если идет непрерывный поток? И запись на изношенные или свежие блоки явно не одно и то же время занимает

Задержки видел по 500мс и больше.
За 10 лет карты сильнейшим образом подешевели.
Вроде, MMC-карты в плане потоков выглядят лучше, но не по цене.

Кста, карты со временем начинают "тупить" даже если работает только на чтение.
Если найдете "крутую" карту с "ровными" характеристиками ожидания, то дайте знать.
Могу поделиться некоторой статистикой, если надо.


Доля обмена между картой и SDIO ничтожна по сравнению с ожиданием данных от карты.
При "ожидании данных в 500мс" будет обмен между картой за 0.5мс или за 2мс уже не так важно.


Где можно взять такие карты? Производитель? Модель карты?

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


Ну конечно. Это изначально стёртые карты


Перед записью блок данных флешь должен быть стёрт. Это физическое свойство флешь. Как бы карта ни была отформатирована, какова бы ни была свежесть блока, но, если он не стёрт, перед записью его надо стереть. А для флешь это самая затратная операция. И никуда от неё не деться.
Ну или заранее, при проектировании, включить голову, посчитать требуемую скорость потока, посчитать задержки стирания и заложить флешку требуемой скорости стирания. Если скорости не хватает - можно заложить две флешки и тем самым или: повысить скорость записи или снизить задержки стирания при том же объёме буфера (пока стирается блок на одной флешке, пишется другая, потом меняются).
Да и файловую систему для такой потоковой записи лучше не использовать.


Это возможно только если их производитель встроил какой-то буфер в саму карту. Что маловероятно.
Автору надо подумать насчёт добавления в устройство буферной памяти необходимого размера. Внешней.

Не могу согласиться, т.к. структура карты оптимизируется для эффективной работы ФС. Т.е. начало карты (область служебных данных) может быть разбито на мелкие блоки, а дальше разбивка может идти на блоки большего размера (область данных). Кроме того размещение блоков ФС на диске (выравнивание) непосредственно влияет на эффективность работы логики выравнивания износа, что неизбежно сказывается на общей скорости записи. Представьте, как карта может записать 32К, которые пересекают границу соседних 4М блоков?

И что из того? Эти самые большие блоки она будет стирать или нет?
ТСу важна не средняя скорость записи, а максимально возможные задержки. Именно от них зависит требуемая глубина буферизации, которая у него отсутствует почему-то.

Понятно, что стирать она будет, т.к. для записи это делать придется. А вот когда она это будет делать и сколько она будет после стирания перемещать данных и есть вопрос, определяющий задержки и среднюю скорость записи. Я имею в виду то, что для запись новых данных идёт в рамках открытого блока в новый ("стёртый" или "свободный") блок. При этом изменение места записи приводит к закрытию текущего блока и результирующему переносу неперезаписанных данных из оригинального блока в частично записанный новый. В идеале, если новый блок был полностью перезаписан, то переносить ничего не нужно, а достаточно закрыть блок, стереть его старую копию и работать дальше. При этом, теоретически, операцию стирания можно было бы запустить в параллель в остальными процессами.



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

У SD-карт набор команд не теоретический, а практический. Не видел такой команды в SD-спецификации, которая позволяет запустить стирание некоего блока параллельно со стиранием/записью других.
(Если Вы таковую знаете - назовите её).
И вообще - где все эти операции перемещения/перераспределения/...? В SD-карте? Вы уверены? Где блоки разного размера и выравнивание износа? Вы не путаете с какими-то другими типами flash-памяти?
Из спецификации SD:

Вот и всё. Пишет - блоками, стирает - секторами. Сектор состоит из SECTOR_SIZE блоков. Эти значения заданы константами в CSD и для каждого там только одна константа.
Правда есть поле ERASE_BLK_EN - разрешение стирания блоков. Но это также относится ко всем блокам карты, а не к некоторым, расположенным в начале или конце. Т.е. - сектора и блоки по всему объёму SD-карты одинаковы по времени стирания/записи (при одинаковом износе конечно).
И в спецификации SD я не видел нигде упоминания про какие-то операции по выравниванию износа, выполняемые картой. Какие блоки сказали ей писать, она те и пишет, сама ничего не перемещая.
Вот возможность наличия RAM-буфера внутри SD-карты для буферизации потока записываемых данных спецификация не исключает. Да и протокол обмена с картой имхо не мешает сделать буферизацию потока записываемых блоков в карте стирая и записывая данные по мере их приёма и накапливания в буфере. Но спецификация и не обещает наличие буфера внутри.

PS: Да полезная вещь для ТС - возможно ему нужно выбирать карты с ERASE_BLK_EN=1 и стирать блоками. Блок меньше и его стирание должно быть быстрее.

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

Число циклов перезаписи современных MLC/TLC NAND Вы знаете, почему же карты живут несколько дольше?
Вот статья 2003 года, отчасти подтверждающая мои слова про наличие механизмов выравнивания износа.

Да я допускаю что внутри там может быть более сложная организация. Я и писал что возможно там есть буферизация потока записываемых блоков (о чём косвенно свидетельствует алгоритм работы команды многоблочной записи).
Но в спецификации это явно не указано! Т.е. - не указано что карта должна это делать. Какой-то конкретный производитель может конечно захотеть и реализовать внутри всё что угодно: и вести статистику использования блоков и даже перемещать самые популярные блоки не только по всему массиву блоков, но и в отдельную память, например FRAM и многое другое.
Но только - зачем ему оно надо? Тратить ресурсы на более сложную разработку, тратить лишние вентили на весь этот механизм, может их лучше потратить на доп. ячейки флешь и сделать бОльшую ёмкость?
Ведь главная цель изготовителя - извлечение прибыли и уменьшение издержек. И если оно не требуется спецификацией, то может кто так и будет делать, то такие карты ТСу ещё найти надо.


И что? Число циклов перезаписи не говорит, что по достижении этого значения, блок сразу откажет. Это минимальное число стираний которое блок должен выдержать, а в реале может в разы больше выдержать.
Вот я сейчас разбираюсь с регенерацией SDRAM. Так вот провожу испытания - выключаю регенерацию и измеряю сколько данные продержатся без регенерации. По даташиту регенерацию надо выполнять не реже чем раз в 64мсек, т.е. хранение данных без регенерации более 64мсек не гарантировано.
А в реале (заполняю всю SDRAM 32МБ псевдослучайными значениями и через заданное время проверяю всю целиком) разрушение данных наблюдаю только после отключения регенерации на 3-4 сек и более.
Если на 1 сек отключить регенерацию, то данные 100%-но сохраняются.

Некоторое время назад выкладывал мини-отчет по производительности записи на SD в непрофильной теме:
http://electronix.ru/forum/index.php?showt...32833&st=31
Краткий вывод - от задержек в десятки и даже сотни мс не избавиться, но при правильной организации структуры памяти можно радикально уменьшить их количество.

Чтобы минимизировать задержки при длительной записи на SD нужно при стирании файлов давать команды trim или erase на карту, в зависимости от того, что она поддерживает. В свежем linux при монтировании можно указать ключом (discard) необходимость использования этих команд. При этом существенно улучшается ситуация с длинными паузами, т.к. карточке не приходится переписывать внутри многократно данные, которые на самом деле уже не используются файловой системой. Это не отменяет необходимости использовать большие блоки для записи (лучше по 16 МБ).

Показалась интересной мысль про то что карта тратит время на стирание.
Стёр всю карту CMD32 CMD33 CMD38
Задержки не уменьшились

Припоминаю, где то ещё была опция автоматического стирания блока перед записью, или что-то вроде того. Подскажите, где это было ?

А время стирания не измерили, было ли оно вообще?


ACMD23. Мне не встречались карты, на которых эта команда давала бы реальное ускорение записи.

многократно тема поднималась тут. Сам сталкивался, имел задержки до 400мс. Буфер конечно решает, но размер впрямую зависит от потока.

Около 2с для карты 8Гб

Можно просто считать карту после стирания и проверить.


Ещё раз: Где в спецификации SD говорится, что карта что-то там внутри себя переписывает????
Дайте ссылку.

Дайте, пожалуйста, ссылку, какую спецификацию Вы имеете в виду. Дело в том, что ранее Вы приводили ссылки на текст Part 1 (Physical Layer Specification) и на мой взгляд совершенно очевидно, что внутренняя структура хранения данных карты лежит за пределами того, что описывается этой спецификацией. Поэтому я и хочу понять, в какой части спецификации SD, по Вашему мнению, задаются методы, алгоритмы и структуры внутренних данных карты.




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



Вы пробовали или только предполагаете работу блоков памяти после заданного числа циклов стирания?
Второй вопрос: поставьте себя на место производителя карт памяти или флешек - исходя из чего Вы будете назначать гарантийный срок?



Прекрасный эксперимент, который говорит лишь о том, что в отдельной точке мирового пространства при имеющихся в ней физических условиях Вы наблюдали описанную картину. В то время как память имеет весьма широкий диапазон рабочих температур и напряжений питания, что означает необходимость обеспечения надёжной работы во всем диапазоне заданных производителем условий. Попробуйте на досуге, проведите эксперимент во всех возможных условиях, а не только на теплом столе. И если при всех этих условиях после отключённой на 1 сек регенерации данных так же 100%-но будут сохраняться, готов буду дальше обсуждать этот вопрос в таком контексте. В противном я не могу считать Ваши слова сколь-либо ценным аргументом.

IlyaSergeev, большое спасибо ! Выравнивание адреса на 0x8000 заметно улучшило дело ! . Но редкие нерегулярные задержки 400мс при использовании FATFS остались.

FATFS написан неэффективно и чуть что лезет писать в FAT, причём пишет совсем понемногу. Поэтому для оптимизации доступа имеет смысл сделать промежуточный слой доступа к носителю (типа кэша), который будет накапливать эти модификации и потом редко записывать единым блоком. И, кстати, стоит обратить внимание на то, как FatFS сконфигурирован. Надеюсь у Вас _FS_TINY == 0 ?

Да. Из описания следует, что _FS_TINY == 1 уменьшает используемый FATFS буфер

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

Вы с логикой дружите??? Я без понятия откуда Вы это взяли.
Ведь это Вы утверждаете наличие неких механизмов внутри SD, поэтому я и спрашиваю - есть документальные подтверждения или это только Ваши домыслы ничем не подкреплённые?


А Вы пробовали? 1000 раз стёрли и на 1001-й раз получили отказ?
И исходя из чего же производитель назначает этот самый гарантийный срок? Вы считаете это как-то связано с числом циклов перезаписи??
Вот специально скачал доку на microSDHC от kingston с: http://www.kingston.com/ru/flash/microsd_cards/sdc4
В ней утверждается:

Т.е. - если следовать Вашей логике и производитель назначает гарантийный срок исходя из числа циклов перезаписи, то берём заявленную скорость передачи 4МБ/сек умножаем её на среднюю продолжительность жизни среднего человека и получаем, что в течение гарантийного срока карта выдержит поистине гигантское число циклов перезаписи (при условии эксплуатации в режиме непрерывной записи)!
Все эти пожизненные и прочие гарантии - всего-лишь маркетинговый ход.


Что именно Вы хотели этим сказать?
Да - условия эксплуатации карт разные и могут меняться. А время жизни (число циклов) задано для наихудшей комбинации этих условий. В реальности же большинство карт эксплуатируются бОльшую часть времени как Вы сказали "на теплом столе". В таких условиях на этом самом "теплом столе" число циклов перезаписи может быть в разы больше минимального, заявленного изготовителем.
Вот именно это я и хотел сказать своей аналогией с SDRAM: 64мсек производителем заданы для наихудших условий эксплуатации, поэтому в моём же случае при комнатной температуре и стабильном питании вдали от крайних значений, получаются на порядки лучшие показатели. И именно поэтому:

Да, что-то вроде, только более специализированной и заточенное под конкретную задачу.



Естественно в курсе, но FAT и так не является отказоустойчивой ФС, по определению. И состояние ФС не гарантируется при отключении питания во время выполнения операции записи. С этой точки зрения мое предложение не ухудшает характеристик получаемого результата.




Я с логикой вполне дружу. Взял я это из Вашего же сообщения в этой теме:


Или Вы этого не писали?



Я давал подтверждения выше по теме. В ответ Вы мне написали, что:


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



Пробовали не с картами памяти, с флешом типа NAND. Требования выравнивания износа при использовании NAND взялись не из воздуха, а из практической необходимости. О чем я Вам и пытаюсь уже несколько раз сказать.



Безусловно. И с механизмами, реализованными в носителях. В противном случае поток рекламаций сведёт на нет всю выручку. А крупные производители умеют считать деньги.

К вопросу о надёжности поинтересуйтесь рекомендациями того же Micron'а относительно eMMC. Пару слайдов прикрепил к этому сообщению.



Ровно то, что и сказал: Ваши слова не аргумент возможно огромного числа циклов перезаписи или огромного запаса надёжности, заложенного производителем "на всякий случай".



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

У ТСа нет ОЗУ даже для буферизации основного потока, не то что ещё и FAT. Ведь в этом-то и вся проблема. Если-б ОЗУ было - проблемы и не было-бы: выкинуть вообще любую файловую систему и писать просто поток блоков на SD через буфер.


Эти "прослойки" есть и на современных компах. Иначе - операции с мелкими файлами на SD становятся оооооочень затратны по времени. Да и на МК при интенсивных модификациях файлов, кеширование очень полезно.
А чтобы не слетали файловые системы - тут разработчик, на этапе проработки идеологии всей системы в целом, должен голову включить и подумать как этого добиться (или супервизиром питания, дающим запас времени после сигнала аварии питания; или дополнительной non-volatile памятью, в которую ПО будет делать журналирование любых критических операций с файловой системой; или ещё какими другими методами).

Если б были ОЗУ в небольших корпусах с каким-то примитивным интерфейсом. А то они все с параллельной шиной, из-за чего у микросхемы и процессора много ног т.е. либо огромные корпуса, либо BGA. Габариты критичны, а BGA дорого

Их есть, например, Serial SRAM and Serial NVSRAM
Но тут перед Вами встанет другая проблема: накладные расходы из-за примитивного интерфейса будут, возможно, больше выигрыша из-за дополнительной памяти. Так что параллельная шина, большие корпуса и т.п. За все нужно платить.

Я тоже такой не знаю, у меня только есть:
1. SD Specifications. Part 1. Physical Layer. Simplified Specification. Version 3.01. May 18, 2010
2. SD Specifications. Part A2. SD Host Controller Simplified Specification. Version 2.00. February 8, 2007
3. SD Specifications. Part E1. SDIO Simplified Specification. Version 2.00. February 8, 2007
И я там не находил ничего, подтверждающего наличие внутри SD механизмов перераспределения износа. Хотя может что и пропустил, так как не изучал от корки до корки.


Требования эти может выполнять например ПО системы, куда подключена SD. Т.е. - прослойка между например FatFS и интерфейсом SDIO/SPI карты. А не контроллер SD-карты, который останется "тупым". Нужно более эффективное использование SD при интенсивных модификациях - вносите соотв. драйвер в ваше firmware. А для подавляющего большинства применений SD-карт это не нужно и не нужно производителям париться добавляя эту мало кому нужную функцию в контроллер SD, тратя на это ресурсы SD-карты.


Да ну!!? А как же тогда работают например флеши программ микроконтроллеров, из которых код может читаться на скоростях около 20-30МГц???
Это что-ж - написали коротенький цикл while () {}, включили, поработала программа несколько суток и адье! - стёрлась!
К деградации ведёт только стирание.

Приведу пример про конкретный чип на основе родственника SDcard - eMMC:





Приведу пример из стандарта 84-A441 на eMMC:



Ну и при вызове Trim:


Вообще ничего волшебного в Trim нет, просто он позволяет посекторно флушить память. Другое дело непонятно, можно ли на MLC вообще не вызывать TRIM, ERASE или ACMD23?

Протестировал тут стирание группы в моей eMMC через CMD35,CMD36,CMD38: при стирании 2/20МБ - то 30мс, то 2 секунды, в не зависимости от длины и наличия данных.

Да, видел их. Они маленькие, всего 128КБайт. А мне, при потоке 1МБайт/с и пропусках 0.5с нужно раз в 5 больше.

Так такие чипы есть. На I2C и на SPI:
а) FRAM (например FM25V20A); есть даже МК с FRAM-памятью (вместо FLASH), например - MSP430FR5739;
б) nonvolatile-SRAM http://www.cypress.com/products/nonvolatil...0-bottom_side-8 (это ОЗУ + FLASH, куда автоматом скидыватся содержимое ОЗУ при аварии питания);
в) и просто ОЗУ есть, только размер вроде небольшой у них.


Вы внимательнее посмотрите на сайте Cypress:
FM25V20A - 256кБ;
CY15B104Q - 512кБ.
И что-то подобное было у других вендоров.

Можно пойти другим путём:
1. Например 4х проводный интерфейс у меня пишет быстрей однопроводного.
2. Взять контроллер с большей внутренней памятью.

Кстати карта имеет право осуществлять запись доли секунды. У моей, согласно даташиту - 250мС. Поэтому я, для надёжности, всегда использую внутренний буфер более чем на четверть секунды.

Хорошо, возможно в каких-то новых картах выравнивание износа есть. Это не противоречит основной спецификации SD.
Только ТСу толку от этого 0. А если эти 2 сек из-за именно выравнивания износа - так только вред один - задержки записи ещё больше могут быть, и как-то ему такие карты отсеивать надо. Или всё устройство переделывать надо, отказавшись от SD или поставив доп. ОЗУ или пересмотрев алгоритм записи.

И тем не менее это так: https://en.m.wikipedia.org/wiki/Flash_memory#Read_disturb

Что теперь скажете?

Из всего этого выбираю проц с достаточным набортным ОЗУ.

Скажу, что несёте чушь и даже не замечаете этого.
Т.е. - Вы как бы не заметили, что там разговор идёт о MLC NAND flash, а не о любой флешь? Возможно для NAND MLC это и так - я не в курсе. Но точно не относится к любой флешь.

Напротив, в контексте этой темы мы говорим о NAND и MLC, как одном из основных ее видов, используемых в картах памяти. Все обсуждаемые проблемы относятся к этому контексту, в т.ч. выравнивание износа и т.п. технологии. При этом Вы периодически прыгаете то на DRAM, то на NOR flash, которая применяется в МК. И, судя по всему, Вам нечего больше сказать по существу вопроса, поэтому я не вижу смысла в дальнейшем обсуждении.

Процев с объёмом набортного ОЗУ достаточным ТСу (128*5 КБ) не такой уж богатый выбор, даже бедный. Но конечно - это самое простое решение.
Мы, для своего устройства, которое тоже пишет поток во Flash (только не SD, а обычные SPI-Flash), в качестве промежуточного буфера выбрали SPI-FRAM. Существенный для нас плюс - её энергонезависимость.
1МБ/сек - это конечно прилично, но думаю при определённых условиях возможно для МК Cortex-M с тактовой >100МГц, хотя тоже не всякого.
Если использовать SPI-FRAM, то они имеют SCLK <= 40МГц. Так как нужен промежуточный буфер, то значит в неё будет идти непрерывно 2-а потока: записи и чтения. Сам чип FRAM успеет прокачать, но должен успеть интерфейс и ПО МК.
Есть ещё такой производитель как https://www.everspin.com/serial-peripheral-interface с его SPI-MRAM памятью. У него тоже есть чипы на 512КБ. И есть чипы с quad-SPI - эти обещают скорость по шине до 52МБ/сек.


Мы говорим о SD-картах вообще. И там может быть любой тип памяти. Даже такой, которого ещё нет, а появится через год-два и карты тогда будут делать в основном на нём.
Это Вы всё время почему-то пытаетесь перевести тему на NAND MLC и говорить о особенностях её работы.
Вчера в SD были SLC, сегодня MLC, а что завтра будет, когда ТС сделает своё устройство, оно будет работать у заказчика и через лет 5 тому потребуется заменить SD-карту? И тут вдруг оказывается, что устройство-то почему-то заточили под особенности работы карт с типом ячеек MLC, которых уже года два как не производят....
Имхо - устройство в своей работе должно основываться только на данных, почерпнутых из CSD, а не домыслах о внутренней кухне контроллера SD.

FRAM по надежности (числу циклов перезаписи) != SRAM (NVSRAM), т.к. судя по документации того же Cypress оно ограничено числами порядка 10E14. Это, конечно, много, но это не бесконечность. Тем более если буфер будет расположен по фиксированному смещению в памяти, а не будет смещаться для выравнивания износа. Будьте внимательны.

К вопросу о надежности NAND есть неплохая статья лаборатории JPL NASA - Disturb Testing in Flash Memories.

Цитата из нее:

Ну попробуйте PIC32MZ1024EFG064-I/MR QFN64 9x9mm 512kB, не знаю, удобно ли под них кодить, но люди выжимают там более 1МБайт/с, хотя про пропуски - неизвестно...


Если бы не ваше требование про отсутствие BGA - я бы поставил 9х9мм 384kB ATSAMS70N20A-CN и поднял бы на нём без пропусков 1.5МБайт/с на своей eMMC, не знаю большой ли для вас LQFP100 14х14мм. Просто HSMCI 4бит - даёт реальный выигрышь перед SPI по задержкам и снижает требования к памяти.