Jump to content

    

:-)

Свой
  • Content Count

    216
  • Joined

  • Last visited

Community Reputation

0 Обычный

About :-)

  • Rank
    Местный

Контакты

  • Сайт
    Array
  • ICQ
    Array

Информация

  • Город
    Array

Recent Profile Visitors

6897 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. Не совсем то, что надо. Хочется именно SoC, чтобы на нормальном процессоре некоторые задачи решать... О, точно! Должны возродиться: https://ez.analog.com/thread/93958
  9. Только заинтересовался вот такой игрушкой: 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 не поделили?..
  10. GPS тоже возможен... В открытом поле особенно... https://www.youtube.com/watch?v=PpNhtQW0o7U
  11. Извините, что вмешиваюсь. А вы работали с платками B200/B210? Если да - удавалось ли получить стабильную передачу данных при полосах 15...35 МГц? А то главное разочарование в них для меня - это постоянные потери данных при записи сигнала длиной десятки секунд (при том, что скорость дисковой системы ПК позволяет выполнять запись потоков в 10-20 раз выше требуемой).
  12. :bb-offtopic: Извините, что не по теме... Скажите, а вам удалось добиться стабильной работы от B200/B210. А то не знаю как побороть постоянные разрывы при передаче данных по USB 3.0. В интернете читал только описание такой же проблемы, а решения так и не нашел. Невозможно гарантировать запись даже 30 сек при частоте дискретизации, например 16 МГц... (Дисковая подсистема ПК тут точно не при чем).
  13. А если ещё немного уточнить. Положим, взять ПЛИС XC6VLX130T. В ней 480 умножителей. Максимальная рабочая частота DSP-блока - 600 МГц. Пусть частота дискретизации 4 ГГц. Пусть требуется КИХ-фильтр порядка 250. Пусть также требуется после фильтрации выполнить децимацию на 7. Тогда требуемые ресурсы оценочно получаются: (4ГГц/500МГц)/2 = 4. 250*4=1000. 1000:7 ~ 150. Т.е. с первого взгляда, как будто бы, вполне реализуемо. Верно я понимаю?
  14. Ага, вот что хотелось понять... Связь числа DSP блоков (получается, что быстрые фильтры только на них), максимальной частоты DSP блока и частоты дискретизации. 5520 / 1380 = 4 (А почему тогда 8 параллелей?). 8*500МГц = 4ГГц.