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