Да ти кажа тя тема изобщо не я следя съответно изобщо не поглеждам детайлите. Случайно се зачетох в поста на Миро, сигурно защото видях думата "бира". Спомням си навремето с HCL дискутирахме FPGA или VHDL и Миро се включи и демонстрира някакви познания, затова предположих VHDL.

Имаш планове да посетиш острова или смяташ да ме водиш в България на пъб?

Нямам конкретни планове... но ми се ходи, по-точно ми се пие бира!
Миналото хилядолетие бях там 4 години и си изкарах много добре, с колеги от различни държави и почти всяка вечер излизахме. Включително и за кратко съм живял в пъб

Абе хубаво беше, а и бяхме млади...

Помисли за някакъв механизъм за дебъг, брейкпоинти и т.н., който не е толкова примитивен като printf(). Ясно е, че хардуерния JTAG няма място тук, но ако направиш "софтуерен" JTAG, който да има същата комуникация с PC-то както хардуерния - ще може и да се дебъгва човешки с Eclipse или VSCode .

За Java2ME не мога нищо да кажа, но за микропитона - това е егати и недоразомението ... Според мен човек трябва да е голям мазохист, за да го използва за нещо повече от мигане на светодиод и то с демонстрационна цел.

вероятно може ... и вероятно ще е функция на кернела да го "спира"
но за сега искам да приключа с инструкциите, че ARMv7 е големо мазало

и реално не исках да е директен хардуерен HAL...

В случая "кернела" ( от бареметал нагоре ) контролира на максимум софтуерното ядро
като му предоставя необходими ресурси да "живее"
Другата полза е мултиплатформеност - всяка хардуерна система със C2ME ( условно наименование на проекта )
би въртяла PIC ( Position Independent Code ) C/C++ ( нативна ) апликация

За абстрактност, скорост ... приложения и ползи, в момента не мога да гадая ...
докато не направя некви тестове

и BTW, в момента не се занимавам с електроника - просто си чеша крастата

или не искам
еби, учи, еби, учи ... после: Дай една цигара...

Като не искаш защо пишеш тук?

Аз поне дори да искам да помогна или да коментирам, честно казано не смея да се обаждам щото в постовете ти има твърде много неясноти.
Преди време пак нещо те тормозеше и пак така не ми стана ясно какво. На мен не ми е зор, де. Просто се кефя като видя някой колега да се разработи. И като повечето българи аз не обичам да работя, но обичам да давам акъл. Може би и ти като българин ще кажеш, че не искаш акъл, а пари. Но пари няма - действай!

Между другото ако не искаш или не можеш да споделяш всичко, по-добре не загадвай много неща наведнъж. Примерно това със софтуерното ядро и PIC код - и двете неясни как и защо, но двете събрани в един проект направо ме хвърлят в оркестъра.. Аз никога и при никакви обстоятелства, колкото и да ми плащат не бих ги съвместил. Но може би не сме на един и същ акъл...

Че писане на HDL не е ли по-забавно от писане на СИ или Асемблер?

- софтуерното ядро - имитира байткод, независим от хардуерната платформа.
и за да не мисля нов байткод и компилатор за него - използвам ARMv7-M + GCC
а за да изпълня байткода - емулация на ARM инструкциите

- PIC ( Position Independent Code )
софтуерното ядро си има собствено (физическо за него) адресно пространство
няма периферия ... просто ползвам "байткода" - логиката на апликацията

хардуерното MCU (kernel) който ще емулира горното(апликацията) не се интересува къде се намира горното
за него той е един BIN записан някъде във флаша му
когато го стартира му дава RAM колкото иска апликацията, а за ROM - използва бина където е записан
Реално прави MMU - фалшиви(виртуални) RAM/ROM, но за апликацията RAM/ROM са си истински
Сега. софтуерното ядро няма периферия, ще използва тези на кернела и не знае нищо за тази периферия освен че може да я манипулира чрез API. Примерно:

Но за апликацията това са две незнайни функции - не знае физически къде се намират, просто иска да ги използва
тук на помощ идва PIC и GCC - компилира тези 2 функции като extern - слага ги в един масив REL/GOT таблици в ELF-а ( накрая е BIN )
А когато кернела стартира апликацията - прави релокация REL/GOT таблицата на апликацията
Пренасочва желаната функция към истинската такава ... API
GCC го прави(компилира) автоматично (-fpic) за да не го правя на "ръка"
Когато кернела емулира и контролира апликацията когато APP поиска API функция, кернела я изпълнява и му връща резултата


Цялата "технология" съществува ... ARMv7-M като байткод и GCC като инструмент,
остава само емулацията и API-то...

Реално така работи Линукс Кернел / Линукс Апликация ( PIC )
Линукс Апликация използва физическото ядро - докато аз софтуерно ядро което е под максимален контрол
еее - за сметка на производителност...

Линукс / Андроид (JAVA) хардуера елмулира JAVA байткода
Хардуер -> Python интерпретира питон или емулира байткод

пример с PLC:
произвеждаш PLC-тa базирани на всевъзможни MCU - STM32, ESP32, PIC32...
за прериферията или трябва да правиш сложни гимнастики или шарваш адресни пространства
за да може IT-ишния инджинер да си напише PLC логиката без да се съобразява с хардуера
и с голяма вероятност IT-шника да забие целия хардуер...

или "универсален байткод" емулация - в случая ARMv7(байткод) и GCC като (безплатен и мултиплатформен) инструмент за компилация
Сега, дали ще е проста PLC логика или сложно IoT приложение - ARM и GCC ще се справят с предизвикателствата

Добре, сега схванах защо ти е PIC-a...

Както се казва бързо схващам, само трябва да ми се обяснява повечко

Още не мога да вдяна смисъла на байткода. Има множество RTOS които имат поддръжка за приложения, включая run-time зареждане и изпълнение. Примерно Nutt-a и други такива. Аз не ползвам такива концепции, затова и не съм задълбавал, но мисля че приложението може да е с динамично линкване, демек всеки път може да го зареждаш на различни адреси, или да е за фиксиран адрес. Мисля, че има всякакви опции, при всички случаи се изпълнява нейтив, имаш пълната функционалност на съответния ОС и библиотеки.
Единствената разлика е, че при теб приложението ще го компилираш еднократно и евентуално ще работи на множество таргети. Иначе се компилира за всеки тип процесор поотделно. Но не виждам какъв е проблема, не знам някой да използва 100 различни платформи едновременно. А и да използва, компилацията ти е най-малкия проблем.
Предполагам това, че тая цялата концепция няма връзка с PLC, то ти просто един вид тестово приложение?

Зависи... Зависи от човека какво му допада, зависи и от конкретния език. За съжаление когато аз се занимавах активно VHDL/Verilog още не бяха навлезли. Повечето ми стаж мина на ABEL което не бих го нарекъл точно HDL. Когато минах на VHDL направо се родих... това е все едно да минеш от 8051 асемблер към Ц++ с STL.
Зависи и от желязото също. На FPGA е доста по-забавно отколкото да кажем за CPLD, в което постоянно не ти стигат ресурсите и трябва да правиш много компромиси. А най-лошото при CPLD-та беше, че се работи с мноооого комбинаторна логика, която компилатора може да рутира както си иска и да промени тайминги на критични сигнали. Много е забавно... такива бъгове се получават и изчезват, че си е почти религиозна работа.

Апликацията да бъде тотално изолирана от хардуера...

байткод наричат бинарните компилации от JAVA, Python... етц,
a при мен е емулация на машинен код от C/C++ за ARM приложение
Преди Андроида така работеше J2ME - пишеш на Java, компилираш и го мяткаш на "тилифона"
Сега с Андроида - пак так...

Ако махна емулатора и оставя само PIC-а - си става динамично зареждане на апликация,
но трябва да е компилирана вече за текущата архитектура
и споделя общ флаш/рам с процесора, а при липса на MMU - и физически адреси...
и в случая -fpic работи само за "незнайните" функции

Не знам... хванал си се, явно ще го направиш.

На мен ми изглежда доста странен тоя подход. Може и да има смисъл в някоя конкретна ситуация. Просто не се сещам за такава.

Поне от моята камбанария виждам много компромиси и ти вероятно си ги знаеш, но ще изброя част за да знаеш какво на мен не ми допада:

1) Емулацията по принцип като решение за интерпретация/скриптосване и т.н.
Има множество алтернативи. Дали ще направиш интерпретатор на BASIC, дали ще е питон някакъв, дали ще е джаба виртуална машина, всичкото е все една и съща концепция. Всички са що-годе изолирани от хардуера, всички или почти всички имат защита на паметта и т.н. Което е по-съществено, всички са що-годе мислени с идеята да не са ужасно бавни. Винаги пишеш на някакво по-високо ниво, често по-високо даже и от това на С/С++ и дали чрез нейтив библиотеки или по друг начин ще са по-бързи от теб. В някои случаи ще са на порядъци по-бързи, просто защото критичния код е нейтив, а не интерпретация.

2) Когато се гони универсалност и имаш някаква форма на интерпретация, обикновено най-доброто решение да се ползва текст, а не байткодове, машинни кодове или някакви други кодове. Текстът има множество предимства. Най-малкото хващаш едно конкретно устройство на полето, закачаш се по някаква конзола, редактираш с тъп редактор ала-vim, да не говорим че може и автоматично да патчнеш всички срещания на еди-какво си с нещо друго. И даденото PLC да кажем, вместо да клати един пин може да клати друго си нещо...
Но по-важно е когато имаш менажиране. Демек да кажем имаш хиляди PLC-та на полето, обаче едно управлява мандра, друго совалка, трето управлява и мандра и совалка едновременно. Ако трябва всичкото това нещо да го менажираш през сървър, той трябва да ти генерира "кода" за всяко едно устойство индивидуално. Аз досега не съм виждал сървър който да генерира С/С++. За сметка на това практически ВСЕКИ сървър генера текст и обикновено тоя текст се генерира на момента за индивидуална заявка. Естествено обикновено се генерира HTML&CSS, но повярвай ми ВСЕКИ веб програмист е свикнал с тая концепция и може да направи система за менажиране на устройства. Казвам го защото сме правели доста такива неща. От друга страна ако се опиташ да ги накараш да ти сглобят валидно С/С++ приложение.... е тогава ще ме разбереш за какво ти говоря.

3) Изборът на RISC процесор и то точно ARMv7. Според мен от чувала с гайки си извадил баш болта. Поне да беше някой CISC.

4) Изолацията на хардуера се прави с абстракции, а не през виртуални машини и накрая пак да стигаш до "int digitalRead(uint32_t pin)".
Да, абстракцията може да я направиш и на високо ниво във виртуалната машина. Но класическото решение е на ниво ОС. То това е ОСНОВНИЯТ смисъл на всяка ОС. За съжаление имаме различни операционни системи и освен че са различни, поради наследство абстракциите им са далеч от идеални. А при ембедед нещата са още по-зле. Много хора си мислят, че RTOS е едно, а абстракцията се прави в библитеките за конкретния таргет. Демек ползват гол кърнел и го наричат това RTOS. Според мен дълбоко погрешно, понеже в него обикновено няма нито real time нито operating system.
Както и да е, аз съм доста субективен в тая област. Знам, че никой не ме пита как трябва да се правят нещата. Това обаче не ме спира да давам акъл по темата. Според мен дефиницията за хардуер е "нещо което приема и/или дава информация". Демек от него може да се чете или пише. Съответно абстракцията на това животно са функции за четене, писане или и двете едновременно. Тази абстракция или по-точно тези функции не може да са специфични за конкретен хардуер или конкретен таргет. Всъщност абстракцията не бива да се ограничава само до реален хардуер. Ти може да имаш и виртуален хардуер или някаква абстракция от по-високо ниво, да кажем като сокет, файл и т.н. Но да кажем, че базовия клас на всички абстракции е клас от тип "handle" и който позволява да четеш и/или пишеш.
Обикновено приложенията не се интересуват какво се крие зад хендъла. Да кажем че PLC-то трябва да чете вход, подаваш му хендъл и толкоз. Това му трябва да си направи логиката. Не му трябва да знае дали зад тоя хендъл има физическо GPIO на процесора, дали е виртуално GPIO да кажем след I2C разширител или някакъв изход на някакво външно устройство закачено през WiFi мрежа или интернет. Ако правиш PLC логика теб тия подробности не те касаят и не бива да те касаят. Единственото което те касае е информацията, която трябва да запишеш или прочетеш, нейния смисъл и естествено синхронизацията. Защото в общия случай "нещото" зад хендъла има някаква скорост с която гълта или повръща информацията. Съответно ти би искал да имаш възможност да избереш дали да блокираш докато информацията цъфне или да не блокираш. Щото примерно може да имаш 10 хендъла и искаш да реагираш веднага ако някой от тях цъфне. Без значение дали хендъла е пин, дали е бутон за канселиране от потребите (ако има юзерски интерфейс), дали е таймер и т.н. Като цъфне - гледаш какво е цъфнало и реагираш според съответното задание.
Надявам се разбираш за какво говоря и защо казвам, че цитираните от теб функции са просто кофти, много кофти идея...