Отладка *

MIK32 АМУР или K1948ВК018 является российским микроконтроллером (МК) с ядром на открытой архитектуре RISC‑V. По какой‑то причине производитель МК ГК «Микрон» предлагает в качестве средства разработки,‑ средство на базе Eclipse, но исключительно под Windows, что далеко не всех устраивает. А также, в руководстве по эксплуатации на данный МК, предлагается использовать VS Code, и это конечно более универсальный (кроссплатформеный) вариант, но предполагает использование VS Code совместно с плагином PlatformIO, что опять же устраивает далеко не всех. Поэтому я рассмотрю в данном руководстве старт работы с отладочной платой MIK32-DIP в ОС GNU/Linux в IDE Eclipse.

Чтобы начать работу вам понадобятся:

В этом тексте вы узнаете, что общего между I2S трансивером и оладьями.

Да... Именно так. А также зачем программисту микроконтроллеров конвейеры и цифровые фильтры.

В тексте изложено про то, как источать звук при помощи I2S + DMA.

Колесо крутится, но хомячок подписки помер. Оно просто крутится.

В начале я хотел бы сказать, что описанные в статье практики очень плохи и неправильны (с тех пор мы добавили надёжные юнит-тесты и интеграционные тесты, а также систему алертов/логирования), что их следует избегать и в первую очередь это человеческие ошибки, которые задним умом кажутся очевидными.

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

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

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

Думаю, что каждый из embeded-разработчиков хотя бы раз в жизни пользовался терминалом для работы с COM-портом ПК - простой программой, позволяющей персональному компьютеру через встроенный интерфейс RS-232 (или USB-переходник) общаться с внешними устройствами, например такими, как GSM-модем или просто обмениваться данными с микроконтроллером в процессе разработки и отладки прошивки.

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

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

Давайте попробуем оптимизировать самый времязатратный этап разработки устройств на базе ПЛИС — отладку прошивки. В этой статье мы расскажем о принципе 20/80 при планировании времени, рассмотрим инструменты для отладки FPGA, вспомним Гордона Мура и Уинстона Черчилля (да-да), затроним отладку сложных распределенных систем и внешних интерфейсов, а в конце — разберемся с типичными ошибками и поделимся полезными практическими советами.

Для начала рассмотрим типовой цикл разработки и моделирования FPGA-прошивки:

Это очередная статья из цикла «BPF для самых маленьких» (0, 1, 2) и первая из серии практических статей про трассировку Linux современными средствами.

Из нее вы узнаете о программе и языке bpftrace — самом простом способе погрузиться в мир BPF с практической точки зрения, даже если вы не знаете про BPF ровным счетом ничего. Утилита bpftrace позволяет при помощи простого языка прямо из командной строки создавать программы-обработчики и подсоединять их к огромному количеству событий ядра и пространства пользователя. Посмотрите на КПДВ ниже… поздравляю, вы уже умеете трейсить системные вызовы при помощи bpftrace!

В отличие от предыдущих статей серии, эта относительно короткая и ее основная часть написана в формате туториала, так что уже после пяти минут чтения вы сможете создавать обработчики и собирать статистику о любом событии в ядре Linux прямо из командной строки. В конце статьи рассказывается об альтернативах — ply и BCC. Минуты во фразе «после пяти минут чтения» подразумеваются меркурианские. Появление уникальных навыков после пяти минут чтения не гарантируется.

Обратная отладка - это как прокрутить фарш назад. Как запихнуть желток и белок обратно в скорлупу. Как сделать доллар по 6 рублей. В общем, она помогает нам находить источники сбоев в программах, перемещаясь "назад во времени" от места их возникновения.

В MSDN'овской статье Process Security and Access Rights есть интересная ремарка:

… if process A has a handle to process B with PROCESS_DUP_HANDLE access, it can duplicate the pseudo handle for process B. This creates a handle that has maximum access to process B.

Если вольно перевести это на русский, то тут говорится, что имея описатель на процесс с правом доступа PROCESS_DUP_HANDLE мы можем, используя функцию DuplicateHandle(...), получить описатель с максимально разрешенными масками доступа на этот процесс.

Это хитрость, о которой я узнал совсем недавно у Senior Android разработчика в моей компании, и теперь я чувствую себя несчастным, сожалея о времени, которое я провел в ожидании сборки Gradle, чтобы проверить свои изменения при написании Android приложений.

• Как начать работать с MIPSfpga
• MIPSfpga – практический опыт
• MIPSfpga и внутрисхемная отладка

1. исполнение кода, данного пользователями, как на ideone.com,
2. «ну мало ли зачем» и
3. «а это уже отдельный вопрос»

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

pgTap – это расширение PostgreSQL для разработки юнит-тестов. Сами тесты, как, собственно, и pgTap, пишутся на plpgSQL, что означает низкий порог вхождения для разработчиков PG.

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

Приветствую еще раз.

Это 2 часть небольшой статьи об отладчиках. В прошлой мы разобрали базу: инструкции + системные вызовы, написали свой отладчик, препарировали gdb и смотрели на отладку в высокоуровневых ЯП со своим рантаймом.

В этой мы посмотрим на процесс отладки в IDE изнутри, а потом пойдем еще глубже...

Привет, Хабр! Меня зовут Роман Вернин, я разработчик систем на кристалле в компании Аквариус. Вместе с коллегами мы разрабатываем микросхемы ASIC. В этой статье я хотел бы поделиться опытом, как можно использовать отладочное средство ПЛИС от фирмы Intel для тестирования, настройки или исследования устройств и стендовых систем.

Этой частью завершается серия статей, рассказывающих о разработке и тестировании сумматора с AXI-Stream интерфейсами. Мы покажем, как можно улучшить тестовое окружение за счет добавления возможности его настройки без повторной перекомпиляции исходников. Также мы модифицируем драйверы и мониторы AXI-Stream интерфейса, чтобы их можно было повторно использовать в других окружениях и проектах.