RX vs TX operation in Software UARTArduino software serial - full duplexUART signal distortion with AVRBest way to connect to UART lines to multiple entitiesWhat happens on STM32 when multiple (UART) Interrupts are triggered at the same time? is there an interrupt stack?Make a forward from one UART to another UARTPIC32 UART buffer overrun in MIDI receiver applicationRouting one UART Tx output to multiple UART Rx using MOSFETMultiplexing UART8051 baud rate calculator using 16-bit timer for software UART timingXBee Wi-Fi module connection directly to UART Sensor
Use 230V 50Hz electronics in U.S.A
draw line according to other angle
Decay of spin-1/2 particle into two spin-1/2 particles
A partially ugly group with a casual secret
Why is Iceland Air's Saga Premium product classified as Business class?
Why did the people of Zion never find evidence of the previous cycles?
Hypothesis testing- with normal approximation
Term for anticipating counterarguments and rebutting them
Simple code that checks if you're old enough to drive
Why do we use the Greek letter μ (Mu) to denote population mean or expected value in probability and statistics
Proving a vector identity involving the line and surface integral
How could a sequence of random dates be generated, given year interval?
What is a GPU year?
Intuition behind the paradox of instantaneous heat propagation
Multiple devices with one IPv6 to the Internet?
"Du hast es gut", small talk meaning?
How to draw "flag format" lambda derivation diagrams as used in the book Type Theory and Formal Proof: An Introduction
Protecting Seals from Forgery
Light turning on and off
How can an immortal member of the nobility be prevented from taking the throne?
Surjection from one string to two strings
How does the Gameboy Link Cable work?
How do I figure out how many hydrogens my compound actually has using a mass and NMR spectrum?
By RAW, can you use your free object interaction while taking the "Use an Object" action?
RX vs TX operation in Software UART
Arduino software serial - full duplexUART signal distortion with AVRBest way to connect to UART lines to multiple entitiesWhat happens on STM32 when multiple (UART) Interrupts are triggered at the same time? is there an interrupt stack?Make a forward from one UART to another UARTPIC32 UART buffer overrun in MIDI receiver applicationRouting one UART Tx output to multiple UART Rx using MOSFETMultiplexing UART8051 baud rate calculator using 16-bit timer for software UART timingXBee Wi-Fi module connection directly to UART Sensor
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty
margin-bottom:0;
$begingroup$
I am short of 1 UART in my MCU. I needed 4 but so far what I have found suitable is an MCU that has 3 UARTs in it, STM32F103. So the 4th one I will have to implement in SW.
Each of my individual UARTs are either doing RX or TX operations only. So now I have an option to implement the SW UART for ONLY RX operation or ONLY TX operation.
Which of the two should be implemented in SW, a UART which is only doing RX operation or a UART which is only doing TX operation?
microcontroller stm32 uart serial digital-communications
$endgroup$
add a comment
|
$begingroup$
I am short of 1 UART in my MCU. I needed 4 but so far what I have found suitable is an MCU that has 3 UARTs in it, STM32F103. So the 4th one I will have to implement in SW.
Each of my individual UARTs are either doing RX or TX operations only. So now I have an option to implement the SW UART for ONLY RX operation or ONLY TX operation.
Which of the two should be implemented in SW, a UART which is only doing RX operation or a UART which is only doing TX operation?
microcontroller stm32 uart serial digital-communications
$endgroup$
22
$begingroup$
Why just not reuse TX or RX side of hw uart that's not used in other ports?
$endgroup$
– Vlad
Oct 14 at 9:24
$begingroup$
Wowowooo thats a lovely thing. Good, Thumbs UP. If you can make it an answer that would be even better.
$endgroup$
– alt-rose
Oct 14 at 9:32
$begingroup$
It will work if the speeds on TX and RX channels are equal, and it's already a part of the @MichelKeijers answer.
$endgroup$
– Vlad
Oct 14 at 9:37
$begingroup$
There are many STM32 models with 4 (or more) USART's (an USART has an additional optional clock pin; if disabled, it is equivalent to UART). For example, the STM32F072RB has 4 USARTs.
$endgroup$
– Erlkoenig
Oct 16 at 7:35
add a comment
|
$begingroup$
I am short of 1 UART in my MCU. I needed 4 but so far what I have found suitable is an MCU that has 3 UARTs in it, STM32F103. So the 4th one I will have to implement in SW.
Each of my individual UARTs are either doing RX or TX operations only. So now I have an option to implement the SW UART for ONLY RX operation or ONLY TX operation.
Which of the two should be implemented in SW, a UART which is only doing RX operation or a UART which is only doing TX operation?
microcontroller stm32 uart serial digital-communications
$endgroup$
I am short of 1 UART in my MCU. I needed 4 but so far what I have found suitable is an MCU that has 3 UARTs in it, STM32F103. So the 4th one I will have to implement in SW.
Each of my individual UARTs are either doing RX or TX operations only. So now I have an option to implement the SW UART for ONLY RX operation or ONLY TX operation.
Which of the two should be implemented in SW, a UART which is only doing RX operation or a UART which is only doing TX operation?
microcontroller stm32 uart serial digital-communications
microcontroller stm32 uart serial digital-communications
asked Oct 14 at 9:17
alt-rosealt-rose
6342 silver badges13 bronze badges
6342 silver badges13 bronze badges
22
$begingroup$
Why just not reuse TX or RX side of hw uart that's not used in other ports?
$endgroup$
– Vlad
Oct 14 at 9:24
$begingroup$
Wowowooo thats a lovely thing. Good, Thumbs UP. If you can make it an answer that would be even better.
$endgroup$
– alt-rose
Oct 14 at 9:32
$begingroup$
It will work if the speeds on TX and RX channels are equal, and it's already a part of the @MichelKeijers answer.
$endgroup$
– Vlad
Oct 14 at 9:37
$begingroup$
There are many STM32 models with 4 (or more) USART's (an USART has an additional optional clock pin; if disabled, it is equivalent to UART). For example, the STM32F072RB has 4 USARTs.
$endgroup$
– Erlkoenig
Oct 16 at 7:35
add a comment
|
22
$begingroup$
Why just not reuse TX or RX side of hw uart that's not used in other ports?
$endgroup$
– Vlad
Oct 14 at 9:24
$begingroup$
Wowowooo thats a lovely thing. Good, Thumbs UP. If you can make it an answer that would be even better.
$endgroup$
– alt-rose
Oct 14 at 9:32
$begingroup$
It will work if the speeds on TX and RX channels are equal, and it's already a part of the @MichelKeijers answer.
$endgroup$
– Vlad
Oct 14 at 9:37
$begingroup$
There are many STM32 models with 4 (or more) USART's (an USART has an additional optional clock pin; if disabled, it is equivalent to UART). For example, the STM32F072RB has 4 USARTs.
$endgroup$
– Erlkoenig
Oct 16 at 7:35
22
22
$begingroup$
Why just not reuse TX or RX side of hw uart that's not used in other ports?
$endgroup$
– Vlad
Oct 14 at 9:24
$begingroup$
Why just not reuse TX or RX side of hw uart that's not used in other ports?
$endgroup$
– Vlad
Oct 14 at 9:24
$begingroup$
Wowowooo thats a lovely thing. Good, Thumbs UP. If you can make it an answer that would be even better.
$endgroup$
– alt-rose
Oct 14 at 9:32
$begingroup$
Wowowooo thats a lovely thing. Good, Thumbs UP. If you can make it an answer that would be even better.
$endgroup$
– alt-rose
Oct 14 at 9:32
$begingroup$
It will work if the speeds on TX and RX channels are equal, and it's already a part of the @MichelKeijers answer.
$endgroup$
– Vlad
Oct 14 at 9:37
$begingroup$
It will work if the speeds on TX and RX channels are equal, and it's already a part of the @MichelKeijers answer.
$endgroup$
– Vlad
Oct 14 at 9:37
$begingroup$
There are many STM32 models with 4 (or more) USART's (an USART has an additional optional clock pin; if disabled, it is equivalent to UART). For example, the STM32F072RB has 4 USARTs.
$endgroup$
– Erlkoenig
Oct 16 at 7:35
$begingroup$
There are many STM32 models with 4 (or more) USART's (an USART has an additional optional clock pin; if disabled, it is equivalent to UART). For example, the STM32F072RB has 4 USARTs.
$endgroup$
– Erlkoenig
Oct 16 at 7:35
add a comment
|
2 Answers
2
active
oldest
votes
$begingroup$
I'm not an electronics engineer, but I would go for using the TX operation as a software UART.
For an RX operation, buffering is needed, and interrupts are needed not to miss information. This is typically handled by a hardware UART.
For a TX operation, you only need to send information, which is happening when you want it (for receiving you don't know beforehand when data will be received).See hooskworks's comment (the right term is if the call can be blocked, it's easy by a software UART).
In case the UART speeds are equal, you can use one UART both for RX and TX. Even if the speeds are not equal and you know you don't receive anything while you send, you could switch speeds meanwhile probably.
$endgroup$
2
$begingroup$
That would be my analysis of the problem too so i think TX'ing on demand, especially if you can TX in a blocking way when you need to, is easier from a software point of view.
$endgroup$
– hooskworks
Oct 14 at 9:26
2
$begingroup$
Luckily the speeds on RX and TX UARTs are same. So it will be good to use an un-used TX pin as my 4th UART port.
$endgroup$
– alt-rose
Oct 14 at 9:52
$begingroup$
Yes, you can even just continue receiving for the shared UART while you are sending.
$endgroup$
– Michel Keijzers
Oct 14 at 9:58
add a comment
|
$begingroup$
It's far simpler to implement a UART transmission in software because you just bit-bang the output port until the bytes are sent. To implement a receiver, you have to do multiple checks on the bits as they arrive (such as waiting for the start bit) and parity checking and usually, you have to run at a much higher processing rate to ensure you can cope with clock speed variations between the remote transmission source and your local receiver.
This latter part is to avoid the misreading of data; a typical receive system will run its clock at approximately 16x the known baud rate and sample the data stream mid-symbol to ensure maximum data integrity. The transmit and receive clocks need to be reasonably similar in case there are few data transitions. Data transitions help re-sync the mid-symbol counter. Below are examples of good similarity in RX-TX clock frequencies followed by a scenario where the receive clock runs much too slow: -
In the latter example you should be able to see that symbol sampling has drifted off to a point where the 4th bit is sampled instead of the 3rd bit. Of course, if there are plenty of bit transitions, the receive clock can be re-synchronized on the fly and this problem is reduced but, with a UART transmission, you cannot avoid all the bits (apart from start) being high or, worst still, all the bits being low.
$endgroup$
add a comment
|
Your Answer
StackExchange.ifUsing("editor", function ()
return StackExchange.using("schematics", function ()
StackExchange.schematics.init();
);
, "cicuitlab");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "135"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/4.0/"u003ecc by-sa 4.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2felectronics.stackexchange.com%2fquestions%2f462788%2frx-vs-tx-operation-in-software-uart%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
$begingroup$
I'm not an electronics engineer, but I would go for using the TX operation as a software UART.
For an RX operation, buffering is needed, and interrupts are needed not to miss information. This is typically handled by a hardware UART.
For a TX operation, you only need to send information, which is happening when you want it (for receiving you don't know beforehand when data will be received).See hooskworks's comment (the right term is if the call can be blocked, it's easy by a software UART).
In case the UART speeds are equal, you can use one UART both for RX and TX. Even if the speeds are not equal and you know you don't receive anything while you send, you could switch speeds meanwhile probably.
$endgroup$
2
$begingroup$
That would be my analysis of the problem too so i think TX'ing on demand, especially if you can TX in a blocking way when you need to, is easier from a software point of view.
$endgroup$
– hooskworks
Oct 14 at 9:26
2
$begingroup$
Luckily the speeds on RX and TX UARTs are same. So it will be good to use an un-used TX pin as my 4th UART port.
$endgroup$
– alt-rose
Oct 14 at 9:52
$begingroup$
Yes, you can even just continue receiving for the shared UART while you are sending.
$endgroup$
– Michel Keijzers
Oct 14 at 9:58
add a comment
|
$begingroup$
I'm not an electronics engineer, but I would go for using the TX operation as a software UART.
For an RX operation, buffering is needed, and interrupts are needed not to miss information. This is typically handled by a hardware UART.
For a TX operation, you only need to send information, which is happening when you want it (for receiving you don't know beforehand when data will be received).See hooskworks's comment (the right term is if the call can be blocked, it's easy by a software UART).
In case the UART speeds are equal, you can use one UART both for RX and TX. Even if the speeds are not equal and you know you don't receive anything while you send, you could switch speeds meanwhile probably.
$endgroup$
2
$begingroup$
That would be my analysis of the problem too so i think TX'ing on demand, especially if you can TX in a blocking way when you need to, is easier from a software point of view.
$endgroup$
– hooskworks
Oct 14 at 9:26
2
$begingroup$
Luckily the speeds on RX and TX UARTs are same. So it will be good to use an un-used TX pin as my 4th UART port.
$endgroup$
– alt-rose
Oct 14 at 9:52
$begingroup$
Yes, you can even just continue receiving for the shared UART while you are sending.
$endgroup$
– Michel Keijzers
Oct 14 at 9:58
add a comment
|
$begingroup$
I'm not an electronics engineer, but I would go for using the TX operation as a software UART.
For an RX operation, buffering is needed, and interrupts are needed not to miss information. This is typically handled by a hardware UART.
For a TX operation, you only need to send information, which is happening when you want it (for receiving you don't know beforehand when data will be received).See hooskworks's comment (the right term is if the call can be blocked, it's easy by a software UART).
In case the UART speeds are equal, you can use one UART both for RX and TX. Even if the speeds are not equal and you know you don't receive anything while you send, you could switch speeds meanwhile probably.
$endgroup$
I'm not an electronics engineer, but I would go for using the TX operation as a software UART.
For an RX operation, buffering is needed, and interrupts are needed not to miss information. This is typically handled by a hardware UART.
For a TX operation, you only need to send information, which is happening when you want it (for receiving you don't know beforehand when data will be received).See hooskworks's comment (the right term is if the call can be blocked, it's easy by a software UART).
In case the UART speeds are equal, you can use one UART both for RX and TX. Even if the speeds are not equal and you know you don't receive anything while you send, you could switch speeds meanwhile probably.
edited Oct 14 at 9:27
answered Oct 14 at 9:25
Michel KeijzersMichel Keijzers
8,97211 gold badges38 silver badges86 bronze badges
8,97211 gold badges38 silver badges86 bronze badges
2
$begingroup$
That would be my analysis of the problem too so i think TX'ing on demand, especially if you can TX in a blocking way when you need to, is easier from a software point of view.
$endgroup$
– hooskworks
Oct 14 at 9:26
2
$begingroup$
Luckily the speeds on RX and TX UARTs are same. So it will be good to use an un-used TX pin as my 4th UART port.
$endgroup$
– alt-rose
Oct 14 at 9:52
$begingroup$
Yes, you can even just continue receiving for the shared UART while you are sending.
$endgroup$
– Michel Keijzers
Oct 14 at 9:58
add a comment
|
2
$begingroup$
That would be my analysis of the problem too so i think TX'ing on demand, especially if you can TX in a blocking way when you need to, is easier from a software point of view.
$endgroup$
– hooskworks
Oct 14 at 9:26
2
$begingroup$
Luckily the speeds on RX and TX UARTs are same. So it will be good to use an un-used TX pin as my 4th UART port.
$endgroup$
– alt-rose
Oct 14 at 9:52
$begingroup$
Yes, you can even just continue receiving for the shared UART while you are sending.
$endgroup$
– Michel Keijzers
Oct 14 at 9:58
2
2
$begingroup$
That would be my analysis of the problem too so i think TX'ing on demand, especially if you can TX in a blocking way when you need to, is easier from a software point of view.
$endgroup$
– hooskworks
Oct 14 at 9:26
$begingroup$
That would be my analysis of the problem too so i think TX'ing on demand, especially if you can TX in a blocking way when you need to, is easier from a software point of view.
$endgroup$
– hooskworks
Oct 14 at 9:26
2
2
$begingroup$
Luckily the speeds on RX and TX UARTs are same. So it will be good to use an un-used TX pin as my 4th UART port.
$endgroup$
– alt-rose
Oct 14 at 9:52
$begingroup$
Luckily the speeds on RX and TX UARTs are same. So it will be good to use an un-used TX pin as my 4th UART port.
$endgroup$
– alt-rose
Oct 14 at 9:52
$begingroup$
Yes, you can even just continue receiving for the shared UART while you are sending.
$endgroup$
– Michel Keijzers
Oct 14 at 9:58
$begingroup$
Yes, you can even just continue receiving for the shared UART while you are sending.
$endgroup$
– Michel Keijzers
Oct 14 at 9:58
add a comment
|
$begingroup$
It's far simpler to implement a UART transmission in software because you just bit-bang the output port until the bytes are sent. To implement a receiver, you have to do multiple checks on the bits as they arrive (such as waiting for the start bit) and parity checking and usually, you have to run at a much higher processing rate to ensure you can cope with clock speed variations between the remote transmission source and your local receiver.
This latter part is to avoid the misreading of data; a typical receive system will run its clock at approximately 16x the known baud rate and sample the data stream mid-symbol to ensure maximum data integrity. The transmit and receive clocks need to be reasonably similar in case there are few data transitions. Data transitions help re-sync the mid-symbol counter. Below are examples of good similarity in RX-TX clock frequencies followed by a scenario where the receive clock runs much too slow: -
In the latter example you should be able to see that symbol sampling has drifted off to a point where the 4th bit is sampled instead of the 3rd bit. Of course, if there are plenty of bit transitions, the receive clock can be re-synchronized on the fly and this problem is reduced but, with a UART transmission, you cannot avoid all the bits (apart from start) being high or, worst still, all the bits being low.
$endgroup$
add a comment
|
$begingroup$
It's far simpler to implement a UART transmission in software because you just bit-bang the output port until the bytes are sent. To implement a receiver, you have to do multiple checks on the bits as they arrive (such as waiting for the start bit) and parity checking and usually, you have to run at a much higher processing rate to ensure you can cope with clock speed variations between the remote transmission source and your local receiver.
This latter part is to avoid the misreading of data; a typical receive system will run its clock at approximately 16x the known baud rate and sample the data stream mid-symbol to ensure maximum data integrity. The transmit and receive clocks need to be reasonably similar in case there are few data transitions. Data transitions help re-sync the mid-symbol counter. Below are examples of good similarity in RX-TX clock frequencies followed by a scenario where the receive clock runs much too slow: -
In the latter example you should be able to see that symbol sampling has drifted off to a point where the 4th bit is sampled instead of the 3rd bit. Of course, if there are plenty of bit transitions, the receive clock can be re-synchronized on the fly and this problem is reduced but, with a UART transmission, you cannot avoid all the bits (apart from start) being high or, worst still, all the bits being low.
$endgroup$
add a comment
|
$begingroup$
It's far simpler to implement a UART transmission in software because you just bit-bang the output port until the bytes are sent. To implement a receiver, you have to do multiple checks on the bits as they arrive (such as waiting for the start bit) and parity checking and usually, you have to run at a much higher processing rate to ensure you can cope with clock speed variations between the remote transmission source and your local receiver.
This latter part is to avoid the misreading of data; a typical receive system will run its clock at approximately 16x the known baud rate and sample the data stream mid-symbol to ensure maximum data integrity. The transmit and receive clocks need to be reasonably similar in case there are few data transitions. Data transitions help re-sync the mid-symbol counter. Below are examples of good similarity in RX-TX clock frequencies followed by a scenario where the receive clock runs much too slow: -
In the latter example you should be able to see that symbol sampling has drifted off to a point where the 4th bit is sampled instead of the 3rd bit. Of course, if there are plenty of bit transitions, the receive clock can be re-synchronized on the fly and this problem is reduced but, with a UART transmission, you cannot avoid all the bits (apart from start) being high or, worst still, all the bits being low.
$endgroup$
It's far simpler to implement a UART transmission in software because you just bit-bang the output port until the bytes are sent. To implement a receiver, you have to do multiple checks on the bits as they arrive (such as waiting for the start bit) and parity checking and usually, you have to run at a much higher processing rate to ensure you can cope with clock speed variations between the remote transmission source and your local receiver.
This latter part is to avoid the misreading of data; a typical receive system will run its clock at approximately 16x the known baud rate and sample the data stream mid-symbol to ensure maximum data integrity. The transmit and receive clocks need to be reasonably similar in case there are few data transitions. Data transitions help re-sync the mid-symbol counter. Below are examples of good similarity in RX-TX clock frequencies followed by a scenario where the receive clock runs much too slow: -
In the latter example you should be able to see that symbol sampling has drifted off to a point where the 4th bit is sampled instead of the 3rd bit. Of course, if there are plenty of bit transitions, the receive clock can be re-synchronized on the fly and this problem is reduced but, with a UART transmission, you cannot avoid all the bits (apart from start) being high or, worst still, all the bits being low.
edited Oct 15 at 10:17
answered Oct 14 at 9:28
Andy akaAndy aka
255k11 gold badges197 silver badges453 bronze badges
255k11 gold badges197 silver badges453 bronze badges
add a comment
|
add a comment
|
Thanks for contributing an answer to Electrical Engineering Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
Use MathJax to format equations. MathJax reference.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2felectronics.stackexchange.com%2fquestions%2f462788%2frx-vs-tx-operation-in-software-uart%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
22
$begingroup$
Why just not reuse TX or RX side of hw uart that's not used in other ports?
$endgroup$
– Vlad
Oct 14 at 9:24
$begingroup$
Wowowooo thats a lovely thing. Good, Thumbs UP. If you can make it an answer that would be even better.
$endgroup$
– alt-rose
Oct 14 at 9:32
$begingroup$
It will work if the speeds on TX and RX channels are equal, and it's already a part of the @MichelKeijers answer.
$endgroup$
– Vlad
Oct 14 at 9:37
$begingroup$
There are many STM32 models with 4 (or more) USART's (an USART has an additional optional clock pin; if disabled, it is equivalent to UART). For example, the STM32F072RB has 4 USARTs.
$endgroup$
– Erlkoenig
Oct 16 at 7:35