:-)

Спасибо большое! Ваши ответы всегда очень интересно и познавательно читать.

Подскажите, а как вы собираете проекты xsdk вне этой оболочки? Создаёте ли заранее bsp в ней и потом используете? Или как-то по-другому? Аналогично с hw? Самого меня раздражает, что изменение состава используемых библиотек bsp приводит к сбросу части настроек. И приходится ручками по gui тыкать повторно. И ещё неясно, что хранить в системе контроля версий: только ли свой проект, но тогда ещё надо бы описывать вот все шаги по настройке bsp. В общем - не подскажете, есть ли более удобный путь, чем тот, который по умолчанию навязан xilinx?..

Любопытно, а чем закончился поиск проблемы? ЗЫ Столкнулся с подобной проблемой на zynq-7000. Ведётся работа в режиме AMP: на одном ядре Linux, на другом FreeRTOS. При некоторых условиях всё намертво зависает. Под подозрением FreeRTOS-ная часть. Но нет опыта разбирательства с такими штуками. Подскажите, что почитать по coreSight? Как разобраться с trace? Где бы увидеть примеры использования и поиска подобных багов?..

Google по фразе " Run-Time Debugging Tool " вывел на FreeMASTER Run-Time Debugging Tool. Ещё посмотрел на ucProbe. Интересные штучки, не знал о таком. В принципе половину задачи они могут помочь решить. Одна из целей действительно посмотреть как что-то крутится в некоторой программе управления в режиме реального времени. И такими штуками это, как будто, красиво получается. Но есть ещё одна подзадача - это передача тестовых воздействий с ПК в устройство. (Вернее программа на Cortex-a9 должна будет передать данные в память ПЛИС и далее считать результат обработки и сравнить с тем, что должно быть. А всё крутится на Zynq7000). Может, для такого тоже есть что-то готовое? Для изучения и вдохновения... В общем-то тоже придерживаюсь мнения, что потерь быть не должно. Впрочем потеря пакетов допустима и вряд ли сильно помешает. UDP или TCP - это, скорее, для упрощения реализации программы на ПК. (Можно, наверное, и до голых Ethernet-кадров опуститься. В 1,5 кБ должны умещаться отдельные кванты телеметрии). Так вот я и пытаюсь разобраться какие протоколы существуют и их пригодность. MQTT пугает каким-то непонятным слоем брокер. Вроде бы, для моей задачи ненужная штука. Я уже выше приводил пример альтернативного протокола: Constrained Application Protocol. Он поверх UDP реализуется. И не содержит никакого брокера. ЗЫ Вообще, конечно, чувствую, что изобретаю какой-то велосипед...

- платформа cortex-A - клиент - некая программа для пользователя - как таковой сети и не предполагается. В 98% случаях - вся сеть состоит из 1ого ПК и 1ого управляемого устройства. В 2% может быть несколько устройств (<5) А чем плох непрерывный поток? С первого взгляда он упрощает ПО на ПК, выполняющее функции управления и приём данных "телеметрии". ("Телеметрия" - это некие данные о состоянии устройства, передаваемые с темпом 1кГц. Запрашивать на ПК данные с темпом 1кГц - как-то страшно.) MQTT с первого взгляда кажется избыточным. Вот видел альтернативу в виде CoAP ( https://en.wikipedia.org/wiki/Constrained_Application_Protocol ) - как будто попроще. Использовал ли кто-нибудь? Возможно, имеет смысл придумать и что-то своё, но думал, что задача слишком уж типовая. И должно быть что-то готовое. Текущее резюме из советов в теме: 1. Лучше UDP, чем TCP. Хотя и TCP тоже норм. 2. Писать либо свой протокол, либо MQTT. Уточню пару нюансов: 1. Работа через большую сеть/интернет не предполагается и не требуется (хотя, если окажется опцией, то отлично). Ethernet выбран - потому что хорошая скорость и доступность почти на любом ПК. 2. Телеметрия - это режим работы при отладке прибора "на столе". В готовом устройстве будет только управление: вкл/выкл, выбор режима и т.д. 3. На ПК предполагается специальная программа для пользователя.

Сценарии использования видятся следующими: 1. Запрос параметра - возврат параметра; 2. Запрос телеметрии - непрерывный поток данных телеметрии до запроса отмены телеметрии. Соединение точка-точка.

Добрый день! Есть задача реализовать управление неким устройством через Ethernet-соединение (1G). Требуется управлять включением/выключением некоторых функций. Также требуется при необходимости получать телеметрию (скорость потока - 1..10 Мбайт/с, может и выше в перспективе). (На устройстве будет скорее всего FreeRTOS+lwip, но не исключен вариант и Linux). И тут возник вопрос - какой протокол использовать поверх UDP или TCP соединения (ещё не выбрано)? Придумывать что-то своё? Или есть что-то типовое, что всеми используется?

Подскажите, пожалуйста, а как можно реализовать запись потока 4GByte/s и сколько это может стоить?..

Случайно наткнулся вот на такую штуку: https://www.crowdsupply.com/era-instruments/erasynth Вроде бы, по теме топика.

С Днём Победы!!!

Не совсем то, что надо. Хочется именно SoC, чтобы на нормальном процессоре некоторые задачи решать... О, точно! Должны возродиться: https://ez.analog.com/thread/93958

Только заинтересовался вот такой игрушкой: PicoZed SDR 1X1 SOM (ZYNQ 7000 + AD9364) ( http://zedboard.org/product/picozed-sdr-1x1-som ), как появилось "End of life notice". Есть ли в природе доступные альтернативы? Сам нашёл следующие: PutoSDR ( https://wiki.analog.com/university/tools/pluto ) - не совсем то, что нужно. ZYNQ самый маленький и вообще какая-то урезанная. SNOWLeo SDR (вместо AD9364 - LMS6002D) - уже не выпускается. YunSDR Y310s - вроде бы, то что надо, но непонятно где купить, сколько стоит и есть ли вменяемые примеры от китайских разработчиков. ЗЫ Интересно что ж AVNET с ANALOG DEVICES не поделили?..

GPS тоже возможен... В открытом поле особенно... https://www.youtube.com/watch?v=PpNhtQW0o7U

Извините, что вмешиваюсь. А вы работали с платками B200/B210? Если да - удавалось ли получить стабильную передачу данных при полосах 15...35 МГц? А то главное разочарование в них для меня - это постоянные потери данных при записи сигнала длиной десятки секунд (при том, что скорость дисковой системы ПК позволяет выполнять запись потоков в 10-20 раз выше требуемой).

:bb-offtopic: Извините, что не по теме... Скажите, а вам удалось добиться стабильной работы от B200/B210. А то не знаю как побороть постоянные разрывы при передаче данных по USB 3.0. В интернете читал только описание такой же проблемы, а решения так и не нашел. Невозможно гарантировать запись даже 30 сек при частоте дискретизации, например 16 МГц... (Дисковая подсистема ПК тут точно не при чем).

А если ещё немного уточнить. Положим, взять ПЛИС XC6VLX130T. В ней 480 умножителей. Максимальная рабочая частота DSP-блока - 600 МГц. Пусть частота дискретизации 4 ГГц. Пусть требуется КИХ-фильтр порядка 250. Пусть также требуется после фильтрации выполнить децимацию на 7. Тогда требуемые ресурсы оценочно получаются: (4ГГц/500МГц)/2 = 4. 250*4=1000. 1000:7 ~ 150. Т.е. с первого взгляда, как будто бы, вполне реализуемо. Верно я понимаю?

Ага, вот что хотелось понять... Связь числа DSP блоков (получается, что быстрые фильтры только на них), максимальной частоты DSP блока и частоты дискретизации. 5520 / 1380 = 4 (А почему тогда 8 параллелей?). 8*500МГц = 4ГГц.

Подскажите, пожалуйста, каковы потенциальные возможности современных ПЛИС в задаче реализации КИХ-фильтра. Скажем, есть современные АЦП с частотами дискретизации до нескольких ГГц. Например, до 4 ГГц. С разрядностью до, например, 12 бит. Понятно, что внутри ПЛИС маскимальные частоты - порядка нескольких сотен МГц. Но путем какого-нибудь хитрого распараллеливания, наверное, можно перейти от входного потока 4ГГц*12бит к чему-то, вроде, 250МГц*192бит. В общем вопрос в том, на что способны современные ПЛИС (скажем virtex 5/6/7). Какой порядок фильтра КИХ можно достичь? Каких частот можно достичь? Вопрос абстрактный - задается для осознания современного развития ПЛИС.

Не уловил вашей мысли... Не могли бы пояснить её? Сам хочу сказать, что китайская навигационная система работает на данный момент гораздо лучше еврпейской. По крайней мере в белокаменной можно не напрягаясь принять сигнал от не менее, чем 4 спутников и определить свои координаты. А вот чтобы поймать сигнал от всех 4 спутников галилео - нужно постараться... такая радость длится не более пары часов в сутки... Кстати, в китайскую систему входят не только среднеорбитальные спутники, но и геосинхронные и геостационарные. Последние передают в дополнение ко всему ионосферные поправки по аналогии с дугими sbas. т.е. возможность диф.коррекции заложена в саму систему, а не в её дополнение.

Хм... Наверное, не более 1 метра имелось в виду... Для RTK задач полно приемников. Посмотрите у таких производителей, как www.javad.com http://www.septentrio.com/ http://www.novatel.com/ http://www.trimble.com/ http://www.furuno.com/en/business_product/gps/index.html Обычно это многочастотные, многосистемные приемники геодезического класса. Но и цена на них соответствующая (единицы-десятки тысяч $). Но в последние годы появилась возможность решать RTK-задачи дешевыми приемниками. Например, navis nv08c-csm или ublox LEA6-T или skytraq s1216 в сочетании с open-source программой RTKlib (http://www.rtklib.com/) позволяют получать RTK решения на небольших базах до нескольких км. Один из важных вопросов в дешевых решениях - выбор подходящей антенны. Т.к. для надежной работы требуется высококачественная навигационная антенна.

Если предполагается сделать что-то, вроде, современного аналога GP4020 ( http://www.microsemi.com/products/product-directory ), поддерживающего кроме GPS ещё и ГЛОНАСС/GALILEO/Beidou - то штука должна быть весьма интересной. По крайней мере гораздо интереснее вот такого проекта ( http://www.kickstarter.com/projects/swiftn...tk-gps-receiver ), собравшего больше 150 000$, в котором в итоге нет ничего RTK-шного на данный момент. Если же предполагается дать доступ только к части свободных ресурсов процессора, то скучно. Такое обещает тот же navis со своим, например, nv08c. Ну а много спутников очень полезно, например, для RTK-шных задач. Ну и для всяких городских условий, когда полнеба или больше закрыто высокими зданиями...

Спасибо, Ledum! Похоже, что оно...

Preamplifier Langer EMV-Technik PA303 ( http://www.langer-emv.de/en/products/distu...ier/pa-203-303/ ). Не подскажет ли кто, что за транзисторы используются?

Так это ж... Вроде бы, уже есть порты OpenPilot и на DiscoveryF3 и на DiscoveryF4: https://github.com/lilvinz/OpenPilot/wiki/D...t-this-is-about . И есть вот такая игрушка, но на STM32F3: http://abusemark.com/store/index.php?main_...;products_id=30 с портом multiwii.

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