[email protected]

Синхронизировать два датчика таким образом я думаю, что смогу. Хотя и не хочется - пусть бы АЦП+DMA разных датчиков работали на своих "родных" частотах, с разбегом по фазе вплоть до одного цикла оцифровки. Пусть за период между синхронизациями датчики разбегутся еще на 1 цикл. Меня вполне устраивает итоговый разбег в 1-2 (да может и 3) оцифровки, как писал в начале. У меня другие непонятки: пусть есть всего один датчик, но при опросе его буфера за 1 с там может быть как 1000, так и 999, и 1001 оцифровка. При идеальном совпадении часов/синхронизации набега не будет, т.е. за 100 c будет суммарно вычитано от 99`999 до 10`001. Проблема в том, что я не знаю, как должен действовать алгоритм на ПК, когда в него поступает неодинаковое количество оцифровок за одинаковый период времени. Можно выкидывать "лишние" и додумывать "нехватающие" оцифровки, но это как-то совсем криво. Здесь я не понял. Тактовые частоты разных датчиков в моем случае не могут совпадать.

Пошел читать

А можно чуть подробнее? Отмерять по RTC каждую миллисекунду, и слать по 1000 запросов на каждый датчик каждую секунду? Как-то слишком грубо, и через 115200 вряд ли это прокачаю. Или просто вас не понял. Команда синхронизации широковещательная на все датчики, длительность на 115200 около 0.5 мс, вроде подходит под критерий? Мне задача видется, как сведение двух (или даже N) разнесенных цифровых микрофонов. Они же по-любому шлют поток оцифровок асинхронно? Если что, не пинайте, я в общем-то не в теме. Как мне кажется, похожие задачи решаются в системах с на порядки большим темпом сбора. И разнесенные датчики могли бы быть на безпроводке и через маршрутизаторы...

Приветствую. Задача не оригинальная: есть система сбора данных с датчиков на компьютер, где необходимо эти данные синхронизировать. Распределенные датчики цифруют сигнал на некоторой известной скорости, например, 1000 sps (с поправкой на точность своих кварцев, пусть +-50ppm). Контроллер сбора последовательно опрашивает датчики по RS-485, забирая из них пакеты оцифрованных данных без потерь в буфер. Пакеты от датчиков содержат в т.ч. свои идентификаторы порядковый номер первой оцифровки в этом пакете. Контроллер может периодически выдавать широковещательную команду на все датчики, по которой они могут сбрасывать номер последней оцифровки. У контроллера есть часы реального времени, отметки которого в момент синхронизации можно периодически подмешивать в общий поток данных. Компьютер периодически выгребает накопленные пакеты из буфера контроллера. Каждую полученную оцифровку нужно привязать ко времени так, чтобы разбежка между разными датчиками не превышала 1..2 оцифровки. На длительном отрезке времени (часы, дни) данные должны сохранять привязку к часам реального времени. Нежелательно терять данные, пока контроллер, датчики и линии связи работают без сбоев. Есть целый ряд очевидных проблем: - скорости датчиков не совпадают из-за разных кварцев, и даже скорость одного датчика плывет со временем; - часы реального времени в контроллере имеют дискретность несколько мс; - команда синхронизации приходит на датчики практически синхронно, но реагируют они на нее с некоторой задержкой; - даже если все работает абсолютно синхронно, за 1 с от одного датчика может прилетать как 1000 оцифровок, так и попеременно то 999, то 1001. - частота оцифровки датчиков может не совпадать, а отличаться, скажем, раза в полтора. Я так понимаю, этой задаче сто лет в обед. Но, к своему стыду, готового, очевидного и надежного алгоритма увязки данных я не нашел. Помогите ссылками, или просто советом.

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

Пользуюсь "родным" драйвером SDIO из состава библиотеки STM32F4xx HAL Drivers. Обмен с отказавшей карточкой происходит штатно, все статусы завершения операций приходят нормальные. Вот низкочастотная диаграмма обмена - видно, что отказавшая карточка возвращает нули. Кроме того, при подключении через адаптер к PC та же история - карточка нормально открывается, можно создать файл с содержимым, но при переподключении карточки файл пропадает. Ладно бы, если это был единичный отказ. Но оно регулярно возникает снова.. И еще, вопрос до кучи: есть ли возможность узнать оставшийся ресурс SD-карточки на запись? Вдруг я ее действительно затер до дыр.

Приветствую! Разрабатываю устройства на связке Cortex-M4, SDIO, uSD, FatFS. Столкнулся с тем, что в редких случаях SD-карточка выходит из строя. Симптомы отказа: штатные запросы к SD происходят нормально, но если считать сектор, записанный после отказа, то будет считан буфер нулей. Информация, записанная на карту до отказа - сохраняется, в т.ч. файловая система и содержимое файлов. Считал CSD и CID с двух карточек (исправной и неисправной) одной партии - отличия только в серийниках и дате производства. Таких карточек накопилось уже штук 5. Похожие симптомы были у товарища, который работал с другим МК и по SPI. Карточки были разного объема и разных производителей. Какой-то системы с отказами не обнаружил. Не исключено, что были отказы устройства в целом - сбои по питанию, перезагрузки. SD запитана через ключ, соответственно при сбросе контроллера она теряет питание (в т.ч. во время выполнения операции). Поделитесь, куда копать.

У меня получилась такая вот диаграмма при записи по 32КБ По X номер блока, по Y - время на запись. В середине там выброс 100 мс. Потери будут, в моем случае это устраивает. Именно стационарная память и нужна, SD была вынужденной мерой от безграмотности. Цены и доступность еще не смотрел.

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

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

Приветствую! Сейчас решал весьма близкую задачу и гугл привел сюда. Хочу поделиться полученным опытом. Если оффтопик, видимо надо перенести. Задача - 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 МБ, или есть еще какие-нибудь хитрости?

Спасибо за консультацию! От индуктивной связи решил отказаться, слишком сложно и не обоснованно. По емкостной связи прикинул, что для обеспечения 30 нФ потребуется слишком большая площадь обкладок, тоже не вариант. Еще можно вывести изолированные контакты наружу, заподлицо с корпусом, т.к. развязка от электроники все равно есть, и при необходимости можно увеличивать изоляцию. Так что пока оставлю разъем. На будущее поэкспериментирую с WiFi, может пригодится. Плюс к тому убедился, что Ethernet "внезапно" не работает по одной паре, такое вот разочарование :-)

Приветствую. Разрабатываю устройство с внешним проводным интерфейсом Ethernet для эпизодического обмена данными с PC. Именно Ethernet выбран как готовое решение, обеспечивающее требуемую скорость передачи данных. Установка электрического разъема на корпус прибора допустима, но конструктивно весьма сложна. В связи с этим вопрос - возможно ли реализовать разнесенный Ethernet-трансформатор (одна обмотка - внутри в приборе, вторая - снаружи на кабеле) для связи прибора с PC? Одной пары будет достаточно для полу-дуплекса. Возможно ли это в принципе для 100 Мбит/с, или 10 Мбит/с? Какую доку по конструированию трансформаторов порекомендуете? Хотелось бы оценить техническую сложность задачи, чтобы сравнить с электрическим соединением через разъем. И еще по поводу WiFi - возможно ли установить антенну внутри металлической оболочки прибора, чтобы можно было связаться с прибором с расстояния 5..10..15 м? В оболочке можно обеспечить радиопрозрачное окно. Можно также попробовать вывести антенну наружу в качестве элемента оболочки. В радиосвязи я почти ноль, за глупость не пинайте.