Систематический программист
Всем привет. Embox продолжает своё путешествие по отечественным микропроцессорам. В этой серии мы опишем путешествие на AMUR (MIK32). Кто не знает, это — полностью отечественный микроконтроллер К1948ВК018 на архитектуре RISC‑V, который производится в РФ на мощностях компании МИКРОН, входящей в ГК «Элемент».
Recently I have bought starfive visionfive-2 SoC for my own experiments, honestly speaking
I am striving to work with risc-v. After some time I decided to share my experience. Here my bulletpoints:
Small preparation USB-to-Serial connector Write image to microSD/SSD Set boot mode settings
Boot Update bootloader Build kernel Native build Pod build Cross-build on amd64: fast and handy
Chroot to risc-v system from amd64 and install packages
Bonus 1: run qemu with risc-v
Bonus 2: build deb packages for risc-v
Bonus 3: kernel build script
Conclusions
Не так давно я уже писал заметку про новый микроконтроллер MIK32 AMUR от отечественного производителя АО "Микрон" и отладочную плату NUKE MIK32 на его базе. В одном из наших изделий мы планируем применить это МК для измерения физической величины (расход жидкости) и выдачи усредненного параметра в цифровом виде. В связи с чем появилась необходимость проверить как работает АЦП в составе этой микросхемы. Микроконтроллер MIK32 "AMUR" укомплектован одним многоканальным аналого-цифровым преобразователем разрядностью 12 бит к входу которого можно подключать до 8 сигналов через встроенный аналоговый коммутатор. В данной статье я приведу пример кода для работы этим АЦП и опишу выявленные проблемы и особенности.
Встроенный LCD дисплей имеет разрешение 640х480 пикселов и отображает 32 оттенка серого цвета. Видеокарта поддерживает режимы VGA (800x600)/HC/CGA/MDA. В качестве центрального процессора установлен камень 386DX, работающий на частоте 33 МГц, оперативной памяти установлено 4 МБ, что по тем временам было весьма жирно. Встроенный жёсткий диск имел размер 200 МБ. В качестве съёмных носителей используется пятидюймовый дисковод, поддерживающий дискеты размером 1,2 МБ, и стандартный дисковод 3,5 дюйма на 1,44 МБ.
Здравствуйте все! ✋
При первой же попытке подключить экран ILI9341 по SPI к MIK32 АМУР выявил пару проблем, одна касается библиотеки HAL от Микрона, а вторая касается платы ELBEAR ACE-UNO ревизии 1.0.1 от ELRON.
Для начала поясню, я использую свой Makefile и работаю в VSCode, есть возможность работать с PlatformIO но я ей не пользуюсь. Прошиваю МК через COM-порт, для этого использую бутлоадер и загрузчик от elron.tech.
Для запуска экрана я взял библиотеку которую использовал ранее для работы с МК от Миландр К1986ВК025 (ОКР «Счетчик М»), заменил внутренности функций SPI_Master_Init, SPI_SendData и т.д., взяв их из примера который находится в репозитории Микрона - HAL_SPI_Master.
В их примере идёт передача 20 байт с одновременным приёмом, мне же необходимо передавать побайтово. В этом моменте как раз и появляется ошибка, с которой пришлось немного повозиться. В функции HAL_SPI_Exchange есть метка error, посмотрите пример ниже:
Открытая архитектура RISC-V активно развивается: в стандарт добавляются новые расширения и инструкции, разрабатываются новые ядра и SoC. Поскольку многие компании видят перспективы архитектуры и готовы использовать ее в продакшене, создается программный стек для высокопроизводительных вычислений — RISC-V HPC (High Performance Computing). Прогресс сопровождает формирование нового тренда — OpenHPC. Он заключается в технологической независимости от решений коммерческих компаний. Причем это относится не только к ПО, но и к железу.
Чтобы концепция OpenHPC реализовывалась быстрее, нужно, чтобы к инициативе присоединилось как можно больше компаний, помогающих в развитии экосистемы решений для RISC-V HPC. Меня зовут Андрей Соколов, я инженер-программист в компании YADRO. В R&D-команде мы поставили перед собой задачу: изучить, как можно поддержать архитектуру RISC-V со стороны библиотек линейной алгебры BLAS и LAPACK. Тестирование одной из open source-библиотек привело нас к интересным открытиям, о которых я расскажу под катом.
При запуске новых плат и устройств с PCIe-соединениями недостаточно просто вставить карту в слот. Нужно так настроить эквалайзеры, редрайверы, пресеты и ретаймеры, чтобы на каждой полосе «поднялся линк», то есть установилось соединение. Это значит, что приемопередатчики на обоих концах распознали друг друга, договорились о кодировке и скорости передачи.
Долгое время без специального дорогостоящего инструмента нельзя было убедиться в устойчивости линка: что он не пропадает при малейших воздействиях температуры, влажности или любопытных лапок. То есть нелегко было узнать количественный запас по уровню сигнала, насколько он близок к границе потери различимости физических уровней — а значит, и разрыва соединения. Эта безнадежная ситуация изменилась с появлением четвертого поколения стандарта PCIe.
Основная прелесть использования ПЛИС, на мой взгляд, состоит в том, что разработка аппаратуры превращается в программирование со всеми его свойствами: написание и отладка кода как текста на специализированных языках описания аппаратуры (HDL); код распространяется в виде параметризованных модулей (IP-блоков), что позволяет его легко переиспользовать в других проектах; распределенная разработка обширным коллективом разработчиков с системой контроля версий, такой же, как у программистов (Git); и, как и в программировании, ничтожно низкая стоимость ошибки.
Последнее очень важно, так как если при разработке устройства классическим методом разработчик несет вполне существенные затраты на сборку и производство изделия, и любая схемотехническая ошибка или ошибка трассировки печатной платы — это всегда выход на очередную итерацию и попадание на деньги, то при работе с ПЛИС ошибки ничтожны по своей стоимости и легко устранимы. И даже если в серийном изделии обнаруживается ошибка, то её во многих случаях можно устранить очередным апгрейдом прошивки «в поле» без замены изделия. Короче, с приходом ПЛИС разработка цифровой аппаратуры все больше и больше выглядит как программирование, а это, помимо всего прочего, существенно понижает порог вхождения в тему, и все больше программистов становятся разработчиками «железа». А новые люди, в свою очередь, приносят с собой в индустрию новые подходы и принципы.
В этой статье я хочу поделиться своим небольшим опытом «программирования» микросхем ПЛИС и тем, как я постепенно погружался в тему ПЛИСоводства. Изначально я собирался написать небольшую заметку про открытый тулчейн для синтеза Yosys. Потом — про язык SpinalHDL и синтезируемое микропроцессорное ядро VexRiscv, на нём написанное. Потом — про замену микроконтроллеров микросхемами ПЛИС на примере моей отладочной платы «Карно». Но в процессе я погрузился в историю появления Hardware Description Languages (HDL), и когда я начал писать, Остапа, как это часто бывает, понесло... В общем, получилось то, что получилось.
А еще эту статью можно рассматривать как глубокое погружение в то, что происходит вот на этом новогоднем видео.
Это вторая и заключительная часть большой статьи. Ознакомиться с первой частью можно по ссылке.
Основная прелесть использования ПЛИС, на мой взгляд, состоит в том, что разработка аппаратуры превращается в программирование со всеми его свойствами: написание и отладка кода как текста на специализированных языках описания аппаратуры (HDL); код распространяется в виде параметризованных модулей (IP-блоков), что позволяет его легко переиспользовать в других проектах; распределенная разработка обширным коллективом разработчиков с системой контроля версий, такой же, как у программистов (Git); и, как и в программировании, ничтожно низкая стоимость ошибки.
Последнее очень важно, так как если при разработке устройства классическим методом разработчик несет вполне существенные затраты на сборку и производство изделия, и любая схемотехническая ошибка или ошибка трассировки печатной платы — это всегда выход на очередную итерацию и попадание на деньги, то при работе с ПЛИС ошибки ничтожны по своей стоимости и легко устранимы. И даже если в серийном изделии обнаруживается ошибка, то её во многих случаях можно устранить очередным апгрейдом прошивки «в поле» без замены изделия. Короче, с приходом ПЛИС разработка цифровой аппаратуры все больше и больше выглядит как программирование, а это, помимо всего прочего, существенно понижает порог вхождения в тему, и все больше программистов становятся разработчиками «железа». А новые люди, в свою очередь, приносят с собой в индустрию новые подходы и принципы.
В этой статье я хочу поделиться своим небольшим опытом «программирования» микросхем ПЛИС и тем, как я постепенно погружался в тему ПЛИСоводства. Изначально я собирался написать небольшую заметку про открытый тулчейн для синтеза Yosys. Потом — про язык SpinalHDL и синтезируемое микропроцессорное ядро VexRiscv, на нём написанное. Потом — про замену микроконтроллеров микросхемами ПЛИС на примере моей отладочной платы «Карно». Но в процессе я погрузился в историю появления Hardware Description Languages (HDL), и когда я начал писать, Остапа, как это часто бывает, понесло... В общем, получилось то, что получилось.
Привет, Хабр!
Предлагаю вашему вниманию самодельный программатор ST-Link V2.1.
Особенности: интерфейс SWD, функция виртуального COM-порта, поддержка SWO, функция MSC (mass storage class), низкая цена.
Воспользуемся одним лишь схемным редактором. Ну и ещё tcl-скриптом. И программатором. И немножко осциллографом...
Сейчас я интервьирую кандидатов которые приходят на позиции в RTL design / проектировщики микросхем на уровне регистровых передач. Но 5 лет назад я интервьировал студентов и других инженеров на позиции в DV / Design Verification / верификаторы блоков микросхем.
Моим стандартным вопросом было написать маркером на доске псевдокод для упрощенного драйвера модели шины (Bus Functional Model - BFM) для протокола AXI. На этом вопросе у ~80% кандидатов наступала агония - они как ужи на сковородке пытались натянуть сову на глобус - приспособить решение для последовательной шины а-ля APB, которое они прочитали в каком-нибудь тьюториале - к шине AXI, которая во-первых конвейерная, а во-вторых, допускает внеочередные ответы на запросы чтения с разными идентификаторами.
Аналогия из другой области: представьте, что кто-то пытается обходить дерево или решить "ханойские башни" - не зная концепций рекурсии и стека. Или написать GUI интерфейс, не зная концепции cобытийно-ориентированной архитектуры.
Бывает нужно удалённо снять лог с какого-либо труднодоступного агрегата или установки. А лучше чтобы логи автоматически отсылались на сервер. Но, как правило, установки и агрегаты имеют контроллер только с локальным проводным интерфейсом. Чаще всего RS-232 или RS-485, в последнее время популярен USB. А может быть в наличии только одна полевая шина типа CAN. Либо бывает нужно одновременно снять лог и с локального интерфейса и с полевой шины. Мы попытались сделать для этих целей неприхотливый промышленный логгер с передачей данных в облака по Wi-Fi с установкой на DIN рейку и возможностью автономного питания.
Once every true-linux engineer gets a trouble: there is no any software in his distro or it's built without needed options. I am keen on the phrase: "Only source control gives you freedom".
Of course, you can build this software on your computer without any src-packages, directly (with simplification: configure, make, make install). But it's a non-reproducible solution, also hard for distribution.
The better way is to make distro-aligned package that can be built if needed and that produces lightly distributed binary-packages. It's about debian-source packages(debian,ubuntu,etc), pkgbuild (for arch), ebuild for gentoo, src-rpm for red hat-based, and many others.
I will use cri-o like a specimen.
Before reading the text below I strongly recommend to get familiarized with the official Debian policy manual placed here and debhelper manpage.
Also you will be required to setup some variables like DEBMAIL and DEBFULLNAME for proper data in changelog and other places.
Для тестирования выбрана аппаратная платформа на базе чипа STM32H753VIH с частотой ядра 480 МГц. Подключение к SD карте выполнено через интерфейс SDMMC с частотой 60 МГц. В качестве драйвера работает стандартная библиотека STM32H7xx_HAL. Используется промежуточное программное обеспечение FileX из пакета Azure RTOS поддерживающее exFAT.
