Кто знает литературу по профессиональному программированию микроконтроллеров?
Знатный апдейт. Разрывает вопрос на две проблеммы не связанны с uC. Вообще программирования uC это просто обычное программирования с дополнительными ограничениями по памяти, хипу, стэку и производительности. Ну да какбэ чтото особенное изза того что нужно знать хоть немного микроэлектронику. Но реально - ничего особенного. Конечно не мешает знать во что превращяется твой код.
Книжно по архитектуре - любые. Хоть блин design patterns :D 
Тяжело абстрактные книжки читать - читай код u-boot/netbsd/linux - смотри как там сделанно. Применительно к твоей проблеме с шиной 485 - там полно пробинга и детектов всякой переферии. Ближайший аналог естественно будет USB. Простейшие стэки для  USB есть в природе на посмотреть. API стэка можешь скопировать, чтоб либа похожа была.
Про прерывания vs poll - это cам разбирайся с требованиями - soft rt у тебя или hard rt. Может у тебя по требованиями вообще лупы нельзя будет делать и надо линейно отрабатывать с ресетом в конце. И конечно посмотри FreeRTOS - хотябы сколько чипов он поддерживает :D
Обработчик запросов и генератор ответов. Для каждого устройство это должно быть что-то свое. Как это красиво оформить? Что бы не ломать код уже существующей либы?
но мене кажется что это проблема выстраивания архитектуры приложения.
Судя по обновлению, вопрос действительно в разработке архитектуры и к микроконтроллерам имеет слабое отношение.
В вашем случае принято делить код отвечающий за связь на слои(
По-моему очевидное решение слещующее принципу открытый/закрытый и
реализовано в куче протоколов и framework):
Слой абстракции от железа / Слой передачи "байтиков" (включая ID устройств,
т.е. запаковку  массива байт в пакеты с ID, возможно полем длина и контрольная сумма) / Слой умеющий как-то сообщать о приходе новых данных (например callbacks).
В случае серьезных проблем с памятью (типа только 256 байт оперативки),
я бы написал генератор кода, т.е. сама абстракция (слои) существовала бы только в
коде, а генератор анализировал бы описание протокола и обработчиков и
смешивал все слои в одну кашу. 
 Помимо таких проблем иногда сталкиваюсь с такой проблемой что не знаю чем лучше воспользоваться: все повесить на прерывания или цикличный обработчик и руками прописывать последовательную обработку(задача решалась в реальном времени не на RTOS(до нее еще руки не дошли))
Почему просто не посчитать выбрав один из критериев - быстродействие, время на реализацию, потребление памяти. Ну и конечно использовать генераторы конечных автоматов.