How choose an interface ?

Damien,

I'm no expert with the OMAP-L138, and this question is probably better served in the OMAP forum. I don't see the uPP interface working cleanly with the ADS8471 and I don't think this is an intended application for this interface.

You should start by taking a look at all of the control signals on the ADS8471 and consider how you wish to control the device since there are a variety of possible configurations. We see the following signals:

• CONVST - This is the convert start pin, it is pulled low for a minimum of 20ns and then begins converting data. This is an input to the device, and tells the device that you need more data.
• BUSY - This signal is asserted high immediately after the falling edge of CONVST and stays high until the device is done converting a sample. This is an output from the device, and tells you when to read data.
• CS - This is the chip select signal. This is an input to the device that tells the device that you are communicating with it. This is important if there are multiple devices on the same communication port.
• BYTE - This is a "byte select" pin. This is an input to the device and is utilized in systems that only provide 8 pins to retrieve the 16 bit conversion result. Essentially, when BYTE is low you receive the upper 8 bits and when BYTE is high you receive the lower 8 bits.
• RD - This is the "read data" pin. This is an input to the device that indicates you are ready to latch new data. When RD transitions low all 16 bits of data are latched on DB[15:0]. While RD and CS are both still low BYTE may be raised high to clock the lower 8 bits in on DB[15:8] as mentioned in the previous item.
• DB[15:8] - Upper 8 bits of conversion data. This is an output.
• DB[7:0] - Lower 8 bits of conversion data. This is an output.

Depending on how you plan on applying the device and what other devices may be on the bus you have some options to remove some of these signals;

• RD can be tied to ground. Under this configuration you would still need to assert CONVST low with CS low to begin a conversion. If CS remains low then data will be latched into DB[15:0] upon the falling edge of BUSY. CS can return high after CONVST has been asserted, under this configuration data will be latched into DB[15:0] after both BUSY and CS have fallen low.
• As previously mentioned CS can also be tied to ground. Under this configuration the device's interface will never go tri-state and therefore will always be "listening" for input on the parallel bus. Only tie CS low if there are no other devices on the bus.
• Both of the previous points can be applied at the same time, i.e. RD and CS tied to ground. This is referred to as "auto-read" mode. Under this configuration you would simply assert CONVST low and wait for BUSY to fall low. When BUSY falls low data is latched in on DB[15:0]. A high on BYTE still puts the lower 8 bits on DB[15:8].

The "auto-read" mode is the simplest method of using the ADS8471. If in addition to operating in this mode you utilized all 16 bits of the data bus made available under uPP, rather than using an 8 bit data bus, you could also remove the use of the BYTE signal and simply tie that low. In this case you would only need to use 2 of the 5 parallel control lines, CONVST and BUSY, of the ADS8471 to retrieve data. I think simplifying the interface in this way is the only hope you have of getting uPP to work with the ADS8471...

Next consider the signals for uPP;

• CHx_CLK - The clock signal synchronizes all other signals on the uPP bus. This includes latching data in and start/enable/wait states. This signal is required in all modes of operation for the interface.
• CHx_START - This indicates that the first 16 bits of an entry are about to begin. From what I read this is mostly for DMA functionality, but I'm not entirely sure what the implications of not using this in this interface would look like.
• CHx_ENABLE - This corresponds to CS for the ADS8471. It lets the uPP bus know that communication is happening. Enable functionality can be turned off for both TX and RX functionality of the peripheral.
• CHx_WAIT - This signal allows a receiver under this interface to request a temporary stop in data transmission. When WAIT is asserted it is expected that the transmitter will stop sending data. The ADS8471 does not support this type of functionality. WAIT functionality can be turned off in TX mode.
• CHx_DATA[n:0] - This is the data bus for the parallel interface. This pairs up directly with DB[15:8] on the OMAP-L138.

Now, looking back to the first bulleted list describing the ADS8471 interface, I took care to highlight which signals are inputs and which signals are outputs. Assuming we're operating under "auto-read" mode with BYTE tied low we have two signals we need to worry about. CONVST (an input) and BUSY (an output). The uPP interface provides 3 modes of operation; TX, RX, and Duplex. TX mode gives the OMAP-L138 control of all signals (except for WAIT), and RX mode gives the device control of all signals (except for WAIT). Duplex mode utilizes channels A and B of the uPP peripheral, one in TX mode and the other in RX mode.

Lets look at operating this in RX mode. The only thing I can see working here is to first disable or tie CHx_ENABLE to ground, like CS for the ADS8471. Since the ADS8471 is a slave device it cannot control CS and assert it low, so we need both to always be listening to the bus. CHx_START should probably also be disabled, because the ADS8471 isn't going to assert any sort of START signal. We can't disable the WAIT pin under RX mode with uPP, but it wouldn't be connected to anything. The CLOCK pin latches all the data and you might get away with having this tied to BUSY with the appropriate polarity settings. When BUSY falls low after a conversion we know new data is going to show up from the ADS8471 and that should be latched into the uPP peripheral. We're still missing CONVST here though. With uPP in RX mode you'd have to utilize a GPIO or something from the OMAP-L138 to trigger a conversion. At that point everything would autonomously be shifted across the bus once BUSY falls low...in theory.

The real problem with doing it this way is that most DMA features aren't utilized as well as they could be. Instead of having a real automated DMA data collection scheme you have to throw in some kind of routine to toggle your CONVST GPIO appropriately, this might be an interrupt or something. This approach is very complex though, and I should think it would be much easier to understand and manipulate if you just bit-bang the interface entirely with GPIOs. You could still leverage some of the more simplistic operation modes mentioned above to reduce pin real-estate. This approach would probably be entirely interrupt driven.

I probably could have gotten away with simply suggesting you to use the bit-banged GPIO approach without going into this much detail here, but I hope this helps you understand the process and considerations more completely with respect to choosing an interface. Also, keep in mind that this forum is intended to service data converter related questions. If you have questions about the ADS8471's digital interface this is certainly the place to come. I strongly suggest that you seek some guidance from the OMAP team as well to make sure I have not overlooked any features of the uPP interface, as I am not an expert with those devices.

Hope this helps...