Sonsivri
 
*
Welcome, Guest. Please login or register.
Did you miss your activation email?
November 26, 2024, 11:46:47 11:46


Login with username, password and session length


Pages: [1]
Print
Author Topic: [Q] Uart Communication Between Two MCU  (Read 5021 times)
0 Members and 1 Guest are viewing this topic.
biomed12
Junior Member
**
Offline Offline

Posts: 94

Thank You
-Given: 67
-Receive: 5


« on: January 20, 2017, 05:37:40 17:37 »

Hello,

I wonder, is there any resistor needed on the uart line? I am using two microcontrollers, one is for filtering and other is for communicating. Generally, the system works good but sometimes, weirdly, doesn't work. It looks like flowing current between MCUs. I directly connected rx, tx and ground pins. I could not fine certain knowledge about it on the www. What is your recommend, will 100k resistors on the rx and tx line solve the problem?

Thanks.
Logged
UncleBog
Active Member
***
Offline Offline

Posts: 133

Thank You
-Given: 165
-Receive: 176


« Reply #1 on: January 20, 2017, 05:59:53 17:59 »

If there is significant current flowing in the UART signals you have a problem that you need to understand, adding resistors will reduce the current but they are unlikely to make your comm's work any better, you may have:

 - Contention, i.e. the microcontroller pins at both ends of a signal are configured as outputs.
 - Tx pin connected to Tx pin.
 - No common ground reference.

I've assumed here that you are using direct logic level signals and not buffering to RS232 levels. None of these suggestions explains why your problem is intermittent so you may have a bad connection somewhere.
Logged
bobcat1
Senior Member
****
Offline Offline

Posts: 304

Thank You
-Given: 4285
-Receive: 94


« Reply #2 on: January 22, 2017, 08:46:20 08:46 »

Hi

You can't connect 2 Tx lines together , you  will need to combine them using a logic gate (use 74HC257- assuming logic signal used) other wise when both transmit can effect each other and consume lot of power

All the best

Bobi
Logged
mars01
V.I.P
Hero Member
*****
Offline Offline

Posts: 537

Thank You
-Given: 697
-Receive: 1774



« Reply #3 on: January 22, 2017, 10:28:16 10:28 »

If you are uncertain about the noise, you can always use buffers (Schmidt triggers maybe?) or isolation (opto?), making sure that the UART speed is not greater than what those buffers can do.

If the only concern is about connecting TX of uC_1 to RX of uC_2 then it depends on the length of the cable. There might be some reflections on the cable so you can use some small resistors in series with the lines, with value like 33 ohms.

If you don't understand about inputs and outputs of UART then while you use UART peripheral:
- RX pin is always configured as INPUT so the pin is in high Z, the current drawn is very very low (CMOS circuitry).
- TX pin is always configured as OUTPUT and the current is limited to the maximum of what the uC pin can source/sink, usually a max of about 25mA.

But because you connect TX from uC_1 with RX from uC_2, the current flowing between the two pins is very very low and amounts to the loses in the input pin (RX).

« Last Edit: January 22, 2017, 08:42:36 20:42 by mars01 » Logged
Gallymimu
Hero Member
*****
Offline Offline

Posts: 704

Thank You
-Given: 152
-Receive: 214


« Reply #4 on: January 22, 2017, 02:47:00 14:47 »

2 microcontrollers, nearby on the same board usually do not require any series, pull up or pull down resistors.

It is always wise to include a pull up or pull down resistor (depending on the UART idle state) so that you don't have unknown behavior at bootup while the pins are still configured as inputs (if that is an issue with you processor).  If you are transmitting off board over a cable.  Some protections or transceivers are a good idea but not required unless your speed exceeds the signal integrity capabilities of your cables (you didn't give us any details in this regard so I will presume you know what you are doing). 

just for some examples to ground yourself:
- bare uart is good for a few feet and a few 10k baud, on board over a few inches up to a few 10s of MHz
- RS232 transceiver is good for a few 10k baud over dozens of feet if not 100.  Shielded cable is wise, twisted pair in this case is worse not better (because it is single ended and increases cross talk)
= RS422/485 is good for a few MHz to 10 or 20 MHz over 100 ft.  twisted pair is a REALLY good idea here.  We used 100' 10MHz over ethernet cable in very high noise industrial environments (i.e. 50KW plasma arcs) and it was very robust.
Logged
CocaCola
Senior Member
****
Offline Offline

Posts: 482

Thank You
-Given: 169
-Receive: 232



« Reply #5 on: January 22, 2017, 06:48:14 18:48 »

- RS232 transceiver is good for a few 10k baud over dozens of feet if not 100.  Shielded cable is wise, twisted pair in this case is worse not better (because it is single ended and increases cross talk)

You can also use ribbon cable with every other conductor being a ground to avoid the cross talk over short distances...
Logged
crunx
Junior Member
**
Offline Offline

Posts: 58

Thank You
-Given: 18
-Receive: 8



« Reply #6 on: January 23, 2017, 08:37:25 20:37 »

Also, a few things to be aware of:
1) The bit rate must be same, and quite accurately so. That is usually easy to achieve when using crystal oscillators. However, if one or both micro-controllers are operated from RC oscillator(s), the frequencies may be a bit too much off for reliable operation. This can be checked easily with an oscilloscope. Just observe and measure bit time in each direction. They should be very much the same.
2) When wiring two boards together, if they have their own power supplies or ground connections, there may be ground currents on the communications ground return. Those can be very nasty, disturbing the data and in some cases could even fry the electronics.
Logged
Sideshow Bob
Cracking Team
Hero Member
****
Offline Offline

Posts: 1002

Thank You
-Given: 231
-Receive: 983



« Reply #7 on: January 23, 2017, 09:23:59 21:23 »

Reading both the OP and the answers. I agree with those who think the problem is that signal with equal nams are connected. As a signal is transmitted in one end it will have to be connected to the receiver pin on the other end. A common mistake done by beginners in serial communication
Logged

I have come here to chew bubblegum and kick ass... and I'm all out of bubblegum
bigtoy
Active Member
***
Offline Offline

Posts: 238

Thank You
-Given: 337
-Receive: 297


« Reply #8 on: January 24, 2017, 05:12:04 05:12 »

Biomed, you said that usually it works, and sometimes it doesn't. That tells me you do indeed have Tx to Rx, because if you had TX to Tx it would simply never work.

Are your two MCUs powered from different power supplies? What happens if you put a voltmeter between the VCC of MCU1 and the VCC of MCU2?  The voltmeter should read zero, or very close to zero. If you're seeing a difference, that's probably going to be bad for one (or both) MCUs.

Putting resistors in the signal lines will reduce the current flow, and hence reduce the chance of damaging the MCUs. But will not help the UART communication. If there's a voltage difference between the two MCUs you don't need resistors, you need isolation. You can use optocouplers if your datarate is slow. An easier solution is to use an isolator IC. For example the Texas Instruments ISO7221.
Logged
zac
Active Member
***
Offline Offline

Posts: 147

Thank You
-Given: 81
-Receive: 57


« Reply #9 on: January 24, 2017, 10:01:38 22:01 »

There should not be significant current flowing in the rx/tx lines.  Have you looked at the signal on a scope? 

Also, are the microcontrollers powered by the same power source?  If not, you may be having problems with current from ground loops.  You can detect that by checking if there is any current flowing through the ground between the the 2 boards. 
Logged
Gallymimu
Hero Member
*****
Offline Offline

Posts: 704

Thank You
-Given: 152
-Receive: 214


« Reply #10 on: January 26, 2017, 06:17:00 18:17 »

Also, a few things to be aware of:
1) The bit rate must be same, and quite accurately so. That is usually easy to achieve when using crystal oscillators. However, if one or both micro-controllers are operated from RC oscillator(s), the frequencies may be a bit too much off for reliable operation. This can be checked easily with an oscilloscope. Just observe and measure bit time in each direction. They should be very much the same.
2) When wiring two boards together, if they have their own power supplies or ground connections, there may be ground currents on the communications ground return. Those can be very nasty, disturbing the data and in some cases could even fry the electronics.

I believe the RS232/UART spec is 2% total freq error is tolerable.  Surprisingly a lot of internal oscillators are getting pretty good.  BUT, I'd always use a crystal when doing async communication as a best practice
Logged
biomed12
Junior Member
**
Offline Offline

Posts: 94

Thank You
-Given: 67
-Receive: 5


« Reply #11 on: January 26, 2017, 10:39:21 22:39 »

Thanks all members. I have written down all of suggestions and I ruined all of the pcb and I will design it again. I will try and write here the results, maybe one of these controllers have retired. Because, after I ruined the pcb layout, I realized that while I was trying to set all of circuit on breadboards, the controller looks like working unstable. I programmed it many many times until now, maybe it dont want to be programmed no longer.

I have one more question, I won't open a new topic.

I am designing some digital filters, some members maybe remember my beginner questions. As you know, many times developers use a timer to trigger adc, which has a value that equals sampling period. In some filter projects, I saw that, samples are being processed group by group. For example, one developer had got 32 sample and processed it and pushed out. An other had used 128 sample every interval. Also I am processing samples one by one. Get one sample, process it and push it result to dac or other terminals. So, is there any special reason for these methos or just a preference?
« Last Edit: January 26, 2017, 10:42:00 22:42 by biomed12 » Logged
mars01
V.I.P
Hero Member
*****
Offline Offline

Posts: 537

Thank You
-Given: 697
-Receive: 1774



« Reply #12 on: January 26, 2017, 11:19:32 23:19 »

If those developers used DMA in conjunction with ADC's then it will make sense to acquire more samples in batch.
Logged
Gallymimu
Hero Member
*****
Offline Offline

Posts: 704

Thank You
-Given: 152
-Receive: 214


« Reply #13 on: January 28, 2017, 03:01:00 03:01 »

I am going to make a gross generalization so correct me if there are good reasons for the other approach, but:

Real DSP is done sample by sample, or at least with a sliding window.  chunk by chunk works in many cases but is often less sophisticated, presents discontinuities in the performance and frequency response, and is less conducive to analysis in the Z domain.  

-edit-

this isn't to say that burst capture of ADC data isn't useful, and it can safe you processor time, but the burst should still be processed in terms of DSP in a sample by sample basis.

« Last Edit: January 28, 2017, 09:29:32 09:29 by Gallymimu » Logged
Sideshow Bob
Cracking Team
Hero Member
****
Offline Offline

Posts: 1002

Thank You
-Given: 231
-Receive: 983



« Reply #14 on: January 28, 2017, 09:07:37 09:07 »

A method I often have used is oversampling(Google is your friend) This is an example there samples are processed group by group. It also seems you have missed an important point. If I remember correct you have a digital filter in your system. No matter what kind of filter you use. Your filter process a group of samples Cool. Another aspect is if your ADC system have a FIFO or not. If your ADC only is double buffered. You have to precess each sample as soon it is ready. So it is not overwritten by the one in process
Logged

I have come here to chew bubblegum and kick ass... and I'm all out of bubblegum
Gallymimu
Hero Member
*****
Offline Offline

Posts: 704

Thank You
-Given: 152
-Receive: 214


« Reply #15 on: January 28, 2017, 09:33:49 09:33 »

A method I often have used is oversampling(Google is your friend) This is an example there samples are processed group by group. It also seems you have missed an important point. If I remember correct you have a digital filter in your system. No matter what kind of filter you use. Your filter process a group of samples Cool. Another aspect is if your ADC system have a FIFO or not. If your ADC only is double buffered. You have to precess each sample as soon it is ready. So it is not overwritten by the one in process

that's a good point: oversampling.  I'd consider most oversampling to be a pre-processing step to feeding the digital filters in many cases i.e. if you end up just averaging, or bit shifting 8x 16x or 32x samples prior to DSP.

Often oversampling can remove the need for such sharp low pass filters/aliasing filters
Logged
Pages: [1]
Print
Jump to:  


DISCLAIMER
WE DONT HOST ANY ILLEGAL FILES ON THE SERVER
USE CONTACT US TO REPORT ILLEGAL FILES
ADMINISTRATORS CANNOT BE HELD RESPONSIBLE FOR USERS POSTS AND LINKS

... Copyright © 2003-2999 Sonsivri.to ...
Powered by SMF 1.1.18 | SMF © 2006-2009, Simple Machines LLC | HarzeM Dilber MC