next topic »

[Reply #15 on:]

...If you are performing a calculation on a large amount of data, that cannot be calculated without all data, then you really have no option but waiting.

Not true. You can move the data from the serial buffer to you own buffer, as fast as possible. This keeps the serial buffer size small, but still allows you to capture all the data (in your own, sketch-specific, buffer).

[Reply #16 on:]

My recommendation is to use Bill Porters EasyTransfer to help with this sort of problem.

How do you propose that OP use this library on the other side?

[Reply #17 on:]

That is completely incongruous to all your previous posts, which talked about a stream of 128 characters coming in.

The quality of the help you receive will almost always be directly proportional to the quality of the information you provide.

That being said, Serial comms should NEVER be coupled to some external activity (in this case, a button press).  Execute your Serial comms completely independently of everything else, store the necessary results somewhere, and then act upon them when necessary (either immediately, or if necessary based on that external activity).

What is this dvr you referred to as well.  Based on your last post, it sounds like the proper means of handling incoming serial data is with a small 4 character ring buffer, constantly checking for a valid checksum with each character read in, until you have a valid checksum, and thus a valid packet of data.  With the absence of any synchronizing  characters, there aren't m/any other options for properly processing the incoming data.

If you look at my posts none of them say about having a stream of 128 characters. I listed the kind of command I am expecting back which was 7120A031 (hex) which is 4 bytes. My initial query was about the Mega only returning 1 byte at a time, and if I iterate the Serial.read 4 times I can read the 4 bytes into a buffer and do what I need to do with them.
All I wanted to know was whether there is a way to increase the serial buffer so that I can read all 4 bytes in one go.

[Reply #18 on:]

All I wanted to know was whether there is a way to increase the serial buffer so that I can read all 4 bytes in one go.

The serial buffer is at least 64 bytes, but you can never read more than one byte at a time out of it.

[Reply #19 on:]

If you look at my posts none of them say about having a stream of 128 characters.

Including this?

Now if I use Tera Term and send the commands through there I get the whole stream in one go as I should. I should be getting up to 128 characters through the serial buffer but it doesnt seem to be the case. I havent changed anything and my code to read it is quite standard and straight forward:

[Reply #20 on:]

There's this, but I never use it.

[Reply #21 on:]

Code:

void handle_button_fire() {
  if (button_fire.update()) {
    if (button_fire.read() == HIGH) {
     
      Serial1.print(STATUS_READ);
     
      if (Serial1.available() > 0) {
     
      int readstatus = Serial1.read();
      Serial.println(readstatus, HEX);
      }
    }
  }
}

I would be surprised if this worked at all, let alone reliably.

You do this:

Code:

      Serial1.print(STATUS_READ);

And a line later check for a response:

Code:

      if (Serial1.available() > 0) {

Too quick, by far. It won't have responded in that time, and if you get anything it would be left over from a previous response.

Put it this way, the read isn't blocking. It doesn't wait for the other end to respond.

[Reply #22 on:]

More info:

http://www.gammon.com.au/serial

[Reply #23 on:]

You can move the data from the serial buffer to you own buffer, as fast as possible

Is not faster than collecting the data once.

This keeps the serial buffer size small, but still allows you to capture all the data (in your own, sketch-specific, buffer).

Copying out the data adds overhead. Why use two buffers when one will do. How is using two buffers even close to efficient in comparison? Keeping a clean serial buffer is a waste of memory if you cannot utilise all bytes it can provide, a secondary buffer will still fill up if not used.

Certainly it adds potential errors due to the ring buffer and possibility of dropped data, but with a smart solution it can work well.

[Reply #24 on:]

As previously stated, the arduino normally gets one character at a time from the serial buffer. This occurrs very rapidly if the looping is uncontrolled (much faster than the buffer is normally filled). You stated that there is no deleniation between the strings being sent other than a time interval. Below is a very simplistic setup that might work for your situation. A short delay is used to control the buffer emptying speed such that a simple string of characters can be captured from the buffer before being processed. You can test using the serial monitor.

Code:

// zoomkat 7-30-11 serial I/O string test
// type a string in serial monitor. then send or enter
// for IDE 0019 and later

String readString;

void setup() {
  Serial.begin(9600);
  Serial.println("serial test 0021"); // so I can keep track of what is loaded
}

void loop() {

  while (Serial.available()) {
    delay(2);  //delay to allow byte to arrive in input buffer
    char c = Serial.read();
    readString += c;
  }

  if (readString.length() >0) {
    Serial.println(readString);

    readString="";
  }
}

[Reply #25 on:]

Why use two buffers when one will do.

Because, if you modify HardwareSerial to increase the serial buffer size, it affects every application until you change it back.

Copying the data into another buffer affects just the one application that is doing the copying.