Jump to content

    

:-)

Свой
  • Content Count

    227
  • Joined

  • Last visited

Community Reputation

0 Обычный

About :-)

  • Rank
    Местный

Контакты

  • Сайт
    http://
  • ICQ
    0

Информация

  • Город
    Мск

Recent Profile Visitors

6776 profile views
  1. Любопытно, а чем закончился поиск проблемы? ЗЫ Столкнулся с подобной проблемой на zynq-7000. Ведётся работа в режиме AMP: на одном ядре Linux, на другом FreeRTOS. При некоторых условиях всё намертво зависает. Под подозрением FreeRTOS-ная часть. Но нет опыта разбирательства с такими штуками. Подскажите, что почитать по coreSight? Как разобраться с trace? Где бы увидеть примеры использования и поиска подобных багов?..
  2. Google по фразе " Run-Time Debugging Tool " вывел на FreeMASTER Run-Time Debugging Tool. Ещё посмотрел на ucProbe. Интересные штучки, не знал о таком. В принципе половину задачи они могут помочь решить. Одна из целей действительно посмотреть как что-то крутится в некоторой программе управления в режиме реального времени. И такими штуками это, как будто, красиво получается. Но есть ещё одна подзадача - это передача тестовых воздействий с ПК в устройство. (Вернее программа на Cortex-a9 должна будет передать данные в память ПЛИС и далее считать результат обработки и сравнить с тем, что должно быть. А всё крутится на Zynq7000). Может, для такого тоже есть что-то готовое? Для изучения и вдохновения... В общем-то тоже придерживаюсь мнения, что потерь быть не должно. Впрочем потеря пакетов допустима и вряд ли сильно помешает. UDP или TCP - это, скорее, для упрощения реализации программы на ПК. (Можно, наверное, и до голых Ethernet-кадров опуститься. В 1,5 кБ должны умещаться отдельные кванты телеметрии). Так вот я и пытаюсь разобраться какие протоколы существуют и их пригодность. MQTT пугает каким-то непонятным слоем брокер. Вроде бы, для моей задачи ненужная штука. Я уже выше приводил пример альтернативного протокола: Constrained Application Protocol. Он поверх UDP реализуется. И не содержит никакого брокера. ЗЫ Вообще, конечно, чувствую, что изобретаю какой-то велосипед...
  3. - платформа 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. На ПК предполагается специальная программа для пользователя.
  4. Сценарии использования видятся следующими: 1. Запрос параметра - возврат параметра; 2. Запрос телеметрии - непрерывный поток данных телеметрии до запроса отмены телеметрии. Соединение точка-точка.
  5. Добрый день! Есть задача реализовать управление неким устройством через Ethernet-соединение (1G). Требуется управлять включением/выключением некоторых функций. Также требуется при необходимости получать телеметрию (скорость потока - 1..10 Мбайт/с, может и выше в перспективе). (На устройстве будет скорее всего FreeRTOS+lwip, но не исключен вариант и Linux). И тут возник вопрос - какой протокол использовать поверх UDP или TCP соединения (ещё не выбрано)? Придумывать что-то своё? Или есть что-то типовое, что всеми используется?
  6. Подскажите, пожалуйста, а как можно реализовать запись потока 4GByte/s и сколько это может стоить?..
  7. Случайно наткнулся вот на такую штуку: https://www.crowdsupply.com/era-instruments/erasynth Вроде бы, по теме топика.
  8. С Днём Победы!!!
  9. Цитата(dm.pogrebnoy @ Apr 29 2017, 19:44) Вариант : http://imt-yar.ru/products/28030425 Не совсем то, что надо. Хочется именно SoC, чтобы на нормальном процессоре некоторые задачи решать... Цитата(PavPro @ May 2 2017, 10:03) Вроде бы PicoZed будет теперь поддерживать Analog Devices, правда под другим названием но по сути будет тот же самый PicoZed. О, точно! Должны возродиться: https://ez.analog.com/thread/93958
  10. Только заинтересовался вот такой игрушкой: 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 не поделили?..
  11. GPS тоже возможен... В открытом поле особенно... https://www.youtube.com/watch?v=PpNhtQW0o7U
  12. Цитата(rloc @ Jun 7 2016, 14:59) Пока не появились AD9368, выгодно смотрятся платки Ettus B210 (с переключаемыми фильтрами, фактически преселекторами) и B205mini-i . Цены были порядка: USRP B205mini-i (Board Only) - $750.00 USRP B210 (Board Only) - $1,119.00 Впрочем о чем это я? Вам они должны быть знакомы. Пол года назад экспериментировал с платами, чипы AD9361 понравились, был удивлен калибровкой квадратурных каналов - подавление боковой полосы 70-80 dBc. Теоретически в GNU radio должен реализовываться векторник, по принципу Planar R54 на резистивном мосту. Правда понадобится минимум B210 с двумя приемниками. Мы будем использовать их в широкополосных приемниках для стендовой аппаратуры, по цене за 120 МГц полосы (по моим измерениям) составляют серьезную конкуренцию Кисайтам и Роде-Шварцам. Извините, что вмешиваюсь. А вы работали с платками B200/B210? Если да - удавалось ли получить стабильную передачу данных при полосах 15...35 МГц? А то главное разочарование в них для меня - это постоянные потери данных при записи сигнала длиной десятки секунд (при том, что скорость дисковой системы ПК позволяет выполнять запись потоков в 10-20 раз выше требуемой).
  13. Цитата(bogaev_roman @ Feb 1 2016, 13:38) Посмотрите еще в сторону Этуса - там нет ничего лишнего, соответственно цена гораздо ниже (точно <1000 уе), чем связка, к примеру, ml605+fmcooms3. http://www.ettus.com/product/category/USRP-Bus-Series С техподдержкой, кстати, у них тоже все нормально, единственный недостаток - нет флешки под прошивку, хотя в последних версиях может что-то поставили. Извините, что не по теме... Скажите, а вам удалось добиться стабильной работы от B200/B210. А то не знаю как побороть постоянные разрывы при передаче данных по USB 3.0. В интернете читал только описание такой же проблемы, а решения так и не нашел. Невозможно гарантировать запись даже 30 сек при частоте дискретизации, например 16 МГц... (Дисковая подсистема ПК тут точно не при чем).
  14. А если ещё немного уточнить. Положим, взять ПЛИС XC6VLX130T. В ней 480 умножителей. Максимальная рабочая частота DSP-блока - 600 МГц. Пусть частота дискретизации 4 ГГц. Пусть требуется КИХ-фильтр порядка 250. Пусть также требуется после фильтрации выполнить децимацию на 7. Тогда требуемые ресурсы оценочно получаются: (4ГГц/500МГц)/2 = 4. 250*4=1000. 1000:7 ~ 150. Т.е. с первого взгляда, как будто бы, вполне реализуемо. Верно я понимаю?
  15. Цитата(RobFPGA @ Jan 13 2015, 00:45) Приветствую! Если Вам надо произвести впечатление на девушку возможностями современных FPGA то например если взять Kintex Ultrascale XCKU115 с его "скромными" 5520 DSP блоками то для входного/выходного потока в 4Гс/с 12бит можно по быстрому сваять симметричный КИХ на 1380 отсчетов (8 паралелей на 500 MHz). Особенно девушка оценить стоимость этого решения Успехов! Rob Ага, вот что хотелось понять... Связь числа DSP блоков (получается, что быстрые фильтры только на них), максимальной частоты DSP блока и частоты дискретизации. 5520 / 1380 = 4 (А почему тогда 8 параллелей?). 8*500МГц = 4ГГц.