Многие пишут про то, что сделано «несерьезно». Честно говоря, отчасти мне не нравится наблюдать такого рода продвижение в сыром/идейном виде. С другой стороны я прекрасно понимаю, что это путь для получения инвестиций, так что все в порядке вещей. Если необходимо, то можем реализовать «правильную» аппаратную часть с адаптацией под производство, контакты должны быть видны в моем профиле.
Если код пишется для любительских поделок, то такой вариант подойдет. Как говориться на вкус и цвет. Но, в более ответственных применениях, такой «сахар» приведет к увеличению сложности верификации проекта и стоимости его поддержки.
Отмечу, что «пишет напрямую в регистры» в большинстве попросту необходимо. Довольно часто невозможно спроектировать программную абстракцию. Или такая абстракция будет неоправданно «тяжелой».
Вероятно они предполагают писать статичный код целиком, то есть с известными именами функций и ветвлениями. Для небольших проектов такое могу представить.
Для офиса выбирали столы и сразу приглянулся этот IKEA Бекант. Потом посмотрел на него в живую. Не стоит он своих денег: не очень устойчив, материал окантовки краев приклеен не очень хорошо — хорошо видны стыки и на картинках он выглядит лучше. За эти деньги мы купили 4 (!) хороших офисных стола и вышло около 14 тысяч.
С какими трудностями столкнулись при разработке? Как исправляли ошибки или сложные моменты из документации? В чем посыл статьи то? Ну платка как платка, стандартные микросхемы и решения.
Так для этого существуют корпоративные блоги. А здесь не хватает исходников на github, раскрытого рассказа о проблемах которые были в процессе изготовления.
Если имена функциям/переменным заданы адекватно, то код легко читается. Комментарии ради комментариев.