The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Выпуск Rust 1.96. Оценка пригодности Rust для создания прошивок к микроконтроллерам

29.05.2026 20:13 (MSK)

Опубликован релиз языка программирования Rust 1.96, основанного проектом Mozilla, но ныне развиваемого под покровительством независимой некоммерческой организации Rust Foundation. Язык сфокусирован на безопасной работе с памятью и предоставляет средства для достижения высокого параллелизма выполнения заданий, при этом обходясь без использования сборщика мусора и runtime (runtime сводится к базовой инициализации и сопровождению стандартной библиотеки).

Методы работы с памятью в Rust нацелены на исключение ошибок при манипулировании указателями и защиту от проблем, возникающих из-за низкоуровневой работы с памятью, таких как обращение к области памяти после её освобождения, разыменование нулевых указателей, выход за границы буфера и т.п. Для распространения библиотек, обеспечения сборки и управления зависимостями проектом развивается пакетный менеджер Cargo. Для размещения библиотек поддерживается репозиторий crates.io.

Безопасная работа с памятью обеспечивается в Rust во время компиляции через проверку ссылок, отслеживание владения объектами, учёт времени жизни объектов (области видимости) и оценку корректности доступа к памяти во время выполнения кода. Rust также предоставляет средства для защиты от целочисленных переполнений, требует обязательной инициализации значений переменных перед использованием, лучше обрабатывает ошибки в стандартной библиотеке, применяет концепцию неизменяемости (immutable) ссылок и переменных по умолчанию, предлагает сильную статическую типизацию для минимизации логических ошибок.

Основные новшества:

  • Добавлен модуль range с реализацией новых типов, развиваемых для замены устаревших типов Range, RangeInclusive, RangeToInclusive и RangeFrom, и позволяющих хранить диапазоны в Copy-структурах. Тип Range определяет диапазоны, ограниченные минимальным и максимальным допустимым значением, тип RangeFrom определяет числа начиная с указанного значения, а тип RangeInclusive - значения вне указанного диапазона. В будущих выпусках дополнительно появятся типы RangeFull и RangeTo, старая реализация будет перенесена в core::range::legacy::*, а синтаксис "N..M" переведут на новый вариант типов.

    Новые типы отличаются тем, что вместо типажа Iterator реализуют типаж IntoIterator, т.е. вместо встроенного итератора определяют то, как преобразовать тип в итератор. Подобный поход позволяет использовать с новыми типами операцию копирования (типаж Copy, показывающий, что значения типа можно дублировать через простое копирование), которая ранее была недоступна из-за несовместимости с типами со встроенными итераторами. Например, новые типы дают возможность сохранить границы среза в структуру, которая полностью копируется без раздельного сохранения начального и конечного значений:

    
       use core::range::Range;
    
       #[derive(Clone, Copy)]
       pub struct Span(Range<usize>);
    
       impl Span {
           pub fn of(self, s: &str) -> &str {
               &s[self.0]
           }
       }
    
  • Добавлены макросы "assert_matches!" и "debug_assert_matches!", проверяющие соответствие значения указанному шаблону и аварийно завершающие выполнение при расхождении. От выражений "assert!(matches!(..))" и "debug_assert!(matches!(..))" новые макросы отличаются выводом отладочной информации со значениями, вызвавшими сбой. Для избежания пересечений со сторонними макросами, поставляемыми с аналогичными именами, новые макросы требую явного импорта библиотеки "core::assert_matches".
    
       use core::assert_matches;
    
       fn get_random_number() -> u32 {
           4
       }
    
       fn main() {
           assert_matches!(get_random_number(), 1..=6);
       }
    
  • При сборке для целевой платформы WebAssembly прекращена передача компоновщику опции "--allow-undefined", разрешавшей связывание при наличии неопределённых символов, которые преобразовывались в импорт из модуля "env". При сборке для WebAssembly все связанные с компоновкой символы теперь по умолчанию обязательно должны быть определены. Для возвращения старого поведения можно использовать переменную окружения "RUSTFLAGS=-Clink-arg=--allow-undefined" или выражение '#[link(wasm_import_module = "env")]" в коде.
  • В разряд стабильных переведена новая порция API, в том числе стабилизированы методы и реализации типажей:
  • В пакетном менеджере Cargo устранена уязвимость CVE-2026-5223, которая может использоваться для перезаписи исходного кода другого crate-пакета в локальном кэше пакетов из того же репозитория через манипуляции с символическими ссылками внутри crate-а пакетов. Уязвимость проявляется только при работе со сторонними репозиториями пакетов и не затрагивает пользователей репозитория crates.io, так как в crates.io запрещена загрузка пакетов с символическими ссылками.

Дополнительно можно отметить публикацию (PDF) результатов анализа пригодности языка Rust для разработки прошивок для микроконтроллеров и встраиваемых систем с ограниченными ресурсами. Исследование проведено компанией STMicroelectronics при участии нескольких европейских университетов. Двум изолированным командам разработчиков была поставлена задача по реализации одной и той же прошивки для микроконтроллеров STM32U585AI с ядром Arm Cortex-M33. Первая команда создавала прошивку на Си, а вторая на Rust.

Тестирование выполненной работы не выявило заметных преимуществ в использовании языка Си вместо Rust при разработке прошивок для микроконтроллеров при сравнении потребления памяти и производительности. Более того, задействование написанного на Rust системного runtime от открытого проекта Ariel OS позволило добиться потребления памяти в проекте на Rust ниже, чем в реализации на языке Си, использующей традиционный стек для разработки прошивок на базе библиотеки newlib.

Размер результирующей прошивки составил 84100 байт в проекте на Rust и 76744 байта в проекте на Си (на 10% меньше), но потребление оперативной памяти в прошивке на Rust оказалось значительно ниже - 24640 байтов против 42608 байтов. Что касается производительности, то при тестировании начальных прототипов, разработанных за 6 недель, реализация на Rust в два раза опережала, реализацию на Си, но обе реализации значительно отставали от расчётной максимальной производительности. После 4 недель, выделенных на оптимизацию, обе реализации достигли примерно одинакового результата, близкого к расчётному максимуму.



  1. Главная ссылка к новости (https://blog.rust-lang.org/202...)
  2. OpenNews: Выпуск Rust 1.95. Добавление Rust в дисплейный сервер Mir. Анализатор трафика ayaFlow на Rust
  3. OpenNews: Google задействовал Rust-библиотеку Hickory в прошивке радиомодуля смартфонов Pixel 10
  4. OpenNews: Intel развивает открытую прошивку ModernFW и гипервизор на языке Rust
  5. OpenNews: Intel развивает виртуальную прошивку TD-Shim, написанную на Rust
  6. OpenNews: Google переписал на языке Rust прошивку pvmfm, используемую в Android
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/65574-rust
Ключевые слова: rust
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (25) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 20:23, 29/05/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >для микроконтроллеров STM32U585AI

    https://www.st.com/en/microcontrollers-microprocessors/stm32u585ai.html
    Интересный эксперимент.

     
     
  • 2.9, Аноним (9), 21:06, 29/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Интересно, во сколько раз при этом будет больше ошибок, чем в uutils?
     

  • 1.2, Аноним (2), 20:33, 29/05/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Лучше производность, быстрее код писать, меньше оперативной памяти нужно и чуть больше места занимает.

    Выбор очевиден.

     
     
  • 2.4, Аноним (4), 20:49, 29/05/2026 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Выбираю SPARK.
     
  • 2.6, Аноним (6), 21:00, 29/05/2026 Скрыто ботом-модератором     [к модератору]
  • –1 +/
     
  • 2.15, Аноним (15), 21:24, 29/05/2026 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Быстрее код писать, воюя с чекером боровов?

    Завязывайте позориться. Если у вас проблемы с БЧ при написании кода, значит вы не понимаете сколько у вас живут объекты и плодите UB, на сях с такой квалификацией вы будете вместо "войны с БЧ" который вас тыкает в проблему ещё до того как вы даже код собрали, сидеть неделями в отладчике.

    > Ах да, для микроконтроллеров же - сплошной @unsafe

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

     

  • 1.3, НяшМяш (ok), 20:33, 29/05/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Под микроконтроллер в 160 мегагерц можно было хоть на бидоне писать, в чём смысл делать какие-то сравнения под эту лошадь. Сообщество на тот же 16-мегагерцовый nRF51 на embassy фигачит со свистом уже много лет, открыли они Америку.
     
     
  • 2.5, Аноним (5), 20:54, 29/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Во, точняк! Раст -- низкоуровневый питон!
     
     
  • 3.14, Аноним (14), 21:19, 29/05/2026 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Низкоуровневый питон называется forth. Это низкоуровневый сишарп.
     
  • 2.7, Аноним (1), 21:05, 29/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Ну они для себя же делали опыт, что и описано в посте, значит им нужнее.
    Да и остальные языки никуда не деваются:
    https://opennet.ru/64135-github
     

  • 1.8, Аноним (6), 21:05, 29/05/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Что-то мне кажется, что если для микроконтроллеров писать на Algol68 с POSIX-расширениями (ga68), то тоже производительность будет не сильно отличаться.
     
     
  • 2.20, Аноним (15), 21:44, 29/05/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это скорее правда. Под железо без изысков (типа всяких SIMD) компилировать чистую математику (а что ещё в эмбеддовке может быть CPU-bound) компиляторы давно уже научились, и язык тут можно вообще любой взять. Если у него конечно бэкенд gcc/llvm, а не самодельное музейное гoвнo из прошлого века.

    Сейчас скорее интересно другое, а именно возможность написать взрослый асинхронный код типа

    '''rust
    task::spawn(async ||
        loop {
            button.await;
            i2c.send(0x12, b"button pressed").await.unwrap();
        }
    );
    '''

    и чтобы он скомпилился в те же 276 байт которые я напишу на ассемблере с ручным диспатчем прерываний и конечным автоматом для состояний. Хотя даже тут интерес уже даже не практический, а фановый, поскольку нет давно железа где было бы принципиально скомпилится это в 276 или 27600 байт.

     
     
  • 3.27, Аноним (9), 22:38, 29/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > скомпилится это в 276 или 27600 байт

    Вся суть растерманов.

     

  • 1.10, Аноним (15), 21:07, 29/05/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    В эмбедном байтодрочестве rust равных нет уже за счёт упаковки структур и нишевой оптимизации. А так-то без экспериментов было понятно что как минимум если писать на нём в C/плюсовом стиле, то и результаты будут примерно такими же. Вот было бы гораздо интереснее сравнить rust с C/плюсовым стилем и идиоматический rust с Option, Result, итераторами, монадическими конструкциями, лямбдами и трейтами, а желательно с ещё более высокоуровневыми штуками типа разбора протоколов через serde или хотя бы nom.

    Пока мой опыт в портировании сишного кода, правда не для эмбеддовки, но как раз разбор строк и протоколов и прочее битодрочество показывает что получается в 3 раза меньше (исходного) кода и он намного понятнее, и работает это быстрее (и юнит тесты рядом с кодом очень удобная штука), но на размер машинного кода я не смотрел. А давний опыт в эмбеддовке (AVR) показал что на полноценном C++ со всякими 'unique_ptr', '<algorithm>' и повсеместными шаблонами (когда разные реализации таймеров и экранчиков прокидываются как шаблонные аргументы, реализация I2C мокается для тестов и т.д.) получает прошивки компактнее дубового сишного кода, после чего про C в нашеё команде вообще забыли.

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

     
     
  • 2.12, Аноним (12), 21:14, 29/05/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ничего интересного в этом нет. Вопрос применения раста в плоскости практического применения вообще не лежит.
     
     
  • 3.16, Аноним (15), 21:25, 29/05/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Какой интересный тейк. Даже интересно в какой плоскости лежит вопрос применения если не в плоскости применения.
     
     
  • 4.19, анонимс (?), 21:36, 29/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Идеологическом. Rust компилируется LLVM написанным на C++ бэкэндом rustc так что машинный код совершенно одинаков
     
     
  • 5.21, Аноним (15), 21:48, 29/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Машинный код одинаков только если писать на общем подмножестве двух языков, на нахрена это кому-то нужно? На rust можно писать на порядок выразительнее, и ответ на вопрос будет ли полученный код компактнее и быстрее не для всех очевиден, а даже без учёта этого, вопросы компайл-тайм проверок и более качественного тулинга - сугубо практические.
     
  • 2.18, Сладкая булочка (?), 21:32, 29/05/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > (и юнит тесты рядом с кодом очень удобная штука)

    В си никто не мешает положить тесты рядом с кодом.

     
     
  • 3.22, Аноним (15), 21:53, 29/05/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Тесты рядом с кодом это, если что так и ни строчкой больше, даже если это первый тест в проекте:

    '''
    fn inc(a: u32) -> u32 {
         a + 1
    }

    +#[test]
    +fn test_inc() {
    +    assert_eq!(inc(1), 2);
    +}
    '''

     
     
  • 4.26, Аноним (9), 22:34, 29/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    И что тут такого особенного, чего не было нигде в других языках?
     
  • 2.28, Аноним83 (?), 22:44, 29/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > писать на нём в C/плюсовом стиле, то и результаты будут примерно такими же. Вот было бы гораздо интереснее сравнить rust с C/плюсовым стилем и идиоматический rust с Option, Result, итераторами, монадическими конструкциями, лямбдами и трейтами, а желательно с ещё более высокоуровневыми штуками типа разбора протоколов через serde или хотя бы nom.

    Столько буков и ни слова о конечном результате, только какие то бесполезные языковые абстракции.


    > А давний опыт в эмбеддовке (AVR) показал что на полноценном C++ со всякими 'unique_ptr', '<algorithm>' и повсеместными шаблонами (когда разные реализации таймеров и экранчиков прокидываются как шаблонные аргументы, реализация I2C мокается для тестов и т.д.) получает прошивки компактнее дубового сишного кода, после чего про C в нашеё команде вообще забыли.

    Потому что видимо на С не пробовали даже делать плагины и абстракции, как оно сделано в том же линухе/бсд в дровах для всего того же самого.

     

  • 1.23, Аноним (15), 21:57, 29/05/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Жаль про размер исходников ничего не сказано.
     
     
  • 2.25, Аноним (25), 22:07, 29/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    А может и сказано...
     

  • 1.24, Аноним (24), 22:05, 29/05/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Я на Go пишу божественные быстрые программы без ошибок впринципе, опыт так сказать большой, учил один язык программирования за жизнь. А Rust это для тех кому время потратить надо впустую на корявый синтаксис, где ничего дельного и шустрого не напишешь без unsafe.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2026 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру