Современный промышленный эмбед

Bingo!

Европейцы молодцы. Потом (а кое-где даже сейчас, см Powerwall) ты сможешь подключить к зарядному устройству электрочайник, или автомобиль к дому чтобы пережить блэкаут, или автомобиль к солнечной панели чтобы зарядить, в общем туда-сюда-обратно, а японцы в это время свои CANбельки не смогут вставить никуда кроме своих автомобилей.

Хорошая попытка, но нет. Оно не подключится - там Powerline был на каком-то несущем питалове типа 12V, но, естественно, переменным током, и ТОЛЬКО для DATA. Шансы равные, CAN ещё и совместимее.

Сам стандарт C емнип содержит только fork.

Наоборот. Начиная с C11 нити в стандарте есть, а fork’а нет.

Давай трезво подумаем и ответим на вопрос: нам нужно написать некую эталонную реализацию, желательно как можно быстрее, но чтобы она точно работала, не падала, и желательно запускалась на нескольких платформах. На чем это сделать? C/C++ сразу отпадают, потому что это самые ненадежные ЯП после ассемблера. Rust? Я уверен, что ты бы первый начал реветь, если бы тебе на нем дали либы. Standard ML? Паскаль? Java?

Вот нифига. Я очень плохо представляю себе «асинхронщину» на си. Это прямо противоречит всей сишной парадигме

Прямо сейчас этим и занимаюсь. Не совсем на Си, а на крестах, но кресты почти никак этому не способствуют, потому что ённый RAII максимально плохо налазит на асинхронщину, поскольку нет ни возможности GC для сложных сценариев, ни даже банальной инициализации-деинициализации объекта как отдельного шага, через которые системы с GC обычно работают, а вместо этого есть конструкторы-дейструкторы, которые требуют немедленного выделения-высвобождения памяти и ничего между. Дальше следствием невозможности работы со сложными объектами является неспособность обоих языков передать управление некой внешней асинхронной функции, короче говоря, нет СОЧЕТАЕМОСТИ.

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

Лол. Разговор — заслушаешься. Одному fork(), в эмбеде, ога. Другому «внешняя асинхронная функция» и «потоки»…

Вы, джентльмены, вообще не в курсе, что софт может работать на голом железе? Максимум — с FreeRTOS’ом (или подобным) для реализации многозадачности, и то — бывает, накладные расходы на переключение контекста и синхронизацию не всегда приемлемы, поэтому вся жизнь возможна только в прерывании таймера (хорошо, если их ещё в железе несколько).

Вы, джентльмены, вообще не в курсе, что софт может работать на голом железе? Максимум — с FreeRTOS’ом (или подобным) для реализации многозадачности, и то — бывает, накладные расходы на переключение контекста и синхронизацию не всегда приемлемы, поэтому вся жизнь возможна только в прерывании таймера (хорошо, если их ещё в железе несколько)

А ты вот в курсе, что есть FPGA, которые и есть настоящее голое железо, а не вариант десктопных процессоров из 80-х на литографии из нулевых.

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

А ты вот в курсе, что есть FPGA, которые и есть настоящее голое железо, а не вариант десктопных процессоров из 80-х на литографии из нулевых.

Мне тут попалось предложение какой-то воронежской fpga, аналог альтеры десятилетней давности - 50000 рублей чип

Мне тут попалось предложение какой-то воронежской fpga, аналог альтеры десятилетней давности - 50000 рублей чип

Какой-нибудь ICE40 на 500 конфигурируемых блоков/4000 логических стоит 600 рублей. Может быть это и дороже AVR, но никакой AVR тебе такой энергоэффективности не выдаст.

Я для своих девайсов пишу SDK на Python.

Не ну а чё, Modbus-RTU поддерживается же!

Ну и выгядит это всё снаружи приятненько:

device.attribute = ATTR_VALUE #И вот тут улетает запрос через RS-485

Правда, куча мусорных запросов по итогу, но я не готов подобие sqlalchemy городить ради трёх с половиной хипстеров, которые будут управлять девайсом через Python, а не через нормальную систему АСУТП.

На Си такое только через кучу форков с циклами ожидания. И еще это безобразие из форков как-то нужно между собой заставить общаться.

Ну да, так ядро и работает. Вызывает системный вызов.

Товарищ, у данной схемы есть один минус. Когда я начну пейсать в суппорт. Ничего не работает. Я должен буду общаться на их языке. Претензии на ноде формулировать.

Товарищ, у данной схемы есть один минус. Когда я начну пейсать в суппорт. Ничего не работает. Я должен буду общаться на их языке. Претензии на ноде формулировать.

Только если там будет заранее описано, под чем оно не работает, или только под чем работает.

Если «designed only for nodejs» - да, обязан. Если же они будут предоставлять API, пусть даже http\s - то по идее претензия должна быть рассмотрена. Ты же к саппорту неработающей VPSки обращаешься на человеческом, а не на PHP.

Ты либо никогда нигде не работал, либо сам суппорт и фонтанируешь. Обязан, бггггг. Ты ещё скажи, судиться с ними, бгггг. Это тебе товарищ не МВидео.

Ты либо никогда нигде не работал, либо сам суппорт и фонтанируешь. Обязан, бггггг. Ты ещё скажи, судиться с ними, бгггг. Это тебе товарищ не МВидео.

И суппортом я тоже был. И не только ИТ-шным, а еще и железячным.

Поэтому да, обязан.

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

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

В 2013 например, я купил ноут HP, не помню какую модель, на AMDe350, оно дико грелось. Отнес его в магазин, мне там начали что-то втирать про неподдержку Linux. Я им ответил, что ноутбук не является программно-аппаратным комплексом, систему охлаждения никоим образом не должно волновать, какой программный код сейчас исполняется, но если они хотят поспорить с этим утверждением - они могут прямо сейчас мне написать отказную о возврате, и завтра на основании этой отказной общаться уже с инспектором. Разумеется деньги мне вернули.

Если же больница за бюджетные деньги купила какой-нибудь МРТ с внешним портом, по которому согласно документации можно TTL импульсами управлять FPS'ом - то функционал здесь ограничивается связкой «TTL->FPS», а не чем я генерирую эти импульсы - nodeJS, python, или мультивибратором на двух транзисторах и кондёре, и «неработоспособность» в данном случае будет определяться условно говоря тестером на этом внешнем порту (импульсы есть\импульсов нет) + отсутствием результата. Но не видом источника TTL-сигналов. Ну и разумеется в таком случае, поставщик сего МРТ получит по башке, а уже характер получения по башке зависит от страны, больницы, поставщика, бюджета, и так далее.