Как правильно писать библиотеки для микроконтроллеров

[osandr]

Добрый день, уважаемые программисты!

Пишу программы для микроконтроллеров на Си достаточно долго. Но все время остается чувство, что можно писать код красивее, понятнее и лучше. Красивые решения находишь, когда изучаешь чужой код, например библиотеки драйверов от производителя чипа. Иногда пишу библиотеки сам с нуля.
Так вот хотелось бы узнать: есть ли какие-то правила написания драйверов/библиотек, чтобы они надежно работали и в то же время код не был громоздким слишком.
Приведу пример. Допустим нужно написать драйвер, работающий с датчиком температуры по интерфейсу SPI. Сначала обычно пишется нижний уровень - прослойка, которая будет абстрагировать программиста от аппаратной части микроконтроллера и будет взаимодействовать с интерфейсом SPI и прерываниями (в зависимости от реализации). Затем будет какой-то промежуточный уровень, который будет через нижний уровень взаимодействовать с регистрами датчика. И наконец верхний уровень, который будет оберткой для промежуточного уровня, абстрагирующий программиста от аппаратной части датчика. Т.е. программист может даже в электронике не разбираться, а просто собирать показания датчика через вызов определенных функций. К чему я веду? К тому, что по-хорошему начиная с нижнего уровня нужно заботиться о надежности драйвера, проверять что аппаратная часть отработала как нужно, что данные корректно записаны или считаны, что не произошло каких-то аппаратных ошибок при передаче. То, что мы записали на шину данных SPI интерфейса данные еще не значит, что они дошли до абонента. К тому же операция эта не мгновенная и необходимо выждать какое-то время для чтения/записи. И тут разные варианты реализации есть: сама простая и, как мне кажется, опасная (в плане зависания), а также не рациональная реализация - это ожидание завершения операции; вторая реализация - это работа по прерываниям, лучше в том плане, что процессор не "простаивает" впустую. И таким образом получается, что все проверки на нижнем уровне они как бы "всплывают" в проверки на верхнем уровне и когда нужно выполнить к примеру несколько записей по SPI подряд, то каждая такая запись обрастает оператором if, что смотрится не очень приятно и читаемо, да и к тому же, я считаю, дает лишнюю нагрузку на процессор и увеличивает машинный код.
Может кто-то поделится своим опытом написания библиотек или посоветует литературу к прочтению? Или выскажет свои мысли по этому поводу как сделать лучше.

[Pavia]

Инкапсулировать. На верхний уровень подавать объекты или структуры с готовыми и валидными данными. Проверки вынести в отдельную функцию типа
bool CheckMyStruct(STmyStruct myStruct)

Сообщение от osandr

что данные корректно записаны или считаны, что не произошло каких-то аппаратных ошибок при передаче.

За передачу отвечает разработчик железа. У него есть требования по надёжности, электромагнитной совместимости, есть рекомендации по трассировки. Так что у него есть возможности для решения.

Если мы хотим доказать что он накосячил, то делаем отдельную проверку шины, условно/периодическую.

А проверку на каждый байт это сугубо индивидуально, от неё никуда не уйдёшь. Если только оформить более красиво.
1)SIGNAL/SLOT
2)try/excep
3)nerro/lasterror, bool.

[osandr]

За передачу отвечает разработчик железа. У него есть требования по надёжности, электромагнитной совместимости, есть рекомендации по трассировки. Так что у него есть возможности для решения.

Это называется "уйти от ответственности". Тогда начинается: программист обвинят инженера-электроника, а инженер-электроник обвиняет программиста. Программа должна отслеживать ошибки аппаратной части и предупреждать верхний уровень об этом, а не просто послали данные и остальное не беспокоит. К тому же иногда железячные проблемы можно обойти программным путем.

[digitalis]

Кесарю - кесарево, слесарю - слесарево. Мне пришлось работать в команде, где у электронщика была отмазка такого типа. "Ты должен все глюки исправлять программно" - "Так как же я могу их исправить, если с таким питанием, как ты мне подаешь, процессор - уже не устройство для выполнения программы, а просто кусок керамики ?" - В ответ - стандартная демагогия "... а кто не хочет - ищет причину"
Драйверов (библиотек, макросов, плагинов и пр.), обеспечивающих нормальную работу на кривом железе - не бывает, думаю. Есть, конечно, кое-что, например, исправление неправильно принятого пакета с помощью избыточного кодирования, но и то в определенных пределах.