MAX485 Transceiver problem RS-485

Go To Last Post
72 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hello forum i have a problem similar to this hread here https://www.avrfreaks.net/forum/m... , i'm now applying my code to proteus simulation i have 2 atmegas communicating over 2 MAX , one at each end , the proteus shows 15k+ warnings of frame errors (find it attached below) , i have tried to add some delays before and after (10 ms) , the code works tho , the data is transmitted and displayed on the LCD but with 15k+ warnings of framing errors , i want to solve this problm before i go to the next step of connecting the RPi to the RS-485 network .

 

things to note that when i put 4 max485 ( 2 at each end , FULL duplex ) one is grounded the other is 5v connected , the system goes as it's supposed to do without an warnings .

 

here is the code of max485 h file & .c file 

 

.c

#define SET_MAX(a,b) ( (a) |=  (1 << (b) ) )
#define CLR_MAX(a,b) ( (a) &= ~(1 << (b) ) )  

void max485_init(void)
{
	MAX_DDR = (1<<MAX_PIN);
	CLR_MAX (MAX_PORT,MAX_PIN); // clearing to enable receiver .
	return ;	
}

void max_Recv(void)
{
	CLR_MAX(MAX_PORT,MAX_PIN);
	return;
}

void max_Trans(void)
{
	SET_MAX(MAX_PORT,MAX_PIN);
	return;
}

 .h

#include "StdTypes.h"

#define MAX_DDR  DDRE
#define MAX_PORT PORTE
#define MAX_PIN  PINE2

void max485_init(void);
void max_Recv(void);
void max_Trans(void);

 

and here is sample of the code when it tries to transmit 

	while (!(is_RBuf_empty(&Resp_RB)))
	{
		
		u8 arr[7];
		Get_Resp_Packet(arr);
	
		max_Trans();
		_delay_ms(10);
		
		UART0_vidTransmitString(arr);
	
		_delay_ms(10);	
		max_Recv();		
	}
	return ;

so what do you think i should do :)

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You have many potential problems-
1. You need a pullup resistor on pin 1 of the max485. This pin is not driven when transmitting, so the resistor ensures the correct logic level. 10k would be ok.

2. Do you handle the usart TXC bit correctly. You shouldn't need enable and disable delays.
3. In a real 485 system, you may need bus bias and termination resistors. I posted a link describing this in great detail in the previous thread.

4. Pulldown resistor on pin 2/3 of max485 to ensure the device defaults to rx when the cpu is in power-up.

Last Edited: Fri. Feb 3, 2017 - 11:00 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
4. Pulldown resistor on pin 3/4 of max485 to ensure the device defaults to rx when the cpu is in power-up.

Wouldnt that be on pins 2/3?

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jim - correctamundo. Fixed.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
Do you handle the usart TXC bit correctly. You shouldn't need enable and disable delays.
mm :D , could you further explain what do you mean how to handle TXC ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You've not shown your transmit code. Read the avr datasheet regarding the usart transmit complete bit.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
You've not shown your transmit code.
i didn't thought it would matter , but here it is

void UART0_vidTransmitByte(u8 u8Byte)
{
	while((UCSR0A & (1<<UDRE0)) == 0x00);
	UDR0 = u8Byte;
}

void UART0_vidTransmitString(u8 u8String[])
{
	u8 i = 0;
	//max_Trans();
	
	while(u8String[i] != 0)
	{
		UART0_vidTransmitByte(u8String[i]);
		i++;
	}
	UART0_vidTransmitByte(u8String[i]);
	//max_Recv();
}

note i use polling , but in RX i use interrupts , i didn't feel that it i'd need an interrupt TX .

here is the init code also 

void UART0_vidInit(void)
{
	//u8 u8Ucsz2;
	u16 u16Ubrr;
	u16Ubrr = lrint(((F_CPU/16)/(InitConfig.u32BaudRate))-1);
	
	//u8Ucsz2 = (InitConfig.u8CharSize & (1<<3)) >> 1;
	UCSR0B =0x00;
	UCSR0C = 0x80;
	UCSR0C |= 0x80 | ((InitConfig.u8CharSize)&~(1<<3)) | (InitConfig.u8Parity) | (InitConfig.u8StopBit);
	UBRR0L = (u8) u16Ubrr;
	UBRR0H = (u8) (u16Ubrr >> 8);
	UCSR0B |= (1<<TXEN0) | (1<<RXEN0) ;
	UCSR0B |= (1<<RXCIE0);
	
	sei();
	
}

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

here is the modified circuit , still same probs 

also is this the thread you are talking about ? https://www.avrfreaks.net/forum/r...

 

here is a quote : 

while( ( USART_CONTROL_STATUS_REGISTER_A & ( 1<<TXC ) ) == 0 ) ;

 

 

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was referring to your previous thread regarding the max488.
You have a virtual oscilloscope, so use that to aid your diagnosis.
I gather you've checked the obvious things like clock speed, fuses etc? Also simple tests like connecting rx to tx without the max485s

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

i'm done with the 488 not suitable for my application .

 

i'v now a simple program , 2 ATMEGAS128 communicating  ( i'm still simulating on proteus ) .

 

here is the code of transmitter 

UART.C

// ********************************** UART transmit Byte (polling) *******************************
void UART0_vidTransmitByte(u8 u8Byte)
{
	max_Trans();
	while((UCSR0A & (1<<UDRE0)) == 0x00);
	UDR0 = u8Byte;
	max_Recv();
	
}
MAIN

	max485_init();
	UART0_vidInit();
	DDRD = 0xFF ;
	PORTB&=~0xFF;
    while(1)
    {
		u8 BYTE = 0x01 ;
		UART0_vidTransmitByte(BYTE);
		_delay_ms(100);
	
    }

and the receiver just blink an led when it receives a the byte (0x01) , i uploaded the proteus conections . i tried to follow this post https://www.avrfreaks.net/forum/r... but all i've got was fail , fail & fail .

 

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
obvious things like clock speed, fuses etc? Also simple tests like connecting rx to tx without the max485s
 yes already tried this and doubled hecked every thing is ok , the program runs fine without any errors if done with 2 max485 chips full duplex , i can go with this but i'm sure there is a way to do it properly with just one , specially because my real application is a half duplex , one mega is talking at a time.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Try this first, Get rid of the MAX48x chips. 

 

Second connect the TX pin of one AVR to the others RX pin

 

Third is to do the same with the others TX pin and connect it to the firsts RX pin

 

See if you get comms with this setup.  If you do then you have solved one big piece of the puzzle.

 

Once you have that working THEN introduce the MAX 48x IC's and go from there

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

already done this and working , the problem is that i cant get communication with 2 max485 ( one at each end ) lots of fram errors , but i can do it with 4 ( 2 at each end ) .... attached below , working as expected .  i just want to solve this issue before i buy max chips .  is this a HW or SW issue 

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You have the tools to diagnose the problem. Hardware or software? It could be both.
Put a virtual scope on the transmit side and another on the receive side. How do the waveforms differ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Messiry wrote:
is this a HW or SW issue

more software than hardware.  Where is the code that controls the T/R pins on the MAX485's?  I bet if you connect a logic analyser to the two data lines and the control it's a timing issue.  Gets you EVERY time

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Messiry wrote:
#define MAX_DDR DDRE #define MAX_PORT PORTE #define MAX_PIN PINE2

 

 

I think this is your problem....You defined MAX_PIN as PINE2.  That pin needs to be an output and must be driven.  If you are configuring it as an input(I think you are) then you are most likely turning the pull up resistor on and off and in reality the pin either gets pulled up to Vcc, or is floats and never goes truly low.

 

Just a thought

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jim PINE2 just equals 2. It looks like he uses the portb register so all should be good.
Again, a few minutes with the virtual scope would uncover the problems.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ok so here is the scope scr shot from proteus , i connected the scope to a & b , the transmitter are on the right , receiver on the left , it seems that the transmitter is ok but the receiving side is flat no changes detected that means there is a HW problem so here are my connections again .

 

the warnings are continuous stream of frame errors at receiving side

Attachment(s): 

Last Edited: Sat. Feb 4, 2017 - 12:41 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jim as kartman says , the PORTD are definedbut not used , it exists becaus that was a copy from other program , here is my max init code 

#include "MAX485.h"
#define SET_MAX(a,b) ( (a) |=  (1 << (b) ) )
#define CLR_MAX(a,b) ( (a) &= ~(1 << (b) ) )  

void max485_init(void)
{
	MAX_DDR = (1<<MAX_PIN);
	CLR_MAX (MAX_PORT,MAX_PIN); // clearing to enable receiver .
	return ;	
}

void max_Recv(void)
{
	CLR_MAX(MAX_PORT,MAX_PIN);
	return;
}

void max_Trans(void)
{
	SET_MAX(MAX_PORT,MAX_PIN);
	return;
}

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'd suggest you start to think a bit more about how to solve your problem. Your screenshot of the oscilloscope suggests there is a problem, so why have you not investigated more? It only takes minutes to setup a test, so what have you tested? What evidence have you harvested?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

i really tried to solve it on my own but i've been trying for the past 2 days and it's frustrating really , i grounded the receiver max  and 5v to transmitter  max ( pine 2 not conected ) it didn't show anything either , so i took out the 560 resistors and it worked but note " the receiver is grounded & transmitter is connected to 5 v " .

 

so the next test was to connect the PINE2 , so i did , and the signal on the transmitter side went off again so it got to be the PINE2 making the problem , but it's a straight forward code , enable max , send byte , disable max .

 

the next test was to connect the PINE2 pin on both sides , so i enabled the transmitter side and never made it a slave , and receiver side disabling the max , and it worked as expected 

 

 

so conclusion is 560 resistors aren't helping  , the PINE is working properly , my gut feeling it's a delay matter  between enabling and disabling  

 

[EDIT] i made another test giving 20 ms delay after enabling , and another 20 ms delay before disabling , XXXX it worked XXXX [EDIT] ( not working ) delay is not helping either but it made fram errors increase slowly 

 

Attachment(s): 

Last Edited: Sat. Feb 4, 2017 - 02:33 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The problem is not your hardware. It's how your software handles the control pin, i.e. The delay. You should watch the UDRE flag on the tansmit side and when it hits then flip the control pin. On the recieve side you use the interrupt and based on your protocol flip the control pin accordingly

Very straight forward stuff

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

there is an error in my prev post , it's not working when i put delay 20ms when connecting PINE2 ,  but , the frame error warning is increasing slowly , meaning if i increase delay before disabling the transmitter the frame error messages decrease ,and vice versa .

but it works when enabling transmitter & disabling receiver permenantly .

 

note this also when i connected 5v to transmitter side ,  the signal are the same on both sides ( first photo attached represent this case ) 

when i connect PINE2 & 20 ms delay  the signal differs and giving me frame errors (2nd photo attached ) 

 

so my question got to be , are it supposed to be atleast one transmitter on the bus ??? or let me say it in a different form , is it supposed that atleast one max is enabled and other are disabled ?

 

[EDIT-1] the fram error occurs when i'm disabling the transmitter (3rd  attached photo below ) as i said , when i'm enabling the transmitter that 20ms delay there are no frame errors only when the delay is finished , boom fram errors start to add up again till the next byte is sent 

 

[EDIT-2} when disabling both sides nothing happens , which is expected :D:D , so this means that it's possible to have devices on bus listening 

Attachment(s): 

Last Edited: Sat. Feb 4, 2017 - 02:42 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thats the whole point of RS485. Many devices sit on the bus and listen for the host calling them. But thats not something you need to think about at the moment as you cannot get two units working

Your screenshots say mega128. Is that the real AVR you are using in the actual setup?

I am a little confused if you are doing all of this in Proteus or on actual hardware.

Help me out on that at least.

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

i'm working on proteus simulation not in real HW phase yet  . but lets take a minute to understand this point of 

jgmdesign wrote:
Many devices sit on the bus and listen for the host calling them
 

 

i'm having a Pi working as master ( simulated by an MCU 128  doing the same code of Pi , at this point the systems works great having all the tx of slaves conected to RX of master and tx of master connected to all the rx of the slave MCUs   )  

 

the application protocol i wrote was :

all devices are listening on the bus even the Master , if master receives an order from server , it sends stop transmission messages broadcast , then send the order to the requested slave , then slave responds with an ACK , then every thing goes back to normal every one is listening ...

then lets say temperature change , or fire was detected , the slave sends a request to the master , the master send stop transmission to all slaves , then allow transmission for the slave who requested to use the bus 

 

this is why i need the bus to be free , the advantage is that i can go to pwr save if there is no data to be sent or orders to be excuted and the bus remains free , the temperature doesn't often change so why loop every 30 secs on all the slaves , why not let the slave request . 

 

so i made a simulation of this system with max488 bus and it worked on simulation , but failed in reality , here is my post https://www.avrfreaks.net/forum/m... it showed that max488 only takes 2 transceivers because there are no DE pin , so i went for the max485 ( 487 in proteus) and now i'm having all kinds of troubles :D 

so any idea how to make a bus that takes all of my slaves and serve my purpose , i'm at this point of being desperate  :D :D 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Messiry wrote:
so what do you think i should do :)

 

 

 

jgmdesign wrote:
You should watch the UDRE flag on the tansmit side and when it hits then flip the control pin.

NO!  Not UDRE -- that is the source of the problem.  You need to watch TXC.  Often discussed here; hunt out other threads.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
Not UDRE -- that is the source of the problem.  You need to watch TXC
you mean like this ? 

void UART0_vidTransmitByte(u8 u8Byte)
{
	UCSR0A |= (1<<TXC0) ;
	//max_Trans();
	while((UCSR0A & (1<<UDRE0)) == 0x00);
	UDR0 = u8Byte;

	while( ( UCSR0A & ( 1<<TXC0 ) ) == 0 ) ;

}

or like this 

void UART0_vidTransmitByte(u8 u8Byte)
{
	UCSR0A |= (1<<TXC0) ;
	//max_Trans();
	while( ( UCSR0A & ( 1<<TXC0 ) ) == 0 ) ;
	UDR0 = u8Byte;

}

my actuall transmit byte code is this 

void UART0_vidTransmitByte(u8 u8Byte)
{

	while((UCSR0A & (1<<UDRE0)) == 0x00);
	UDR0 = u8Byte;

}

 

Last Edited: Sat. Feb 4, 2017 - 03:24 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am a little confused if you are doing all of this in Proteus or on actual hardware.

Help me out on that at least.

It's all in Proteus, so the problem can be any number of things. It's just a guessing game at this point.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I know little about RS485 but I think I know enough to say that when you transmit you need to monitor TXC until it says the very last bit has been shifted out (this is why you don't use UDRE) and then you switch the direction so the AVR is then ready to receive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Messiry wrote:
you mean like this ?

Neither.

 

theusch wrote:
Often discussed here; hunt out other threads.

167 hits for site search "rs485 txc".  A very recent https://www.avrfreaks.net/forum/u... discusses your very issue.  You will need to read all the responses until it finally sunk in.

 

A mere mention https://www.avrfreaks.net/comment...

 

Another directly pertinent:  https://www.avrfreaks.net/comment...

 

Addressing RS485 framing errors:  https://www.avrfreaks.net/forum/r...

 

With a sample of my usual RS485 code:  https://www.avrfreaks.net/forum/a...

 

Directly pertinent:  https://www.avrfreaks.net/forum/u...

 

Above from the past 6 months or so.  Many more earlier hits as well.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Messiry - you're going around in circles as your debugging technique is not very scientific. You oscilloscope pictures tell us very little as you've chosen poor horizontal settings - had you set it so you can clearly see one byte transmitted and be able to see each bit, then the problem would be obvious.
You've repeatedly ignored me and others telling you about the importance of the TXC bit and it seems you have not read the datasheet regarding this.
Another problem will become apparent when you use the raspi - it will most likely have timing issues controlling the 485 direction. I've previously suggested you use something like a ftdi232 chip as it has hardware to do this - precisely with no software intervention. I've also suggested a means where you do not even need to use 485 at all.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

i posted multi scr shots , but here is one representing one byte , regarding the ft232 ( Not available in egypt ) , i don't need 485 ok i can live with that , what do you suggest instead 232 ? direct tx rx connections ? , i have not ignored your TXC talk , i'm doing it wrong , here is my last update to the transmitting byte code 

void UART0_vidTransmitByte(u8 u8Byte)
{
	max_Trans();enabling max 

         while((UCSR0A & (1<<UDRE0)) == 0x00);
	UDR0 = u8Byte;

        while(!(UCSR0A & (1<<TXC0)));//waiting for TXC flag
	UCSR0A |= 1<<TXC0 ; // clearing TXC0 flag 

        max_Recv();disabling max 

note that in forever loop i transmit 1 byte only which is  0x01 , 

 

thank you for your patience i'm still a student trying to figure out , but actually you made me very anxious about Pi would still have timing issues :S :S  

Attachment(s): 

Last Edited: Sat. Feb 4, 2017 - 05:47 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

so one last question before i give hope , have anyone of you guys made an rs485 NW and worked as it supposed to ?? just wondering 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Messiry wrote:

... have anyone of you guys made an rs485 NW and worked as it supposed to ??

 

Yes...

 

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Would you please identify the main problem ? Am i handling the TXC wrong ?? ??

Last Edited: Sat. Feb 4, 2017 - 06:51 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:

Messiry wrote:
so what do you think i should do :)

 

 

 

jgmdesign wrote:
You should watch the UDRE flag on the tansmit side and when it hits then flip the control pin.

NO!  Not UDRE -- that is the source of the problem.  You need to watch TXC.  Often discussed here; hunt out other threads.

 

clawson wrote:
I know enough to say that when you transmit you need to monitor TXC until it says the very last bit has been shifted out (this is why you don't use UDRE) and then you switch the direction so the AVR is then ready to receive.

 

CORRECT!! Sorry about that. 

 

Messiry wrote:
so one last question before i give hope , have anyone of you guys made an rs485 NW and worked as it supposed to ?? just wondering

 

YES here is one of mine:

http://www.broadteq.com/

 

 

 

Messiry wrote:
thank you for your patience i'm still a student trying to figure out , but actually you made me very anxious about Pi would still have timing issues :S :S

POSSIBLY.  One of my colleagues has been using a Beagle Bone on a design and he could not get the RS485 to work properly.  It turned out that The Bone had issues flipping the control line, and there was online talk about the problem as well.  We came up with a fix, but it was not the ideal solution.  The Pi might be different though. 

 

Thats the least of your issues though.  Getting your simulation to work is first. 

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Messiry wrote:
Would you please identify the main problem ? Am i handling the TXC wrong ?? ??

 

ZIP UP your project code and post it here.  Looking at little chunks of it here and there is a waste of our time....and yours

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@ Brian Fairchild

 

Did your RS485 boards blow up?? surprise wink

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yeah and tickets were sold for the event too! devil

Ross McKenzie ValuSoft Melbourne Australia

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have used RS485 and the max490 for years on the pipe organ projects.  I think my versions date back to 2012.  The existing hardware that was 8051 based went back to the 1990s.  I do not think there is much of the 1990s stuff left other than the Max490.

 

@BrianFairchild's photo above is not unlike the theater my stuff is installed in.   We are currently running the Pipe organ data over XLR 3 pin shielded  microphone cables.  500000 baud 9 bit MPM bit banged on the host with some 200+ foot runs between the organ console and the pipe chambers.   I do use pull-ups where needed and have active RC jumper enabled termination when appropriate.  I am running the system as a master slave network, which each slave has it's own address,  The communication is one way with no feedback to the master.  (well the in console Keyboards also run under RS485 but that is done in SPI mode, letting the RS485 buffer the SPI data)  MIDI is way too slow for a Real Pipe organ with thousands of pipes controlled by hundreds of keys.   Professional systems have delays between 5 and 25 nanoseconds.  MIDI takes about a millisecond to transfer a note.   At any given time to get that full pipe organ sound 50 or more pipes are sounding at once.  We are talking the full ochestra.  Most synths max out at 3 or 4 voices to create a single chord, which is fine for electronic music that will be mixed up into backing tracks.

 

RS485 is also what the 1984 macs called a serial port.  The RS232 just ran over half of it.  The network version was called Appletalk, which later got it's own IP layer.

 

I think DMX is also RS485 based which controls the lighting in most theaters.  That means there is a controller on each lighting instrument in @BrianFairchild's photo.

 

There seems to be a lot of confusion between the hardware layers and the data protocols that run on top of them.  RS485 is just a hardware layer not unlike Ethernet.  You could Run TCP/IP on the RS485 hardware if so inclined. (Or vice versa.)   The packets and ports are what make things talk to one another.  These really only exist in software.  As I noted I run SPI through the Max490s. 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

here is a simple project of a loopback and flashing an led , it's working but with 15k warnings and frame errors

 

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have a number of RS485 busses running Modbus up at the gas plant at Idku. Most of the nodes are mega128 based. Has been working since 2005. I have many wonderful memories of that trip.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

nice memories ,they don't seem  nice to me , right now i'm making bad memories :D

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Messiry wrote:
nice memories ,they don't seem nice to me , right now i'm making bad memories :D

 

I opened the zip file, then closed it when I saw all the .c files for things....I'll look at it later after I digest dinner.

 

In the meantime maybe someone else will have a go at it.

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Messiry - most of us do not have a proteus licence and very few of us have ever used it. However it does seem popular in the former british colonies.
Here's how i would've debugged the problem-
Scope the tx, direction and the positive rs485 bus. Send a value that has a few bit changes in it like 0x55 or 0xaa. Set the scope settings so you can see one byte clearly - you should be able to verify the actual calue being sent. You should also see the relationship between the data being sent and the direction and what is actually going out onto the bus. If there is problems with the timing of the direction pin - you will see it here.

Once you've got the sending sorted out, then look at the receive side. Scope the rs485 bus and the rx signal. By now you should know what the data should look like. If the bus is not biased correctly, you may see glitches or the rx signal going low when it should be high.
All these tests are easy to perform in proteus. The process learned here can be applied to the real hardware.
As for the raspi doing rs485 - i did a quick google and there was a lot of noise - i didn't find anything concrete that stated exactly how it works. The core problem is the timing of the rs485 direction. Most of the usb to serial chips can handle this - ch340, pl2302, ftdi232. Again, you now have the techniques to identify the problem - how to use the oscilloscope. If you don't have a real oscilloscope, you can use the soundcard of your PC as a crude scope.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

GUYSSSSSSSSSS, i solved it i will upload it shortly 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

so my code was not the problem :) the connections were , i saw this thread http://www.gammon.com.au/forum/?... , and there you go ( scr1 attached was the answer to all of my misery )  the 120 ohm resistor was causing trouble and i have no idea how or why :D 

here are my scope on the transmitter side tx and recv side rx matching and between there is the enable pin 

 

FINALLY i can have some rest , but don't go any where guys , tomorrow real HW begins :D , thank you is not enough the reason that i'm desperate is that the SW is working properly and today i tested one micro with the RPi and every thing is uploading correctly , my next step is to make this code with other atmega . this is my graduation project and the deadline is in 2 weeks :D the last task is the bus .

Attachment(s): 

Last Edited: Sun. Feb 5, 2017 - 12:58 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What you don't understand will come back and bite you at some stage. Assuming you put the biasing resistors the right value and the correct value AND you put in the termination resistors - does the simulation work? If not, then there is probably an issue with how Proteus simulates the rs485 bus. The r485 bus spec states >200mV is a valid logic state. Do the math on the resistors and do you get this? Get the bias resistors biasing the wrong way, and the receiver will see a 'break' condition rather than an 'idle' condition. A break condition will be registered as a framing error. Logical process would've identified these problems early.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I use Rs485 with AVR devices for a long time. One problem that is tricky is that the bus goes to tristate after a transmission to allow other devices to respond messages. When some device starts the transmission it activates the driver before sending the start bit. At the moment the driver has transmission enabled , depending on the bus characteristics, chips used and terminations and pull-ups/ pull-downs , ground connections between the devices, it may appear a glitch at the bus that triggers a false start bit detection. This false start bit detection disrupt the sincronism of the serial communication. At least the first byte may be lost. This false trigger may occur when the bus is in tri state because no device is transmitting. A noise may start many receivers to try to detect a valid packet. If someone starts the transmission in sequence, this new packet may be lost.
The chips Usart checks if the start bit is valid, sampling again around the middle of the start bit. This eliminates the glitch, but also may take out of sinc with the real packet that comes along.
A solution for dealing with the problem is to delay the start of transmission of the start bit of the first byte of the packet 2 bit time slots. If the glitch occurs when the driver is activated, the usart of the receivers will filter it out and reset the usart receive state in time to wait for another real start bit. But now the driver is fully activated and the following start bit will be detected correctly. All other bytes of the packet will be ok because the driver is not released until the final of the last stop bit is finished. Of course , as said before in this topic, the microcontroller should use the correct interruption signal to release after the stop bit final.

Eng.Marco Aurélio Carvalho

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Termination resistors are important to avoid signal reflexions at high bit rate and long cables. But they also degenerates signals levels. So for short cables or data low data rates (let's say 9600~57600bps) signal reflexions ringing stabilize before usart samples at middle of the bit. In this case termination resistors does not help. But the glitch from activation of the tx driver may be frequently present , disturbing the communication. Pull-up / pull down resistors may atenuante the glitch and become more effective. Connecting the Vss/0V/Gnd of the rs485 drivers between devices also helps, but demand more wires. At least a third wire. The ground connection between devices also helps a lot to avoid chip damages when the devices are far away from each other and a lightening stroke occurs.

Eng.Marco Aurélio Carvalho

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Another issue that need some care is the receive signal line after transmitting a byte. In my projects I also listen to bytes that are being transmitted as clue to see if there was no collision with another transmition. So, the RE signal in my projects are all time in active state.
Purge the receive buffer before entering a SW state of analyzing receive data. So, any unexpected data will be disregarded and only data received at expected timing will be accepted. This is packet timing sync. In previous post I wrote about start bit/byte sync.

Eng.Marco Aurélio Carvalho

Pages