Насчет запаса в камне. Я тоже всегда так думал, а теперь понял, что это правило уместно не всегда. Вот у нас есть несколько аппаратных блоков, которые контролирует MCU. Сложных протоколов нет, файловой системы, GUI и прочего. Хардкор, кароче.
Пусть работа аппаратных блоков описывается машиной состояний. Большой и ветвистой. Но конечной.
Есть у нас есть программа в MCU, которая обрабатывает все состояния и все переходы, и делает это не нарушая реальности времени объекта управления, то вопрос - а где здесь место для запаса? Ну разве что 5% - на уход частоты накристального тактового генератора.
Причем в варианте простого MCU TDD можно устроить на аппаратном уровне.
https://ru.wikiped …0%B0%D0%BD%D0%B8%D0%B5
Иметь снаружи тестовый блок с нужным числом цифровых|аналоговых входов|выходов, и быстродействующую систему управления ими.
Я много постил про Ehernet как инструментальный интерфейс в embedded. Как пример
http://caxapa.ru/697801.html
10мкс латентность из user space Linux до реальной железяки. Вполне себе нормальный тестовый стенд получается.
Вопрос в том, что ассемблер надо правильно готовить. Ему надо придать человеческое лицо и юзабилити. Тогда станет возможна реализация новых парадигм программирования.
Evgeny_CD, Архитектор (25.07.2017 11:53, просмотров: 104) ответил Dingo на М-м-м.. Ассемблер ведь задейсвтуют для использования преимуществ и сглаживания острых углов архитектуры. Как вы собираетесь унифицировать наличие/отсутствие аппаратного умножения, инструкций LPM для AVR, уникальности аккумулятора для x51 и