ЯП с компиляцией в Си для эмбебеда

https://stackoverflow.com/questions/8563670/how-to-convert-llvm-ir-to-c-code
Так по идее можно попытаться любой llvm язык в сишку протранслировать

Проще C выучить и не выпендриваться

А как же повыпендриваться ? Ведь МК задачи без ООП, генериков и лямбд не все решать дееспособны… ПМСМ «повыпендриваться» = «Но я хочу писать с классами, генериками, лямбдами итд»

https://github.com/libav/c99-to-c89/

https://github.com/JuliaComputing/llvm-cbe

Вносите Eddy_Em

Любой язык, который будет адекватно работать на 8-бит контроллере будет также подобен С, то есть будет его собратом и иметь тот же уровень. Любые фичи имеют оверхед. Либо размер кода и данных будет гигантским и с этим будут проблемы на твоём контроллере, либо жрать инструкции как не в себя ну и тд тп.

В качестве вариантов могут быть только варианты Pascal(в том числе Ada но тут надо смотреть), варианты фортрана, Форта естественно ну и если найдёшь - варианты Caml. Но всё это будет слабо отличаться от С.

Были такие попытки для AVR контроллеров. BasCOM и FastAVR. Васик короче. Оба в итоге слились. Вернее один купил другой, а потом тупо превратился в мелкую местечковую проприетарну недоподелку, которая даже на мигание светодиодом создает прошивку раз в пять жирнее чем на сишке.

Да и главный вопрос: это 8 бит. Ты уверен, что там нужно что-то фичастее сишки? Зачем? Какой-нить стм32 я бы понял, но 8 бит…

Тут я не согласен. Сейчас пишу для stm8 используя С11 компилятор от iar. Много применяю шаблоны. Немного начал использовать boost. Но ирл эти абстракции ничего не стоят. Регулярно проверяю ассемблерных выхлоп.
Для тини13 тоже писал на куче шаблонов. Гцц очень хорошо оптимизирует код.

Haskell

Тут на форуме уже давали ссылку на видео как Nim использовали для контроллера со следующими характеристиками: 8-Bit Microcontroller, ATmega 32u4, 16Mhz, 32KB Flash, 2.5KB RAM, 1KB EEPROM.

Но вообще, я согласен с мнением, что для таких контроллеров нужен только си либо ассемблер. Даже и для STM32 си достаточно. Языки более высокого уровня имеет смысл использовать когда есть нормальная ОС.

МК задачи без ООП, генериков и лямбд не все решать дееспособны

Ну ты пошутил, так пошутил! Как раз таки с ООПщиной, генериками и лямбдами поди-ка найди железячника!

Я на форумах по радиоэлектронике только пару человек встречал, которые под STM32 на С++ пишут. Но глядя, сколько времени один из них убил на написание всей низкоуровневой подложки, поверх которой теперь он так лихо может фигачить, я сомневаюсь, что С++ имеет хоть какое-то преимущество в этом плане над С: я свои сниппеты просто копипастой втыкаю в новые проекты, немножко переделываю настройки по надобности — вуаля! Тоже почти не нужно каждый раз долго ковыряться в RM.

Что до восьмибитников, то при нынешней (точней, той, которая до «кремниевого кризиса» была) стоимости 32-битных МК вообще нет смысла уродоваться с восьмибитками!

компилятор от iar

И не стыдно тебе, вендузятнику, на ЛОР ходить?

8 битный МК

классами, генериками

Мальчик явно болен и классами тут не помочь.

Он есть под линукс
IAR теперь с блекджеком!!!!

А что за лицензия: GPL, BSD, Apache или еще какая свободная? ;)

Попробуй использовать метапрог

Много применяю шаблоны. Немного начал использовать boost.

Что же у тебя там за задачи?

лорчую.

Препритарная. 8к ограничение кода. Но ты же знаешь что самые ходовые stm8 как раз 8к те ограничения фактически нет.

А если пользоваться sdcc, то проблем никаких нет. Вот сколько всякой чуши я на STM8 понаделал, пока дурным был. Сейчас я уже маловероятно возьмусь что-нибудь реализовывать на STM8: те же STM32F030 по соотношению цена/качество намного приятней.

Из восьмибиток есть разве что CH55X китайские, у которых безкристальный USB и ядро 8051. Но вот у самых дешевых (которые как раз стоят, как 20-ногие STM32F030 были до "крЫзиса") всего лишь 1кБ оперативки. Впихнуть туда что-то, приличней USB-релюшки или клавиатурки/джойстика, будет проблематично.

У тебя там много хорошего кода который мне бы пригодился. Но ты пишешь под GPL так что не выйдет :-/

Что до восьмибитников, то при нынешней (точней, той, которая до «кремниевого кризиса» была) стоимости 32-битных МК вообще нет смысла уродоваться с восьмибитками

Проблема заключается в чем... System-on-Chip для мобилки с 260 МГц ARM926EJ-S, 94 kB RAM, 256 kB flash, кучей обвеса для радиосвязи, экрана, памяти стоит оптом около 1$. Оптовая цена самых дешманских микроконтроллеров c 16 байтами оперативы — где-то 0.5$. Посередние есть какой-нибудь Infineon XMC1100 на Cortex-M0 33 MHz с 8-64kB flash, 16kB SRAM за 0.6-0.7$. Ты уже тупо платишь за кремний и корпус, а не за контроллер. Зачем?

Китайцы сейчас используют аналоги тиньки 13 по цене 2.5 цента за шт. http://www.padauk.com.tw/en/product/index.aspx

Сам возмутился — сам ответил: таки есть решения с шестью ножками за 3 цента:

https://lcsc.com/product-detail/PADAUK_PADAUK-Tech-PMS150C-U06_C168658.html

Да, тут низкая цена достигается как раз за счет экономии на ножках и корпусе. Ждем микроконтроллеров с четырьмя ножками.

Есть. В sot23-6 корпусе

Китайцы сейчас используют аналоги тиньки 13 по цене 2.5 цента за шт. http://www.padauk.com.tw/en/product/index.aspx

«Аналог» — это громко сказано. Скорее «огрызок тини13».

Есть. В sot23-6 корпусе

Ну это ж целых шесть ножек. Много и дорого. Надо четыре ножки.

Рабочих 4.

Vala - Этакий C# от гнома. Говорят прибита гвоздями к gtk.

Т.к. Vala использует GObject, то она прибита к GLib (а не к GTK).

А если пользоваться sdcc, то проблем никаких нет

Не знаю как сейчас, но лет 5 назад у него были феерические глюки при компиляции.

По качеству оптимизации он и сейчас сливает наверное всем. IAR же говорят крут и своё бабло отрабатывает.

Я сравнивал. sdcc вообще никак не оптимизирует. Iar выжимает каждый байт

Я на форумах по радиоэлектронике только пару человек встречал, которые под STM32 на С++ пишут.

Ну уж не «пару», а «десятки» как минимум :-) Вот, даже оська есть на плюсах. А вот аж целый подфорум по ней на электрониксе.

Но глядя, сколько времени один из них убил на написание всей низкоуровневой подложки, поверх которой теперь он так лихо может фигачить

Я подозреваю, что ты про это. Не так уж и много времени. Кусочками, по мере надобности. Зато как клёво теперь «лихо фигачить» :-)

Ну да. Я как бы направляю лучи поддержки разработчикам sdcc, но если для 32х битных контроллеров есть хотя бы gcc, то для 8битных МК свободных альтернатив фактически нет.

А что тебе мешает под двумя лицензиями писать? Работодателю отдаешь арабскую, а на гитхаб выкладываешь GPL!

Я тоже заказал ch55x ради usb. Iar умеет 8051. Я бы рад использовать sdcc но им до iar как до луны :-/

Примерно в те времена я под STM8 и писал. Да, код неоптимизируемый местами и приходится ручками оптимизировать, это не gcc, конечно, но на безбабье и рыбу раком, как говорится! Ведь под STM8 больше нет свободных компиляторов!

Так я пишу под лицензией Apache v2. Твоя GPL завирусит мою Apache

Рабочих 4

Если ты про PFS154, то там все шесть задействованы:

https://datasheet.lcsc.com/szlcsc/1812131724_PADAUK-Tech-PFS154-S16_C317613.pdf

PFS154-U06:SOT23-6 (60mil)
6 ног - 2 питания = 4 рабочих

PFS154-U06:SOT23-6 (60mil)
6 ног - 2 питания = 4 рабочих

Без питания он чот не работает.

Есть еще такой компилер как COSMIC. Который недавно зделал бесплатными тулчейны для АРМ и СТМ8.

Nim lang

Ведь МК задачи без ООП, генериков и лямбд не все решать дееспособны…

А вот я, пришедший из zx80 ассемблера и его бейсика, не смог в эти ваши ООП и прочее.

Ты ирл использовал? Сколько флеша отъест его рантайм? Обойдется ли он без uint64 и float?

Сам посмотри что там генерится в сишечку httpss://nim-lang.org/docs/nimc.html#compiler-usage-generated-c-code-directory

В общем интересуют истории успеха.

Запускал php интерпретатор на 200Мгц МИПСе и 500Мгц ППЦ с 2-8Мб оперативки где даже поддержки флоатов не было

И работало идеально в реальном времени все обрабатывалось, сотни строк кода на ПХП, интерпретатор был https://ph7.symisc.net/ (тамже есть и SQL интерпретатор/сервер который тоже работает) все на Си без зависимостей с поддержкой всех возможных архитектур.

Видел в дистрибутиве OpenWRT есть Джава интерпретатор я забыл как называется, но он тоже в сотни килобайт размером который запускает джава байткод на любой архитектуре.

И железа слабее 200Мгц просто нет уже больше 10 лет, куда ты «в теории» можешь чтото полезное поставить (от старых мобилок до роутеров и старых Пи-подобных АРМов)

Поэтому если тебе в 2021 нужно писать на С++/других языках то лучше и проще взять дешевую Расбпери/Орандж ПИ подобную плату с АРМом и писать туда на чем хочешь, не страдая херней с платформами которым больше 20 лет.

Запускал php интерпретатор на 200Мгц МИПСе и 500Мгц ППЦ с 2-8Мб оперативки где даже поддержки флоатов не было

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

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

устройство нужно делать под задачу, у меня не было «абстрактной задачи сделать одно устройство на все случаи жизни» мне нужен был минимальный вебсервер на том железе что было, и он работало и досихпор работает (я убрал пхп за не надобностью оставив банальные html с поддержкой серверных скриптов)

рыночным аргументом,

у тебя аргумент человека с adhd, пытаешься «сделать невозможное»

я лично не представляю «твою задачу» потому что в 2021 РаспбериПи-подобная плата с АРМ на 2Ггц и 2Гб оперативки стоит в районе 50$ и на основе этого делают «все» и умные дома и камеры видеонаблюдения и умные колонки

и «спорить» или даже обсуждать твою большую фантазию с «абстрактной невозможной задачей» я не буду, у меня у самого флешбеки от одних твоих сообщений

Допустим у меня есть 8 битный МК
писать с классами, генериками, лямбдами итд

Зачем там классы? Для полтора таймера и 2К ОЗУ? Или ты пины собрался классами описывать? Вся суть программирования под такой МК это инициализировать периферию, настроить в цикле принятие данных по аппаратному интерфейсу, отработать по сырым данным сравнивая с каким нибудь уже поготовленным массивом данных и щелкануть какой нибудь релюхой на одном из пинов. Там даже Си с избытком хватает.

32-битных МК вообще нет смысла уродоваться с восьмибитками

не соглашусь, если тебе все богатство переферии 32битного контроллера не нужно то зачем его ставить, если нужна какая-то сигнальная банальщина?

на типичном 8-битном микроконтроллере (HC05, 8051, PIC-18F и т. Д.) Можно изменить состояние бита порта, используя одну инструкцию. На типичном ARM (32-битном), если содержимое регистра было первоначально неизвестно, потребуется последовательность команд из четырех команд:

    ldr  r0,=GPIOA
    ldrh r1,[r0+GPIO_DDR]
    ior  r1,#64
    strh r1,[r0+GPIO_DDR]

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

С другой стороны, 32-битные контроллеры неизменно предназначены для эффективного доступа ко многим видам структур данных, которые могут храниться в памяти. Для сравнения, многие 8-битные контроллеры очень неэффективны для доступа к структурам данных, которые не являются статически распределенными. 32-битный контроллер может выполнять в одной инструкции доступ к массиву, что потребует полдюжины или более инструкций на типичном 8-битном контроллере.