Search

Technical Discussion Group Forum

This forum is provided for user discussion. While Beacon EmbeddedWorks support staff and engineers participate, Beacon EmbeddedWorks does not guarantee the accuracy of all information within in the Technical Discussion Group (TDG).

The "Articles" forums provide brief Articles written by Beacon EmbeddedWorks engineers that address the most frequently asked technical questions.

To receive email notifications when updates are posted for a Beacon EmbeddedWorks product download, please subscribe to the TDG Forum of interest.

TDG Forum

PrevPrev Go to previous topic
NextNext Go to next topic
Last Post 20 Dec 2004 01:39 PM by  scobb
installable ISR
 23 Replies
Sort:
You are not authorized to post a reply.
Page 2 of 2 << < 12
Author Messages
mikee@logicpd.com
New Member
New Member
Posts:


--
28 Oct 2004 02:26 PM
The SysIntr values you get from the OAL are in no way related to the actual IRQ value. If they are the same, it's purely by chance.

The IRQ values you are seeing in the header file correspond to a hardware IRQ line. They make sense within the physical context of the processor. For instance, on the A40x processors, this value corresponds to the bit number within the Interrupt Controller Register.

The SysIntr values are logical values assigned at random by the OAL. The OAL associates a hardware IRQ with a logical SysIntr internally. The SysIntr value is registered by the kernel as an event that your IST will wait on. So, your ISR should return the SysIntr value you get from the OAL. The kernel will see this SysIntr value and then wake up your IST so your driver can go about the rest of its work.

I know it sounds confusing at first, but it is a way of logically seperating interrupt handling from the actual hardware that the kernel is running on.

So, the short answer to your question is to ignore the SYSINTR_XXX values that you see in oalintr.h and use the values returned from IOCTL_HAL_REQUEST_SYSINTR.

--mikee
mpinton
New Member
New Member
Posts:


--
05 Nov 2004 12:11 PM
Hi,
One more question (yeah right). In my IISR ISRHandler function, to access the physical registers I do the following:

DWORD dwMemSpace = 1; // i/o space
PVOID lpGpioRegs; // ptr to GPIO base reg
PHYSICAL_ADDRESS gpioPhysAddr = {GPIO_BASE, 0}; // GPIO physical address

// map the physical address into the kernel space (where this IISR is located)
if (!::TransBusAddrToStatic(Internal,
0,
gpioPhysAddr,
sizeof(GPIOREGS),
&dwMemSpace,
&lpGpioRegs))
{
return(SYSINTR_CHAIN);
}
// make sure we are here validly, must be correct instance and the correct interrupt
if (!dwInstanceIndex ||
!(((GPIOREGS*)lpGpioRegs)->intstatus & IN_BASE))
{
return(SYSINTR_CHAIN);
}

// deassert the interrupt
((GPIOREGS*)lpGpioRegs)->gpiofeoi |= IN_BASE;
return(sdwSysIntr);


Are the parameters for the TransBusAddrToStatic correct (esp for the bus type and bus #)?
TIA,
/michel
mikee@logicpd.com
New Member
New Member
Posts:


--
05 Nov 2004 01:24 PM
Michel,

Don't use Internal as the bus-type. I know that it sounds right, and theoretically should work, however, I think that the only valid bus-type for our BSP is ISA. Mainly because I wrote the CEDDK back before Microsoft added the Internal bus-type. We may have fixed it during release 1.0, I can't remember right off the top of my head. Either way, Isa will work the exact same way and I know it is implemented correctly.

Also, you should call TransBusAddrToStatic() from the driver's main DLL. Then, pass in the appropriately mapped addresses to the IISR via a call to KernelIoctl(). The way you have your code set up right now has you calling that function during every interrupt event which would incur quite a bit of unnecessary overhead. Plus, I'm not sure if you will be able to call that function from a kernel-linked library.

Try something like:

During the driver's loading process.

void
install_ISR(......)
{
LoadIntChainHandler(.....);
TransBusAddrToStatic(.....);

/* Fill in some sort of information structure. */
/* Pass the information structure to the IISR. */
KernelLibIoControl(&info, IOCTL_GIISR_INFO, ...);

}


Inside the Installable ISR's code.

BOOL
IOControl(......)
{
switch ( ioctl_code )
{
case IOCTL_GIISR_INFO:
/* This input/output control is used when the
* IST is passing us a filled-in GIISR_INFO
* structure. This structure includes the value
* of the SysIntr that we should return, the
* address of of our hardware port, etc. */
if ( (sizeof(GIISR_INFO) != len_in) || (!buf_in) )
{
/* Invalid size of input buffer or bad input
* buffer pointer. */
return (FALSE);
}
/* The compiler may generate a memcpy call for
* a structure assignment. Since we are not
* linking with the CRT, we use our own copy
* routine. */
my_mem_copy(......);
break;

.......
}


static void
my_mem_copy(GIISR_INFO *dst, const GIISR_INFO *src)
{
size_t count = sizeof(GIISR_INFO);

while ( count-- )
*((BYTE *)dst)++ = *((BYTE *)src)++;

return;
} /* end my_mem_copy() */



Regards,
--mikee
scobb
New Member
New Member
Posts:


--
20 Dec 2004 01:39 PM
I'm trying to do the same thing (have a driver for IRQC) and am trying to build the foo_driver.dll and foo_isr.dll using eVC++ (not PB) so that we can field upgrade the device.

Are there any other particular things to worry about in this environment?

Any good book reference suggestions for CE 4.20 - the whole DLL and ISR world. There is a huge transition between handling ISR's in a RTOS and with CE.

Cheers,
Steve
You are not authorized to post a reply.
Page 2 of 2 << < 12