Ну, насчёт определения скорости — если честно, то мне просто хотелось поставить жирную точку с запятой в процессе. Я с 2017 года активно играл в создание анализатора. Хотелось сказать: «Работает — теперь пользуемся, а создаём теперь что-нибудь другое». Поэтому глубже пока разбираться не стал. А для тех, кто вдруг захочет взять идею и развить — описал, что удалось найти. У производителей же коммерческих анализаторов выбора нет. Им надо сделать, и всё тут. Но у них чаще всего цена такая, что можно в схему поставить не только ULPI.
Что касается формата — конечно же хочу! Если есть возможность не тратить время на разработку полноценного декодера, но получить его малой кровью для личных нужд — этим же надо пользоваться!
Нет, всё было не настолько плохо. Она спросила. И в целом — можно и отказаться. Но она будет надоедать своим поведением. Я в своё время с PSoC этой же фирмы разбирался. Тогда месяц постоянно отказывался, потом всё равно сдался. Но я тогда искал, как автообновление отключить — не нашёл. Поэтому сейчас особо и не стал спорить. Их софт обновляется весь оптом. Один менеджер показывает список для всего, что установлено. Сам стартует, сам смотрит, сам нудит, мол, пора, а то завтра снова пристану.
Это предложение или предположение? :)
Нет, не хотим. Мы даем поработать с настоящими платами из разных инструментов, может и PlatformIO поддержим. Но у нас нет цели создать подобный инструмент — они уже есть и они классные.
Хм, да, по портам — аппаратно у нас все готово, а программную часть — ждем оказии, например, если запустим с кем-то учебный курс или вебинар, в котором этот функционал потребуется.
С аналоговым вводом-выводом чуть сложнее. В принципе как делать — понятно. Виртуальный логический анализатор и пр. Но там уже и некоторая аппаратная поддержка понадобится. Думаю до этого тоже доберемся, но позже.
Да, разнообразие будет расти. Не думаю что получится прям «все-все», но, как вариант, начать с новинок (например, L5 вышли совсем недавно, а у нас уже есть). А по источникам и наблюдателям — какой вариант был бы удобен для вас? Или хоть какие-то?
Возможности имитировать работу с тачем пока нет. Было бы очень интересно, если бы кто-то из читателей предложил хороший способ это сделать. Сейчас мы ориентируемся на образование, а работа с тачем, кажется, нужна на этапе создания реального потребительского устройства. Но в этой задаче удаленного доступа в любом случае уже недостаточно. Так что по поддержке тача ситуация двойтсвенная — с одной стороны интересно было бы сделать, с другой — кажется что слишком сложно, учитывая вроде бы отсутствующий на этот функционал спрос.
Это да, выбор пока скромный. И добавить то плат не проблема, тут скорее вопрос — а какие платы должны там быть? Вот ваши платы, например — они интересные, но очень недорогие, и, кажется, тот, кому они интерены, легко их купит и не станет заморачиваться с удаленкой. А вы как считаете, какие платы должны быть представлены? Ну и даже пусть подходящих для вас плат пока нет — поделитесь, что бы делала ваша гипотетическая прошивка-победитель?
Это — посыл, что отвечать на уточняющие вопросы вправо-влево от основной линии статьи я не смогу. Правда, если надо — я их переадресую тем, кто это всё реализовывал.
Про мои познания в Линуксе я пишу не впервые. Был бы «ацтой» — я бы не проводил обучение в стиле «смотрите, я сам разобрался, сейчас научу всех, кто хочет это сделать, но пока боится». Например, тут. Не стал бы разжёвывать для таких, как я, чёткие правила именования последовательных устройств (в сети, что я находил — всё было обрывочно). Не стал бы учить достукиваться до любых блочных накопителей (кстати, жутко провальная статья и по просмотрам, и по рейтингу, никому это не интересно).
В общем, самоуничижение — это не потому, что я считаю Линукс плохим. Не переживайте. Просто я начинал с RT-11 на ДВК и СМ ЭВМ, потом — ДОС (это не только командная строка, это Int 21h, Int15h, Int 10h и прочие полезные прерывания), потом — WIN3.1… А потом я был уже безвозвратно испорчен. Если кто-то задаст наводящие вопросы в комментариях — я поплыву. Чем позориться — лучше сразу предупредить, что меня самого сейчас потихоньку учат. Ну, а я — стараюсь уровень остальных подтягивать, не будучи при этом гуру.
Ну, из тех, с кем я общался — никто про этот велосипед не знал. Мало того, когда я стал гуглить — тоже не нашёл ничего в целостном виде. Каждая из частей отдельно — да, есть, если про неё знать. Всё, собранное в кучу — (проброс через socat, настройка пользователя, чтобы клиенту ничего не требовалось делать, программная работа из Windows) — нигде.
Так что если хотя бы 50% читателей узнали что-то новое — уже писать стоит.
Что касается гибкости настроек — я не совсем понял вопрос. Потребности в общении с удалённым микроконтроллером при удалённой же отладке, этот способ закрывает. Скорость задать можно, прокачать данные — тоже. А управление потоком всё равно в подавляющем большинстве случаев при работе с контроллерами не используется.
Да само-то изделие тривиальное. Его мой знакомый по моим эскизам за один вечер набросал в PCAD и ещё за один — развёл. Оно интересно именно методикой разработки «прошивки». Большинство знакомых делают без применения «стержня» (Platform Designer). Вернее, некоторые уже не делают, а делали. Вроде, я кое-кого сумел уже убедить сменить подход.
В общем, тут изделие само — тривиально. Предыдущее (Redd) было посложнее, но идеологически — тоже типовое с точки зрения железа. Важно показать тем, кто работает по-старинке, что есть красивая методика, как быстро и удобно «прошивки» писать. И я это делаю, по мере сил.
Если что-то и рассказывать, то в этом направлении. Но опять же, «серьёзные» разработчики это и так знают. Я этих методик от разных «серьёзных» людей нахватался, только с Xilinx на Альтеру перенёс идеи.
Сейчас не по велению сердца, а по желанию Заказчика разбираемся с Litex и RISC-V. Там у всех шин стоят таймеры, которые таймауты ловят. Забавная штука. Заодно удобно проверять, что попал в область адресного пространства, которая не имеет аппаратуры. Если запись/чтение ужасно тормозят — значит как раз на такой таймер попал. Причём там это принудительно добавляется, отказаться, не применяя бубен, нельзя. Но зато точно ничего не подвиснет. Шина точно будет освобождена.
Кстати, а если slave медленнее(ну мало ли) чем spi?
Об этом я позаботился в прошлой статье. Мастер точно тормознутый. Проверено! Я этот анализатор задумал в 2017-м и очень активно делаю уже год. Некогда идеала достигать было! Надо было уже добить его! Опять же, в статье показан подход, как проектировать, не тратя излишних усилий, если они не нужны.
Как выжимать из системы побольше — уже было. Например, первая часть, вторая часть и третья часть. Или вот. Ну, или вот. Но иногда лучше выиграть по сроку разработки, если производительности и так хватает.
P.S. conduit_end можно было бы назвать как-то более подходяще по смыслу
Это Квартус так назвал. А я просто не стал переименовывать. Как-то привык в таких простых вещах переименовывать только то, что без смены имени работать не будет. Каждой линии SPI пришлось сменить имя. А тут… Работает и ладно. Вот если бы их было два! Там имело бы смысл осмысленные имена дать, чтобы самому не запутаться.
В цикле остались две штуки. Они уже сделаны, просто ещё на Хабр не выложены (теги вписывать — не в WORDе форматирование делать). И что дальше — пока не придумал. Но в анализатор уже по проекту реально играю. Проект как ждал, чтобы вовремя свалиться.
Первое — в следующей статье я покажу, что мне крайне невыгодна реально высокая скорость SPI. Я в ПЛИС автомат построил такой, который не терпит высокой скорости. А более крутой — не хотелось тратить время на разработку.
Дальше — я играл в SPI и даже в SDIO на разновидности FX3 по имени FX3S. Там работа была возможна только через хитрый API. Как я уже отметил, API у Кипарисов уж чересчур хитрый. Наверняка можно и напрямую через порты, но не хотелось тратить время на изучение.
Опять же, когда я просил товарища развести мне плату — не было времени детально разбираться и указывать настоящие SPI ноги (я до сих пор не знаю, какие именно нужны были бы, и есть ли они у FX3 без S). Тем более, что на тот момент у меня ещё не было видения, как я буду управлять ПЛИСкой со стороны FX3. Про SPI придумалось во время проекта на базе Litex, когда я играл в переходники «что угодно в WISHBONE». Именно тогда я подумал, что почему бы не сделать свой SPI в AVALON_MM?
В общем, управляющие ноги на плате выбраны по принципу «А почему бы и нет?». Сейчас я работаю на уже готовой плате. Так что на ней — только через GPIO и программную шину.
Итого, технических причин нет. Все — глубоко личные. Для моей задачи хватит этого, тратить время на ненужное — нет этого самого времени, а к статье это относится всё равно чисто, как вспомогательная вещь. Так что статью про Vendor команды вполне не стыдно было написать и с таким уровнем SPI.
А для моей задачи — я уже в этой статье писал, что «я не проверяю статуса, ведь я знаю, что всё работает медленно, так что точно успеет отработать». И перейдя с TCL на С++ и USB3, я продолжаю говорить то же самое. Теперь гарантированная задержка возникает в SPI. Удобно! Для данной конкретной задачи, разумеется.
В синхронном режиме у нас получилось использовать её только с восьмибитными данными (по документации, старший байт в этом режиме не используется). И конкретно я не понял, можно ли там посылать что-то, что будет информировать ПЛИС, что перед нею команда. Только поток слать у меня получилось (я специально отмечаю, что «у меня» — может я просто слепой).
В общем, если мы будем делать новую ревизию платы Redd, то выкинем её. Одна из задач игр в FX3 — чтобы понять, можно рассматривать её на замену, или лучше поставить очень старую, но очень добрую FX2LP.
В следующей статье я буду в FX3 команды слать как раз через EP0. А через одну — этими командами до AVALON_MM достукиваться. Один из законов Мерфи гласит: «Всякую вещь можно наладить, если достаточно долго вертеть её в руках». Вот FX3 у меня налаживается быстрее, чем FT2232H (ту я бросил быстрее, чем получил что-то красивое).
Но знакомый, который работает через FT600 — говорит, что он у себя тоже уже всё наладил. В отличие от FT2232H, там можно через разные точки разные потоки слать, как он говорит. Получается поток команд и поток данных, например. То есть, FTDI тоже идёт навстречу пользователям… Хотя, про латентность у FT600 он тоже говорил много нехороших слов. Так что грабли есть везде.
Это не из разряда «146%». Как я отмечал в тексте, на выходе ULPI чуть больше шестидесяти мегагерц осциллограф видит. Отсюда и набег.
Большое спасибо!
В целом — классно, а в частности — как исследую все детали, так опишу. Я собирался описывать это в плане большой и красивой кнопки Cancel, отображения процентов полученного буфера и т.п.
Ага, я начерно уже играл в это для изохронных транзакций, чтобы ловить бесконечный поток аудио. Начисто, с замерами для Bulk — чуть попозже собирался попробовать. Если найду там чего-то интересного, то тоже опишу. При играх с изохроном мне показалось, что на сверхвысоких скоростях может выйти заминка, но пока не ощупаю — боюсь что-то утверждать наверняка. Она может быть, может не быть. Просто смущает необходимость в бесконечном цикле вызывать libusb_handle_events(). Что будет, если на бешеной скорости поток задумается и не сделает этого вовремя? Опять же, надо разобраться, как выводить систему из последнего входа в эту функцию, если устройство долго не шлёт ничего. Так что сначала тщательная проверка, как будет время свободное. Слишком много вопросов, на которые надо ответить перед тем, как начать пользоваться.
Ну, мне доводилось работать с переходниками USB3 в SATA на уровне конечных точек, чтобы BADы на диске не приводили к проблемам.
Что же до примера — мне почему-то кажется, что правильно спроектированный драйвер USB должен все зачистки производить по событию «отключилось приложение». Мало того, при выдёргивании-то уж из разъёма, сама система всё должна зачистить. Так что мне кажется, что этот вариант — уже излишество. Как минимум — никто же в жизни так не делает. Или, по крайней мере, мне не известно, чтобы делал. Всегда Windows даже если узнает устройство в новом разъёме — стремится установить его драйвер. Жёлтые восклицательные знаки в диспетчере устройств Windows — скорее исключение, чем правило, значит, драйвер старается быть установленным. Хотя, здесь всё это — не догма. Если окажется, что кто-то так делает — я сначала пощупаю на практике, а потом уже буду какие-то выводы для себя делать. Но пока не встречал именно для USB.
Что же до фильтра UsbDK- скорее всего, виновато именно то, что он хранит свои собственные списки, поэтому выдёргивание-вставка устройства и не помогает. Причём исходники у него открытые, наверняка всё можно поправить. Но внутри он достаточно сложен, поэтому на разбирательство нет времени.
1) В этой статье я постарался раскрыть тему про работу USB вообще, а не про Кипарисов в частности. Вот завтра придётся пользоваться чем-то другим, и как людям быть? Проще взять драйвер, который будет работать с любым чипом. Кипарисы ограничились своими (как минимум, лицензионно)… Как хотят. Ну, и плюс да, формально эта система может попасть в следующую версию нашего комплекса Redd, про который был предыдущий цикл статей. А там базовая ОС — Linux. Так что libusb тут идеален. Он везде подойдёт.
При этом упомянуть существование CyUSB (и CyAPI) было нужно. Вдруг кто-то решит, что ему это подходит и дальше разберётся по документации? Во времена FX2LP я сам только так и работал.
2) Хоть WinUsb, хоть CyUSB, хоть UsbDK по умолчанию грузятся при старте ОС обычно. Если дадите ссылку на описание Вашего варианта, чтобы было ясно, как настроить и как действовать — будет полезно.
3) Конечная цель цикла — разработка анализатора с потоковой передачей данных, без буферизации на самой плате. Верхний предел скорости известен. ULPI тактируется частотой 60 МГц. Голова выдаёт 16 разрядные данные. Итого 120 миллионов байт в секунду. Если бы система не прогоняла через себя такой поток — дальше в неё играть было бы бесполезно. Вариант с буферным SDRAM уже есть, он описывался в нескольких статьях предыдущего цикла про Redd, а прогнать из SDRAM в PC можно и через USB 2.0. Так что надо было или 120, или нисколько. К счастью, всё прокачалось без потерь. Правда, с данными, которые могут то начать течь, то остановиться — есть ещё одна весёлость, о ней я расскажу отдельно.
Что касается формата — конечно же хочу! Если есть возможность не тратить время на разработку полноценного декодера, но получить его малой кровью для личных нужд — этим же надо пользоваться!
Нет, не хотим. Мы даем поработать с настоящими платами из разных инструментов, может и PlatformIO поддержим. Но у нас нет цели создать подобный инструмент — они уже есть и они классные.
С аналоговым вводом-выводом чуть сложнее. В принципе как делать — понятно. Виртуальный логический анализатор и пр. Но там уже и некоторая аппаратная поддержка понадобится. Думаю до этого тоже доберемся, но позже.
Про мои познания в Линуксе я пишу не впервые. Был бы «ацтой» — я бы не проводил обучение в стиле «смотрите, я сам разобрался, сейчас научу всех, кто хочет это сделать, но пока боится». Например, тут. Не стал бы разжёвывать для таких, как я, чёткие правила именования последовательных устройств (в сети, что я находил — всё было обрывочно). Не стал бы учить достукиваться до любых блочных накопителей (кстати, жутко провальная статья и по просмотрам, и по рейтингу, никому это не интересно).
В общем, самоуничижение — это не потому, что я считаю Линукс плохим. Не переживайте. Просто я начинал с RT-11 на ДВК и СМ ЭВМ, потом — ДОС (это не только командная строка, это Int 21h, Int15h, Int 10h и прочие полезные прерывания), потом — WIN3.1… А потом я был уже безвозвратно испорчен. Если кто-то задаст наводящие вопросы в комментариях — я поплыву. Чем позориться — лучше сразу предупредить, что меня самого сейчас потихоньку учат. Ну, а я — стараюсь уровень остальных подтягивать, не будучи при этом гуру.
Так что если хотя бы 50% читателей узнали что-то новое — уже писать стоит.
Что касается гибкости настроек — я не совсем понял вопрос. Потребности в общении с удалённым микроконтроллером при удалённой же отладке, этот способ закрывает. Скорость задать можно, прокачать данные — тоже. А управление потоком всё равно в подавляющем большинстве случаев при работе с контроллерами не используется.
В общем, тут изделие само — тривиально. Предыдущее (Redd) было посложнее, но идеологически — тоже типовое с точки зрения железа. Важно показать тем, кто работает по-старинке, что есть красивая методика, как быстро и удобно «прошивки» писать. И я это делаю, по мере сил.
Если что-то и рассказывать, то в этом направлении. Но опять же, «серьёзные» разработчики это и так знают. Я этих методик от разных «серьёзных» людей нахватался, только с Xilinx на Альтеру перенёс идеи.
Об этом я позаботился в прошлой статье. Мастер точно тормознутый. Проверено! Я этот анализатор задумал в 2017-м и очень активно делаю уже год. Некогда идеала достигать было! Надо было уже добить его! Опять же, в статье показан подход, как проектировать, не тратя излишних усилий, если они не нужны.
Как выжимать из системы побольше — уже было. Например, первая часть, вторая часть и третья часть. Или вот. Ну, или вот. Но иногда лучше выиграть по сроку разработки, если производительности и так хватает.
Это Квартус так назвал. А я просто не стал переименовывать. Как-то привык в таких простых вещах переименовывать только то, что без смены имени работать не будет. Каждой линии SPI пришлось сменить имя. А тут… Работает и ладно. Вот если бы их было два! Там имело бы смысл осмысленные имена дать, чтобы самому не запутаться.
В цикле остались две штуки. Они уже сделаны, просто ещё на Хабр не выложены (теги вписывать — не в WORDе форматирование делать). И что дальше — пока не придумал. Но в анализатор уже по проекту реально играю. Проект как ждал, чтобы вовремя свалиться.
Первое — в следующей статье я покажу, что мне крайне невыгодна реально высокая скорость SPI. Я в ПЛИС автомат построил такой, который не терпит высокой скорости. А более крутой — не хотелось тратить время на разработку.
Дальше — я играл в SPI и даже в SDIO на разновидности FX3 по имени FX3S. Там работа была возможна только через хитрый API. Как я уже отметил, API у Кипарисов уж чересчур хитрый. Наверняка можно и напрямую через порты, но не хотелось тратить время на изучение.
Опять же, когда я просил товарища развести мне плату — не было времени детально разбираться и указывать настоящие SPI ноги (я до сих пор не знаю, какие именно нужны были бы, и есть ли они у FX3 без S). Тем более, что на тот момент у меня ещё не было видения, как я буду управлять ПЛИСкой со стороны FX3. Про SPI придумалось во время проекта на базе Litex, когда я играл в переходники «что угодно в WISHBONE». Именно тогда я подумал, что почему бы не сделать свой SPI в AVALON_MM?
В общем, управляющие ноги на плате выбраны по принципу «А почему бы и нет?». Сейчас я работаю на уже готовой плате. Так что на ней — только через GPIO и программную шину.
Итого, технических причин нет. Все — глубоко личные. Для моей задачи хватит этого, тратить время на ненужное — нет этого самого времени, а к статье это относится всё равно чисто, как вспомогательная вещь. Так что статью про Vendor команды вполне не стыдно было написать и с таким уровнем SPI.
А для моей задачи — я уже в этой статье писал, что «я не проверяю статуса, ведь я знаю, что всё работает медленно, так что точно успеет отработать». И перейдя с TCL на С++ и USB3, я продолжаю говорить то же самое. Теперь гарантированная задержка возникает в SPI. Удобно! Для данной конкретной задачи, разумеется.
Подробнее — тут и чуть-чуть тут
В общем, если мы будем делать новую ревизию платы Redd, то выкинем её. Одна из задач игр в FX3 — чтобы понять, можно рассматривать её на замену, или лучше поставить очень старую, но очень добрую FX2LP.
В следующей статье я буду в FX3 команды слать как раз через EP0. А через одну — этими командами до AVALON_MM достукиваться. Один из законов Мерфи гласит: «Всякую вещь можно наладить, если достаточно долго вертеть её в руках». Вот FX3 у меня налаживается быстрее, чем FT2232H (ту я бросил быстрее, чем получил что-то красивое).
Но знакомый, который работает через FT600 — говорит, что он у себя тоже уже всё наладил. В отличие от FT2232H, там можно через разные точки разные потоки слать, как он говорит. Получается поток команд и поток данных, например. То есть, FTDI тоже идёт навстречу пользователям… Хотя, про латентность у FT600 он тоже говорил много нехороших слов. Так что грабли есть везде.
120046706 Bytes / Sec
Это не из разряда «146%». Как я отмечал в тексте, на выходе ULPI чуть больше шестидесяти мегагерц осциллограф видит. Отсюда и набег.
Большое спасибо!
В целом — классно, а в частности — как исследую все детали, так опишу. Я собирался описывать это в плане большой и красивой кнопки Cancel, отображения процентов полученного буфера и т.п.
Спасибо за ремарку!
Что же до примера — мне почему-то кажется, что правильно спроектированный драйвер USB должен все зачистки производить по событию «отключилось приложение». Мало того, при выдёргивании-то уж из разъёма, сама система всё должна зачистить. Так что мне кажется, что этот вариант — уже излишество. Как минимум — никто же в жизни так не делает. Или, по крайней мере, мне не известно, чтобы делал. Всегда Windows даже если узнает устройство в новом разъёме — стремится установить его драйвер. Жёлтые восклицательные знаки в диспетчере устройств Windows — скорее исключение, чем правило, значит, драйвер старается быть установленным. Хотя, здесь всё это — не догма. Если окажется, что кто-то так делает — я сначала пощупаю на практике, а потом уже буду какие-то выводы для себя делать. Но пока не встречал именно для USB.
Что же до фильтра UsbDK- скорее всего, виновато именно то, что он хранит свои собственные списки, поэтому выдёргивание-вставка устройства и не помогает. Причём исходники у него открытые, наверняка всё можно поправить. Но внутри он достаточно сложен, поэтому на разбирательство нет времени.
При этом упомянуть существование CyUSB (и CyAPI) было нужно. Вдруг кто-то решит, что ему это подходит и дальше разберётся по документации? Во времена FX2LP я сам только так и работал.
2) Хоть WinUsb, хоть CyUSB, хоть UsbDK по умолчанию грузятся при старте ОС обычно. Если дадите ссылку на описание Вашего варианта, чтобы было ясно, как настроить и как действовать — будет полезно.
3) Конечная цель цикла — разработка анализатора с потоковой передачей данных, без буферизации на самой плате. Верхний предел скорости известен. ULPI тактируется частотой 60 МГц. Голова выдаёт 16 разрядные данные. Итого 120 миллионов байт в секунду. Если бы система не прогоняла через себя такой поток — дальше в неё играть было бы бесполезно. Вариант с буферным SDRAM уже есть, он описывался в нескольких статьях предыдущего цикла про Redd, а прогнать из SDRAM в PC можно и через USB 2.0. Так что надо было или 120, или нисколько. К счастью, всё прокачалось без потерь. Правда, с данными, которые могут то начать течь, то остановиться — есть ещё одна весёлость, о ней я расскажу отдельно.