[Elsystems 0]

Ошибаетесь. ТС случайно пропустил букву 'т' между последним '0' и 'р'.

В принципе - да, какой нибудь "жирный" заказчик вроде вчерашнего почтового ящика может отстегнуть пол ляма за такой "Комплекс ПО". Подрядчик тоже "жирный" и сам делать не будет и найдет кто сделает за 50т.р., ну а субподрядчик уже за 500р. ищет того кто сделает.

[[email protected] 0]

Приветствую!

 

Сейчас решал весьма близкую задачу и гугл привел сюда.

Хочу поделиться полученным опытом. Если оффтопик, видимо надо перенести.

 

Задача - STM32F4, 8 каналов АЦП12, 250KSps ==>> непрерывный поток 4MBps на SD.

Потери данных нежелательны, но при затыках карточки допускаются.

Желательно использование файловой системы.

 

Сначала по прямой записи на SD через драйвер SDIO by STM.

Тестил на разных карточках SDHC 16 и 32 ГБ.

1.1 Писать необходимо блоками кратными 512 байт, но крайне желательно увеличивать блок как минимум до 16, лучше 32 КБ.

1.2 Писать блоки желательно по последовательным адресам с выравниванием по размеру блока. Напр., адрес 0x00594000 выровнен по 16 КБ.

1.3 На некоторых карточках помогает предварительная команда стирания области из нескольких блоков CMD32..38. На других карточках разницы не заметил.

1.4 На некоторых карточках помогает команда предстирания блока ACMD23. На других карточках разницы не заметил.

В результате получилось записывать блоки по 16КБ примерно за 2.5..3.0 мс - меня это вполне устраивает.

Скорость SDIO, кстати, была 32 МГц вместо допустимых 48 МГц.

 

Но.

2.1 В зависимости от проверяемой карточки, регулярно возникают задержки до 5..10 мс после записи очередных 2..4 Мб.

2.2 В зависимости от проверяемой карточки, нерегулярно возникают задержки до 20..100 мс после записи очередных 8..16 Мб.

2.3 Запись блоков переменной длины по произвольным адресам выливается в постоянные задержки 100..500 мс.

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

 

Пляски с файловой системой (FatFs)

3.1 Карточку сразу разметил на кластера по 32КБ, чтобы каждая попытка записи блока не приводила к нескольким обращениям к SD.

3.2 Первая попытка использования FatFs привела к тому, что запись блока 16КБ при помощи fwrite() выливалась по меньшей мере в 6..7 мс, нередко существенно дольше - это не позволяло писать требуемый поток.

3.3 Предварительно выделил место под файл, чтобы исключить необходимость обращения к FAT в процессе записи потока - особо не помогло.

3.4 Выяснилось, что кластера FS вовсе не выравнены по размеру кластера, что противоречило (1.2). Начал копаться в исходниках f_mkfs() и выяснил, что хитрый японец пытается выровнять область данных по размеру элементарного стираемого блока носителя, и обращается с запросом к драйверу disk_ioctl(GET_BLOCK_SIZE). Моя реализация драйвера возвращала 0, и японец умывал руки. Исправил на 32КБ - и время каждого fwrite() упало до 3 мс, что и требовалось изначально.

 

Пока не растерял приподнятого настроения, настрочил пост.

Еще не пробовал записывать по несколько ГБ - возможно выяснится что-нибудь еще. Если выяснится, попробую принудительно стирать всю область данных при форматировании.

Регулярные артефакты до 10..20, реже 100 мс при обращении к SD сохранились, но это в общем устраивает. Вопрос опытным - бороться здесь можно только буфером от 0.5 МБ, или есть еще какие-нибудь хитрости?

 

[adnega 11]

Вопрос опытным - бороться здесь можно только буфером от 0.5 МБ, или есть еще какие-нибудь хитрости?

Под "бороться" вы понимаете обработку напильником FatFs или полностью собственную реализацию?

Для реалтайм потоков много ОЗУ не помешает - можно хранить и буфер данных и кэшировать таблицу FAT.

Можно предварительно создать файл или порцию файла значительного размера (чтобы не перезаписывать FAT по ходу), и

писать только область данных непрерывными кусками большого размера. А при окончании потока записывать информацию о файле и

удалять не потребовавшиеся кластеры из FAT.

 

Что насчет MMC, вроде у них с потоками должно быть получше?

[[email protected] 0]

Под "бороться" вы понимаете обработку напильником FatFs или полностью собственную реализацию?

Что насчет MMC, вроде у них с потоками должно быть получше?

 

"Артефакты" на 100 мс у меня возникают без всякой FatFs. Дорабатывать файловую систему нет смысла, пока не удастся повысить качество прямой записи на SD. Попробую как-нибудь записывать большими блоками под 4МБ, может что новое возникнет.

Про MMC не в теме. Ознакомлюсь, спасибо.

Кстати, раз такое дело. А существует ли какой-нибудь вид Flash-накопителей с возможностями порядка SD, но в нормальном индустриальном корпусе под пайку?

[jcxz 187]

Кстати, раз такое дело. А существует ли какой-нибудь вид Flash-накопителей с возможностями порядка SD, но в нормальном индустриальном корпусе под пайку?

http://www.spansion.com/Products/memory/eM...NAND-Flash.aspx

[Elsystems 0]

Приветствую!

 

Сейчас решал весьма близкую задачу и гугл привел сюда.

Хочу поделиться полученным опытом. Если оффтопик, видимо надо перенести.

 

Задача - STM32F4, 8 каналов АЦП12, 250KSps ==>> непрерывный поток 4MBps на SD.

Потери данных нежелательны, но при затыках карточки допускаются.

Желательно использование файловой системы.

 

А теперь главный вопрос - продадите наработки за 500р.?

[adnega 11]

А теперь главный вопрос - продадите наработки за 500р.?

Только перед этим допилить 1Msps и 4 канала. Поток там был около 7MBps.

[[email protected] 0]

А теперь главный вопрос - продадите наработки за 500р.?

Вы серьезно, или об этом?

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

 

Только перед этим допилить 1Msps и 4 канала. Поток там был около 7MBps.

Ну да, в лоб получилось порядка 5MBps и с потерями. Если увеличить буфер до 32КБ и поднять скорость SDIO, как раз влезет в 8MBps. А дальше только продолжать разбираться с SD и/или ставить внешнюю RAM.

Пока буду изучать eMMC, как то я упустил эту тему.

[adnega 11]

и поднять скорость SDIO, как раз влезет в 8MBps.

Практика показывает, то обмен по SDIO в сравнении с готовностью данных в карте находится на несколько порядков ниже.

Например, 32кБ при 48МГц по 4 битному интерфейсу можно передать за 2 мс.

Карточка может задуматься на куда большие времена.

Пока буду изучать eMMC, как то я упустил эту тему.

Если не нужно туда-сюда таскать карточку, а достаточно просто запаять на плату, то можно.

Кста, тем цены не сильно кусаются?

[aaarrr 68]

Кста, тем цены не сильно кусаются?

Если сравнивать с продающимися в каждом ларьке uSD, то сильно, конечно. Но можно еще вычесть стоимость разъема.

Плюс требования к плате, т.к. eMMC корпусируются в BGA с шагом 0.5мм.

 

Со стороны производительности чудес ждать не стоит - та же память с другим интерфейсом.

[[email protected] 0]

Практика показывает, то обмен по SDIO в сравнении с готовностью данных в карте находится на несколько порядков ниже.

Например, 32кБ при 48МГц по 4 битному интерфейсу можно передать за 2 мс.

Карточка может задуматься на куда большие времена.

У меня получилась такая вот диаграмма при записи по 32КБ

По X номер блока, по Y - время на запись. В середине там выброс 100 мс.

Потери будут, в моем случае это устраивает.

 

Если не нужно туда-сюда таскать карточку, а достаточно просто запаять на плату, то можно.

Кста, тем цены не сильно кусаются?

Именно стационарная память и нужна, SD была вынужденной мерой от безграмотности. Цены и доступность еще не смотрел.

 

[aaarrr 68]

Именно стационарная память и нужна, SD была вынужденной мерой от безграмотности.

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

[adnega 11]

У меня такой график.

По X - номер записи в отсортированном по убыванию массиве времени записи.

По Y - время записи блока в мс.

Для разных размеров блоков и для последовательной (serial) или случайной (random) записи.

[ветерок 0]

повторю ещё раз

 

если кому надо на AVR...

готовое решение здесь

http://www.rlocman.ru/shem/schematics.html?di=106266: