Hi:

Is the card a pci card? If it is, the most currect BSP should have a
function called pciIntConnect that may be more correct in that
intConnect replaces the ISR associated with the IRQ and the
pciIntConnect chains them, in that multiple ISR can hang off the same
IRQ. This is implemented very inconsistently between BSP, and
sometimes intConnect is all you need. I wouldn't worry about it for
now, but do you pciIntConnect if it's available to you.

Also, if it's a pci card, you should find the pci device on the pci bus
via it's vendor/part it, and then get the IRQ from the config space
hearer irq field. In theory vxWorks or the pc's BIOS could move the
IRQ's around. Again, if you've done a sysPciShow and pciHeaderShow and
know you're on IRQ5, you should be ok hardcoding it for experimentation
purposes.

intEnable is a general purpose wrapper function which is replace by the
BSP, so calling intEnable or the bsp specific sysIntEnable both may be
OK. Check out your sysLib.c for your BSP and you'll see sysIntEnable
in there. It should also shed light on the intConnect param.

Re the incConnect macro, if my BSP doesn't have it, then I don't use
it. The parameter varies greatly based on your arch (read the Pentium
Arch suppliment in the doc directory), to see what to use. it can be
the IRQ directly or the intLevel that maps directly to the PIC
register.

Structure wise. your codes ok, but during the ISR you normally clear
the int source somehow. If the switch just causes the int directly,
then you may get a lot of calls as the switch bounces, unless it
prevents that in HW. Also, if depends it you need to set the HW up for
edge or level interrupts - that's device specific. Disabling ints
during the ISR might also be good.

I'd play around with this all from the shell. Do the int connect to
the logMsg, and push the button. If the int works, the logMsg will get
called and you'll see the message. It'll save experimentation time.

Sorry I can't be more specific - I just don't have a lot of Pentium
examples.

Good luck,
lc





Troels Jensen wrote:
> Hi
>
> Another VxWorks newbie question: ISR installation.
>
> VxWorks 6.2, pcPentium BSP. I have an I/O extension card with a button
> on it, connected to IRQ5. I would like to install an ISR that catches
> button pushes, and do so in a VxWorks Downloadable Kernel Module. I
> have done this:
>
> void myIRQ5Handler(void)
> {
> logMsg("*** Interrupt! ***\n", 0,0,0,0,0,0);
> }
>
>
> void init()
> {
> int vectorNo = INT_NUM_GET(5);
> if(intConnect((VOIDFUNCPTR*)(INUM_TO_IVEC(INT_NUM_ GET(5))),
> (VOIDFUNCPTR) myIRQ5Handler, 0) != OK)
> {
> printf("ISR connect ERROR\n");
> }
> else printf("ISR connect OK\n");
>
> if(sysIntEnablePIC(5) == ERROR) printf("IRQ Enable ERROR\n");
> else printf("IRQ enable OK\n");
> }
>
>
> The main problem seems to be that INT_NUM_GET is an undefined macro:
>
> "__TESTER__.cpp", line 21: error (etoa:4020): identifier "INT_NUM_GET"
> is
> undefined
> int vectorNo = INT_NUM_GET(5);
>
>
> So the questions:
>
> (1) How do I get the macro. I know it is defined in /configInum.h,
> but including this file only generates other errors
> (2) Does the code seem OK to install an ISR for IRQ5?
> (3) Does the interrupt enabling seem okay?
> (4) What is the difference between intEnable and sysIntEnable, and
> which should I use?
>
> Example code, including #inclues, would be greatly appreciated.
>
> Thanks, Troels

Hi again

Thanks. Got me going. I now have the ISR running. I have wrapped the
ISR and its installation in a class - let me know if u wish to see it.

/Troels Jensen

LarryC wrote:
> Hi:
>
> Is the card a pci card? If it is, the most currect BSP should have a
> function called pciIntConnect that may be more correct in that
> intConnect replaces the ISR associated with the IRQ and the
> pciIntConnect chains them, in that multiple ISR can hang off the same
> IRQ. This is implemented very inconsistently between BSP, and
> sometimes intConnect is all you need. I wouldn't worry about it for
> now, but do you pciIntConnect if it's available to you.
>
> Also, if it's a pci card, you should find the pci device on the pci bus
> via it's vendor/part it, and then get the IRQ from the config space
> hearer irq field. In theory vxWorks or the pc's BIOS could move the
> IRQ's around. Again, if you've done a sysPciShow and pciHeaderShow and
> know you're on IRQ5, you should be ok hardcoding it for experimentation
> purposes.
>
> intEnable is a general purpose wrapper function which is replace by the
> BSP, so calling intEnable or the bsp specific sysIntEnable both may be
> OK. Check out your sysLib.c for your BSP and you'll see sysIntEnable
> in there. It should also shed light on the intConnect param.
>
> Re the incConnect macro, if my BSP doesn't have it, then I don't use
> it. The parameter varies greatly based on your arch (read the Pentium
> Arch suppliment in the doc directory), to see what to use. it can be
> the IRQ directly or the intLevel that maps directly to the PIC
> register.
>
> Structure wise. your codes ok, but during the ISR you normally clear
> the int source somehow. If the switch just causes the int directly,
> then you may get a lot of calls as the switch bounces, unless it
> prevents that in HW. Also, if depends it you need to set the HW up for
> edge or level interrupts - that's device specific. Disabling ints
> during the ISR might also be good.
>
> I'd play around with this all from the shell. Do the int connect to
> the logMsg, and push the button. If the int works, the logMsg will get
> called and you'll see the message. It'll save experimentation time.
>
> Sorry I can't be more specific - I just don't have a lot of Pentium
> examples.
>
> Good luck,
> lc
>
>
>
>
>
> Troels Jensen wrote:
> > Hi
> >
> > Another VxWorks newbie question: ISR installation.
> >
> > VxWorks 6.2, pcPentium BSP. I have an I/O extension card with a button
> > on it, connected to IRQ5. I would like to install an ISR that catches
> > button pushes, and do so in a VxWorks Downloadable Kernel Module. I
> > have done this:
> >
> > void myIRQ5Handler(void)
> > {
> > logMsg("*** Interrupt! ***\n", 0,0,0,0,0,0);
> > }
> >
> >
> > void init()
> > {
> > int vectorNo = INT_NUM_GET(5);
> > if(intConnect((VOIDFUNCPTR*)(INUM_TO_IVEC(INT_NUM_ GET(5))),
> > (VOIDFUNCPTR) myIRQ5Handler, 0) != OK)
> > {
> > printf("ISR connect ERROR\n");
> > }
> > else printf("ISR connect OK\n");
> >
> > if(sysIntEnablePIC(5) == ERROR) printf("IRQ Enable ERROR\n");
> > else printf("IRQ enable OK\n");
> > }
> >
> >
> > The main problem seems to be that INT_NUM_GET is an undefined macro:
> >
> > "__TESTER__.cpp", line 21: error (etoa:4020): identifier "INT_NUM_GET"
> > is
> > undefined
> > int vectorNo = INT_NUM_GET(5);
> >
> >
> > So the questions:
> >
> > (1) How do I get the macro. I know it is defined in /configInum.h,
> > but including this file only generates other errors
> > (2) Does the code seem OK to install an ISR for IRQ5?
> > (3) Does the interrupt enabling seem okay?
> > (4) What is the difference between intEnable and sysIntEnable, and
> > which should I use?
> >
> > Example code, including #inclues, would be greatly appreciated.
> >
> > Thanks, Troels