Jump to content
Sign in to follow this  
nemi

2 MSP430 sharing one USB UART?

Recommended Posts

I haven't tried this (yet) but I was wondering if the MSP430G2211 chip that accompanies the MSP430G2231 chip pre-installed on the launchpad could share the same PC USB UART interface, at the same time?

 

I was thinking that if each had different serial command sets and only transmitted data after receiving a command then they could share the same (9600 baud) comms to a host PC, doubling the I/O lines available, assuming there is no USB UART speciic issue that I am unaware of.

 

I realize both chips would have to be programed separably, one would then be installed in the launchpad demo PCB and the other would share the GND, VCC, TX, RX links.

 

Has anyone tried this or have a reason it would not work? :oops:

Share this post


Link to post
Share on other sites

I do not see any problem.

RXD signals for both the MSP430s can be connected together and driven by the USB interface.

TXD signals from the MSP430s could use serial resistors and then connect together to drive the USB interface. This is to prevent contention despite of the fact that only one of the MSP430s should drive it at any given time (the other one should switch to DIR=0 and ignore the input).

Share this post


Link to post
Share on other sites

how will you know if the usart is busy?

I would have RX and TX connected together so you can listen if an other msp430 is speaking right now to the usart.

Share this post


Link to post
Share on other sites
how will you know if the usart is busy?

I would have RX and TX connected together so you can listen if an other msp430 is speaking right now to the usart.

 

Dedicate a pin on each, and tie them to the same pullup resistor. When one is using the uart, have it pull the pin low. When it needs to use the uart, have it check the status of the pin. If it is low, delay, and check again in a few ms. If still high, the line is clear.

 

Essential the same traffic management idea used in ethernet hubs and i2c.

Share this post


Link to post
Share on other sites

Without dedicating more pins and code space, not likely.

 

Since RX and TX are tied together, everything transmitted out of a msp430 would go to the pc uart. Short of a pc based program running some sort of relay anyway.

 

Have each MSP430 AND the PC based messages preface with an addressing scheme.

 

Messages to a MSP430 need to have an address byte, which the program transmits to the msp430s. The msps read the address byte, and then if it does not match their programmed address, ignore all commands until they receive a all clear command. The msp that was address talks to the computer as normal.

 

When you need a msp to talk to the other, they do the same thing, send a message with an address byte, which the program recognizes, and then sends the message back onto the line, like a relay (possibly also logging the information).

 

Basically, you are emulating a Ethernet Hub network. I doubt we can fit that onto the existing valueline chips. Maybe the newer ones.

Share this post


Link to post
Share on other sites

You would. When you tie the RX and TX together, you are trying the RX of both msp430s to the TX of the ti uart. And the TX of both msp430s to the RX of the ti uart.

 

For uart communication betwix Msp1 and Msp2, you need to connect the RX of one to the TX of the other and visversa.

Share this post


Link to post
Share on other sites

Oh sorry I miss understood. I thought you meant tying them all together. would that work? tying all the rx pins together and all the tx pins together and then connect those together. Granted you would have an echo of every thing you send but it should be ignored if you have an address byte. Just a thought.

Share this post


Link to post
Share on other sites

I mean, that could work, but then you would have to program it to ignore everything it sent itself, and probably work at less than half duplex. I think that might just be more of a trial in futility or frustration.

Share this post


Link to post
Share on other sites

Hey, discourse and discussion is the bread and butter of engineering.

 

What I think might not work, might work, because maybe I didn't think of the angle or technique used, you know?

 

(Personally, I just find the idea of creating a new communication protocol annoying. Better to leech on someone else's work :P)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×