User
В прошлом году я написал программу, вычисляющую 255 цифр числа π на самом первом микропроцессоре от Intel - 4004. В той статье я упоминал рекорд ENIAC'a - 2035 цифр [^1], но побить его не смог. Настало время закрыть гештальт. В этот раз возьмём одного из преемников от Intel - 4040.
Давно хотел написать статью на такую интересную и больную тему как импортозамещение. А именно, как это все выглядит и чем пахнет в той сфере, где я работаю – разработка и производство электронной техники, а конкретно – аппаратуры связи. У меня накопилось множество мыслей, занимательных историй, ознакомиться с которыми будет наверняка небезынтересно даже тем людям, кто далек от этой сферы.
В этой статья предлагаю обобщить, перечислить и обсудить общие системные атрибуты хорошего firmware (прошивки) для микроконтроллерных проектов, которые не зависят от конкретного приложения или проекта.
Моя первая настоящая работа была странной.
2013 год. Четвёртый курс информационной безопасности, я вроде разбираюсь в визуальном бейсике и самонадеянно ищу вакансии программиста на hh. Их там не то что бы сильно много, поэтому через десять минут поисков я отправляю резюме на какой-то завод, где в вакансии есть нужные слова. Они приглашают меня на собеседование, и через три дня у меня есть работа.
1С-программистом с нулевым знанием 1С. С записью в трудовой «Системный администратор» с нулевыми знаниями системного администрирования. Ну то есть как — эникействовать же все могут, вот и могу. Наверное.
Так прошёл целый год, полный переписывания легаси на 1С, софта для этикеток на С++ и дельфи, включения бухгалтерских компьютеров обратно в розетку и, конечно, вообще без визуального бейсика.
Этот случай так запал мне в душу, что я на всякий случай запомнил некоторые странности оттуда (и ещё с других мест, где мне нужно было работать с программистами). Байки, во. Пусть будут байки о разработке.
Дисклеймер. Всё пишу по расплывчатым воспоминаниям, поэтому если бывшие коллеги читают это — привет на сто лет.
Сап, котятки.
Я пришёл рассказать о проекте UAVCAN — новом сетевом стандарте для организации взаимодействия узлов и компонентов современных транспортных средств с высоким уровнем автономности/автоматизации. Название является акронимом от Uncomplicated Application-level Vehicular Computing And Networking (несложные бортовые сети и коммуникации уровня приложения).
В этой публикации объясняется текущее положение дел и тренды в области сложных бортовых систем, существующие и грядущие проблемы, как мы их решаем и каких успехов добились. Во второй части наши коллеги из Университета Иннополис подробно осветят практическую сторону внедрения UAVCAN на примере конкретных проектов.
Первый блин проекта был заложен в 2014-м. С самого начала это был эксперимент в минимализме: возможно ли в разработке сложных распределённых бортовых систем опираться на мощные абстракции, избегая при этом роста сложности реализации и связанных с ним трудностей валидации и верификации.
Мы наблюдаем быстрый рост сложности бортовых систем, связанный с развитием функциональных возможностей транспортных средств (особенно беспилотных) в целом, и систем автоматического управления в частности.
Давайте пробежимся по способам софтостроения, придуманным примерно за 70 лет его существования. Их не так много, как может показаться. Но достаточно много, чтобы завести в тупик.
Предлагаю ознакомиться с ранее размещенными материалами по проекту Starlink (SL):
Часть 1. Рождение проекта ‣ Часть 2. Сеть SL ‣ Часть 3. Наземный комплекс ‣ Часть 4. Абонентский терминал ‣ Часть 5. Состояние группировки SL и закрытое бета-тестирование ‣ Часть 6. Бета-тестирование и сервис для абонентов ‣ Часть 7. Пропускная способность сети SL и программа RDOF ‣ Часть 8. Монтаж и включение абонентского терминала ‣ Часть 9. Сервис на рынках вне США ‣ Часть 10. SL и Пентагон ‣ Часть 11. SL и астрономы ‣ Часть 12. Проблемы космического мусора ‣ Часть 13. Спутниковая задержка в сети и доступ к радиочастотному спектру ‣ Часть 14. Межспутниковые каналы связи ‣ Часть 15. Правила предоставления услуг ‣ Часть 16. SL и погода ‣ Часть 17. Второе поколение SL ‣ Часть 18. SL на рынке COTM ‣ Часть 19. Что у SL в будущем
"No matter how hard you try, you can't make a racehorse out of a pig. You can, however, make a faster pig" (комментарий в исходном коде Емакса)
Всем известен тот факт, что свиньи не летают. Не менее популярно мнение о том, что интерпретаторы байт-кодов как техника исполнения языков высокого уровня не поддаются ускорению без применения трудоёмкой динамической компиляции.
Во второй части серии статей об интерпретаторах байт-кодов я на примере небольшой стековой виртуальной машины ПВМ («Поросячья Виртуальная Машина») постараюсь показать, что не всё потеряно для трудолюбивых поросят с амбициями и что в рамках (в основном) стандартного C вполне возможно ускорить работу таких интерпретаторов по меньшей мере в полтора раза.
Так сложилось, что основным языком для работы с микроконтроллерами является C. Многие крупные проекты написаны именно на нем. Но жизнь не стоит на месте. Современные средства разработки уже давно позволяют использовать C++ при разработке ПО для встраиваемых систем. Однако такой подход до сих пор встречается достаточно редко. Не так давно я попробовал использовать С++ при работе над очередным проектом. Об этом опыте я и расскажу в данной статье.
