У меня есть забавный профессиональный рефлекс, который выработался у меня за годы работы. Я, как человек, находящийся сразу в обеих лагерях игровой индустрии и в окопах разработки, и в кресле дизайнера — на слово «память» реагирую уточняющим вопросом:

— «О какой именно памяти мы говорим?»

Зачастую, конечно, речь идет о ней родимой — об оперативной памяти компьютера. О RAM, гигабайтах, скорости загрузки, прогрузке полигонов и вот этом всем техническом великолепии, которое заставляет наши игры выглядеть и работать так, как они работают. Это понятный, измеримый, абсолютно конкретный ресурс, с которым мы, как разработчики, постоянно боремся, пытаясь впихнуть невпихуемое и оптимизировать неоптимизируемое.

Но есть и другая память. Та, что скрывается за сухой статистикой «количества одновременно играющих». За каждым мощным ПК, за каждым гигагерцем и терафлопсом сидит не просто железо. Там сидит человек. И эта статья — именно о нем. О человеке, чья память, в отличие от компьютерной, работает чуть менее предсказуемо. Она капризна, избирательна, подвержена эмоциям и легко может «зависнуть» от перегрузки. Но, не поверите... она все ещё достаточно предсказуема!

У нас была рабочая видеокарта, драйвер для нее, Linux, полный набор кода, который заставлял работать нашу видеокарту, возможно, была даже прошивка. Не то чтобы это был необходимый запас для запуска AMD GPU на ПЛИС с RISC-V. Но если начал запускать видеокарту на ПЛИСе с RISC-V Linux, становится трудно остановиться…

Вэтом тексте изложены базовые теоретические основы по CAN шине безотносительно к конкретному микроконтроллеру.

CAN — это двухпроводный, дифференциальный, последовательный, полудуплексный интерфейс для передачи бинарных данных между электронными платами (PCB). В качестве кабеля чаще всего применяют одну экранированную витую пару проводов с именами: CAN_L и CAN_H.

Зачастую, в проектах ограничивается использование препроцессора по следующим причинам:

— Он не похож на весь остальной язык;
— Макросы могут возвращать неполные синтаксические конструкции, или вовсе различные, в зависимости от параметров.

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

Со всеми его недостатками, инструмент есть в языке и достоин изучения.

В первой статье мы разобрались с базовыми терминами: что такое Embedded Linux, чем он отличается от обычного дистрибутива, из чего состоит, как происходит его загрузка и с помощью каких инструментов всё это можно собрать.

Надеюсь, что те, кого эта тема зацепила, уже обзавелись платой с SoC на борту — без неё часть шагов будет упущена, а удовольствие от результата будет неполным.

Пришло время перейти от теории к практике!

Все знают аббревиатуру CI/CD. Continuous Integration and Continuous Delivery - Непрерывная интеграция и Непрерывная поставка. Но едва ли можно найти более неправильно понимаемую нашей индустрией идею, чем непрерывная интеграция. Практика, которая была придумана, чтобы её делали разработчики, почему-то превратилась в объект работы девопсов, хотя к культуре DevOps ну вообще никакого отношения, по идее, иметь не должна.

Так что вот вам статья про то, как так вышло, что сейчас под CI понимают что угодно, кроме того, чем она, на самом деле, является.

Привет! Без лишнего: в статье расскажу про атаки на кэш-память в процессорах семейства ARMv8. Подробно изучил их для совершенствования безопасности KasperskyOS: познакомлю с теорией и практикой, механизмами работы и способами митигации. Также кратко расскажу, как мы тестировали каждый способ атаки на KasperskyOS, какие из них оказались неприменимы, какие могут представлять угрозу и как микроядро с подобными угрозами справляется. Если интересно гранулярно погрузиться в типологию атак на кэш — добро пожаловать!

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

Настало время освоить очередное семейство ARM-совместимых микроконтроллеров. За плечами уже AVR, MSP430x, LPC21x, STM32x, MDR32x, ESP32x, SPC58x, CC26x2, NRF53x, AT32Fx. Теперь вот YTM32x от компании YUN TU (Suzhou YTM Semiconductor Co Ltd).

С какой же стороны следует подходить к микроконтроллерам YTM32x?
Давайте разбираться...

Однажды по работе мне прилетела задача по сборке и запуску Linux на одноплатном ПК. Тогда я, будучи разработчиком ПО для микроконтроллеров, встал в небольшой ступор — задачка явно не решалась установкой IDE и нажатием в ней кнопки «Собрать проект». Гугл помог узнать о том, что существует некий Buildroot. В материалах по теме всё выглядело довольно просто: скачай, настрой, дерни пару команд, загрузи результат на одноплатник — и можно запускать! Получается, процесс не многим сложнее установки дистрибутива Linux или Windows на обычный ПК? Конечно же, нет. Ведь если у тебя в руках кастомный одноплатник неизвестного китайского бренда, а не BeagleBone или Raspberry Pi, то зарыться в Buildroot придётся с головой...

Есть множество материалов написанных о работе полупроводников и работе транзисторов.

Зачем еще одна?

Дело в том, что я заметил такую тенденцию в вузовских учебниках – довольно подробное описание работы p-n перехода и очень поверхностное описание работы биполярного транзистора. Зачастую «механика» работы такого транзистора описывается довольно схематично (в совершенно неработоспособном виде) и далее следует быстрый переход на описание внешних параметров. Причем у этих же авторов описание «механики» работы полевого транзистора дается куда обширнее. Видимо, авторы учебников сами не очень «догоняют», как там все работает. И это не удивительно. Человечество вначале эры полупроводников пыталось повторить схему работы вакуумной лампы на полупроводниках, т.к. работа лампы достаточно логична. И собственно полевые транзисторы, в какой-то степени повторяют принцип работы вакуумных ламп. Но вот биполярный транзистор, хотя и был изобретен первым, но это было скорее случайное изобретение, а не осознанный путь к цели.

И даже после изобретения биполярного транзистора, сами его изобретатели не сразу поняли принцип его работы, хотя это были довольно продвинутые люди в области полупроводников.

Если Вы задавали себе вопросы наподобие таких:

почему через коллекторный p-n переход, включенный в обратном направлении, течет ток, да еще и самый, что не на есть главный рабочий ток?

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

Почему ток в базы через открытый эмиттерный p-n переход меньше тока через закрый коллекторный p-n переход?

Ну и совсем «подковыристый» вопрос. Почему при включении биполярного транзистора по схеме с общим эмиттером, когда транзистор полностью открыт (находится в режиме насыщения), напряжение на коллекторе становиться меньше напряжения базы? Ведь если смотреть на транзистор с точки зрения пирога n-p-n переходов (как рисуют в учебниках), то сумма падения напряжения на двух p-n переходах (открытом эмиттерном и закрытом коллекторном) должно быть больше напряжения на одном открытом эмиттерном переходе. А оно у нас меньше.

puts "ПЛИС-культ привет, FPGA / RTL / Verification ХАБ!"

Последние несколько месяцев я плотно сижу в Vivado и Tcl и вот решил с вами поделиться своими "открытиями" в области отладки Tcl скриптов, которые вероятно не многие из вас вообще пишут или используют в своей работе.

Несмотря на свою архаичность, Tool Command Language все же остается самым востребованным языком управления средой проектирования для ПЛИС и ASIC. ЕМНИП все эти инструменты управляются через Tcl, Vivado так уж точно, поэтому было бы не плохо научиться или хотя бы посмотреть какие инструменты отладки этих самых пресловутых Tcl-сценариев вообще существуют или существуют ли они вообще, кроме православного puts

В этой заметке, я постараюсь вам показать, что advanced tcl debugging - это не миф, а вполне реальная сущность, которая была создана еще на заре двухтысячных и не то что бы эта сущность как-то изменилась за эти 20 с небольшим лет.

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

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

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

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

Однажды на работе техлид порекомендовал мне проштудировать книгу Understanding the Linux Kernel Бове и Чезати. В ней рассмотрена версия Linux 2.6, сильно не дотягивающая до более современной версии 6.0. Но в ней явно ещё много ценной информации. Книга толстая, поэтому на её изучение мне потребовалось немало времени. Занимаясь по ней, я решил настроить такую среду разработки, в которой я мог бы просматривать и изменять новейшую версию ядра Linux — чтобы было ещё интереснее.

Есть и другие статьи, в которых рассказано, как собрать ядро Linux. Но в этой статье я немного иначе организую и подаю информацию.

Вопрос

Я знаю, как декодировать UTF-8 с помощью битовой математики и таблиц поиска (см. https://github.com/skeeto/branchless-utf8), но если я хочу преобразовать кодовую точку UTF-8, то можно ли сделать это без ветвлений?

Для начала, можно ли как-то написать эту функцию на C, которая возвращает количество байтов, необходимых для хранения байтов UTF-8 кодовой точки, без использования ветвления? Или для этого потребуется огромная таблица поиска?

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

Итак. Пусть у нас есть полиморфная (шаблонная, перегруженная, - неважно) функция f(x).
И мы написали концепт, который говорит, что тип может быть аргументом этой функции.
Назовём его fable, то есть, "f-абельный", или, по-русски, "сказка". (Эта сказка будет страшной).

На C++20 это выглядит очень просто и элегантно. (Без requires в виде шаблонной метафункции это тоже делается, но заметно громоздче).

Cosmopolitan Libc хорошо известна своим «полиглотным жирным бинарным» хаком, который позволяем исполняемым файлам запускаться на шести операционных системах для AMD64/ARM64. Вас может удивить, что при этом она может быть лучше С‑библиотекой для вашего продакшена. Чтобы продемонстрировать это, давайте сравним библиотеку мьютексов Cosmo с другими платформами.

Мы напишем простой тест, который создает 30 потоков, увеличивающих одно и то же число 100 000 раз. Это поможет проверить, насколько хорошо реализация мьютексов справляется с задачей при интенсивном использовании.

• Рассмотрим общие сведения об архитектуре БК-0010
• Поговорим об интерфейсах, о том, как их создавать и как с ними работать.
• Создадим несколько вспомогательных IP, внешний вид и характеристики которых меняются в зависимости от параметров.

• Выбрать Development board и необходимые PMOD к ней
• Определиться с дизайном проекта, выбрать clock domains и правила перехода между ними
  
• Освоить основные функции Xilinx Vivado – создание проекта, работу с блочными схемами, компиляцию, симуляцию, отладку
• Сделать несколько IP с интерфейсом AXI4
• Поработать с внешними устройствами
• Сделать с нуля собственный процессор с контроллером шины и обработкой прерываний
• Написать модуль для верификации
• Наконец собрать всё вместе и получить реализацию на FPGA легендарного (как минимум для тех, кто тогда жил) компьютера середины 80-х – БК-0010

Свет видел много любительских реализаций std::tuple, и реализация своих велосипедов — наверное, это действительно действенный способ обучения: вряд-ли можно сказать, что ты что-то по-настоящему понимаешь, если не можешь объяснить, как это что-то устроено.

Многие пытливые умы на протяжении десятилетий задавались вопросом: как же реализован std::tuple, как мне реализовать свой тупль (кортеж)? [1]

И немало было дано ответов на такие вопросы и написано статей ([2]). Однако я берусь утверждать, что все они имеют один фатальный недостаток! Конкретнее, они все рассматривают в основном лишь один (и при этом неэффективный) способ реализации: с помощью множественного наследования или рекурсивного инстанцирования, имеющий в свой очередь множество своих недостатков, главный из которых — неэффективное использование памяти.

В то время как современный C++ позволяет реализовать тупль гораздо проще (без обилия шаблоноты) и эффективнее.