HAL?, Как правильно сделать hardware abstraction в проекте? Опции

[khach]

Окончательно запутавшись в ножках АРМа прошу помощи клуба.
Есть проект, развивающийся. В настоящее время на LPC2138. Но неисключено переползание на другие камни (sams, AduC). Как правильно писать проект с использованием HAL (hardware abstraction layer), чтобы потом небыло мучительно больно переписывыть под другой камень или просто взаимно переставлять ножки. Может кто-то поделиться проектом, где бы вся перефирия была вынесена в отдельный модуль? Хочется посмотреть пример, как это надо делать правильно.

[Velund]

А вопросец то наверное многих волнует. Я к тому же пришел, надо ваять что то эдакое... ;-)

Сейчас сел разделять работу с I2C периферией (а у меня 5 слейвов на шине, разных, от TAOSовского датчика освещенности до далласовского I2C потенциометра) на 2 "слоя" - собственно драйвер I2C устройства и "прослойка" которая обеспечивает работу всех этих драйверов с I2C периферией конкретного камня или реализует bit banging на портах ввода-вывода.

Потом видимо придется сделать то же самое и с SPI.

Надоело каждый раз перезатачивать отлаженные уже куски кода под другой камень и отлаживаться заново.

Собираюсь сделать все это kernel-aware, чтобы если в проекте присутствует например ucos, автоматом подтягивались куски кода которые заведуют семафорами, и варианты "вклинивания" в транзакцию на шине исключались в корне.

Но пока все только на уровне неотлаженных огрызков. Для себя решил насчет "стандарта" вызовов драйверов железа и по мере сил делаю (в фоновом режиме).

На самом деле - проектец такой, который бы можно было сделать "народным". ;-)

[aaarrr]

ИМХО, нет здесь универсальных подходов. Наиболее разумно, на мой взгляд, просто вынести
"низкоуровневую" работу с переферией в отдельные блоки ("spi.c", "i2c.c" и т.д.), но не
заморачиваться при этом чрезмерной стандартизацией процедур. По опыту могу сказать, что
перенос весьма объемного проекта (несколько десятков тысяч строк) с одной платформы на
другую (в моем случае AT91R40008 -> S3C44B0X), занимает 1-2 дня.
А вот стандартизация структур данных может быть очень полезна: например, модуль FIFO, написанный
несколько лет назад, использую без изменений до сих пор, и практически во всех проектах общение с UARTом осуществляется именно через этот модуль (тоже своего рода HAL).

[Koshak]

IMHO, универсальный подход здесь есть, но чем выше степень универсальности, тем выше perfomance penalties. Последнее imho имеет в embedded systems больший вес в силу ограниченности ресурсов...
Наработки по этому делу есть, к примеру могу привести BlueStreak Software Library by Sharp.
она состоит из аппаратно независимой части - Sharp Bluestreak Library (ABL), и двух аппаратно зависимых - chip support
package (CSP) и Board Support Package (BSP). В частности, на сайте можно найти реализацию под процы LH7xxxx.
Все взаимодействие с апппаратурой (начиная от GPIO и кончая графикой и mmu) происходит через ABL (через стадартные вызовы abl_ioctl(), abl_open(), abl_read(), abl_write(), ...), которая, в свою очередь, общается со списком драйверов из CSP и BSP. При переходе на новый камень нужно написать CSP, на новую плату - BSP.
работающий софт можно посмотреть можно здесь http://www.sharpsma.com/mcu/mculibrary.php
портировать под другие ARM тоже не составит труда, также там есть порты под PEG, uC/OS II, ThreadX.