|
We are about to start the development of a win 2k/xp driver for the DM642 evm. We want to be able to pass a bitstream from the EVM to the PC over the PCI bus. Ideally we would like to use the DSP/BIOS reference framework GIO model that TI suggest in spra845. From what I can gather reading this documents, a lot of the effort for the PCI transfer will have to be undertaken in the host. The host (PC) will have to constantly monitor the status of the PCI registers, and set up the PCIMA register. Alternatively, we are planning to use a doorbell type scheme with a simple message queue in DSP memory space to control the PCI operation. By sending messages using the DSP memory space, the DSP can then set its own PCIMA register for transfers. Now this is the only solution we came up with, and it requires a lot of wrapping of the GIO driver, moving it further away from an ideal RF5 solution. Has anyone got any ideas of a practical way to structure a PCI driver that can avoid the need for a separate message queue in DSP memory? |
|
|
DM642 PCI Driver
Started by ●March 10, 2004
Reply by ●March 10, 20042004-03-10
|
Christian- > We are about to start the development of a win 2k/xp driver for the > DM642 evm. We want to be able to pass a bitstream from the EVM to the > PC over the PCI bus. Ideally we would like to use the DSP/BIOS > reference framework GIO model that TI suggest in spra845. Why not use TI's existing driver? And call it from your DLL or driver? > From what I can gather reading this documents, a lot of the effort > for the PCI transfer will have to be undertaken in the host. The host > (PC) will have to constantly monitor the status of the PCI registers, > and set up the PCIMA register. Alternatively, we are planning to use > a doorbell type scheme with a simple message queue in DSP memory > space to control the PCI operation. By sending messages using the DSP > memory space, the DSP can then set its own PCIMA register for > transfers. Now this is the only solution we came up with, and it > requires a lot of wrapping of the GIO driver, moving it further away > from an ideal RF5 solution. > > Has anyone got any ideas of a practical way to structure a PCI driver > that can avoid the need for a separate message queue in DSP memory? We use an interrupt-driven "talker" program in DSP memory -- we use the TI driver to send/receive data to an intermediate onchip memory area, and the talker program moves this data to/from final chip or board destination. This is the same architecture we use on other C6xxx boards we either support or build ourselves. The host cause the talker program to run after setting up a short command area in memory. We do this by calling TI's driver to make low-level HPI transfers to/from the talker memory. Also the DSP code can cause an interrupt to our driver, which in turn just uses the TI driver again to make transfers. Note that the talker program and its interrupt are *not known* to DSP/BIOS. Our host applications require independent access to any and all memory and resources, asynchronously, without halting or stopping the processor, or getting involved with RTDX in any way. -Jeff |
