Медленная работа SD карточек — кто виноват и что делать?

Давно думал написать статью на Хабр, но все как-то не решался. Хотя и кажется, что есть мысли, которые были бы небезинтересны сообществу, но останавливает предположение, что это «кажется» проистекает от завышенной самооценки. Тем не менее попробую. Поскольку я профессионально занимаюсь электроникой, в частности, программированием микроконтроллеров, довольно-таки длительное время (как я подозреваю, дольше, чем живет большАя а может даже и бОльшая часть читателей Хабра), то за это время накопилось изрядное количество интересных случаев. Представляю на суд сообщества рассказ об одном из них.

Итак, в одной разработке мне потребовалось сохранять значительные объемы информации с целью последующей передачи через сеть в обрабатывающий центр. Поскольку полученное устройство предполагало серийное производство, был выбран вариант с применением относительно недорогих компонентов, и, в частности, микроконтроллера как центрального элемента системы. Поскольку в тот момент (середина 2012 года) предложение микроконтроллеров с Ethernet PHY на борту не отличалось разнообразием (да и сейчас положение не намного лучше), был выбран МК фирмы TI семейства Stellaris, конкретно LM3S8962, тем более что отладочная плата для него у меня уже имелась. МК на тот момент относительно новый, активно продвигаемый фирмой TI (это в конце 2013 года она ВНЕЗАПНО перевела всю серию в разряд NRND), и обладающий вполне достаточными для решения данной задачи параметрами. Для хранения информациии был выбран вариант с SD карточкой, в первую очередь из за их доступности и дешевизны, а также потому, что на отладочной плате наличествовало контактное устройство для них, а на поставляемом с платой отладки CD имелись многочисленные примеры, в том числе и для SD карт. Интерфейс к карточке был реализован простейший — SPI, предложенные примеры сходу заработали, принятое решение позволяло обрабатывать полученные данные до написания интерфейса при помощи элементарного переноса карточки из устройства в кард-ридер ПК, так что первоначальная отладка алгоритмов взаимодействия с объектом управления проблем не вызвало, по крайней мере в этой части проекта. Как все понимают, проблемы возникли несколько позже…


Когда алторитмы были отлажены и устройство в целом заработало, начались тестовые прогоны. И тут выясняется, что SD карточка не способна записывать информацию в том темпе, в котором объект управления ее поставляет, причем разница скоростей составляет разы, а с учетом размеров единицы хранения (2.7 мегабайта) создать промежуточный буфер по приемлемой цене не удасться. Переходя к конкретным цифрам, требовалось файл размером 2.7 мегабайта записывать на SD карточку не более, чем за 1.6 секунды, а реально данные записывались 30 секунд, причем карточки были приобретены класса 10, то есть утверждали скорость записи 10 мбайт/сек. Борьба за скорость шла в несколько этапов и противниками оказывались то микроконтроллер, то стандартная библиотека (фирменная от TI между прочим), то, собственно, SD карточки.

Первый этап — исследую тайминги записи и сразу же выясняю, что запись различных участков информации идет разное время, причем время записи одинаковых блоков информации существенно (в разы) отличается. Путем экспериментов с различными размерами блоков записи устанавливаю простую закономерность — чем больше блоки информации для записи, тем меньше время записи, отнесенное к ее размеру. Псокольку модули библиотеки поддерживают FAT и записывают информацию посекторно, а переделывать их смысла не вижу, переформатирую карточку на размер сектора 32 кбайт и получаю время записи 14 секунд — 1 очко SD.

Второй этап — проверяю работы SPI интерфейса и обнаруживаю, что он работает на частоте 12.5 мгц, хотя описание позволяет установить частоту передачи до 25 мгц (половина от тактовой частоты процессора 50 мгц). Выясняется, что подпрограмма установки частоты SPI модуля из библиотеки ограничивает максимально возможную частоту значением 12.5 мгц, причем в документации на интерфейсный модуль микроконтроллера подобное ограничение отсутствует.
  i = ROM_SysCtlClockGet() / 2;    if(i > 12500000)    {        i = 12500000;    }

Изменяем код и получаем уменьшение времени записи в 2 раза до 7 секунд — 1 очко TI.

Третий этап — исследую модули обмена с SD карточкой и обнаруживаю весьма непроизводительное расходование времени в низкоуровневых процедурах, а именно: модуль SPI в микроконтроллере имеет в своем составе FIFO буфер на 8 байт, что позволяет ускорить работу с ним. Модуль вывода до передачи очередного байте проверяет флаг «буфер передачи не полон» для ожидания возможности переслать следующий байт, и вроде бы все нормально. Но вслед за передачей байта вызывается модуль приема байта (дело в том, что при передаче в интерфейсе SPI одновременно производится и прием), который должен выбрать из приемного буфера эти ненужные принятые байты. И вот эта процедура опрашивает флаг «буфер приема не пуст», то есть ожидает окончания сериализации последнего байта буфера. То есть ждет, пока не будет полностью передан текущий байт и лишь потом готовит следующий для передачи.
void xmit_spi(BYTE dat) {
   uint32_t ui32RcvDat;
   SSIDataPut(SDC_SSI_BASE, dat); /* Write */
   SSIDataGet(SDC_SSI_BASE, &ui32RcvDat); /* flush data */
}

Исправляю обнаруженую ошибку (а как это еще назвать ?) и получаю время передачи файла 3 секунды — 1 очко TI.
И вот что получилось в результате оптимизации, не учитывающей особенности задачи.
static void xmit_spi_my (BYTE const *dst, int length)
{  int i, *p, *d;
  d=(int*)(SDC_SSI_BASE+SSI_O_DR);
  p=(int*)(SDC_SSI_BASE+SSI_O_SR);
  do {
    while (!(*p & SSI_SR_TNF)) {}
    *d=*dst++;
  } while (--length);
  while (*p & SSI_SR_RNE) i=*d;
}

Четвертый этап — исследую модули более высокого уровня и выясняю что, поскольку передача данных в интерфейс предусмотрена только из памяти, мне приходится проводить двойную работу — сначала читать поток данных из объекта управления и пересылать в оперативную память микроконтроллера (а это, между прочим, 32 килобайта буфера), а потом из памяти в регистры интерфейса SPI. Пишу свой собственный модуль для передачи данных непосредственно из регистра в регистр, и получаю время записи 1.6 секунды. При этом обращение к своему модулю маскирую внутри стандартного вызова, чтобы файловую система понимала, что переданы 32 килобайта — 1 очко TI.

Пятый этап. Поставленная цель уже достигнута, но процесс оптимизации продолжается по инерции. Исследую еще раз сигналы на интерфейсе и обнаруживаю, что на самом деле передается не непрерывная последовательность тактовых импульсов, а 8 бит данных плюс пауза в 2 такта. Ну хорошо, девятый бит нужен для передачи сигнала синхронизации (не путать с тактовым сигналом), причем мне он совершенно не нужен, но десятый то зачем? Эксперименты с различными режимами SPI привели к получению передаваемого сигнала в реальные 8 бит без пропусков и, соответственно, к времени записи 1.3 секунды — 1 очко Stellaris.

Шестой этап. Вроде бы все хорошо, но совершенно неожидано возникает еще 1 проблема — при потоковой записи множества файлов первые 3 укладываются в требуемый интервал и даже с небольшим запасом, а вот четвертый файл показвает время записи намного большее — до 1.8-2.0 секунд и, соответственно, нарушает последовательность. Пробую очевидное решение, предположив что дело в переходах через страницы записи FLASH памяти, и исключаю эти места из обработки. Теперь начинают долго записываться те файлы, которые раньше записывались хорошо. Многочисленные эксперименты приводят к выводу, что поведение FLASH как то связано с ее особенностями внутренней организации. Я полагаю, что внутренний генератор высокого напряжения для записи ( его существование несомненно) не способен удержать требуемый уровень напряжения при длительных операциях и требует определенного времени на восстановление заряда. При этом общая средняя скорость выдерживается, но мне то нужна не средняя скорость, а мгновенная скорость записи каждого файла. Здесь могло бы выручить введение буфера данных для выравнивания нагрузки, но было найдено другое решение — приобретены SD карточки различных фирм и среди них нашлись те, которые давали постоянное время записи в 1.4 секунды без существенных разбросов. Конкретные названия фирм-производителей карточек называть не буду, чтобы не сочли статью рекламной — 1 очко SD.

Итог — задача решена, устройcтва отгружены потребителю и функционируют без сбоев, общий счет по количеству обнаруженных и исправленных проблем: SD карточки — 2, библиотека от TI — 3, особенности микроконтроллера -1. А из всего вышесказанного можно сделать следующий выводы:
1. С особым вниманием следует относится к имеющимся библиотекам стандартных программ с примерами применения. Они, как правило, функционируют и даже иногда без ошибок, но никоим образом НЕ оптимизированы по производительности. Так что смотрим исходные коды (благо они есть) и творчески модифицируем их. Более того, у меня сложилось мнение, что подобные свободно распространяемые бибилиотеки сознательно сделаны неоптимальными, чтобы стимулировать приобретение их платных аналогов.
2. С осторожностью относимся к спецификациям относительно производительности различных устройств, то есть внимательно читаем спецификации, в каких режимах и какие цифры достигнуты, а не просто смотрим 1-2 цифры параметров и решаем, что нас они устроят.
3. Внимательно читаем документацию на модули микроконтроллеров, пытаемся понять их внутреннее устройство, не забываем про осциллограф для изучения реальных процессов на реальной плате.

И в завершение статьи одно маленькое замечание — решил посмотреть, как обстоят дела в реализации аналогичных процедур в новом пакете поддержки микроконтроллеров типа TIVA-C (TivaWare_C_Series-2.0.1.11577). Ну что можно сказать — традиции не нарушены. Абсолютно все те же грабли лежат все в тех же местах, причем добавились еще одни — теперь функциии вызываются не непосредственно из FLASH памяти, а из так называемой ROM библиотеки с использованием двойного индексирования, что быстродействия не прибавляет. Как говорил Михаил Жванецкий «Или мы будет жить хорошо, или мои произведения всегда будут актуальны». Пока что верно второе.
Поделиться публикацией
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама
Комментарии 38
  • +6
    > задача решена, устройcтва отгружены потребителю и функционируют без сбоев

    Потом пользователь решает заменить стандартную карточку на другую и опаньки.
    • +17
      В инструкции по эксплуатации данный момент был прямо отражен — замена на другой тип только после согласования с разработчиком
    • +8
      Могу в какой-то степени поспорить с выводом #1 — «С особым вниманием следует относится к имеющимся библиотекам… Они, как правило, функционируют и даже иногда без ошибок, но никоим образом НЕ оптимизированы по производительности.… Более того, у меня сложилось мнение, что подобные свободно распространяемые бибилиотеки сознательно сделаны неоптимальными, чтобы стимулировать приобретение их платных аналогов»
      Применительно к последнему — они сделаны такими для удобства использования и простоты работы.
      Гораздо проще создать в библиотеке готовые процедуры типа «Записать из памяти в сектора карты...», «Считать с карты в память по адресам...» и им подобные. При этом предполагается, что конечный пользователь уже сам доведёт данный пример до соответствия своим личным нуждам.
      Не спорю, примеры порой изобилуют довольно узкими местами в плане производительности (пример — приличная часть библиотек STM, плюс работа в IDE той же Arduino), но при этом повышается «Юзабилити» для конечного пользователя, хотя в некоторых местах значительно снижается скорость работы.
      Пример:
      Что пользователю проще освоить быстро? Вариант чтения документации к микроконтроллеру и вдумчивого программирования (когда он точно знает, ЧТО хочет получить и каким методом), или первый опыт мигания светодиодом, когда нужно подставить несколько параметров в вызов уже написанной функции, или передать ей же структуру, в которой (относительно) понятными именами полей описаны режимы работы портов, задержки, тактирование и прочее вместо того, чтобы опять же, записать от силы 5-8 значений в регистры.
      Да, библиотеки хороши в начале. В проекте, где требуется производительность и необходимость выжать из кристалла все доступные ресурсы, нужно писать с нуля.

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

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

      Продолжайте в том же духе!
      • +1
        совершенно с Вами согласен.
        Я рассматривал вариант достаточно продвинутого пользователя и реальных задач, для которых и давал рекомендации.
        Для начального ознакомления стандартные бибилиотеки вполне приличны.
        И все таки — почему их не сделать сразу хорошими?
        • +3
          > И все таки — почему их не сделать сразу хорошими?
          В том-то и проблема, что это довольно сложно сделать. Для того, чтобы сделать оптимальную библиотеку, нужно очень много времени. А сейчас продукты штампуют буквально оптом, а библиотеки к ним просто копируют, возможно, немного видоизменяя, где-то немного поправляя. Но при этом библиотека остаётся совместима с большой частью линейки, под которую рассчитывалась даже без изменений. На то она и библиотека.
          Если подгонять каждую функцию под возможности конкретного камня, потребуется немало человеко-часов, за которые опять же, нужно платить.
          При просмотре кода отдельных библиотек порой волосы шевелятся на спине — так они «собраны на коленке». Но при этом свою функцию выполняют.

          А в частности, Ваш пример — это уже оптимизация. К сожалению, она выполнима только под конкретные условия работы.
          Например, поменялся размер доступного буфера — уже нужно пересобирать часть кода. А в библиотеку передаются только какие-то ссылки, значения, размерности. Ну и так далее.
          Подводя итог — это просто очень сложно, да и мало кому нужно, к сожалению.
          • 0
            Наверное, Вы правы, и это очень грустно.
            Даже такая великая фирма, как TI, вовлечена в гонку новых моделей и времени на доводку не остается.
            Как Вы верно заметили, копируют бибилиотеки, не вникая в суть.
            Насчет не нужно — наверное тоже верно — проще повысить частоту МК, чем привести в порядок бииблиотеки.
            Но все таки по поводу части 2 — наверное когда то ограничение скорости было оправданно аппаратурой, но теперь то зачем, если современные SPI такого ограничения не требуют.
            Здесь явно видно бездумное копирование, я бы даже назвал это карго-культом.
            А что касается сложно сделать хорошими — да, конечно, но стремится то надо, а я не вижу такого стремления.
            Более того, в одной бииблиотеке для отечественного МК (кстати, собираюсь про него написать) увидел вообще жуткую вещь — процедура, записывающая информацию в регистр внешнего устройства, то есть 2-3 такта процессора, была обернута в 4 (четыре) вызова функции ( да да именно вызова а не переопределения) и, соответственно, занимала 26 тактов, то есть кпд 10%.
            С печалью я гляжу…
            • 0
              > Насчет не нужно — наверное тоже верно — проще повысить частоту МК, чем привести в порядок бииблиотеки.
              Не столь уж критично. Просто наращивание мощности MCU может и не произойти, т.к. линейка контроллеров уже поступила в продажу и улучшать её не будут.
              Просто подвести библиотеку к какому-то готовому варианту, который бы и остался совместим и при этом был быстрым — это из разряда фантастики.
              > "… то есть 2-3 такта процессора, была обернута в 4 (четыре) вызова функции… "
              К сожалению, и подобное видел, хоть и не столь ярко выраженное. Печально-печально.

              > Но все таки по поводу части 2 — наверное когда то ограничение скорости было оправданно аппаратурой, но теперь то зачем, если современные SPI такого ограничения не требуют.
              Возможно, какой-то костыль? Либо библиотека для работы отладочной платы? Тут даже не предположу.
              • 0
                Делали отладку на медленном анализаторе логики, а потом забыли повысить назад? :-)
                • 0
                  Простите? Вы про ограничение SPI?
                  Кстати, как вариан, но тогда бы я ограничивал на меньших значениях… надо же успевать слить данные куда-то =)
              • 0
                С печалью я гляжу…

                Это вы просто не вдавались в анализ библиотек и операционных систем на других платформах, где, как считается, в этом нет необходимости.
                • 0
                  Вы так тонко пошутили про .Net?
                  Тот фреймворк вообще некоторыми местами очень «радует». Например, количеством подгружаемых ресурсов.
                  На x86/x64 уже давно не особенно оптимизируют.
            • 0
              может я страдают теорией заговора, но мне кажется, что у каждой крупной компании есть связи с производителями коммерческого по и производителями стартеркитов, им как раз и достаются первые образцы и спецификации, а уж потом какая нибудь небольшая индусская контора пишет примеры. И второе, что хотел бы отметить — это то, что меня раздражает неэффективная с точки зрения использования ОЗУ инициализация перефириных устройство через длинные структуры. Недавно смотрел библиотеку старых техасских контроллеров АРМ ТМС470 библиотека написана в 98-99 годах и написана гораздо качественнее сегодняшних библиотек.
              • 0
                Редко пользуюсь в решении своих задач библиотеками, но недавно глянул как в одной библиотеке организованно обращение к портам ввода вывода.
                Наглядность и универсальность решения конечно хорошо, но к каким тормозам это приводит!
                Мне очень часто попадают задачи, где надо вытягивать вычислительные возможности микроконтроллера по максимуму, тогда всё приходится кодить ручками. Иной раз делаешь несколько вириантов работы куска программы — через разные прерывания, обычным опросом, оптимизируешь код после просмотра дизасемблера. В крайнем случае приходится делать вставки на ассемблере.
                Ну а если необходимо четырьмя кнопками управлять двумя сервами, тут конечно можно и ARDUINO c еёбиблиотеками использовать.
          • +4
            Ну а зачем изначально выбирать неподходящий кристалл? В 2012 году уже были те же СТМки с эзернет и аппаратным SDIO на борту.
            Да даже без аппаратного SDIO DMA даст существенный прирост производительности, разгрузив процессор.
            А так получается, что намеренно берем контроллер без ДМА, без СДИО, и долго решаем проблемы софтварно.
            • +3
              В то время ST (насколько я помню) имели на борту только MАС часть Eth, а у TI был интегрированный PHY.
              Юмор ситуации в том, что я знакомился с архитектурой Cortex именно на ST и (почему то) решил, что раз в ST есть DMA, то он будет и в Stellarise, что оказалось совсем не так. Конечно DMA, а особенно аппаратный SDIO мне бы сильно помог. Вариант создания своего софтового SDIO я рассматривал, но он, к сожалению, получался даже чуть медленнее за счет необходимости руками генерить клоки к нибблам.
              • 0
                Клоки клоками, вам бы еще и CRC пришлось бы считать ручками, а это уже совсем печально)
                • 0
                  ага еще и CRC — совсем про нее забыл, но мне и клоков хватило, чтобы понять что проваливаюсь.
            • +7
              Собственно, интерфейс SPI на SD и не обязан обеспечивать максимальную скорость, по которой специфицирована карточка. Эта скорость достигается по полному интерфейсу SD. Интересно, что по SPI удалось достичь таких высоких скоростей.
              • 0
                Спасибо, познавательно. А вот такой вопрос, вы как-то исследовали живучесть SD карт при столь интенсивной записи? У меня получилось убить три 4-х гиговых карты (две Transcend 150x и одну GoodRAM) записью логов. Каждая жила около двух месяцев, пока я понял, что это не случайность :)
                • +3
                  На самом деле поток не был НАСТОЛЬКО интенсивным постоянно.
                  Это было устройство перехвата сканов в Xerox, и такая интенсивность шла только при потоковом сканировании, поэтому пиковая производительность была требованием ТЗ.
                  Реальную загрузку копировального аппарата Вы представляете.
                  Кроме того, были приняты следующие меры: SD карточка была предварительно размечена на 1000 файлов ( с именами data000.dat — data999.dat — недостаток фантазии у меня) и в дальнейшем директория не менялась, что исключало деградацию системной области, а запись шла со смещением последовательно во все файлы, то есть каждый кусок пространства FLASH использовался в 1000 раз медленее входного потока. Пометка о занятости файла содержалась в нем самом, а не в какой то общей области, и при включении в оперативной памяти создавался своего рода каталог, с которым и работали.
                  Были приняты меры по контролю состояния файлов (тайминги записи и отсутствие ошибок) с выключением данного файла из обслуживания, но за время работы 10 устройств в течении года (пока шел авторский надзор) ни разу не сработали.
                  Так что в общем было многое сделано для предотвращения деградации носителя. На этапе отладки я делал тестовое устрройство, которое имитировало скан каждые 1.6 секунды и прогонял такой режим непрерывано 2 недели. Потом SD исселедовал на наличие проблеммных зон (по сравнению тайминга до и после тестов) и отличий не обнаружил.
                  • +4
                    С таким подходом есть смысл вообще отказаться от файловой системы FAT и вести запись на карточку непосредственно. Вы уже обнаружили, что драйвер FAT съедает значительную часть быстродействия, а вдруг там еще где-то остались тормоза? А так бы избавились от него совсем.

                    Еще как вариант — оставить формат FAT, но сразу забить все место на карточке одним непрерывным файлом на весь ее размер. Начальный сектор и длину этого файла как-то заметить и далее вести непосредственную запись в секторы карточки, не интерпретируя структуры ФС. Такой подход слегка упрощает считывание информации на компьютере, так как не нужны права администратора для доступа к карточке без ФС.
                    • +2
                      Файловая система была взята изначально для того, чтобы делать удобную отладку — переткнул карточку, скачал файлы, проконвертировал и смотри, почему образы битые и тд.
                      Когда отладка закончилась, думал о варианте без FAT, но поскольку и все так заработало, до конца идею не довел.
                      В общем, как всегда — временное решение, превратившееся в постоянное )
                • 0
                  лежит данный стартеркит с контролером у меня на полке, в связи с его прекратившемся выпуском так и не решился его освоить, у него действительно уникальная фишка в том, что его можно цеплять непосредственно к трансформатору ethernet. Скажите а что у СТМ есть такие, чтоб без «микреля»?
                  • 0
                    У TI теперь (спустя год после снятия Stellaris) есть МК с PHY в серии TIVA-C. например XXM4C129 — неплохой кристалл.
                    Я все таки даю TI шанс исправиться ).
                    У ST, насколько я знаю, так и не появилось среди Cortex-M моделей
                  • +1
                    Да… А так надеялось, что однажды…

                    В каждом ноуте сейчас есть слот для SD-карты, и засунуть туда флешку на 16 Гб, чтобы грузить ОСь, либо чтобы в винде подключить ее как кеш работы с диском — вроде как отличная идея, но никогда не получалось, чтобы идея эта давала быстроту. Все думал «почему», и рассуждал, какую же карточку купить, чтобы оно уже хоть как-то не тормозило. Мечты!

                    Вывод прост — самым быстрым из внешних накопителей все равно остается SSD-диск, засунутый во внешний USB3-кейсик. Там и интерфейс хорош, и вибрации не боится, и потребляет не сильно много.
                    • +1
                      Для SD/MMC карт есть один «недостаток», который «мешает» работать им быстро при чтении большого числа маленьких файлов — необходимость прервать поток команд и начать чтение заново.
                      Кстати, в числе сложностей с USB-устройствами — невозможность выполнять очень быстро большое количество мелких операций (особенность работы самого контроллера USB НЕ в режиме bulk обмена, то есть потокового, в котором и достигается большая пропускная способность). В режиме мелких операций каждое такое действие происходит не чаще 1000 раз в секунду (спецификация USB — частота прерываний). Хотя, можно зарезервировать часть полосы обмена, но это уже для устройств НЕ со стандартными драйверами.
                      Опять же, обменя данных с такиим устройством происходит через весь стэк USB протокола обмена.
                      А вот если подключать даже SD/MMC/TF карты через переходники в виде S-ATA накопителей — тут они уже смогут развить значительно бОльшие скорости доступа (хотя и упрутся в количество операций в секунду).
                      • +1
                        Точно. При операциях с большим количеством мелких файлов внешний USB3.0 карманчик становится слишком «задумчивым». Перевесил на eSATA — песня! правда неудобно что два шнурка — один, собственно, eSATA, а второй USB, для питания.
                        А насчёт карточек — так во многих новых буках и неттопах они подключаются на Realtek-овский PCI-E кард-ридер RTS5229. На высококлассных картах должно быть заметно преимущество, на уровне первых SSD.
                        • 0
                          В режиме USB есть ещё минус – отсутствие TRIM'а, что сказывается на живучести и быстродействии SSD в дальнейшем.
                          • 0
                            Надо будет проверить. Мне кажется, что если в контроллере есть поддержка ATA pass-through, то TRIM должен заработать. По аналогии со SMART-ом.
                    • 0
                      А можете поделиться информацией о «хороших» карточках? Параметры oemid, cid и т.д. (модель и производитель мало что дают).
                      В линуксе это всё лежит в /sys/block/mmcblk0/device/
                      • 0
                        У меня конкретно заработали SanDisk SDHC 8 Mb 10 C, а вот подробные параметры не вспомню. Где то валялся мой экземпляр платы, если найду, то укажу.
                      • +2
                        Неужели такая большая проблема внешний PHY поставить? Что-то мне подсказывает, что какие-нибудь STM32F107 + DP83848 обошлись бы в сумме дешевле, чем микроконтроллер от TI. В режиме RMII потребовалось бы всего 9-10 соединений от МК к PHY, если мне не изменяет память. Плюс вдобавок получили бы аппаратный SDIO, и не надо было бы заморачиваться со всеми описанными проблемами.
                        • 0
                          Респект и уважение автору с старой закалкой. Достойно уважение понимание принципов работы и анализ реализаций. Совершенно такая же ситуация и в программном обеспечении совершенно непонятно почему…
                          • 0
                            Мораль сей басни такова.
                            Если хочешь получить устройство с максимальным быстродействием не использую стандартных библиотек, а пиши свои оптимизированные по скорости драйвера того модуля, который используешь.
                            В особо тяжёлых случаях используй вставки на ассемблере.
                            Минус такого подхода один — необходимо хорошо знать архитектуру чипа с которым работаешь да ещё и ассемблер для него, хотя бы в общих чертах.
                            • 0
                              На редкость точно сформулировали. Полностью соглавсен.
                            • 0
                              А есть ли способ побороть состояние ожидания при записи у SD карты? Недавно реализовал на stm32 через sdio запись на карту. Да, всё круто, мегабайты в секунду всреднем пишет. Но бывает, что запись замирает на 500-1500мс, и карта выдаёт busy. Когда пишешь поток, это очень неудобно. Пока решил вопрос внешней SRAM к контроллеру, куда складывается поток, а потом переписывается на карту. Но может быть есть способ проще?
                              • 0
                                Как раз то, что было у меня, мне пришлось искать подходящую карту. Но у меня приостанавливалось не более чем на 500 мс, наверное, от катрочки зависит.
                                • +1
                                  Да, специально купил пачку карточек разных производителей. От 2 до 32Гб, от нонеймов до кингстонов и тошиб. И несколько выводов сделал:
                                  1. Нонейм или фирменная — от этого не зависит бизи на запись. Те же тошибы тормозили по 700мс, а какая-то карта без маркировки на 8гб делала 300мс.
                                  2. В доках на стандарт SD карт написано, что бизи может быть не более 250мс. Этого не соблюдает никто.
                                  3. От ёмкости карточки время не зависит. Логично было бы предположить, что при больших размерах блока флеши нужно большее время на стирание блоков например. И из-за этого могли быть тормоза. Хотя я предстирание юзаю.
                                  4. Подозреваю, что виной всему wear leveling, который не только на SSD но и на SD картах есть. И одному производителю известно, когда он включается, что делает, и сколько по времени отрабатывает. В эпоху больших RAM в девайсах — всем видимо пофигу.

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