RS485 Communication between ATMEGA128 and ATMEGA8A

Go To Last Post
23 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

 

I am trying to establish RS485 communication between ATMEGA128 and ATMEGA8A using RS485. I have written code for both the controllers to communicate with each other but i am facing issue that after some time ATMEGA8A is not receiving data from ATMEGA128

 

My ATMEGA128 Code. please give your suggetions

 

 

void RS485Slave(){

   TransmitCharecterSlave(1);

   SlaveACK=ReceiveCharecterSlave();

   if(SlaveACK == 0x01){

   FireDetect = ReceiveCharecterSlave();

   FaultDetect = ReceiveCharecterSlave();

   if(FireDetect == SlaveFireDetect){

      PORTE &= (~(1<<FIRE)); // switch ON status LED

      PORTB |= (1<<BZR); // Switch on Buzzer

      FireDetectAlert(SlaveAddress); // Display Fire zone with details

      TransmitCharecter(SlaveFireDetect); // Send fire Detect Condition to repeater

      FireFaultStatusToReapeter(); // send whole display screen to repeater

 }

 

}

void TransmitCharecterSlave(char SlaveData){

PORTE |= (1<<RXE0) | (1<<TXE0);

while(!(UCSR0A&(1<<UDRE0)));

UDR0=SlaveData;

}

char ReceiveCharecterSlave(){

char ch=0,temp=0;

_delay_ms(1);

if((UCSR0A & (1<<RXC0)) == 0x80)

ch=UDR0;

return ch;

}

 

Code for ATMEGA8A (Only Communication routine)

 

 

PORTD &= (~(1<<DE)); // Enable Reception and disable transmission

SlaveAddress=RS485Receive();

if(SlaveAddress == PINB){

  PORTD |= (1<<DE); // Enable Transmission and disable reception

  PORTD &= 0xEC; // switch on OPEN LED

  RS485Transmit(SlavePositiveACK);

  RS485Transmit(SlaveFireDetect);

  RS485Transmit(SlaveFaultDetect);

  SlaveFaultDetect=0;

  SlaveFireDetect=0;

}

 

Last Edited: Wed. Dec 13, 2017 - 04:17 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What are you using for the CPU clocks on the two units?

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

Hi Jim,

Thanks for the reply.

I am using 1MHz internal clock for both the controller

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

Since you are calling out Mega128 and Mega8a I will move this to the Mega forum.

 

shindehari32 wrote:
I am using 1MHz internal clock for both the controller

NOT A GOOD IDEA!

 

What baud rate?

 

East Coast Jim

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

Please Read: Code-of-Conduct

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

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

Baud rate: 9600
Stop bit: 1
Start bit: none
Data bits: 8
Party : none

May I please ask, why using 1MHz is not good idea

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

Refer to the datasheet regarding your choice of baud rate and clock - the error is significant. However, both your devices will have the same error, not withstanding that the internal oscillator is not accurate. Do yourself a favour and add crystals to the devices.
In order to minimise the number of potential problems, wire the txd/rxd from device to device - rule out any problems introduced by RS485 and the associated circuitry.
Also be aware that you need to clear the M103 fuse on the mega128, otherwise your code wont run properly. Again, refer to the datasheet.

Once you’ve sorted the easy problems out, then you need to look at how you send the data via RS485. You need a methos of framing your data in order to be able to detect the start, length and error check your data. Otherwise your system will be highly unreliable. There are plenty of examples of protocols - modbus, snap, bacnet etc

Last Edited: Wed. Dec 13, 2017 - 07:46 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for reply.

I will follow your suggestion and get back to you soon about the results

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

sorry for delay in reply.

the problem has been resolved.

as per your suggestion i have tested the rs232 master slave communication without RS 485 driver and it is working fine. after this test i started debugging the RS485 and i found that the problem is in software part. i have to give delay of 1ms after transmitting from master to slave and also delay of 1ms after transmotting ack from slave to master. in short for rs485 communication i have to add 1 ms of delay after each charecter transmission in case i want to immediatly do the receiving action. i was not able to find out why this delay is required in case of RS485 communication.
plz reply why this is happening incase of RS485 Communication.

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

shindehari32 wrote:
i was not able to find out why this delay is required in case of RS485 communication.

??? 

shindehari32 wrote:
RS485Transmit(

You didn't show that routine.

 

You don't show the handling of the transmit-enable for your RS485 driver.  The 1<<DE >>might<< be the transmit-enable, but we don't see the definitions, nor do I see anywhere where TE is cleared.

 

Chances are that you are not waiting for the transmission to complete (USART TXC bit set) before you are clearing TE.  A delay can also be effective, but certainly is crude IMO.  (but than there are those that swear by using delays in HD447680 drivers instead of polling the ready bit.  probably a good chance that some of those will chime in here voting for using TXC versus delay)

 

 

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

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

shindehari32 wrote:
i want to immediatly do the receiving action. i was not able to find out why this delay is required in case of RS485 communication.

I had this happen to me once...

 

Lee Hit the nail on the head with the answer:

theusch wrote:
Chances are that you are not waiting for the transmission to complete (USART TXC bit set) before you are clearing TE.

In my case I was watching the UDRE bit as opposed to the TXC bit.  This meant that I was de-asserting the TE bit thinking the transmitter was done, but in fact it only meant the Data register was empty, UDRE does not provide the status of the USART shift register.  Hence I was slicing off the last transmitted byte.

 

As lee mentions, show your transmit routine.  You should not have to have a 1ms delay between every byte

 

JIm

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

Please Read: Code-of-Conduct

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

Last Edited: Sat. Jan 6, 2018 - 04:26 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There is no need of a 1ms delay for RS485.

That delay is probably just masquerading some software bug in your code.

I've done 115k2 baud over rs485 with avr's running on a clock as low as 1.84MHz.

That was about as much as an AVR can handle, but it had a quite big firmware overhead.

For a more robust design I decided to have some extra margin and not go below a frequency of 3.6864MHz for 115k2.

 

In my design the cpu overhead is about 200 cpu cycles per received byte (less for sending).

You can extapolate the minimum delay between "packets" from that.

 

So to dispose of the bug in your software follow the path between the last byte send and preparing the uC for receiving data.

 

Adding a Logic analyser (USD 7 from Ali / Ebay, search for "24m 8ch") helps a lot in detterminging if the fault is with "sending" or "receiving".

Timing for the RS485 enable is also important.

The fastest way to release the RS485 enable is to do it in the "transmission Complete" interrupt.

 

I also want to advise against using internal rc oscillators for uart communication. Especially if the tolerance is > 1%.

You might get it working, but it's not reliable and likely to generate intermittent problems.

If the RC oscillator is better than 1% (over a decent temperature range) it's probably good enough.

But even then I advise to use a crystal during development just to make the list shorter of "what goes wrong now?" during software development.

Paul van der Hoeven.
Bunch of old projects with AVR's:
http://www.hoevendesign.com