This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Part selection help

Other Parts Discussed in Thread: MSP430G2203, MSP430FR2310, MSP430F5172

I need to specify a microcontroller for a simplistic but (relatively) fast communication bridge between UART and SPI.

The key requirements are:

  • UART and SPI can operate independently and simultaneously
  • UART BAUD rate of 1 Mbps achievable
  • SPI clock (when SLAVE) of at least 10 Mbps achievable
  • Small board space and low price :-) (meaning I don't need some massive MCU with lots of other peripherals)

Does TI offer something that fits the bill?

Thanks

  • MSP430FR2310, MSP430G2203
  • Thank you for your input.

    I am having trouble understanding the datasheets: They specify max communication speeds for UART and SPI Master, but not SPI Slave. I need SPI Slave. What is the maximum supported SPI Slave input clock, assuming the MCU is clocked at its maximum 16 MHz?

    If I understand correctly, Table 5-18. eUSCI (SPI Slave Mode) Switching Characteristics gives the following calculation: fUCxCLK = 1/2tLO/HI with tLO/HI ≥ max(tVALID,MO(Master) + tSU,SI(eUSCI), tSU,MI(Master) + tVALID,SO(eUSCI)). This doesn't seem to make sense because when I plugged in these values, max(6ns+20ns, 35ns+42ns) I got ~12.9MHz -- it doesn't make sense to me because every MCU I've ever seen always has slower SPI capability when SPI Slave. Maybe I made a mistake?

    Any help is appreciated.

    These parts do seem to meet the other requirements, as long as SPI Slave can achieve 10 MHz.
  • When the (e)USCI module is in SPI slave mode, the only difference is that the lock is sourced by the pin, and not by the internal signal. So it should behave like in master mode, with the timing limited only by the analog properties (as specified in the datasheet). 12.9 MHz sounds plausible.

    In practice, the limit is probably not the frequency, but the setup/hold times of the SPI master.
  • Another, perhaps more stringent, limitation may be the ability of the slave to deal with the data. This is throughput thing, not a bitrate thing.

    Neither of these devices has DMA. At 10MHz, the slave (at 16MHz) only has about 13 CPU clocks (very few) to deal with each byte. If your transactions are more than 1-2 bytes long, with no inter-byte delays, the slave will over/underrun.

    There are some small-ish devices in the F5 series (I've worked with the MSP430F5172, but there are others) which have DMA. They're also capable of 25MHz (CPU).
  • Bruce McKenney47378 said:
    Another, perhaps more stringent, limitation may be the ability of the slave to deal with the data. This is throughput thing, not a bitrate thing.

    Neither of these devices has DMA. At 10MHz, the slave (at 16MHz) only has about 13 CPU clocks (very few) to deal with each byte. If your transactions are more than 1-2 bytes long, with no inter-byte delays, the slave will over/underrun.

    There are some small-ish devices in the F5 series (I've worked with the MSP430F5172, but there are others) which have DMA. They're also capable of 25MHz (CPU).

    Thank you for pointing that out. Given that we'd like to transmit / receive bursts of 36 bytes at a time and communicate concurrently through SPI and the UART, the lack of DMA will make this a tall order. I'll take a closer look at the part you mentioned. Thanks again for helping.
  • Clemens Ladisch said:
    When the (e)USCI module is in SPI slave mode, the only difference is that the lock is sourced by the pin, and not by the internal signal. So it should behave like in master mode, with the timing limited only by the analog properties (as specified in the datasheet). 12.9 MHz sounds plausible.

    In practice, the limit is probably not the frequency, but the setup/hold times of the SPI master.

    Thank you for clearing that up. Now it makes much more sense why the calculation for fUCxCLK references MO(Master) and MI(Master).

**Attention** This is a public forum