Embox v0.6.1

Портирован mbed-tls.

Этот?

И что там нового с флеш-устройствами, тоже интересно.

Портирован mbed-tls.

Да, этот https://github.com/Mbed-TLS/mbedtls. Думаем еще полноценный openssl затащить, но он потяжелее будет.

И что там нового с флеш-устройствами, тоже интересно.

Когда то рассказывали, что можно кусок (или целиком) какой нибудь NOR или NAND флешки представить как блочное устройство, развернуть на нем простую файловую систему для хранения настроек или логов. Мы ее доработали, и добавили возможность создать несколько блочных устройств, одно для настроек, а второе, используем например для перепрошивки образа embox по сети.

Кстати,

Улучшена поддержка архитектуры AARCH64.

Шаг в сторону третьей малины :)

Vostok Uno-VN035

Встроенное ОЗУ: 16 Кбайт; ПЗУ (FLASH): 64 Кбайт

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

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

STM32F103 Blue Pill

Там еще меньше памяти - 20 килобайт ОЗУ, у меня есть такая. Как оно влезает туда?

Улучшена поддержка архитектуры RISC-V.

Поддержки XHCI (USB 3) я смотрю там нету. USB порты в VisionFive 2 работать не будут.

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

Да, у Embox принцип специализированности, максимально все в статике собирается. В отличие от универсального Линукс, нет бинарной совместимости, она только на уровне исходников. Каждый раз оригинальный образ собирается, собстенно по этому и безопасно, внешний код (не зная полную конфигурацию), не удастся запустить. И да, набор драйверов тоже под конкретное железо.

Что получилось, вот в этой статье описали

Как влезает трудно объяснить :) А вот что в итоге

make confload-platform/stm32/f1/stm32f103_bluepill
make

И дальше через openocd как здесь описано

Поддержки XHCI (USB 3) я смотрю там нету. USB порты в VisionFive 2 работать не будут.

Да, пока не будут. Есть в планах, но не первоочередных.

Присоединяйтесь, добавите будем очень благодарны:)

Спасибо, статья всё объясняет, откуда берется волшебство сиё

Оно использует статическое выделение памяти, из-за этого маленькие бинарники получаются.

Это жирный контроллер. Я FreeRTOS на G070 гоняю, всегда хватает памяти. Там например для PWM надо только 4 байта. Но с операционками надо быть очень аккуратным, xTaskCreate может легко сломать RT.

Оно использует статическое выделение памяти, из-за этого маленькие бинарники получаются.

Ну в Embox можно использовать кучу. Все таки маленькие бинари получаются, поскольку очень мощная система сборки, включаются только требуемые модули. Пришлось собственный специализаированный язык написать, внутри модель строить и так далее. Но если речь о том что эти процессы вынесены в статику, то да, имено так:)

Это жирный контроллер. Я FreeRTOS на G070 гоняю, всегда хватает памяти.

Смотря какая функциональность. Умельцы из Востока, что только в этот «жирный» МК не запихали. Ну или, вот статья о МК с еще меньшими ресурсами. Хотя дело не в ресурсах а в функциональности, которая вам нужна.

Но с операционками надо быть очень аккуратным, xTaskCreate может легко сломать RT.

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

Пришлось собственный специализаированный язык написать

Обычные GCC и C же, порты на ассемблере. У CMSIS и FreeRTOS по крайней мере.

Так дело то не в языке для бизнес логики (C/C++, ассемлер) конечно мы все совершенно обычными средствами собираем. Но, собираем только то что нужно, и с теми параметрами которые требуются. Никакие CMSIS и FreeRTOS не помогут вам сделать Linux без Linux. (Например Embox единственный кто OpenCV запускает на MK https://habr.com/ru/companies/embox/articles/539572/ ну и если интересно, почитайте наш блог, говорят много интересного и в техническом плане тоже :)

WolfSSL не рассматриваете?

Когда то рассказывали...

Это типа линуксового usb-storage.ko? или это локально на устройстве внутри системы отображение NAND как флеш-накопителя?

WolfSSL не рассматриваете?

Спасибо. Повесил issue

Это типа линуксового usb-storage.ko? или это локально на устройстве внутри системы отображение NAND как флеш-накопителя?

Да, скорее второе. Это представление NAND флеш как блочного устройства, можно читать писать. Аналог MTD на Линукс. Но у нас еще и есть возможность куски внутренней флеш памяти можно использовать. Очень удобно, когда прямо dd используешь, или в раздел по ftp грузишь сырой образ.

А поясните тем кто в танке, оно для stm32 использует свою реализацию драйверов для периферии? Т.е. не HAL от STMicroelectronics?

А поясните тем кто в танке, оно для stm32 использует свою реализацию драйверов для периферии? Т.е. не HAL от STMicroelectronics?

Конечно у нас есть обертки, но мы используем HAL из Cube, поскольку можно быстро запустить реализацию и не плодить новый код. Как описано в статье это позволяет существенно ускорить переезд на новую плату. Но мы все больше задумываемся над уходом от куба, как минимум иметь и свои версии устройств, уж очень он много неприятностей может доставить.

Ага, а еще вопрос: а почему не выбрали какую либо (более менее) известную систему сборки, например CMake, или даже лучше - Qbs т.к. более гибкая?

Например, было бы проще для юзеров работать с проектом ембокса из IDE, которые поддерживают эти системы сборки, и сразу там же конпелять, отлаживать код. А то вводить в консоле всякие make команды не всем удобно.

И еще вопрос, а как дела обстоят с конпеляторами, отличными от Gcc/Clang, например с IAREW, KEIL, COSMIC, RENESAS, и т.п? Трудно ли будет это подцепить?

Ага, а еще вопрос: а почему не выбрали какую либо (более менее) известную систему сборки, например CMake, или даже лучше - Qbs т.к. более гибкая?

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

Например, было бы проще для юзеров работать с проектом ембокса из IDE, которые поддерживают эти системы сборки, и сразу там же конпелять, отлаживать код. А то вводить в консоле всякие make команды не всем удобно.

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

И еще вопрос, а как дела обстоят с конпеляторами, отличными от Gcc/Clang, например с IAREW, KEIL, COSMIC, RENESAS, и т.п? Трудно ли будет это подцепить?

Сложный вопрос, не пробовали, код достаточно переносим, но фронтэнд нужен GCC.

И главное не понятно зачем это делать? Clang понимаю зачем, а вот проприетанный KEIL.

Embox принципиально кроссплатформенный, микроконтроллеры это только небольшая его часть.