I have several sensors that all use TTL UART for communication. I need to be able to talk to each sensor and recieve each sensors data seperately. I need to be able to set the baud rate for each sensor every time I talk to them (they all use different baud rates).
Will this work? Is there a better way? Concerned with causing timeing problems and cross talk if they are daisy chained.
Thanks,
Hello.
What baud rates are the sensors using? If they are slow enough, the easiest thing might be to do software serial on your microcontroller.
Your circuit is not very safe because one sensor might be trying to drive its TX line LOW while the other is trying to drive it HIGH.
- Ryan
AHRS only transmits data when a GET_DATA packet is received over the UART. And the others are not really the sensors but PICF648A and those only send data when polled by the Master PIC I believe.
What I am doing is taking the input data and doing what ever math needs to be done and storeing the finished data. Then when the master PIC is ready for updated data the master polls the correct source for that data.
GPS and goes directly to a PIC16F648A and the AHRS goes to another PIC16F648A. Maestro 12 is the other sensor and this is found in the datasheet. “If you aren’t interested in receiving TTL serial bytes from the Maestro, you can leave the TX line disconnected”
So really what I have is two Pic16F648A’s and the Maestro 12 sensor on the TX, RX over the UART.
The reason for the two PIC16F648"s is to leave the master PIC16F887 with the final process of taking final data and computing final outputs in real time. bThe project is a auto pilot for RC planes.
I hope this clear up my thinking.
Your input is valued.
Hello.
You cannot connect safely multiple TX lines directly together because these are all outputs, even when the devices aren’t transmitting (they drive high when idle). If you want to use a single master serial receive line, you should connect all your transmit lines to it through an AND gate and ensure that you never have more than one transmitting at a time.
Note that you can leave out the AND gates on the RX lines of your slave devices if you program them to use a device-addressable protocol that is compatible with the Maestro’s. In that case, you would just connect all your slave RX lines directly to the master TX line and devices would ignore commands that are not addressed to them.
- Ben
Thanks for the great information!
Let me explore another solution: I2C / SPI-to-UART converter (SC16IS750)
IF this will work for getting all the sensors to work on a single communication type that will allow speed and addressing of the sensors using the address of the SPI-to-UART. The second thing that is good about this is I can use a second PIC to be between the sensor and the main PIC(16F887). The sensor via Uart to PIC via SPI to the main PIC. The second PIC has to do calculations on the data from the sensor and send the final data to the main PIC. Much to much calculations to all be done on the main PIC.
So this is how I think it will work:
sensor to SPI-to-UART to main PIC for the slower sensors, for fast sensor to SPI-to-UART to PIC(for calculations) to main PIC.
I think maybe I don’t completely understand what you’re doing, but my impression is that it either won’t work or will be needlessly complex. Can you draw a diagram of the various components you are planning to use and how they will be connected?
Do your PICs have hardware I2C modules? If so, why not use serial for the Maestro and I2C (or SPI) between your master PIC and its slaves? I’m still not clear on why you need an I2C- or SPI-to-serial converter.
- Ben
Ok I will draw it tomorrow and post it. Basicly I have three sensors that require UART and one that needs PSI plus the cell phone has to use UART. So I have to save the UART for the phone.
That leaves PSI or I2C for the three sensors. PSI is faster and each slave has its own address. Therefore they won’t be cross talking as each will be addressed and polled for data as the main PIC is ready for it. One of the three sensors has to have a PIC(this will talk to the sensor with a UART and SPI as a slave to the main PIC) over it as it has a lot of calculations to do to get to the final data for output to the main PIC.
Then I have two barometers that talk I2C only to the main PIC.
main PIC
UART Master Master Master I2C I2C
SPI SPI SPI
UART slave slave slave
SPI SPI SPI I2C I2C
phone Sensor1 Sensor2 PIC Barometer1 Barometer2
UART
UART
Sensor3
Hope this helps till tomorrow, when I will draw the picture.
Sorry, lost the formatting when posted.
This is what I envision for hooking up the sensors to the main PIC. The "Slave PIC has the calculations to do. The phone has to be UART. The sensors have no address.
What is it about SPI that you don’t like?
Thanks, hope this makes the project communication clearer.
I don’t dislike SPI, but note that SPI does not have a notion of an “address” the way I2C does. Rather, you will need to connect a different I/O line to the slave-select pin of each SPI slave device in order to prevent cross-talk.
Your proposed setup doesn’t seem unreasonable to me, but it is significantly more complicated than the one you originally mentioned:
My claim was that you should be able to program your two PICs with an addressable serial protocol that is compatible with the Maestro’s and then connect all three to the same serial line. If there is more going on (and it seems there is), then this suggestion might not be so helpful.
- Ben
