Как правильно создать многофайловый проект, Ошибка при линковке Опции

[alux]

Привет всем.
Создаю проект на IAR v.4.12A, состоящий из многих С-файлов. Проблема возникает при линковке в один файл. Если быть точнее, то при попытке вызова battery_charge(); из main возникает ошибка Error[e46]: Undefined external "FAST_charge" referred in bc ( IAR projects\pribor\Release\Obj\bc.r90 ). В main подключены хидеры всех используемых модулей, в том числе и bc.h :

///// main.c ////////
#include "bc.h"
...........
void main (void)
{
battery_charge();
}

//// bc.c /////
#include "bc.h"

void battery_charge(void)
{
FAST_charge();
}

///// bc.h ////////
extern void FAST_charge(void);
extern void TRICKLE_charge(void);
extern void battery_charge(void);

//// NiMh.c ////////
#include "NiMH.h"
void FAST_charge (void)
{
}


//// NiMh.h //////
void FAST_charge(void);

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

Сообщение отредактировал alux - May 6 2007, 14:40

[SasaVitebsk]

Простите, решил сюда добавить, чтобы темы не плодить.
Не так давно пишу на Си. За этот период сильно изменил свои подходы. Теперь проект разбиваю на файлы, которые логически закончены. Это даёт возможность многократного использования с минимальными изменениями. Но вот столкнулся с некоторыми проблемами в таком подходе. В принципе я о них уже читал в разных темах и общие указания слышал/запомнил.

Сама проблема возникает когда п/п из другого файла используется в прерывании, которое в main описывается. Как выходить из неё - вроде понятно. 1) Вообще убрать вызовы п/п. 2) перенести п/п в файл, где пишется прерывание.

Собственно меня интересует более общая тема. Как всётаки сделать так, чтобы и овцы целы и волки сыты. То есть вопросы следующие.

1) Правильным ли является подход с выделением логически законченного блока в отдельный файл со своим хедером. И если "нет" или "не совсем", то хотелось бы услышать как поступают проффессионалы.
2) Как использовать такие "почти библиотеки", чтобы уменьшить накладные рассходы и при этом сохранить красоту написания проги.
3) Является ли выигрышным в этом смысле вариант с С++ и созданием классов/объектов.

[Сергей Борщ]

п/п из другого файла используется в прерывании, которое в main описывается.

Это как? Обычно обработчик прерывания описываю не в main, а в том же файле, что и остальные п/п соответстующего модуля. А зачем обработчик уносить в тот же файл, где и main? Или это архитектера вроде pic, когда одно прервание на все случаи? Плюсы помогут, ибо в них можно в заголовочном файле описать обработчик как inline.

[alexander55]

А зачем обработчик уносить в тот же файл, где и main?

Это дело вкуса.
Я вижу это так.
Если железно ясно, что
- используется прерывание
- и это универсальное решение,
то прерывание имеет смысл иметь в модуле, где осуществляется реализация.
Если :
- хочется иметь main как диспетчер, в котором видна вся логика функционирования
- main небольшой по размеру
- возможны изменения (без прерывания или с прерыванием),
то лучше обработчик прерывания в main.
В дальнейшем, когда все устаканится или размер main станет неприличным по размеру, можно его перенести.

[Сергей Борщ]

Если :
- хочется иметь main как диспетчер, в котором видна вся логика функционирования

Если это ARM, то в main достаточно заносить адреса обработчиков (объявленных как extern) в нужные регистры контроллера прерываний. Тела самих обработчиков в main() не нужны. Если это проц без контроллера, то у него скорее всего вектора жестко распределены за периферией, и выбор вектора просто однозначен - в main нечего диспетчерить. Если хочется иметь выбор из нескольких одинаковых периферийных модулей (UART, например), то можно попробовать так:

Код

в Hardware.h указываем
#define RS232_MODULE   USART1
#define RS485_MODULE   USART0

в RS232.c:
#pragma RS232_MODULE##_UDRE_vect
interrupt void RS232_transmit_handler()
{

} //опять main.c не у дел

Наконец, если используются плюсы и обработчик - метод класса, то код этого метода с атрибутом inline размещается в заголовочном файле, а в main.cpp пишется "обертка":

Код

__irq void RS232_Handler()
{
      RS232.Handler();
}
или
#pragma USART1_UDRE_vect
interrupt void RS232_transmit_handler()
{
      RS232.Handler();
}

при этом обработчик делается private, а функция-обертка объявляется другом класса. Но при желании эти обертки уносятся в файл соответствующего модуля и можно снова применить первый вариант.

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

Мне кажется, что всякие методики проектирования создают именно для того, чтобы по возможности исключить такую непроизводительную работу. Хотя, конечно, идеала не существует и процесс был и будет итеративным. Но количество итераций можно попытаться уменьшить.

[alexander55]

Наконец, если используются плюсы и обработчик - метод класса, то код этого метода с атрибутом inline размещается в заголовочном файле, а в main.cpp пишется "обертка":

Код

__irq void RS232_Handler()
{
      RS232.Handler();
}
или
#pragma USART1_UDRE_vect
interrupt void RS232_transmit_handler()
{
      RS232.Handler();
}

Я это и имел ввиду.

в main нечего диспетчерить.

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

[Сергей Борщ]

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

У меня в main.c обычно находятся собственно main() и __low_level_init(). Глядя на main() можно попытаться понять логику работы всей системы, правда есть одно исключение :

Код

int main()
{
    OS::Run();
}

Детали находятся за рамками и если требуются, то понятно, где это можно посмотреть (глядя на модуль).

Так RS232_transmit_handler() - это и есть детали. А логика описывается getchar(), putchar() и hasinput(). Мне так кажется...

Прерывание - метки времени. То есть там целый набор. в том числе вызовы опроса клавиатуры.

В таком случае наименьшие накладные, наверное, можно получить если "набор" описать в заголовочных файлах как static inline функции.

[alexander55]

У меня в main.c обычно находятся собственно main() и __low_level_init(). Глядя на main() можно попытаться понять логику работы всей системы, правда есть одно исключение :

Код

int main()
{
    OS::Run();
}

Это логичный и устоявшийся модуль.

Так RS232_transmit_handler() - это и есть детали. А логика описывается getchar(), putchar() и hasinput(). Мне так кажется...

В данном случае так.

В таком случае наименьшие накладные, наверное, можно получить если "набор" описать в заголовочных файлах как static inline функции.

Или включить максимальную оптимизацию по требуемому параметру.