developing drivers for custom boards

It just worked fine for me, on a stock install. The errors are there, but it still loads with halrun.
What does dmesg say after your attempted loadrt?
do you see the highlighted line below?

andypugh@ubuntu:~/emc2$ sudo comp --install constant.comp
make -C /usr/src/linux-headers-2.6.32-122-rtai SUBDIRS=`pwd` CC=gcc V=0 -o /Module.symvers modules
make[1]: Entering directory `/usr/src/linux-headers-2.6.32-122-rtai'
CC [M] /tmp/tmpmKP5S1/constant.o
Building modules, stage 2.
MODPOST 1 modules
WARNING: "hal_init" [/tmp/tmpmKP5S1/constant.ko] undefined!
WARNING: "hal_exit" [/tmp/tmpmKP5S1/constant.ko] undefined!
WARNING: "hal_export_funct" [/tmp/tmpmKP5S1/constant.ko] undefined!
WARNING: "hal_malloc" [/tmp/tmpmKP5S1/constant.ko] undefined!
WARNING: "hal_pin_bit_newf" [/tmp/tmpmKP5S1/constant.ko] undefined!
WARNING: "rtapi_snprintf" [/tmp/tmpmKP5S1/constant.ko] undefined!
WARNING: "hal_ready" [/tmp/tmpmKP5S1/constant.ko] undefined!
WARNING: "hal_pin_u32_newf" [/tmp/tmpmKP5S1/constant.ko] undefined!
WARNING: "rtapi_print" [/tmp/tmpmKP5S1/constant.ko] undefined!
CC /tmp/tmpmKP5S1/constant.mod.o
LD [M] /tmp/tmpmKP5S1/constant.ko
make[1]: Leaving directory `/usr/src/linux-headers-2.6.32-122-rtai'
cp constant.ko /usr/realtime-2.6.32-122-rtai/modules/emc2/
andypugh@ubuntu:~/emc2$ halrun
halcmd: loadrt constant ioaddr=0x378
halcmd: show pin
Component Pins:
Owner Type Dir Value Name
3 u32 OUT 0x00000000 constant.0.R0-in
3 u32 OUT 0x00000000 constant.0.R0-out
3 u32 OUT 0x00000000 constant.0.R1-in
3 u32 OUT 0x00000000 constant.0.R1-out
3 u32 OUT 0x00000000 constant.0.R2-in

andypugh wrote:

This probably isn't the problem, but "constant" is a bad choice of name, as that is a pre-existing hal module.

I just grabbed the example out of the HAL manual... might be a bad example.

John

btvpimill wrote:

Does the port set-up refered to by PCW go in the EXTRA_SETUP section? This makes sense to me based on how I understand the comp descripton page. If this is so, would it go like this:

Yes that is exactly what it is for.

EXTRA_SETUP gets macro-expanded in the generated C-code and is called once per-instance. So if you loadrt 2 of your comp, EXTRA_SETUP will get called twice.
You can use the extra_arg variable to differentiate which instance is being set up. (as your code shows), but in your case, and for your own use, you could use the pre-defined "personality" modparam for the ioaddr and keep things a bit simpler. I have tended not to, so that the modparam name is a little more self-explanatory. I can think of good arguments to switch from "personality" to "cfg" for the pre-defined name too, but it is now too late.

btvpimill wrote:

I don't understand what you mean by this:

but in your case, and for your own use, you could use the pre-defined "personality" modparam for the ioaddr and keep things a bit simpler.

I mean that you could use:

option personality;

and then

loadrt mycomponent personality=0x378

and then just use "personality" everywhere you want the base address instead of ioaddr[extra_arg] and leave out the modparam parsing code at the beginning of the function.

btvpimill wrote:

IT WORKED!!!!!!!!!!!!! :woohoo!

Once you get things working you tend to notice that, actually, it is quite easy if you do the right things in the right order.