This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Device Driver package link error


I've been trying to write a generic TPU (Time Processor Unit) driver for the MPC555 based on Bob Koninckxx's Encoder driver.
To do this I've tried to separate stuff that's specific to a particular TPU function such as quadrature decode for the encoder into separate files from the stuff that is generically required to setup and run the TPU.

So in my file structure I now have:

packages/devs/tpu/mpc555/current/src/tpu.c
packages/devs/tpu/mpc555/current/src/tpu.h
packages/devs/tpu/mpc555/current/src/dev_encoder.c
packages/devs/tpu/mpc555/current/cdl/tpu_mpc555.cdl

This is a first step towards being able to enable other functions such as PWM and DIO by having the corresponding source files with only the code specific to those TPU functions. By TPU function I mean the microcode that is loaded into each TPU channel for it to perform a specific 'function' not a single C code function. So I might additionally have dev_pwm.c and dev_dio.c as well. Each of these functions would be enabled as CDL components of the TPU device and have their own interfaces in the IO layer such as /dev/enc1 and /dev/pwm1 etc.

I've added to the package level of tpu_mpc555.cdl:

compile -library=libextras.a tpu.c dev_encoder.c

And I've also tried separate entries:

compile -library=libextras.a tpu.c 
compile -library=libextras.a dev_encoder.c

The problem I've facing is are link errors at the appication link stage, such as:

Project_install/lib/extras.o(.text.tpu3_encoder_lookup+0x64): undefined reference to 'tpu_disable'

Where tpu_disable is a function declared in tpu.h and the function entry in tpu.c, but called from dev_encoder.c which includes the header tpu.h.

I've tried an objdump on libextras.o and the functions such as tpu_disable are present, but the linker doesn't seem to find them.
Is this a name managling problem, or am I being naïve in my understanding of the linking process?

I notice that most of the driver code in /devs has only a single source file and generally keep any header files in the same folder and not in a parrallel /include as this isn't seen at the compile stage unless explicitly included in a relative path.

Any thoughts appreciated.

Steven Clugston

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]