Additional UARTs

[Noodleface]

Hello everyone, first post here. I did try to search but did not see many actual solutions. Perhaps someone here can help.

A little background on the project. We have two RPi's that will be connected by RF Transceivers. A couple other IC's will be connected to each (GPS, Camera, etc). These devices all need to access serial UARTs, that of which the RPi provides only one. Perhaps we should've got something else, but this is what we have so we need to get a solution to this. Our code is written in C using the wiringPi libraries.

1) Is a software UART possible? I know we can "flip" the bits on a GPIO rather quickly, and really we only need 9600bps max. Is it possible to write a software UART or will it peg the CPU too hard? Has anything like this been done?

2) USB -> Serial. We aren't using the USB ports at the moment, so would going from serial to USB work in our favor? What parts would we need? I know there is an RS232 breakout for the RPi, but are there additional parts/wiring we will need beyond connecting the Tx/Rx/GND/VCC pins? What will the data rate over USB max out at?

3) I2C/SPI -> UART. I have seen some posts regarding breakouts that go from the I2C pins to create additional UARTS (up to 4). How feasible is this and how difficult would it be to interface with? I have heard we may need to write our own driver to handle the UARTs on the breakout.. how big of an undertaking is this?

Are there any other solutions? We were a bit naive when we chose the RPi for this project and did not realize that we would need so many UARTs. To think, we were debating on a Beaglebone (some have 4 UARTs). I'd like for us to be able to use the RPi and create a solution though.

Additionally, if we can figure something out I'd love to share our project and solution as I feel it is a bit unique.

Thanks for the help!

[techpaul]

1) Is a software UART possible? I know we can "flip" the bits on a GPIO rather quickly, and really we only need 9600bps max. Is it possible to write a software UART or will it peg the CPU too hard? Has anything like this been done?

As the OS will not necessarily give guaranteed timing you might be able to do this for ONE but will require a task that will take a lot of the CPU time.

2) USB -> Serial. We aren't using the USB ports at the moment, so would going from serial to USB work in our favor? What parts would we need? I know there is an RS232 breakout for the RPi, but are there additional parts/wiring we will need beyond connecting the Tx/Rx/GND/VCC pins? What will the data rate over USB max out at?

Look at devices like FT4232 a 4 poor serial USB device from FTDI, could solve most of your problems in one device.

3) I2C/SPI -> UART. I have seen some posts regarding breakouts that go from the I2C pins to create additional UARTS (up to 4). How feasible is this and how difficult would it be to interface with? I have heard we may need to write our own driver to handle the UARTs on the breakout.. how big of an undertaking is this?

Unless the UARTs have a way of providing interrupt status, you will have to continually poll all four devices so this will make this more complicated in software, and depends on how much traffic is coming through all the UARTS.

Are there any other solutions? We were a bit naive when we chose the RPi for this project and did not realize that we would need so many UARTs. To think, we were debating on a Beaglebone (some have 4 UARTs). I'd like for us to be able to use the RPi and create a solution though.

Are there alternative parts you want to add with I2C or different interfaces like USB you could use instead?

[Noodleface]

1) Is a software UART possible? I know we can "flip" the bits on a GPIO rather quickly, and really we only need 9600bps max. Is it possible to write a software UART or will it peg the CPU too hard? Has anything like this been done?

As the OS will not necessarily give guaranteed timing you might be able to do this for ONE but will require a task that will take a lot of the CPU time.

2) USB -> Serial. We aren't using the USB ports at the moment, so would going from serial to USB work in our favor? What parts would we need? I know there is an RS232 breakout for the RPi, but are there additional parts/wiring we will need beyond connecting the Tx/Rx/GND/VCC pins? What will the data rate over USB max out at?

Look at devices like FT4232 a 4 poor serial USB device from FTDI, could solve most of your problems in one device.

3) I2C/SPI -> UART. I have seen some posts regarding breakouts that go from the I2C pins to create additional UARTS (up to 4). How feasible is this and how difficult would it be to interface with? I have heard we may need to write our own driver to handle the UARTs on the breakout.. how big of an undertaking is this?

Unless the UARTs have a way of providing interrupt status, you will have to continually poll all four devices so this will make this more complicated in software, and depends on how much traffic is coming through all the UARTS.

Are there any other solutions? We were a bit naive when we chose the RPi for this project and did not realize that we would need so many UARTs. To think, we were debating on a Beaglebone (some have 4 UARTs). I'd like for us to be able to use the RPi and create a solution though.

Are there alternative parts you want to add with I2C or different interfaces like USB you could use instead?

Thanks for your reply!

I was looking up the FT4232 as suggested, and if I understand this correctly would we wire each device to this unit, then connect from USB -> RPi's USB and each device shall show up as it's own COM port? Would we need additional RPi drivers to recognize the setup in this way or will it somehow be able to access each unit separately?

We cannot add units that use I2C or SPI, we are pretty much stuck with what we have.

[techpaul]

Thanks for your reply!

I was looking up the FT4232 as suggested, and if I understand this correctly would we wire each device to this unit, then connect from USB -> RPi's USB and each device shall show up as it's own COM port? Would we need additional RPi drivers to recognize the setup in this way or will it somehow be able to access each unit separately?

We cannot add units that use I2C or SPI, we are pretty much stuck with what we have.

They should appear as /dev/ttyUSBxx or similar names. Yes each is separate as far as software is concerned and the remote devices. I believe the standard libraries will support the device as is check FTDI site first for what linux driver is needed.

[Noodleface]

I will look into this.. seems like a nice device. Thanks for the input.

As always, I also welcome additional solutions.