Перейти к содержанию
    

:-)

Свой
  • Постов

    218
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о :-)

  • Звание
    Местный
    Местный

Контакты

  • Сайт
    Array
  • ICQ
    Array

Информация

  • Город
    Array

Посетители профиля

7 434 просмотра профиля
  1. Спасибо большое! Ваши ответы всегда очень интересно и познавательно читать.
  2. Подскажите, а как вы собираете проекты xsdk вне этой оболочки? Создаёте ли заранее bsp в ней и потом используете? Или как-то по-другому? Аналогично с hw? Самого меня раздражает, что изменение состава используемых библиотек bsp приводит к сбросу части настроек. И приходится ручками по gui тыкать повторно. И ещё неясно, что хранить в системе контроля версий: только ли свой проект, но тогда ещё надо бы описывать вот все шаги по настройке bsp. В общем - не подскажете, есть ли более удобный путь, чем тот, который по умолчанию навязан xilinx?..
  3. Любопытно, а чем закончился поиск проблемы? ЗЫ Столкнулся с подобной проблемой на zynq-7000. Ведётся работа в режиме AMP: на одном ядре Linux, на другом FreeRTOS. При некоторых условиях всё намертво зависает. Под подозрением FreeRTOS-ная часть. Но нет опыта разбирательства с такими штуками. Подскажите, что почитать по coreSight? Как разобраться с trace? Где бы увидеть примеры использования и поиска подобных багов?..
  4. Google по фразе " Run-Time Debugging Tool " вывел на FreeMASTER Run-Time Debugging Tool. Ещё посмотрел на ucProbe. Интересные штучки, не знал о таком. В принципе половину задачи они могут помочь решить. Одна из целей действительно посмотреть как что-то крутится в некоторой программе управления в режиме реального времени. И такими штуками это, как будто, красиво получается. Но есть ещё одна подзадача - это передача тестовых воздействий с ПК в устройство. (Вернее программа на Cortex-a9 должна будет передать данные в память ПЛИС и далее считать результат обработки и сравнить с тем, что должно быть. А всё крутится на Zynq7000). Может, для такого тоже есть что-то готовое? Для изучения и вдохновения... В общем-то тоже придерживаюсь мнения, что потерь быть не должно. Впрочем потеря пакетов допустима и вряд ли сильно помешает. UDP или TCP - это, скорее, для упрощения реализации программы на ПК. (Можно, наверное, и до голых Ethernet-кадров опуститься. В 1,5 кБ должны умещаться отдельные кванты телеметрии). Так вот я и пытаюсь разобраться какие протоколы существуют и их пригодность. MQTT пугает каким-то непонятным слоем брокер. Вроде бы, для моей задачи ненужная штука. Я уже выше приводил пример альтернативного протокола: Constrained Application Protocol. Он поверх UDP реализуется. И не содержит никакого брокера. ЗЫ Вообще, конечно, чувствую, что изобретаю какой-то велосипед...
  5. - платформа 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. На ПК предполагается специальная программа для пользователя.
  6. Сценарии использования видятся следующими: 1. Запрос параметра - возврат параметра; 2. Запрос телеметрии - непрерывный поток данных телеметрии до запроса отмены телеметрии. Соединение точка-точка.
  7. Добрый день! Есть задача реализовать управление неким устройством через Ethernet-соединение (1G). Требуется управлять включением/выключением некоторых функций. Также требуется при необходимости получать телеметрию (скорость потока - 1..10 Мбайт/с, может и выше в перспективе). (На устройстве будет скорее всего FreeRTOS+lwip, но не исключен вариант и Linux). И тут возник вопрос - какой протокол использовать поверх UDP или TCP соединения (ещё не выбрано)? Придумывать что-то своё? Или есть что-то типовое, что всеми используется?
  8. Подскажите, пожалуйста, а как можно реализовать запись потока 4GByte/s и сколько это может стоить?..
  9. Случайно наткнулся вот на такую штуку: https://www.crowdsupply.com/era-instruments/erasynth Вроде бы, по теме топика.
  10. Не совсем то, что надо. Хочется именно SoC, чтобы на нормальном процессоре некоторые задачи решать... О, точно! Должны возродиться: https://ez.analog.com/thread/93958
  11. Только заинтересовался вот такой игрушкой: 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 не поделили?..
  12. GPS тоже возможен... В открытом поле особенно... https://www.youtube.com/watch?v=PpNhtQW0o7U
  13. Извините, что вмешиваюсь. А вы работали с платками B200/B210? Если да - удавалось ли получить стабильную передачу данных при полосах 15...35 МГц? А то главное разочарование в них для меня - это постоянные потери данных при записи сигнала длиной десятки секунд (при том, что скорость дисковой системы ПК позволяет выполнять запись потоков в 10-20 раз выше требуемой).
  14. :bb-offtopic: Извините, что не по теме... Скажите, а вам удалось добиться стабильной работы от B200/B210. А то не знаю как побороть постоянные разрывы при передаче данных по USB 3.0. В интернете читал только описание такой же проблемы, а решения так и не нашел. Невозможно гарантировать запись даже 30 сек при частоте дискретизации, например 16 МГц... (Дисковая подсистема ПК тут точно не при чем).
×
×
  • Создать...