RE: xr16c864 Quad uart and shared interrupts
- From: Rob <Rob@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Sun, 10 Aug 2008 10:08:00 -0700
Hi,
When one ore more of the UARTS generate an interrupt, you need to check ALL
of the UARTS for data-ready, and handle the data (put it in rec-buf).
Hard to say what existing drivers do exactly without studying the code in
detail.
UARTS are simple enough to write a single-layered driver from scratch, so
you won't have to depend on external components (in this case MS...)
Greetings,
Rob.
"larstore@xxxxxxxxx" wrote:
Hello!.
I have a geode system which uses a XR16C864 quad uart chip (connected
on the ISA bus).
This chip has 4 interruptlines going to a CPLD, where they are OR'ed,
and connected to the CPU IRQ10 line.
So, in other words i need to share IRQ10.
This system used to run Windows CE .net, and someone has written a
working driver and ISR, but when using this on Windows CE5 (which i
need to), it does not work.
The old ISR was actually just GIISR.DLL, which was called for each
uart like this
KernelLibIoControl(pHWHead->hIsrHandler, IOCTL_GIISR_INFO, &Info,
sizeof(Info), NULL, 0, NULL)
where the GIISR_INFO struct is:
Info.SysIntr = pHWHead->dwSysIntr;
Info.CheckPort = TRUE;
Info.PortIsIO = TRUE;
Info.UseMaskReg = FALSE;
Info.PortAddr = (DWORD)pHWHead->pIIR_FCR; //ISR when read
Info.PortSize = sizeof(BYTE);
Info.Mask = SERIAL_IIR_INT_SOURCE_MASK;
And, when the IST event is triggered, the ISR is read like this
KernelLibIoControl(pHWHead->hIsrHandler, IOCTL_GIISR_PORTVALUE, NULL,
0, &(pHWHead->IIR), sizeof(BYTE), NULL)
This returns the ISR of the correct uart, and the processing begins.
My problem is:
At some point beween CE4 and 5, MS decided to change the structure of
the COM16550 driver completely (from C to C++ and more layered).
I have created a new COM16864 driver based on this new COM16550, i
have also used the new GIISR,.
This works great as long as i only use one port at a time
BUT, when sending data to two ports at a time, the interrups goes
high(as seen on oscilliscope on com10), and it is not cleared until
the port is closed again.
I think this is because one of the UART receive FIFOs goes above the
trigger level, which will cause an interrupt, but for some reason the
interrupt is not registered in the driver, and therefore the FIFO will
not be emptied, and the interrupt stays high.
I have read alot about the GIISR not being suitable for serial IRQ
sharing, or that the GIISR_INFO checkport value will cause
unpredicable behaviour when used with IRQ sharing, but my problem is:
THIS WORKED ON THE OLD SYSTEM!
What happens when GIISR finds a valid value in the chain of ISRs? Will
it ever look further down the chain for another valid intterupt?
If anyone have any ideas or suggestions, please help!
Regards,
LT
- References:
- xr16c864 Quad uart and shared interrupts
- From: larstore
- xr16c864 Quad uart and shared interrupts
- Prev by Date: PM PDD Choise?
- Next by Date: Re: PM PDD Choise?
- Previous by thread: Re: xr16c864 Quad uart and shared interrupts
- Next by thread: Hive Registry and TIPC card problem
- Index(es):
Relevant Pages
|
