В.С. Кухарук, В.А. Ухин

В статье рассматривается пример расчета первичных и вторичных параметров дифференциальной пары высокоскоростного интерфейса USB 3.1 в САПР SimPCB Lite, разработанной компанией ЭРЕМЕКС.

При проектировании высокоскоростных интерфейсов на печатной плате важно рассчитывать параметры линий передачи с высокой точностью. Одним из таких интерфейсов является USB 3.1, у которого скорость передачи данных достигает 10 Гбит/с. На таких скоростях несогласованность импеданса может критически повлиять на целостность сигнала, что приведет к некорректной работе всего устройства.

В статье подробно рассматривается процесс вычисления параметров линии передачи с контролируемым дифференциальным волновым сопротивлением для интерфейса USB 3.1 в САПР SimPCB Lite. Расчет ослабления сигнала и перекрестных помех, применительно к USB 3.1, будет рассмотрен в следующих статьях.

Но вначале немного о самом интерфейсе

Интерфейс USB 3.1 — это развитие универсальной последовательной шины (Universal Serial Bus), предложенное как обновление к USB 3.0. Он представляет собой второе поколение спецификации USB 3.x и был представлен USB-IF (USB Implementers Forum) в 2013 году. Давайте рассмотрим его:

Ниже представлены основные особенности интерфейса USB 3.1.

Сравнение USB 3.1 c предыдущими версиями (Таблица 1).

Привет! Меня зовут Андрей, я технический директор в компании КЕДР Solutions. Мы занимаемся контрактной разработкой электроники и программного обеспечения. “Рисуем” платы и кодим уже больше 10 лет! 

В этом материале я решил приоткрыть завесу тайны и рассказать о некоторых особенностях нашего ремесла. Я раскрою специфику нашей внутренней кухни и приведу несколько примеров из нашей практики, как разработка электроники выглядит в реальной жизни. Буду также рад почитать в комментариях о том, как работают другие команды. Затрону следующие вопросы:

Что такое коллективный экспресс (7$/кг) и как его использовать?

Почему с 45$/кг бывает дешевле, чем с 23$/кг?

Как заказать компоненты/всячину с сайтов JLC (jlcfa, lcsc, jlcpcb, …)?

С 1688, Тао бао и других китайских площадок?

Привезти из Европы, США (Маузера, Диджикея и т. д.)?

Где платы с размерами >100х100 мм будут дешевле?

Надеюсь, продуманная навигация по статье и таблицы помогут быстро найти и сравнить полезную информацию.

Некоторое время назад мне удалось-таки сделать обратную разработку нескольких экранов от смартфонов с интерфейсом MIPI DSI.

В какой-то момент пришло время пробовать запускать и проверять наработки, но под рукой не было удобного железа с MIPI DSI видеовыходом. Поэтому решил спроектировать свою плату, а по пути узнать что-то новое.

Обратная и прямая разработки поскакали в одной упряжке :-)

Посмотрим живой процесс разработки. Это всегда интересно!

В первой части рассмотрим несколько решений и выберем наиболее подходящее. А также начнём проектировать схему.

Что стоит самому разработать электронные наручные часы. Можно ли сделать часы простыми и одновременно эффектными. Как совместить в одних часах отладочное средство для изучения программирования и полезный гаджет.

Это были не вопросы, а скорее план действий по разработке наручных часов, которые мне захотелось сделать пару лет назад. Не сказать, что моё увлечение часами помогло мне прокачать мои способности, но времени на это ушло прилично. В результате у меня накопился некий опыт, которым я бы хотел поделиться с теми, кому близка тема создания электронных гаджетов.

Здравствуйте, дорогие читатели Хабра! Я давно хотел поделиться своими знаниями о работе с реестрами под ключ, так как нигде нет четкой и последовательной информации по этой теме. Сегодня мы разберем, как управлять зависимостями через реестры vcpkg и как кэшировать их на сервере.

Желание поиграть в проектирование собственного процессора обычно приводит к покупке платы с FPGA. Но мне захотелось сделать шаг дальше и начать не с Verilog-а, а с паяльника.

Это статья о том, как я занялся разработкой электроники, не имея почти никакого опыта в этой сфере. Цель - сделать устройство с FPGA на котором можно загрузить Linux, подключить экран и клавиатуру, а потом прямо там писать и компилировать код.

Зачем это нужно? Это хобби. Практической ценности не имеет. Просто я так развлекаюсь. А сейчас у меня, к моему собственному удивлению, все задуманное получилось, и я хочу показать и похвастаться.

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

Эта серия статей родилась как заметки на полях к замечательной книге Game Engine Architecture, книга большая, объемная и охватывает все аспекты создания движка. Но там нет нюансов практической разработки. А чтобы видеть нюансы надо понимать не только теорию, все же GAE больше теория, но знать как работает код игры изнутри. Чтобы понимать как, и главное почему, используются выбранные механизмы внутри игры, чтобы видеть проблемы с производительностью и архитектурой, как их искать и как чинить, для этого придется понять как работают и как создавались игровые движки.

Если мне не изменяет память - Кармак сказал, что лучший способ [создания игр] — написать собственный движок ( "The right move is to build your own engine" ), на что многие возразят: это вовсе не так просто. Но папа Doom'a известен не только своим вкладом в разработку игровых движков, но и довольно часто высказывался критически о развитии игровых движков в целом, и о преимуществах создания собственных технологических решений вместо использования готовых.

Эта философия, которой он придерживается на протяжении всей карьеры, была связана с тем, что собственный движок даёт разработчикам полный контроль над технологией и возможность создавать решения, заточенные под конкретные нужды их проектов.

Что больше всего бесит при первом запуске устройств с управлением по Ethernet? Необходимость его искать в сети с использованием зоопарка из подходов. Тут используются программы автопоиска (например Winbox для MikroTik), дефолтные IP адреса (все эти 192.168.1.1, 192.168.100.1, 192.168.2.1 - кто во что горазд). Иногда надо со смартфона показывать QR коды в камеру устройства или передавать настройки тональными сигналами в микрофон. Мы задались целью найти стандарт для поиска устройств в сети и внедрить его в свои устройства на основе микроконтроллеров и/или одноплатных компьютеров. Это статья о стандартах, их особенностях, преодолённых трудностях и об открытом коде, который мы написали для себя и считаем лучшей в мире открытой реализацией SSDP сервера и клиента.

В статье описывается опыт использования ARM ядра, встроенного в ПЛИС GOWIN GW1NSR-4C, в качестве процессора общего назначения для формирования PSK31 сигнала. Сигнал формируется с помощью генератора синуса, который был описан в предыдущей статье. Используются отладочная плата LilyGO T-FPGA, в составе которой ПЛИС GW1NSR-LV4CQN48PC6/I5, ЦАП на основе DAC904, ide GOWIN FPGA Designer и образовательная версия GMD.

❯ Содержание:

• 1. Механическая защита
• 2. Последовательное включение диода
• 3. Параллельное подключение диода
• 4. Диодный мост
• 5. SBR — диоды
• 6. Релейная защита
• 7. Схема защиты на полевом транзисторе P-типа
• 8. Полевой транзистор N-типа с бустерной накачкой затвора
• 9. Биполярные транзисторы в качестве защиты от переполюсовки

Разработка контроллера шагового двигателя

Высоковольтный драйвер шагового мотора. Схема почти полностью на китайских элементах. Питание схемы 75В. Создание дешёвого проекта во время кризиса полупроводников в 2022.

Для более быстрого старта обучения дизайнера уровней, разобрал частые ошибки новичков, с примерами и решениями.

В данной статье подробно рассмотрим, как собрать ядро, поддерживающее EVL core, и библиотеку, реализующую пользовательский API для этого ядра. А также разберем некоторые аспекты реализации драйвера устройства и приложения под Xenomai 4.

Xenomai — Фреймворк для разработки приложений реального времени на базе ядра Linux. Проект Xenomai был запущен в 2001 году с целью эмуляции традиционной ОСРВ и облегчения ее переноса на GNU/Linux с сохранением гарантий работы в режиме реального времени. Изначально Xenomai был связан с RTAI (интерфейсом приложений реального времени), но на данный момент он независим.

Мы будем работать с Xenomai версии 4. Xenomai 4 имеет архитектуру с двумя ядрами. Первое ядро Linux: для задач, отличных от реального времени, и ядро Xenomai: для задач реального времени. Ядро Linux и ядро реального времени работают практически асинхронно, оба выполняют свой собственный набор задач, всегда отдавая последнему приоритет над первым. Для осуществления доступа к основным сервисам реального времени в проекте Xenomai предусмотрена библиотека С, известная как libevl.

Xenomai поддерживает множество архитектур, таких как PowerPC, Blackfin, ARM, x86, x86_64 др. В данной статье мы используем компьютер c архитектурой x86_64 (Процессор: 12th Gen Intel® Core™ i5-12400 × 12, память: 32,0 ГиБ), операционной системой Debian GNU/Linux 12 (bookworm).

И снова здравствуй, Хабр! Мы добрались до второй части повествования о параллельном запуске двух ОС на FPGA с процессорной подсистемой. 

В этой статье мы сначала определим минимально необходимые компоненты для запуска Embedded Linux. Затем осуществим сборку под ARM стандартными инструментами производителя и под Soft-CPU «вручную». И наконец, подготовим загрузочный носитель, чтобы подойти во всеоружии к запуску и верификации проекта, которые ожидают нас в заключительной части цикла.

Ошибки программистов C++ — это отдельный вид искусства, вроде бы простой язык, но стоит отвлечься на чашечку кофе, как компилятор начинает вываливать простыню ворнингов пополам с ошибками, и иногда это больше похоже на древнеегипетские письмена, чем на нормальный выхлоп. Вы наверное и сами не раз сталкивались с разыменованием nullptr или перепутали (= и ==) по недосмотру. Часто причиной ошибкой является лень или невнимательность, или усталость - не зря появились суеверия "не комитить в пятницу вечером", "не кодить в состоянии изменного сознания" или "избегать кода под кофейным угаром", ну это когда три-четыре кружечки кофе навернул и пошел нести добрый код направо и налево.

Вообще статья планировалась про то как можно поиздеваться над switch оператором - была у меня запись разговора с одного питерского митапа, проходившего несколько лет назад и где присутствующим предложили написать "невозможный", но работающий код со switch. И вот в поисках этой записи я наткнулся на файл с описанием "пятничных" багов и комитов, которые бы в трезвом уме посреди недели врядли бы проскочили в мастер. А еще была статья тоже про ошибки "Федя, дичь", где уважаемый хабрачитатель угадывал причину разных ошибок, явных или не очень. Поэтому я решил продолжить в том же стиле, вопрос - ответ, а вам предлагаю также поучаствовать в отгадывании возможных причин. Все примеры из реальных проектов, игр, движков и пятничных комитов.

C++ не прощает ошибок, но именно в этом его "шарм". В большинстве приведенных примеров сохранен стиль и названия параметров, только немного подчищены коментарии, дабы не палить контору.

Среди множества задач, решаемых программистом, одной из самых частых является подумать и добавить новый функционал в приложение. И там уже может быть много похожего функционала, он может быть хорошо написан, хорошо документирован. Искушение заключается в том, поддаться своей лени и задействовав специфические мышцы левой руки поместить чужой код в "новый" функционал. Другими словами, очень хорошо спроектированный код (равно как и очень плохой) готовит к разработке методом копипасты последующие поколения разработчиков. То есть мы находим в нашем коде что-то похожее на то, что мы хотим добавить, копируем это и вставляем, меняя небольшие детали, специфичные для нашей новой функции. Или находим что-то похожее на stackoverflow. Я отнюдь не против поиска и даже отдельных моментов разработки через анализ чужих решений, в любом случае код придется понять, принести, адаптировать. Да чего греха таить, я тоже не пишу весь код из головы.

Игры бывают разные, большие и маленькие, триA и супер инди, в компаниях с сотнями разработчиков и что создаются самородками-одиночками. Редко их делают с нуля и пишут код только игры, чаще пишут игровые тулы, редактор и параллельно пишут саму игру. За всей этой многомиллиардной индустрией стоит код, много кода, очень много кода. Игровые движки и фреймворки – мощные инструменты, которые помогают разработчику творить его идеи и создавать увлекательные игровые миры. Это каркас, на котором строятся все игровые вселенные, они включают в себя сотни инструментов, библиотек и ресурсов, позволяя разработчикам превратить строчки кода в театр для одного зрителя.

Существует более сотни игровых движков, каждый из них содержит как минимум одну фичу которой нет ни в каком другом. Всех возможностей вместе нет ни в одном, и это прекрасно - иначе бы такой движок монополизировал рынок. Хм, Unreal5 ты ли это? Иногда полезно пробежать по release notes движка, чтобы оставаться в курсе последних новостей. Возможно вы разрабатываете свое решение и эта статья натолкнет вас на новые идеи. Готовы узнать что ваша любимая игры была сделана не на Unity, а на православном SDL?

В ранние годы развития компьютеров программисты могли лишь мечтать о портируемости. Все программы писались непосредственно в машинном коде для каждой компьютерной архитектуры, на которой они должны были работать. Языки ассемблера с мнемоническими именами каждой команды CPU и другие удобства сильно упростили жизнь программистов, но программы по-прежнему были привязаны к архитектуре. Тогда ещё не изобрели операционных систем, поэтому программа не только управляла всей компьютерной системой, но и должна была инициализировать всю периферию, а также управлять ею. На самом деле, такие низкоуровневые программы реализовывали драйверы для каждого используемого ими устройства. И каждый раз, когда программу нужно было перенести на оборудование с другой архитектурой, она в буквальном смысле переписывалась с учётом различий архитектуры набора команд CPU, структуры памяти и так далее.

Именно так произошло с Unix, который изначально был написан Кеном Томпсоном на языке ассемблера более пятидесяти лет назад. Первые версии Unix писались для платформы PDP-7, а для портирования его на PDP-11 нужно было переписывать код. Когда Дэннис Ритчи создал язык программирования C, и вместе с Томпсоном они переписали на нём основную часть кода Unix, внезапно оказалась возможной портируемость ПО. Тому были две главные причины. Во-первых, код, написанный на языке высокого уровня, не зависит от платформы, потому что компиляторы транслируют его в язык ассемблера целевой архитектуры. Это ещё важнее для целевых платформ на основе процессоров RISC, так как они требуют написания гораздо большего количества ассемблерных команд, чем процессоры CISC. Даже при портировании Unix на другую платформу основная сложность заключалась лишь в адаптации зависящих от архитектуры частей кода. С другой стороны, сама операционная система абстрагирует все особенности оборудования от пользовательской программы.

Программистам не нужно реализовывать многозадачность, управление памятью и драйверы для используемых ими устройств, потому что всё это часть ядра ОС и работает в адресном пространстве ядра. Пользовательские программы работают в пользовательском адресном пространстве и получают доступ ко всем предоставляемым ОС функциям при помощи интерфейса системных вызовов. В ОС реального времени, например, в Zephyr OS ситуация немного отличается, но принцип изоляции и защиты памяти для пользовательских программ сохраняется. Это приводит к двум выводам: