OMAP-L1x Peripheral PIN MUX Issue

Hi Ravi

Ravindra said:

Does TI intend to bring out a new version of the OMAPL137/138 processor with higher pin-outs so that such PIN MUX issues do not occur or

Nothing in the near future. If you are interested in the roadmap information, please do contact your local TI support team

Ravindra said:

Is there any other option of having a ARM9 with a floating point DSP?

Same as above. Is ARM9 a must or a floating point DSP a must for you?

Ravindra said:

16-bit LCD, MMC0 and MMC1, 2 UARTs, 2 I2C ports and 1 SPI interface, EMAC and MII, EMIFA/EMIFB

Using the PIN MUX Utility, we find out that we can never have the second UART enabled in the above configuration. When we try to enable the same, the other interface pins clash.

Going back to your immediate engineering issue, I am hoping that you have done adequate analysis on the pin mux and plausible options. What are you using EMIFA for, do you need all 8 pins for MMC/SD i/f , and how many CS for SPI port?

Not knowing all of the above, I tried to use the pinmux utility to come up with a configuration. Let me know what would be missing in this to meet your application needs

Also, if an additional UART is the only thing that is missing, then I wonder if you can make use of PRU to create a soft UART. The PRU based Soft UART makes use McASP serializers (which I believe some should be available based on your stated peripheral requirements)

Details on PRU based implementation in a white paper

http://focus.ti.com/lit/wp/spry136/spry136.pdf

The actual implementation is done by Mistral

http://www.mistralsolutions.com/assets/downloads/opendoc.php?document_url=datasheets/UART.pdf

Hope this helps

Regards

Mukul

Mukul, Thanks a lot for taking the initiative on preparing a PIN MUX configuration.

For us, having both ARM9 and the Floating point DSP is a must. We need the ARM9 as the system controller and the floating point DSP to run the Medical data analysis algorithms

Mukul said:

Going back to your immediate engineering issue, I am hoping that you have done adequate analysis on the pin mux and plausible options. What are you using EMIFA for, do you need all 8 pins for MMC/SD i/f , and how many CS for SPI port?

 

Yes, I understand the problem that you have stated in terms of SPI slave devices. We are intending to re-use the LogicPD SOM so as to keep the BOM cost low. The LogicPD SOM has a SPI based NOR Flash. For the LCD, there is also plan to have the capacitive touch-screen. However, on the LogicPD SOM the PMIC Chipset also supports Touch-Screen interface over I2C. So for now having two Slave devices over the SPI and atleast 3 devices on the I2C Bus is sufficient. On the I2C we anticipate the PMIC, Battery monitoring circuitry, Touch-screen devices.

I am aware of the PRU based Soft UART solution, I am working for Mistral. It will be nice if we could meet sometime in case you work here in TI Bangalore.

Having 2 UARTs is a must product requirement, since we intend to connect external BP/Oximetry related add-on boards via the UART in the near future to this product.

Regards,

Ravi

Ravindra said:

For us, having both ARM9 and the Floating point DSP is a must. We need the ARM9 as the system controller and the floating point DSP to run the Medical data analysis algorithms

Thanks for clarifying. The current OMAPL1x device family is best suited for this. OMAPL138 is a very popular processor for us, and IMHO the pinmux done by the chip architect is creative and reasonably flexible. However, like most pinmuxing decisions, there will always be some end use case / peripheral mix that would be hard to comprehend and meet. 

Ravindra said:

Yes, I understand the problem that you have stated in terms of SPI slave devices. We are intending to re-use the LogicPD SOM so as to keep the BOM cost low.

Thanks for clarifying this, as I understand your constraints better now. Since you are not designing a board from scratch, then I can understand how this is additionally a limitation.

Ravindra said:

I am aware of the PRU based Soft UART solution, I am working for Mistral. It will be nice if we could meet sometime in case you work here in TI Bangalore.

Good to know that, then I don't have to advocate the soft UART approach to you. Not @ TI Blr :). 

Let us know if you have any additional questions or anyway we can help on this further.

Regards

Mukul

Mukul,

Sorry, i could not respond to you earlier.

Can the PRU be used to simulate multiple UARTs? 2 exactly.

We checked against the PinMux Utility and it looks like some of the McASP Serializers [0 to 7] clashes with the MII pins. So we have serializers 8 to 15 avaialble. Is this sufficient enough to implement two UARts?

We may not need flow-control on these ports.

Regards,

Ravi

Mukul,

Sorry, i could not respond to you earlier.

Can the PRU be used to simulate multiple UARTs? 2 exactly.

We checked against the PinMux Utility and it looks like some of the McASP Serializers [0 to 7] clashes with the MII pins. So we have serializers 8 to 15 avaialble. Is this sufficient enough to implement two UARts?

We may not need flow-control on these ports.

Regards,

Ravi

Ravi

Ravindra said:

Can the PRU be used to simulate multiple UARTs? 2 exactly.

The rule of thumb as far as I understand is 1 full duplex (RXD/TXD) UART per PRU or 4 half duplex UARTs, ignoring flow control. OMAPL1x/AM18x devices have 2 PRUs in the PRUSS (PRU0/1), so you can get 2 full UARTs or 8 half UARTs.

The McASP based softUART solution requires only 2 serializer pins to implement a full UART, you have 8 available so 2 UARTs should be easily do-able.

Regards

Mukul