Pull to refresh

Comments 38

> задача решена, устройcтва отгружены потребителю и функционируют без сбоев

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

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

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

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

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

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

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

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

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

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

Articles