UART channels

Well, the description is a bit unclear here and inconsistent to later descriptions of the USCI.

There are two USCI-A and two USCI-B modules in the 47173. Making a total of 4. Later MSPs refer to one A and one B module as a single USCI module (so a 5438 with 4 USCIs ahs 4 A and 4 B modules).

You can use all 4 modules at the same time. But with some limitations. Tha A modules can run as eitehr SPI or UART adn the B modules can run as SPI or I2C each. Yet you cannot use any combination as they partly use the same pins. Each A/B pair only has 6 port pins

So if you use the UART of the A module (which takes 2 lines only), you can use SPI or I2C on the B module. But if you use 4 pin SPI (slave) on the A module, the B module cannot work at all, as both, I2C and SPI, require at least 3 pins and only 2 are left. Two 3-pin SPIs (master) work as well as SPI+I2C or UART with 3 or 4 pin SPI or I2C. Just I2C and 4-pin SPI isn't possible.

This is true for each A/B pair.

Thanks for your replay,

does that mean that I can enable

USCI_A0 as UART,

USCI_B0 as I2C,

USCI_A1 as SPI,

USCI_B1 as I2C,

and use them at the same time

Thanks

Haitham 

Haitham ElBadrashiny said:

use them at the same time

Yes, as long as he SPI is master (3-wire) and not slave or in a multi-master setup (in which cases it would require the STE signal which collides with the I2C signal requirements)

The only problem you face is on the software side: the A and B modules share a common interrupt for their RX and TX events

The USCI0_RX interrupt vector serves the UART and both SPI RX events as well as the I2C status events of USCI0A/B (same for USCI1_RX and USCI1A/B) and the TX interrupt serves the TX events for UART and both SPIs of USCIA/B as well as RX AND TX event for the I2C (!!!). You'll need to check all the status bits to determine who's signalling what. And be careful not to reset the wrong status bits accidentally when handling the requests.

Later versions of the USCI have one vector for all events in each submodule (A or B respectively) and an interrupt vector register on each submodule to provide you with information about the highest priority event. So A and B are really independent from the software view. And the info what caused the interrupt is collected at a central place (the individual IFG bits still exist). Things evolve. But be happy you don't have the USART module form the old 1x series. There I2C was a real pain. The hardware was doing (forcing) way too much and was useless for simpler tasks such as sending a start address and then reading the data bytes from there - I ended up with a software I2C.