ISR installation - VxWorks

This is a discussion on ISR installation - VxWorks ; 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 ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: ISR installation

  1. ISR installation

    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


  2. Re: ISR installation

    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



  3. Re: ISR installation

    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



+ Reply to Thread