How many serial communication(RX/TX) channels does Boron have?

Currently, I use Boron RX/TX pins to communicate with some other board, but now I want to it to communicate with another additional board through another RX/TX channel. I know Electron has at least two if not three serial communication channels, how many does Boron have?

Sadly the Xenon board has 2 sets of Rx/Tx pins but the Boron has only 1 set (the processor itself has 3 sets). It was a choice of what processor pins to bring out given the size constraints of the board.

A pity as I have a similar need - I use one to communicate with a 4DSystems display and would like second to link to a Xenon on the same board.

1 Like

While you already got your answer, here would be the place for own investigations :wink:
https://docs.particle.io/datasheets/cellular/boron-datasheet/#peripherals-and-gpio
image

1 Like

The nRF52840 only has two hardware UARTs, not three. And there is only one exposed to the user on the Argon and Boron because the nRF52 connects to the network coprocessor (ESP32 on the Argon and u-blox modem on the Boron) by serial, leaving only one port on RX/TX.

It is possible to add UARTs by I2C or SPI; I recommend the SC16IS7xx series as they are known to work.

3 Likes

Thank you so much guys.

Hey @rickkas7, is there more info on the data rate for this UART interface? How does that relate to the WiFI data transfer rate?
I see in the Argon datasheet that the BLE/NFC radio has a 2Mbps max rate. I am thinking BLE is always going to be faster than the WiFi connection… unless we can execute code within the ESP32?

@Pescatore, the nRF5284 datasheet is a bit hard to read (it’s very complex and verbose) but here’s an excerpt for the UARTE interface:

6.34 UARTE — Universal asynchronous receiver/transmitter with EasyDMA The Universal asynchronous receiver/transmitter with EasyDMA (UARTE) offers fast, full-duplex, asynchronous serial communication with built-in flow control (CTS, RTS) support in hardware at a rate up to 1 Mbps, and EasyDMA data transfer from/to RAM. __

Looks like 1MBit/sec

Is that also the speed at which it operates with the ESP32 for WiFi communication?

Thanks - I will follow up on this device as one possible solution to my needs

This is my library for the SC16IS740/50/60 (single port) chip:

I built a board with the dual port SC16IS752 in the Adafruit FeatherWing form-factor but I haven’t made the software driver modification for it. It should be pretty simple; the chips are nearly identical beyond the port selection.

1 Like

Hi,
I am new to all of this, can you show me where on that data sheet it explains how many serial ports there are. I read through the whole thing as well as did a search for the word “serial” and there are only 5 hits for the word; 1 in the side bar and 4 in the power consumption section.

I assume there is a jargon I don’t understand and will really appreciate you pointing it out.

If you’re asking about the Boron, @ScruffR shared a screenshot from the data sheet; keyword UART. If you’re asking about something else, I’d suggest starting a new thread and referencing the device model you’re looking for.

1 Like

I am asking about the Boron and thanks for helping me :slight_smile:

I actually got here because I am trying to get a GNS reciever and a bluetooth module working with the boron. It looks like I can do that one at a time (going to do the same for the cellular) but not at the same time.

I couldn’t find anything on the data sheet about serial ports and honestly it isn’t clear for someone who doesn’t know what UART means. Even with what you told me the diagram shows 4 UART pins. I am sure this means something to you but for those of us with limited knowledge it is sanskrit.

I'm not sure what you mean with that.
You will not really need to manage the cellular connection on the Boron yourself neither would you (under normal circumstances) communicate with the cell modem directly over UART/Serial.

Also what are you referring to with "one at a time"? How many GNS receivers do you intend to connect to that one Boron and why?
Or do you mean GNS and a BT module? But for that I'd ask why again, since the Boron is itself BT enabled.

Have you looked here too?

However, at least a very rudimentary undersanding how a Universal Asynchronous Receiver-Transmitter (aka serial communication device) works would be needed.
You shouldn't be puzzled by the fact that you need multiple pins for transmitting (Tx) and receiving (Rx) data (the extra two are for flow control and won't be needed in most circumstances).
If you are lacking that basic understanding you can maybe do a web search for UART as this is an universal concept not unique to Particle devices.
Even the pin designations in the datasheet (e.g. UART_CTS, UART_RTS) could be googled

BTW, when the focus of this thread is about serial communication and my screen shot shows a reference to UART chances are that both can be used synonymously :wink:

2 Likes

THANK YOU!!!

Seriously I have been looking all over for the API docs, all I could find are the how to’s. I did discover that the boron has its own BLE module after making that post so my life just got a bit easier.

I haven’t tested it yet but it is my understanding that cellular and GNS antennas can interfere with each other unless the antenna placement is carefully designed. It is my intention to only have one on at a time to hopefully eliminate any interference. Regardless in my use case the cellular connection will be used sparingly, hopefully once a day except in certain scenarios in which it will basically be turned on until the battery dies.

Additionally I want to also experiment with using LoRa as well as accelerometers and barometers. I don’t need to run them all at the same time so I can just use some reed relays to switch the Rx and Tx pins between devices.

I didn’t realize UART was synonomous with serial communication. I thought it was one protocol among many like TTL, I2C and SPI, thanks for setting me straight on that one. I also reas about RS-232 which I thought was serial communication over a single I/O, but honestly it sometimes feels like a rudimentary understanding requires weeks of study AND trying to find what to study takes a concerted effort.

I am a software developer by trade, I knew alot was being abstracted away, I guess I just never realized how much.

It is also my understanding that the Boron is unable to support software seriel. I couldn’t find that information in the docs either. You have given me hope that it is there. I think I just need to spend more time trying to figure out the layout of particles documentation. I think I have gotten spoiled, if I google a package/object for C#, Java, Python, etc the docs are usually the first couple links, this takes a lot more research.

I will throw in there since you got a little saucy with the “let me google that for you” it isn’t always clear what is a general term worth googling and what is a highly specific term where google will fail. For instance if I google MISO I get links to soup. I eventually get to Multiple Inputs Single Output if I refine my search, but I am not 100% sure that I have it right.

There is a lot of information out there and if you don’t even know what the acronym stands for it makes it very difficult to look up sometimes. I know when I am working with new people I can sometimes forget how much I know that they don’t. I was talking to a co-worker about Strings the other day, they are ops not dev and were quiet confused, jargon is hard until you get it down.

1 Like

My current browser tabs:

I am not trying to be lazy.

1 Like

Unfortunately the chances for that a next to zero. In order to get a stable communication for more than just a couple of bytes you'd need a good time base (which on Gen2 devices can be simply implemented via timed interrupts) cannot be found that easily on Gen3 devices.
The better option would be a HW solution as Rick suggested.

BTW, neither of these (UART, TTL, I2C, SPI, RS-232) are strictly protocols.
They are rather types of hardware interfaces. So would UART be the "hypernym" for and RS232, RS485, Serial over TTL, ... each of which would transport the same kind of bit stream but with different electrical characteristics.

In such a case the addition of "SPI" should be enough to boil the link-soup down to something more palatable.

BTW, in that case it stands for "Master In Slave Out", nicely giving away the direction of flow of data for that pin - the Master takes in what the Salve sent out.

1 Like

I had exactly the same problem - needing to communicate to more than one peripheral over serial. The solution that has worked well for me is a multiplexer IC. I am currently using the 74HC4052D. It is easy to use, and has a DIP package (breadboard friendly) version for prototyping; the 74HC4052E.

1 Like

This topic was automatically closed after 12 days. New replies are no longer allowed.