2015-12-07 5 views
0

У меня есть проект C в среде MPLAB IDE, где я хочу, чтобы файл main.c мог использоваться для более чем одного HW, который у меня есть. Основное различие заключается в том, что контакты PIC связаны друг с другом.MPLAB IDE 8.85 условно, включая заголовок

Идея состоит в том, чтобы создавать разные файлы .h и .c для каждого HW, который поддерживает мой основной файл, и включать только тот, который соответствует HW, для которого я хочу построить.

Что-то вроде этого:

#if defined(HW_1) 
    #include "hw1.h" 
#elif defined(HW_2) 
    #include "hw2.h" 
#endif 

Эти дополнительные файлы (hw1.c и hw2.c) включают в себя главным образом определения функций штырей, таких как:

#define GPI_PG_3V3 RD2 

и связанных с ними функций ,

Но проблема в том, что разные HW могут иметь одинаковые функциональные возможности, но на разных контактах. Это означает, что для разных HW могут существовать одни и те же переменные #define.

Хотя я включаю соответствующий файл .h в соответствии с моим HW, в структуре MPLAB у меня есть один и тот же проект, и это означает, что я должен включать все файлы .h в одно и то же время. Но это приводит к проблеме, компилятор считает, что имеются различные определения того же переменное, например .:

Error [237] S:\PIC_Code\ACCEED_4420\Source\acceed1480.c; 23. function "_initGpio" redefined 

Кто-нибудь есть хорошее представление о том, как решить эту проблему? Одна идея, которая пришла ко мне, состоит в том, чтобы иметь разные проекты для всех разных HW, которые у меня есть. Это единственное решение? В таком случае было бы сложно структурировать каталоги проектов.

+0

Конфигурация проекта - это функция, которая может создавать проект внутри проекта. Доступно ли это в вашей версии? Он доступен в MPLAB X –

+0

@PunitVara К сожалению, я не нашел ничего подходящего. Я вижу только конфигурацию сборки, но это между выпуском и отладкой. Что делает эта функция в MPLAB X? – nickagian

ответ

1

Возможно, вы захотите взглянуть на this question. Ваша проблема будет более легко разрешена с помощью пространства имен C++, но поскольку вы используете C, вам, вероятно, придется использовать некоторые хаки. В вопросе приемлемый ответ, вероятно, не подходит вашему делу, а второй может добавить небольшие накладные расходы (особенно, поскольку вы, похоже, используете старый компилятор). Вы должны попробовать один из макросов в других ответах.

Мое предложение, если ваш компилятор не кричит, заключается в использовании некоторой макромагии для условной компиляции и включения некоторых файлов. Это имеет преимущество, заключающееся в том, что вы не компилируете все, что может сэкономить некоторое пространство, если компилятор плох (поскольку это MPLAB 8, это может быть).

В вашей "my_hw.h":

// change this line to change the hardware code 
#define THE_DRIVER_TO_USE hw1 


#define STRINGIFY2(x) #x 
#define STRINGIFY(x) STRINGIFY2(x) 

#include STRINGIFY(THE_DRIVER_TO_USE.h) 

В некотором файле "hw_includer.c", вы положили, что и никогда не менять:

// optional macro, see below 
#define ALLOWED_TO_COMPILE 1 
// yes, include a .c 
#include STRINGIFY(THE_DRIVER_TO_USE.c) 

Теперь вы просто должны изменить макрос THE_DRIVER_TO_USE для замены драйверов и включить my_hw.h вместо hwX.h. Он будет включать в себя право .h и скомпилировать право .c. Требование к этому - НЕ компилировать hwX.c самостоятельно. Вы либо исключаете их из компиляции в IDE, либо помещаете весь код в .c внутри защитника #endif, если вы не можете.

+0

Это действительно интересно, что вы предлагаете. Но я немного потерял тебя. Вы сказали, что необходимо НЕ компилировать hwX.c самостоятельно. Но как он будет скомпилирован? Только #including? Я также не знал, что можно # включить файл .c. Другой вариант, который вы сказали с «ALLOWED_TO_COMPILE», вероятно, хорошая идея. Я могу поместить весь код в защитную оболочку и разрешить - с помощью # define - только один hwX.c для фактического компиляции. – nickagian

+0

@ user1428960 В том числе не больше, чем копирование вложенного файла, поэтому трюк заключается только в компиляции «hw_includer.c», который будет содержать правильный «реальный» .c. Таким образом, «real» .c не должен быть предварительно скомпилирован, иначе они будут скомпилированы несколько раз. Обычно существует 2 типа IDE. Некоторые вслепую компилируют все компилируемые файлы (.c для C), другие только компилируют файлы, добавленные в категорию, обычно называемые «источниками». В зависимости от типа MPLAB 8 (я забыл), было бы проще просто исключить конкретный .c или использовать макро-трюк. – ElderBug

Смежные вопросы