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

Что касается задач на каждый чих, то часто-густо это от желания применять однотипный инструмент не там, где нужно. Но тут скорее проблем несколько. Во-первых, я считаю стоит выделить особенно, нужно разделять приложения и BSP (драйвера, сервисы и протоколы) как минимум по жанру - вторые пишут системные программисты и готовят тем самым удобства для прикладных, решающих первую - "реальную задачу". Если есть хоть какое-то API к системной части (BSP), то это достаточно изолирующий слой. Также всё время смешиваются задачи абсолютно несоизмеримых временных масштабов, а соответственно и точностей/погрешностей. А как только разработчик приложения перестаёт рваться к написанию обработчика прерывания, сразу наступает спокойствие и на нехватку ресурсов как-то жалобы не очень-то слышны ;) Я как только заканчиваю писать дров, сразу становлюсь совсем другим человеком, иначе такая пурга получается;))) когда приложение малюю Конечно, стиль написания приложений может учитывать определенные требования, а именно передачу ресурса (который процессорное время) системе или не учитывать. Если не учитывать, то только вытеснение может отобрать ресурс для других задач (такого же вида приложений и для системных нужд). Добровольно же отдавать процессорное время удобно в "узлах" программных автоматов и просто во время ожидания. Думаю, что тут нужно делать выбор на этапе проектирования в результате оценки пригодности или непригрдности соответствующего механизма (инструмента) поставленным заданиям (в т.ч. по критичным по времени участкам и по затратам памяти).