Средства и методы разработки

Еще раз, о чем я тут пытаюсь толковать. 1. Есть 2 варианта системы - 2-х уровневый (ПЦ+MCU) для stand alone, и 3-х уровневый (то же + host PC) для лаборатоно-разработческих целей. 2. Целевой код работает только с неким API, которое дает ОСь + дрова + некий framework. Прямое обращение к железу, подбор времени пустыми циклами и проч. запрещены. 3. Свойства API состоят в слеюущем: -- можно программировать события с привязкой к RT с точностью 100 мкс или 1мс. -- встроенные функции API проверяют наступление нужных событий в нужное время с точностью 100 мкс или 1мс. На примитивном уровне я это так себе представляю: * по аналогичии с критическими секциями time_critical секции * по старту секци запускается некий таямер * в коде есть вызовы фукций time_check_critical (time_ptr, 200, LESS_THEN, time_error_fn_ptr). И если прошло менее 200 мкс, то идем дальше, и наче валимся на обработчик ошибок 4. Фишка физического уровня MCU состоит не в том, чтобы побайно принимать или предвать по UART [как пример], а в том, что высокоуровневый драйвер оперирует понятиями PPP(HDLC) пакет, LCP пакет и т.д. В обсчем, такое ООП на железном уровне. Побайтным поток на прием и передачу должен быть обязательно, но он скорее для дебаг целей. 5. MCU тоже имеет некий стандартизованныый набор протоколов и интерфейсов, и от конкретного MCU зависит лишь набор набортной периферии. 6. Основная обработка данных происходит в ПЦ. MCU должен быстро качать данные и иметь буферную память нужного объема, сложная обрабока на борту сильно опциональна. Хороший DMA важнее FPU. При правильной реализации всего выше описанного портирование на "железо не хуже, чем" и ОСь "новее, чем" будет относительно простым делом. Понимаю, что любители получать ЗП за выравнивание времянок нопами готовы сжечь меня на костре, и тем не мнее, жду конструктивной критики.