next topic »

[on:]

Hello all.  I have a program that works correctly on my Arduino UNO but when I upload the program to my MEGA2560 it does not function properly. 

Here is my code....

Code:

#include <SimpleTimer.h>
#include <SoftwareSerial.h>
SoftwareSerial mySerial(2, 3); // RX, TX
int DIR = 7;
word incoming=0;
SimpleTimer timer;

void setup()
{
  digitalWrite(DIR, LOW);
  pinMode(DIR, OUTPUT);
  Serial.begin(9600);             //PC Serial comm   
  mySerial.begin(9600);          //485 serial communication
  timer.setInterval(500, Poll);  // timed actions setup

}


void loop()
{
  timer.run();              //starts poll function
}

//*******************************************FUNCTIONS***************************************

void Poll()       // function to be called repeatedly
{
  incoming = 0;
  digitalWrite(DIR, HIGH);    //to talk to device
  mySerial.write((byte)0xAA);   
  mySerial.write((byte)0x02);
  mySerial.write((byte)0x00);
  mySerial.write((byte)0x00);
  mySerial.write((byte)0x5E);
  mySerial.write((byte)0xEA);
  Serial.println("Polling Command Sent");

  digitalWrite(DIR, LOW);  //to read form device
  Serial.print("Response: ");
  while(mySerial.available() >= 7)
  {
    incoming = mySerial.read();
    Serial.print(incoming, HEX);
    Serial.print(" ");
  }

  Serial.println();
  Serial.print(incoming); //prints value of incoming for debug
  Serial.println();
 
  switch (incoming)
  {
  case 249:
    Serial.println("Good Response From Poll");
    break;

  case 20:
    Serial.println("SW1 Pressed");
    break;

  case 38:
    Serial.println("SW2 Pressed");
    break;

  }
}

My circuit uses a MAX485 to communicate with a sensor board via 485.  RE and DE are tied together and connected to PIN 7 to send and receive commands.  When using the UNO the sensor board is sent the Polling Command and a good response is received.  If one of the switches is activated then the command is received correctly by the UNO.  When using the MEGA the program uploads to the board but there is no response from the sensor board when the polling command is sent, I know the board is getting the command and sending the response (there are LEDs on the sensor board to indicate a 485 connection) but it is not received by the MEGA.  I get no response, incoming has a value of 0 the correct response is 7 bytes of hex data.  I am using the same circuit and have tried all the serial ports on the MEGA as well as using software serial.  When the same circuit is connected back to the UNO then the commands are sent and received correctly. 

I need to use the MEGA because of all of the I/O for other parts of the project.  I figure I am missing something simple but I'm lost, any help would be greatly appreciated. 


-Mike

[Reply #1 on:]

This may well be one of those simple "wrong pin" problems.

Like here!

http://arduino.cc/forum/index.php/topic,141173.0.html

[Reply #2 on:]

Why are you using SoftwareSerial when the Mega has 4 hardware serial ports?

Also not all Mega pins support pin change interrupts and thus SoftwareSerial doesn't work on all of them. I don't have the list on me right now, but that is definitely the case.

[Reply #3 on:]

Keep in mind that controlling the DIR direction output pin to switch the external translator chip for send mode to receive mode is working outside the scope of the hardware serial library which is using interrupts and software buffers to hold data before sending. Others have shown that often the last character(s) being sent will get 'chopped off' due to the direction control bit activating before the serial library code has had a change to empty the transmitter buffer and have all the characters actually be sent out the hardware uart. One poster solved the problem by using a delay after the last serial.write command but before switching the DIR output pin to receive mode. The duration of the delay will depend on the baud rate being used.

Not sure what impact using software serial has on line switching direction control.

Lefty

[Reply #4 on:]

Keep in mind that controlling the DIR direction output pin to switch the external translator chip for send mode to receive mode is working outside the scope of the hardware serial library which is using interrupts and software buffers to hold data before sending. Others have shown that often the last character(s) being sent will get 'chopped off' due to the direction control bit activating before the serial library code has had a change to empty the transmitter buffer and have all the characters actually be sent out the hardware uart. One poster solved the problem by using a delay after the last serial.write command but before switching the DIR output pin to receive mode. The duration of the delay will depend on the baud rate being used.

Not sure what impact using software serial has on line switching direction control.

Lefty

An actual legitimate use for Serial.flush()  ?

[Reply #5 on:]

Thanks for all the replies.  Turns out it was a simple error.  I was using pins on the MEGA that didn't support software serial.  I changed the code to use pins that are compatible and the all is well.  Thanks for the help. 


-Mike

[Reply #6 on:]

Keep in mind that controlling the DIR direction output pin to switch the external translator chip for send mode to receive mode is working outside the scope of the hardware serial library which is using interrupts and software buffers to hold data before sending. Others have shown that often the last character(s) being sent will get 'chopped off' due to the direction control bit activating before the serial library code has had a change to empty the transmitter buffer and have all the characters actually be sent out the hardware uart. One poster solved the problem by using a delay after the last serial.write command but before switching the DIR output pin to receive mode. The duration of the delay will depend on the baud rate being used.

Not sure what impact using software serial has on line switching direction control.

Lefty

An actual legitimate use for Serial.flush()  ?

Quite possibly, and it would be about time something to be found for that rather 'interesting' command.  

But seriously keep in mind that there is still a single (or double?) hardware character buffer in the UART hardware also, so it could still be possible to stomp on a last character sent situation if the baud rate was too slow for the code execution of the DIR change command.

Lefty

[Reply #7 on:]

I think the send buffer is single buffered, the receive buffer is double-buffered. You are more likely to miss an incoming byte (doing something else at the time) than miss an outgoing byte, which after all, you control the rate of.

[Reply #8 on:]

I think the send buffer is single buffered, the receive buffer is double-buffered. You are more likely to miss an incoming byte (doing something else at the time) than miss an outgoing byte, which after all, you control the rate of.

But the issue is when to turn on the digital output pin changing the RS-485 transceiver chip from send mode back to receive mode, so there is a timing situation to consider. I would think that the normal strategy is to always stay in the receive mode until you actually need to send something, change to send mode, send the data, change to rec mode, so it's that last transition that is the critical one I would think and because the serial library and UART hardware work kind of asynchronously to the sketch code execution I think there is always a stomp on the output character failure mode lurking. Switch to fast and you stomp on outgoing characters, switch too slow and you risk stomping on a incoming character.

Lefty