2010-10-03 2 views
3

Я работаю над базой кода «C», написанной специально для встроенного процессора одного типа. Я написал общий «объектно-ориентированный» код psuedo для таких вещей, как светодиоды, линии GPIO и АЦП (с использованием структур и т. Д.). Я также написал большой объем кода, который использует эти «объекты» в агностическом/аппаратном режиме.# включает в файлы C для конкретных конкретных процессоров

Теперь мы перемещаем другой тип процессора в микс, и я хотел бы сохранить текущую структуру кода, чтобы я мог использовать библиотеки более высокого уровня. Тем не менее, мне нужно обеспечить различные реализации кода нижнего уровня (светодиоды, GPIO, АЦП).

Я знаю, что #includes в .C-файлах обычно смотрят сверху вниз, но в этом случае это уместно? Например:

// led.c 
#ifdef TARGET_AVR 
#include "led_avr.c" 
#elseifdef TARGET_PIC 
#include "led_pic.c" 
#else 
#error "Unspecified Target" 
#endif 

Если это неуместно, то чем лучше реализовать?

Спасибо!

ответ

3

Поскольку компоновщик не все равно, что имя исходного файла на самом деле (он заботится только о том, экспортируемых символах), вы можете изменить командную строку компоновщика для каждой цели для указания соответствующего модуля реализации (led_avr.c или led_pic.c).

Обычного способ управления нескольких исходных файлов платформы, чтобы положить каждый набор файлов реализация платформы в своем собственном каталоге, так что вы можете иметь avr/led.c и pic/led.cavr/gpio.c и pic/gpio.c и т.д.).

2

Это хорошо. Вы можете использовать другие приемы, как:

#ifdef PROC1 
#define MULTI_CPU(a,b) (a) 
#else 
#define MULTI_CPU(a,b) (b) 
#endif 
0

Наиболее распространенный способ сделать это, вместо того, чтобы включать файл C, - это изменить систему сборки (что бы она ни была) для компиляции или не скомпилирования этих определенных файлов C.