Запустить Ваш пример на на MIK32 (без SDL) не представляет труда, вопрос скорее был в экранчике. То есть, предлагается взять SPI экранчик с приемлемым разрешением, и добавить его поддержку в SDL и уже на него вывести?
Нужно смотреть реализацию print() В embox например можно отключить поддержку плавающей точки в printf и производных функций `include embox.compat.libc.stdio.print(support_floating=0)`
Отличная идея, мы подобное делаем для внутренней памяти МК (https://habr.com/ru/companies/embox/articles/573244/ ) Но с АМУРом могут возникнуть ряд труностей. :( Одну Вы отметили, шина занята, нужно изучать можно ли вообще подмешивать команды Другой вариант это попробовать разместить процедуры работы с SPI (и flash) в eeprom и оттуда их вызывать. Но его очень мало и... в общем идея отличная, сами смотрели на эту flash как на расширитель возможностей, но есть ряд очевидных сложностей в реализации.
Ответил выше. Лично мое мнение, что АМУР для узкого спектра задач (достаточно простых) напримре вспомогательный контроллер, одного двигателя или как элемент доверия при загрузке системы. Но это очень важный шаг для развития всей отрасли! На нем уже можно отлаживать какой то сафт, как то обучать, делать какие то простые устройства и так далее
Пока к сожалению не много, простейшие сбор данных с датчика и после какого то значения отработка (ситуации). То есть, этот МК рассматривается как элемент доверия к системе, самих характеристик (например ОЗУ не возможно расширить), явно не достаточно для современных функциональных требований! А вот на К1921ВГ015 (https://habr.com/ru/articles/881784/) уже много. В будущем расчитываем на производство аналогичный на территории РФ
Если своим считать испечённый кристалл, то, на сегодняшние день, да. Но, если смотреть несколько дальше, то свои ядра (особенно риск5) и младшие модели которые можно по технологии например 90 нм, например МК, то они могут появиться довольно скоро. Пока не начнется этот длинный путь, цель точно не приблизиться!
:)))) Процесс идет, надеюсь ситуация будет улучшаться. Но конечно требуется время, столько времени обсер не уделяли этому внимания, а просто деньги рубили...
Спасибо. Но подумал, если начинать с этого каждый раз, то до чего то осмысленного никогда не дойдем :)Прогаем АСУ-ТП ( МЭК 61131-3 языки) на базе отечественного MK (https://habr.com/ru/articles/881784/)
Да, в первом приближении все так, нужен только машинный таймер, и как показано встатье, на первом этапе можно вообще без прерываний, только lds архитектурная подерка и UART ( какой то интерфейс чтобы видеть что есть результат) и build тоже стандартный
По последнему пункту не совсем понятно может ли Embox (или приложение в её оставе) исполняться прямо из Flash ? На нашей СнК есть поддержка XiP, т.е. NOR flash память мапится в адресное пространство 0xA0000000.
Да, можно исполнять прямо из flash. ROM регион
Вопрос в том, кто скопирует сегмент .data в RAM, а так же проинициализирует .bss, .stack и .heap.
Embox копирует секцию .data (если нужно) и зануляет .bss, устанавливает указатель стека (размер стека задается в конфиге), указатели стека для потоков устанавливаются отдельно Embox, кучу инициализирует тоже embox (если нужно).
Руслан, вот опубликовал статью (https://habr.com/ru/articles/884438/ ). На мой взгляд все достаточно просто. MMU не обязателен, но может быть использован если потребуется. Возникнут естестенные вопросы, как прошить (положить в память) программу и есть ли какой нибудь UART, чтобы общаять. Но все они решаемые! :)
Спасибо. Конечно! :)
Спасибо за статью и огромную работу!
Мы похожие вещи пытаемся делать, причем на отечественной элементной базе (https://habr.com/ru/articles/881784/). Сейчас работаем над 4Diac.
Понял, спасибо!
Запустить Ваш пример на на MIK32 (без SDL) не представляет труда, вопрос скорее был в экранчике. То есть, предлагается взять SPI экранчик с приемлемым разрешением, и добавить его поддержку в SDL и уже на него вывести?
Спасибо за отличную работу и статью. Очень круто.
Хочу предложить в качестве варианта запуска ОС Embox.
Мы уже проделали большую работу в плане запуска графического стека на легких платформах (Разбираемся в особенностях графической подсистемы микроконтроллеров, Запуск Qt на STM32. Часть 2. Теперь с псевдо 3d и тачскрином) И конечно уже есть поддержка RISC-V RV32I (Добавляем в Embox новую платформу с архитектурой RISC-V , Embox дает (RISC)-пять на платформе VOSTOK)
Нужно смотреть реализацию print()
В embox например можно отключить поддержку плавающей точки в printf и производных функций
`include embox.compat.libc.stdio.print(support_floating=0)`
Отличная идея, мы подобное делаем для внутренней памяти МК (https://habr.com/ru/companies/embox/articles/573244/ )
Но с АМУРом могут возникнуть ряд труностей. :(
Одну Вы отметили, шина занята, нужно изучать можно ли вообще подмешивать команды Другой вариант это попробовать разместить процедуры работы с SPI (и flash) в eeprom и оттуда их вызывать. Но его очень мало и... в общем идея отличная, сами смотрели на эту flash как на расширитель возможностей, но есть ряд очевидных сложностей в реализации.
У нас была какая то простая консоль с цветами (не помню может vt102), но сейчас она не сильно востребована. Если предложите изменения будем рады:)
Ответил выше.
Лично мое мнение, что АМУР для узкого спектра задач (достаточно простых) напримре вспомогательный контроллер, одного двигателя или как элемент доверия при загрузке системы. Но это очень важный шаг для развития всей отрасли! На нем уже можно отлаживать какой то сафт, как то обучать, делать какие то простые устройства и так далее
Пока к сожалению не много, простейшие сбор данных с датчика и после какого то значения отработка (ситуации). То есть, этот МК рассматривается как элемент доверия к системе, самих характеристик (например ОЗУ не возможно расширить), явно не достаточно для современных функциональных требований!
А вот на К1921ВГ015 (https://habr.com/ru/articles/881784/) уже много. В будущем расчитываем на производство аналогичный на территории РФ
Он лежит не в platform а в 'templates/' (обычно это общие для архитектуры темплейты)
`make confload-riscv/minimal`
PS Спасибо, что пробуете!
Спасибо интересно. Не знал о таком.
Но все таки ARM Cortex M0 не очень выглядит "своим" :)
Если своим считать испечённый кристалл, то, на сегодняшние день, да. Но, если смотреть несколько дальше, то свои ядра (особенно риск5) и младшие модели которые можно по технологии например 90 нм, например МК, то они могут появиться довольно скоро. Пока не начнется этот длинный путь, цель точно не приблизиться!
:))))
Процесс идет, надеюсь ситуация будет улучшаться. Но конечно требуется время, столько времени
обсерне уделяли этому внимания, а просто деньги рубили...Ой, lds.conf из которого генерится линкер скрипт (карта памяти ) :)
Спасибо. Но подумал, если начинать с этого каждый раз, то до чего то осмысленного никогда не дойдем :)Прогаем АСУ-ТП ( МЭК 61131-3 языки) на базе отечественного MK (https://habr.com/ru/articles/881784/)
Да, залили, а что конкретно поправить?
Да, в первом приближении все так, нужен только машинный таймер, и как показано встатье, на первом этапе можно вообще без прерываний, только lds архитектурная подерка и UART ( какой то интерфейс чтобы видеть что есть результат) и build тоже стандартный
Да, можно исполнять прямо из flash. ROM регион
Embox копирует секцию .data (если нужно) и зануляет .bss, устанавливает указатель стека (размер стека задается в конфиге), указатели стека для потоков устанавливаются отдельно Embox, кучу инициализирует тоже embox (если нужно).
Да, вот https://habr.com/ru/articles/884438/
:)
Руслан, вот опубликовал статью (https://habr.com/ru/articles/884438/ ). На мой взгляд все достаточно просто. MMU не обязателен, но может быть использован если потребуется. Возникнут естестенные вопросы, как прошить (положить в память) программу и есть ли какой нибудь UART, чтобы общаять. Но все они решаемые! :)