Serial comunication between YUN and Mega

Hi to everybody!
I know that there are lots of posts similar to mine, but I can't find any solution to my problem:
I'm using arduin Mega to read analog inputs and print them on OLED display and I wanto to pass some data to arduino YUN in order to be printed on a html page, stored in the micro SD card and published on Thingspeak.
The sketches for the Mega and the YUN are already done, but I'm having a lot of trobles with serial comunication, I think that bridge functions are perturbating the system and I dont't know how to read serial data properly.

First I tested the comunication between an arduino Mega and arduino Nano (just for debugging the sketch) and everything was working good using these sketches:

SENDER:

const char startOfNumberDelimiter = '<';
const char endOfNumberDelimiter   = '>';
int ActualTempV,  ActualTempF,  ActualTempA,  ActualpH;
void setup ()
{
  Serial.begin (9600);
} // end of setup

void loop ()
{
  //ricava valori
  ActualTempV = (millis() / 1000);
  ActualTempF = (millis() / 20);
  ActualTempA = (millis() / 35);
  ActualpH = (millis() / 425);

  //Scrivi valori
  mandaSeriale();

  delay (1000);
}



void mandaSeriale ()
{
  Serial.print (startOfNumberDelimiter);
  Serial.print ('v');                 //identificativo variabile
  Serial.print (ActualTempV);         // send the number
  Serial.print (endOfNumberDelimiter);
  Serial.println ();

  Serial.print (startOfNumberDelimiter);
  Serial.print ('f');                   //identificativo variabile
  Serial.print (ActualTempF);           // send the number
  Serial.print (endOfNumberDelimiter);
  Serial.println ();

  Serial.print (startOfNumberDelimiter);
  Serial.print ('a');                   //identificativo variabile
  Serial.print (ActualTempA);           // send the number
  Serial.print (endOfNumberDelimiter);
  Serial.println ();

  Serial.print (startOfNumberDelimiter);
  Serial.print ('p');                     //identificativo variabile
  Serial.print (ActualpH);                // send the number
  Serial.print (endOfNumberDelimiter);
  Serial.println ();

}

RECEIVER:

#include <Adafruit_GFX.h>
#include <Adafruit_SSD1306.h>

Adafruit_SSD1306 display(4);

const char startOfNumberDelimiter = '<';
const char endOfNumberDelimiter   = '>';

long serialTempVasca, serialTempFondo, serialTempAmb, serialpH ;

void setup ()
{
  Serial.begin(9600);
  display.begin(SSD1306_SWITCHCAPVCC, 0x3C);
  display.clearDisplay();

} // end of setup

void loop ()
{

  while (Serial.available ())
    leggiSeriale ();  //leggi ingressi

  display.clearDisplay();
  display.setTextSize(1);
  display.setTextColor(WHITE);
  display.setCursor(0, 0);
  display.print("T Acqua: ");
  display.print(serialTempVasca/10,1);
  display.print("T Acqua: ");
  display.print(serialTempFondo);
  display.print("T Acqua: ");
  display.print(serialTempAmb);
    display.print("T Acqua: ");
  display.print(serialpH);
  
  display.display();

}


//leggi ingressi
void leggiSeriale ()
{
  static long receivedNumber = 0; //appoggio
  byte c = Serial.read (); //singolo byte
  static boolean v, f, a, p;

  switch (c)
  {

    case endOfNumberDelimiter:
      if (v)
        serialTempVasca = receivedNumber;
      else if (f)
        serialTempFondo = receivedNumber;
      else if (a)
        serialTempAmb = receivedNumber;
      else if (p)
        serialpH = receivedNumber;
    //....elsif...


    // fall through to start a new number
    case startOfNumberDelimiter:
      receivedNumber = 0;
      v = false;
      f = false;
      a = false;
      p = false;
      //....
      break;

    case '0' ... '9':
      receivedNumber *= 10;
      receivedNumber += c - '0';
      break;

    case 'v':
      v = true;
      break;

    case 'f':
      f = true;
      break;

    case 'a':
      a = true;
      break;

    case 'p':
      p = true;
      break;



  } 
}

But when I load the sketch on the YUN whit software serial, it didn't behave like expected: If Bridge is called softwareserial don't work; the values are not collected in the same way.

Can you hel me please?

Later I will need to send data (exact time) to Mega from YUN, so I need biderectionability.

Thanks in advance.

It's a while since I used my Yun - disappointing waste of money really. This Thread about disabling the bridge may be of interest.

It was madness on the part of the Yun developers not leave the Arduino Serial1 port available for normal serial communication on the Yun

...R

Thank you so much.

If I will disable the bridge, can I still read/send data to html pages?

What you suggest to use insted of YUN?

Up to now I was using just YUN to read, process and send data to SD, html, thingspeak...but later I decided to add a OLED display including the needed libraries...the sketch becomes too big.
I tried to trim the libraries, but I just reduce a little bit...I can't trim them furteher more!
So I decided to use arduino MEGA, and make this serial comunication.

But actually is very complicated!

Do you have some other solution?

The project is pretty simple:
read 4 AI, write 8 DO, command 2 servomotor
print data on display, datalogger on SD,
print to html (optional thingspeak).
Save configuration permanentely (EEPROM or SD)
Need always to run with exact time.

Thank you.

illomellino:
But when I load the sketch on the YUN whit software serial, it didn't behave like expected: If Bridge is called softwareserial don't work; the values are not collected in the same way.

It's good you posted the working code examples, but what we really need to see in order to help is the code that isn't working. You say SoftwareSerial isn't working, but none of the code you posted uses SoftwareSerial.

What pins are you using for software serial on the Yun? If you look at the reference page for SoftwareSerial, there is a "Limitations" section that talks about a limited set of pins that can be used with a Leonardo. The Yun uses the same processor as the Leonardo, so the same limitation applies here.

We really need to see your specific code, because SoftwareSerial does work on the Yun - I personally have a very reliable project that uses two instances of SoftwareSerial to talk to two Arduino ProMinis.

Robin2:
It's a while since I used my Yun - disappointing waste of money really. This Thread about disabling the bridge may be of interest.

I don't believe the Bridge is the issue here. SoftwareSerial does play well with the Bridge. I think there is a different issue.

It was madness on the part of the Yun developers not leave the Arduino Serial1 port available for normal serial communication on the Yun

I don't want to take this discussion off track, and I'm well aware of your feelings about the Yun, but it's the serial connection between the AVR and Linux processors that is the heart of the Yun and makes it what it is: a combination of powerful networking brought to you by Linux, and the real-time low-level hardware control brought to you by the AVR processor. To do this, the two processors need to talk to each other. How would you have them do that without using that serial connection? I suppose other links could be used, like SPI, but then someone would be complaining about that being tied up.

illomellino:
the sketch becomes too big. ... I can't trim them furteher more!

A good way to minimize the sketch size on the Yun is to do the bare minimum of processing in the sketch. Use it for what the AVR processor does best - control shield I/O pins - and do as much of the heavy processing as possible on the Linux side. For example, in your case, read the inputs and send the raw data down to Linux. Code on the Linux side reads that data, processes it and makes any decisions, sends it to ThingSpeak, writes it to the SD card, computes the output values, and formats the display. The Linux code then sends the display contents and desired output pin and servo position values up to the sketch, and the sketch outputs those values to the hardware.

If you are doing the SD card logging, display formatting, or ThingSpeak communications in the sketch, you can save a lot of sketch space by doing that down in Linux. Yes, the sketch can do all of that, but the Linux side can do it better and faster, and doesn't have the limited memory constraints that the sketch is forced to live with. Most of my projects use the Bridge library and a Process object. The Process object starts a Python script on the Linux side. Anything the sketch prints to the Process object is read by the Python script by reading standard input. Anything the Python script prints can be read by the script by reading from the Process object. The Process object has the same communications interface as Serial and SoftwareSerial, so the same code a sketch uses to read and write the serial port will work with a Process object. And on the Linux side, the same code that reads from the keyboard and writes to the screen will talk directly to the sketch when that script is run from a Process object.

Doing the heavy processing on the Linux side sounds daunting at first, but it is a very powerful and useful technique to learn.

If I will disable the bridge, can I still read/send data to html pages?

Yes, but you will still have to get the data from the sketch to the Linux side of the Yun. Without the Bridge, you will have to write that communications link yourself.

Do you have some other solution?

You could possibly connect the Mega's USB port to the Yun's USB host port. You would then open the serial connection to the Mega in Linux (perhaps using the PySerial library with Python) and do all of the communications with the Mega on the Linux side. To do this, you will need to load a Linux package to provide a driver for the Mega's USB connection, I know there have been threads on this forum explaining how to do that. This page gives a brief overview.