Доступен выпуск проекта Tinygo 0.32, развивающего компилятор языка Go для областей, в которых необходимо компактное представление результирующего кода и низкое потребление ресурсов, таких как микроконтроллеры и компактные однопроцессорные системы. Компиляция для различных целевых платформ реализована при помощи LLVM, а для поддержки языка применяются библиотеки, применяемые в основном инструментарии от проекта Go. Код распространяется под лицензией BSD...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=61396
Сборщику мусора на устройствах жёсткого реального времени самое место.
Куча приборов где реальное время не упало никому. Для каких нибудь кондиционеров реакции вообще минутами измеряется и тащить туда переоценных и вечно делающих баги сишников просто смысла нет.
> переоценных и вечно делающих баги сишников просто смысла нет1. Зарплаты переоцененных сишников ниже срежднего мидла фронтендеров на JavaScript
2. а про баги обидно - можно и вычистить и покрыть тестами
Разработчики невоенных встроенных систем в целом мало получают. Да и военных тоже, но не все.
> Разработчики невоенных встроенных систем в целом мало получают. Да и военных тоже,
> но не все.Да это в РФии так. Ну РФия и стала светочем инноваций... правда, с другой стороны списка. Может заспорить с каким-нибудь Лесото.
То ли дело другие места, истинные светочки инноваций, за которые правда приходится платить зачастую чеками как в 18 веке.
> То ли дело другие места, истинные светочки инноваций, за которые правда приходится
> платить зачастую чеками как в 18 веке.В более приличных странах понимают что нормальные специалисты не собираются работать за еду.
... не собираются работать за еду.а только за вкусную еду
Какого списка? Кто его составлял?
>Куча приборов где реальное время не упало никому.Может быть, реальное время и не упало, а вот железо под эти нужды можно купить подешевле, если не тащить лишние абстракции, что уже чисто статистически экономит кучу денег.
> Куча приборов где реальное время не упало никому. Для каких нибудь кондиционеров
> реакции вообще минутами измеряется и тащить туда переоценных и вечно делающих
> баги сишников просто смысла нет.Да как сказать? Для какой-нибудь защиты от превышения напряжения/тока, декодирования сигнала пультика и проч - реалтайм таки весьма пригодится. Не, простите, пультик не будет ждать пока у вас там GC мусор соберет, вы либо успеете собрать пакет как он летел в эфир, либо уж упс и пульт не сработает.
А ставить что-то отдельное для более жесткого реалтайма это отдельные деньги и канитель. Все обычно вешается на 1 камень по возможности. И там GC таки будет не подарок.
И... И... Ииииии... Пользователь просто нажмет кнопку на пультике ещё раз - даже и не матюкнется при этом. А общая стоимость обслуживания игогошницы по сравнению с сями выйдет раз в 8-10 меньше - в хорошем для цэшников случае. Такие вот дела.
Идите нафиг с таким предложением! Я хочу один раз нажать кнопку и чтобы всё работало!
А ещё ты хочешь более быструю лошадь вместо машины. Как же ты не поймёшь что производителю лучше знать чего ты хочешь.
Но купишь по местной привычке - вот самое дишманское из всех решений, да?
> Но купишь по местной привычке - вот самое дишманское из всех решений, да?Ну и вот получит пультик работающий через раз тогда :)
>> Но купишь по местной привычке - вот самое дишманское из всех решений, да?
> Ну и вот получит пультик работающий через раз тогда :)Я вас умоляю! "через раз" на gc наступать - даже со старой java'ой постараться надо было. А с учётом частоты использования типового "пультике" - ну, раз в полгода, может быть...
Как? Как можно гарантировать, что в пульте не села батарейка, что он не обернут фольгой, что ты не запихнул его в кастрюлю с борщем, в лучшем случае на пульте будет лампочка, которая мигнет зеленым если команда прошла, или красным если нет, или не мигнет вовсе, что опять же значит - нет.Рилтайм не гарантирует выполнение, он гарантирует фиксированное время ответа, уже есть блюпуп пульты, которые в целом не сложно допилить до рилтайма, ну будет там свой рилтайм, который всегда на связи, синхронизирует время, и будет лампочкой мигать, только сколько это будет выжирать батареи, и зачем?....
вот когда батареи позволят работать устройствам годами, будут ли это батареи на ядерном распаде, или квантовые схемы "кушающие" микроватты, да опять же уже есть, только цена их несоизмерима, а значит никто в здравом уме не станет пихать их в пульт для кондера, а вот когда технологии позволят делать хотябы сопоставимо по цене, вот тогда, может быть и да
>Для какой-нибудь защиты от превышения напряжения/тока, декодирования сигнала пультика и проч - реалтаймсо всякими защитами по току/напряжению почти согласен, но пультик. вот не смеши.
сигнал приемника заводиться на апаратуру с прерыванием (или таймер или GPIO), данные в прерывание складываются в буфер и затем спокойно обрабатываюися в основном цикле.
> сигнал приемника заводиться на апаратуру с прерыванием (или таймер или GPIO),
> данные в прерывание складываются в буфер и затем спокойно обрабатываюися в основном цикле.Заводить сигналы контролируемые внешним миром на IRQ как бы несколько моветон ибо так вам в результате можно всю систему жесточайше положить ремотной активностью - устроив "interrupt storm" в самом брутальном и лобовом виде. При том в энных условиях это даже само может получиться, даже не злонамеренно.
Алсо до того как это рассказывать нехило бы позырить на формат пакетов пультов. Ну вот нет в МК железок таких - и даже подпор измерений таймером все равно не отменяет нужду быстро вертеться на все это дело, на каждый бит.
> вечно делающих баги сишников просто смысла нетГлупости пишешь.
GC можно выключить.
https://news.ycombinator.com/item?id=27117777
Ну так выключи её, Go отлично работает и без, просто код должен быть написан соответсвующе.
Если компилировать вне контроллера, то и смысла нет, уже все равно чем компилировать.>>Скомпилированная программа напрямую может >>запускаться на микроконтроллерах,
Речь о обычном бинарнике.
Судя по фразе, что для датчиков и интерфейсов
предоставляются "специальные драйверы",
(то есть вместо протестированных кот в мешке), предположу что это плохо уживается с остальным ПО контроллера.
Об обработке ошибок и блокировках слышали?
Действия например при зависании одного из устройств на i2c шине? ;)
Тут сборщиком мусора сыт не будешь.>> что позволяет применять Go в качестве >>языка для написания сценариев автоматизации
Да ну? А если в скрипте ошибка, всё ПО контроллера полетит к чертям?
И как обновлять отдельный из "скриптов автоматизации"? ;)В общем, игрушка для АЭС.
Так же как на сименсе.
> Скомпилированная программа напрямую может запускаться
> на микроконтроллерах, что позволяет применять GoА что они с GC там сделали? С ним видите ли реалтайм получается - "не очень". Или это так, на правах "дадим микропитону пинка не только в вебе"?! Ринать трупы - некультурно! :)
Ну, во-один - задач, для которых критичен именно строгий риалтайм в мире сильно не 100%. И в мире эмбеддовки - не 50% даже. Во-два если уж лезть в эту кроличью нору, быстро выясняется, что generic linux для таких задач подходит не очень-то. И не-generic тоже не предел мечтаний. Но почему-то толпу топильщиков "за rtos" мы не видим... А вот цэшников наблюдаем.
Может дело не в инструменте и не в особенностях предметной области - а в давлении на чюйство илитарности и, одновременно, карман?
Да не... Быть такого не может, ерунда какая-то.
Ты это сейчас раст так решил захейтить? Зря ты так, тут пацаны такое не любят.
Расту место в исследовательских проектах. Проблема утечек памяти и выхода за границы сильно переоценена: зачастую, в приложении таких ситуаций бывает очень много, но они не к чему не приводят, потому сишникам и нас****.
А если серьезно - те, кто тянут Раст и на си бы написали без косяков, а вот как учебный язык, который приведет понимание работы с памятью - это отличное решение
> если серьезно - те, кто тянут Раст и на си бы написали без косяковО, святая простота
> Проблема утечек памяти и выхода за границы сильно переоцененаВсего лишь 70% всех cve
>в мире эмбеддовки - не 50% дажеВ embedded таких большинство. Без точного тайминга с учётом инерции ротора и резонансов ты даже шаговым двигателем нормально не покрутишь, он будет сильно вибрировать, трещать, греться и проскальзывать, и ни о какой точности позиционирования даже речи не будет идти.
>>в мире эмбеддовки - не 50% даже
> В embedded таких большинство. Без точного тайминга с учётом инерции ротора и
> резонансов ты даже шаговым двигателем нормально не покрутишь, он будет сильно
> вибрировать, трещать, греться и проскальзывать, и ни о какой точности позиционирования
> даже речи не будет идти.Ну, если вы так говорите... То всякому I(ди)OT'у в этот момент становится очень удивительно узнать, что они, оказывается, "строгий real-time" обеспечивают.
щас бы заниматься всякой фигней типа рулить шаговиком силами МК вместо того что б взять готовы
* что бы взять готовый драйвер у того же ТI.
>у того же ТIА как же импортозамещение, Советский инженер? ;)
> А как же импортозамещениеесли надо, то импортозамещай.
я не против. или что? подсказать как это сделать?
>>в мире эмбеддовки - не 50% даже
> В embedded таких большинство. Без точного тайминга с учётом инерции ротора и
> резонансов ты даже шаговым двигателем нормально не покрутишь, он будет сильно
> вибрировать, трещать, греться и проскальзывать, и ни о какой точности позиционирования
> даже речи не будет идти.Да вон какой-то тип на ESP с микропитоном - попробовал софтварно, микропитоном, "частотник" мотору изобразить. В принципе - оно даже сколько-то как-то работало даже. Но, правда, потом оказалось что если его предоставить себе надолго, иногда силовые ключи бабахают, лол.
MicroPython уже не нужен?
> MicroPython уже не нужен?Да он никогда и не был нужен.
> Tiny
> LLVMМожно выбрать только одно.
Картошку перевели в очистки на 99%
С одной стороны здорово, что развивают альтернативные компиляторы, а с другой стороны, это дополнительное распыление сил сообщества на разные фронты.
Ждём микродотнет
да пожалуйста - https://github.com/nanoframework
> Ждём микродотнетСто лет как есть - одно время даже пытались агрессивно впаривать. Но что-то никому не надо оказалось.