I need a second serial async input channel on the MSP430G2553 and would like to use the SPI USCI to do this.

Is the USCI SPI baud rate stable enough to do this at 300 baud, 2400 baud or 9600 baud? I am currently using the 8 MHz clock.

Is there any other option that can save me from bit-banging?

Might it be possible to do asynchronous receive by starting the clock-out when the start-bit is received?

My current thinking for Rx on the SPI at 300 baud is as follows:

  1. start bit interrupt disable
  2. wait for 1/2 bit
  3. do Rx enable
  4. Rx interrupt
  5. start bit interrupt enable

One can use 10 bit receive on some of the other members in the family that contains a SPI.

Please note that this is a similar question to: Can I use SPI for asynchronous serial output? but the answer is much more complex because the SPI clock output must be aligned with the Rx bitstream.

Only half duplex is possible if you want to do Tx the same way.



closed as unclear what you're asking by Chris Stratton, uint128_t, Voltage Spike, ThreePhaseEel, Dmitry Grigoryev Feb 28 '17 at 17:13

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • \$\begingroup\$ You can get a chip that contains a UART and has a SPI interface. \$\endgroup\$ – Dave Tweed Feb 26 '17 at 12:15
  • \$\begingroup\$ @DaveTweed That question is about Tx, not Rx! \$\endgroup\$ – CL. Feb 26 '17 at 12:22
  • 1
    \$\begingroup\$ @CL.: I realize that this is asking about input instead of output, but they're so closely related that it really should just be one question. \$\endgroup\$ – Dave Tweed Feb 26 '17 at 12:22
  • 1
    \$\begingroup\$ Seriously, just use an external chip, or bit-bang the second UART with GPIO. Trying to coerce the SPI interface to do full-duplex asynchronous communication will be much more difficult. Better still, just select a microcontroller that has two UARTs to begin with. Why are you so married to this particular one? \$\endgroup\$ – Dave Tweed Feb 26 '17 at 13:23
  • \$\begingroup\$ OK, I've reopened the question. But unless you can be up-front about what your real requirements are, it's likely to get closed again as people get tired of chasing a moving target. \$\endgroup\$ – Dave Tweed Feb 26 '17 at 15:22

Some possible solutions:

1. UART by Software: Maybe it's a good time for you to consider this option. In this case the transmission is very simple using a timer. The reception is a bit trickier. However the things get easier with the support of external interrupt on RX pin (to detect the start bit). Always taking into account that the receiver will sample the pin in the middle of the bit period. The solution is limited to small baud rate rates, so that the error is below 5%.

2. MAX3100 SPI compatible UART from MAXIM or MAX14830 (quad Serial UART with 128-Word FIFO).

3. UART through SPI ": Yes, the MSP430G2553 has two independent UCSI modules: USCI_A0 can operate in UART/LIN, IRDA and SPI modes and USCI_B0 in SPI and I2C modes. So, I believe you intend to use USCI_B0 to emulate an additional UART. Similar to the UART by software, the complexity will depend on whether you want only transmission, reception, or both. Also the transmission will be simpler. You should consider what SPI mode (0 to 3) to choose in order to define the UCCKPL (CPOL) and UCCKPH (CPHA) behavior. I remember the definition of UCCKPH is inverted in relation to the traditional definition of CPHA. In many SPI based applications, the MSB is sent first. Otherwise, in UART, D0 bit is transmitted first. That can be configured in UCSI registers.

In any case, they follow references with guidelines for a possible implementation (first is more detailed):

Using the ST626X SPI as a UART, from ST

Using the SPI as an Extra UART Transmitter, from TI

But there will always be a software overhead, because the SPI protocol is as the name says: SPI - not UART, and finally, make sure it's worth.

  • \$\begingroup\$ Option 3 is exactly what I am looking for. Although the MSP430G2553 and MSP430FR6989 can only Tx 8-bits at a time, the MSP430 SPI can do 10-bits. For Rx I suspect that a resync will be required after each character, but might be possible. I will mark this as an answer until such time as more MSP430 details are provided in an answer.. \$\endgroup\$ – skvery Feb 26 '17 at 19:40
  • \$\begingroup\$ This is not a useful answer, as it skips over the key details that make the proposal much more complicated than imagined. \$\endgroup\$ – Chris Stratton Feb 26 '17 at 20:43
  • \$\begingroup\$ @Chris Stratton: I believe the OP is the one who would decide the usefulness of the answer. If my answer has new information in relation to others, then it may be something useful. Voting down: This is definitely not helpful here, since it contain no errors. We are all spending some time to help those who ask. The idea was to provide guidelines and not write complete source code. So, I propose that you present your "useful" solution! \$\endgroup\$ – Dirceu Rodrigues Jr Feb 26 '17 at 22:42
  • \$\begingroup\$ @DirceuRodriguesJr - you misunderstand how things work here. Votes are precisely how the community weighs the usefuleness of an answer through their substantial collective expertise; if the poster was in a uniquely good position to judge it, they probably wouldn't have needed to ask the question in the first place! To understand what is wrong with your answer, real old_timer's \$\endgroup\$ – Chris Stratton Feb 26 '17 at 23:36
  • \$\begingroup\$ @Chris Stratton: In addition to you saying that "skvery" is not able to judge the usefulness of the response, still states that "my answer is wrong" (this not applies, since I've proposed different solutions and provided a link to a source code as a starting point). Also, I think if there was a problem with my answer, it would be more interesting to put a proper technical comment and not continue to advocate down votings. In any case, we are awaiting your "useful" answer. \$\endgroup\$ – Dirceu Rodrigues Jr Feb 27 '17 at 0:16

Quite simple no. You do not have a clock to go with your RX data so the spi controller has nothing to clock the data with. If you were to somehow manage to use a timer to fake the clock there will be drift possibly within a few characters, but eventually. Nothing dictates that the sender is going as fast as they can, so there will be gaps.

The data coming in will immediately or eventually not be aligned in a desirable way, if possible you would still have to do your own search for start bits and stop bits and parity if used. Slightly easier than bit banging but who knows. Not sure if bit banging is the right term more like polling.

Crazy but you could create a timer that is 8 or 16 or some number times overclocked, feed that into your spi controller clock, strap the enable as enabled (does that part even have a slave spi controller or is it master only), and then basically turn the spi controller into a logic analyzer from which you have to find the bit edges and extract the characters in software like a uart would.

You could also use interrupts if the gpio supports both edges or use two pins and tie the signal to both one to look for rising and one for falling, using a timer measure the time between edges and again have to in software do the uart decoding of the bistream.

Much easier to just by the right part with the right resources or get an external spi or i2c uart and hook that up to the MSP430, and let it do the uart work. Maybe even a dual and have both uarts come in from there, maybe buy a lesser msp430 without a uart but with spi.

  • \$\begingroup\$ My proposal is to fake the clock for one character only and to resync the clock at each start bit. \$\endgroup\$ – skvery Feb 26 '17 at 16:05
  • \$\begingroup\$ I guess this is one of those "what happened when you tried" it situations then... \$\endgroup\$ – old_timer Feb 26 '17 at 16:23
  • \$\begingroup\$ yes, seems like it... I can only ask and if I get no suggestions or definite no, see if I can make it work? \$\endgroup\$ – skvery Feb 26 '17 at 16:29
  • 1
    \$\begingroup\$ You have to find the start bit edge, deal with the isr and its latency, get the timer started for 9 or 10 edges, grab the data from spi and if there is another start bit right away then start this again. Would this be less work than oversampling with a timer interrupt and polling the gpio? \$\endgroup\$ – old_timer Feb 26 '17 at 16:31
  • \$\begingroup\$ Indeed, an interrupt to fire off the SPI reception at 1x might work for characters in isolation but it's going to be very tricky for a sequence of packed characters since you'll need to be arming your new trigger detector asynchronously to the old data collector which is just finishing. But the idea of hardware-assisted oversampling to feed subsequent software character extraction seems a good one, with less overhead than a pure software approach. \$\endgroup\$ – Chris Stratton Feb 26 '17 at 20:46

Not the answer you're looking for? Browse other questions tagged or ask your own question.