Кибернетика, автоматика, протоколы

Нет нигде готового howto. Я раньше тоже спрашивал. Отвечали "а вот это и есть know-how, за которое $$$ зарабатывается". Литературы толковой мало и всё не в ту сторону, дальше от embedded. Практически кроме какой-то литературы, документации описывающей существующие ОС, статей в интернете и т.п. -- опереться не на что. Нет какой-то единой теории "как программировать микроконтроллер". Во-первых я бы не сбрасывал со счетов "автоматное проектирование" А. А. Шалыто. Да, практически в том виде как представлена технология имеет много недостатков, но он в общем-то даёт ключ, какой должен быть подход к _проектированию_ управляющих алгоритмов. От конечных автоматов далее можно практически легко перейти к событийному программированию. От повсеместно навязываемого императивного (блок-схемы) -- сложно. Потом какая-либо литература описывающая устройство операционных систем. Хоть бы тот же Таненбаум с его "Операционными системами". Полезно вообще знать что бывает в том же windows (там, увы, всё искусственно слишком запутано), в том же unix, и почему так сделано. Там вообще подходы изначально немного с разных сторон, что наводит на интересные мысли. А процесс в unix, если исключить потоки (появившиеся в unix относительно недавно) мало чем отличается от программы для микроконтроллера (и начинается с main() именно потому). Потом знакомство хотя бы с парой систем GUI на PC очень наводит на мысли как может быть организована событийная система в рамках одного потока. Реально многопоточная многозадачность на МК скорей миф, да и на PC, если речь заходит о серверных приложениях с высокими нагрузками -- тоже. Всё сводится скорей к событийно-ориентированному программированию. В рамках которого человеку сложно постоить "из головы" какой-то алгоритм без ошибок. В отличии от императивного (блок-схемы). Но легко перейти от конечных автоматов (читатай статьи Шалыто, опять же), где события собственно привязаны к переходам между состояниями. От блок схем к автоматам и обратно опять же легко перейти. Вообще кодированию на C или ассемблере должен был бы предшествовать процесс создания алгоритмов согласно техническому заданию и т.п., но в российской действительности в мелких конторах часто от начала и до конца часто во всём виноват программист, как всегда... Ну а про события, сообщения и т.п. в литературе всё разжёвано. Про другие методы синхронизации параллельных программ и т.п. Если на пальцах, то событие -- оно произошло или нет (семафор, флаг), а сообщение это уже как письмо, с информационной нагрузкой. Может возникнуть вопрос, а для чего они нужны. А для того и нужны, для организации событийного программирования, когда исполнение программы начинается по какому-либо событию, вместо тупого опроса в big loop. Самый главный элемент любой ОС -- планировщик, с которым связаны все методы синхронизации и по их состоянию он определяет что же будет работать дальше (когда средствами ОС к конкретному примитиву синхронизации привязывается очередь его ожидающих процессов, например). Без планировщика можно было бы тупо напрямую нужную функцию вызывать (вместо сообщения, например), или в цикле проверять флаг. Опять же эти есть в литературе. Твоя проблема в том, что тебя тут год назад спровили "список литературы дать?", а ты воспринимаешь как наезд. См. ftp://pc.fk0.name/pub/books/os/Modern-Operating-Systems-2.djvu