Здесь так много ошибок и бреда, что пришлось бы разбирать каждую строку. Поэтому вместо разбора каждой ошибки опишу свои мысли по данному вопросу.
1. Языки высокого уровня для МК (Rust, C++, C) часто компилируются в один и тот же ассемблер при решении одной задачи. Как минимум, для С и С++ это на хабре было описано.
2. Выбор языка и железа обусловлен стоящей задачей. Для единичной поделки будет разумно взять Распберри/Джетсон и накидать скрипт на питоне за полчаса. Для миллиона тостеров, где каждая сотая цента имеет значение, будет выгодней тупейший микроконтроллер и полкило ассемблера, а то и ASIC.
3. digitalWrite будет работать на любом МК, куда портирована Ардуино. DDRB привзяывает вас не только к AVR, но и конкретному чипу, т.к. для Arduino Mega, например, порт и пин для 10-го вывода могут уже отличаться от Mini. Это опять выбор — компактность+скорость или портируемость. Крайне неверно считать, что одно лучше другого. Это разные задачи, требующие разных решений.
В итоге, для каждой конкретной задачи нужно понять на каком языке её выгоднее решать и насколько сильно нужно абстрагироваться от железа.
Плата прикидывается клавиатурой и при нажатии на кнопку отправляет command + w. Будет ли работать без окна в фокусе — не знаю. На днях была аналогичная статья для кнопки mute, там говорилось про глобальные хоткеи, которые работают без фокуса.
Честно говоря, статья ни о чём. Для меня основная проблема с Sourcetrail — огромное количество ошибок, связанных с отсутствием заголовков, которые лежат по указанным путям. Но он их не видит. В общем, самая интересная и нужная часть — настройка проекта — в статье не раскрыта вообще никак.
К IDE описываемое решение никак не относится, более того, именно STM32CubeIDE автор упомянул. Здесь идея в том, чтобы избавиться от отдельного отладчика (ST-Link, JLink), перенеся его функции прямо в отлаживаемое устройство.
Лет 7 назад хотел провернуть такую же штуку в устройстве, разработанном в компании, но не смог — разработчик не подключил дополнительную линию адреса от DRAM к CPU. Пришлось заказывать новую ревизию платы. Здесь товарищу повезло, что производитель карты был готов к такому объему памяти.
Лично я вас ни к чему не принуждаю, просто уточнил, что STM32 не такой уж новодел. Сам 15 лет назад начинал с AVR, потом STM8/32, сейчас NRF52. Интересно же посмотреть куда движется индустрия и как меняются МК.
Насколько я знаю, российской электроники очень мало и преимущественно это космические компоненты по космическим ценам. 50% против текущих 20 — это, считай, в 3 раза увеличить долю. Выглядит маловероятным за 5 лет.
Если очень хочется, можно и залоченный контроллер разлочить.
embeddedartistry.com/blog/2021/01/18/is-memfault-the-future-of-fault-debugging-we-think-so
По сути, готовое решение для сбора, отправки и исследования дампов.
1. Языки высокого уровня для МК (Rust, C++, C) часто компилируются в один и тот же ассемблер при решении одной задачи. Как минимум, для С и С++ это на хабре было описано.
2. Выбор языка и железа обусловлен стоящей задачей. Для единичной поделки будет разумно взять Распберри/Джетсон и накидать скрипт на питоне за полчаса. Для миллиона тостеров, где каждая сотая цента имеет значение, будет выгодней тупейший микроконтроллер и полкило ассемблера, а то и ASIC.
3. digitalWrite будет работать на любом МК, куда портирована Ардуино. DDRB привзяывает вас не только к AVR, но и конкретному чипу, т.к. для Arduino Mega, например, порт и пин для 10-го вывода могут уже отличаться от Mini. Это опять выбор — компактность+скорость или портируемость. Крайне неверно считать, что одно лучше другого. Это разные задачи, требующие разных решений.
В итоге, для каждой конкретной задачи нужно понять на каком языке её выгоднее решать и насколько сильно нужно абстрагироваться от железа.
— Датчик другой
— Экран другой
Приведённый код не имеет смысла применительно к описанному проекту.