Serial RX Buffer and SPI.

Hi everyone,

I have some gumby questions regarding serial TTL, buffers, and whether or not SPI might be able to help me.

I have an arduino uno with a cellular shield plugged in. I am running the basic sketch example for the shield from sparkfun.

#include <NewSoftSerial.h>  //Include the NewSoftSerial library to send serial commands to the cellular module.
#include <string.h>         //Used for string manipulations

char incoming_char=0;      //Will hold the incoming character from the Serial Port.

NewSoftSerial cell(2,3);  //Create a 'fake' serial port. Pin 2 is the Rx pin, pin 3 is the Tx pin.

void setup()
{
  //Initialize serial ports for communication.
  Serial.begin(9600);
  cell.begin(9600);
  
  //Let's get started!
  Serial.println("Starting SM5100B Communication...");
}

void loop() {
  //If a character comes in from the cellular module..
  //If a character is coming from the terminal to the Arduino...
  if(Serial.available() >0)
  {
   // create tcp connection
    incoming_char=Serial.read();  //Get the character coming from the terminal
    cell.print(incoming_char);    //Send the character to the cellular module.
   //do send here, run through 100 byte for loop then send packet
  }
}

I have modified the example (not shown, on another computer) to create a TCP connection (100 byte packets) and send the data from the serial connection (arduino) through the cell connection (cellular shield).

The serial data transmits fine if it is slowly fed into the uno. However, if you transfer data at 9600, when the code goes off and does the TCP transmission, bytes are being dropped off the recieve buffer because there is data missing.

A friend indicated that a possible soltuion might be to write to an SD card such as the micro sd shield from sparkfun because they have faster transmission speeds. Does that sound right? If you are recieving data on the serial port, could you also write it to the SD shield? Would you do this a byte at a time?

Can someone tell me the size of the serial recive buffer? Can this be increased? Can I get a link? Any links clarifying how you can recieve large files on serial and store them/transmit them on another softwareSerial connection would be awesome!

Can someone tell me the size of the serial recive buffer?

From: HardwareSerial.cpp "#define RX_BUFFER_SIZE 128"

Well:

#if (RAMEND < 1000)
  #define RX_BUFFER_SIZE 32
#else
  #define RX_BUFFER_SIZE 128
#endif

However you are limited by software serial:

incoming_char=Serial.read();  //Get the character coming from the terminal
cell.print(incoming_char);    //Send the character to the cellular module.

I’m not sure whether the sending is going to limit the receiving. It might.

If you are recieving data on the serial port, could you also write it to the SD shield? Would you do this a byte at a time?

Writing a byte at a time is about the most inefficient way you can do it. What about (using either method) getting a “transaction” (eg. something ending with a newline) from the Serial port, and then sending it somewhere else?

What about (using either method) getting a "transaction" (eg. something ending with a newline) from the Serial port, and then sending it somewhere else?

This would be ideal, but what I'm not sure of is if you're recieving on the serial port, and stop to write something on the software serial, will I end up missing bytes coming in on the serial port?

The serial port is connected up to a 9600 baud rate com port with no flow control (no RTS etc) just RX and TX.

I assume the SD shield must be a lot faster to write to than reading/recieving from a 9600 serial port? Otherwise you would lose bytes?

Forgive me, I'm not electrical at all, I'm a software engineer by trade. :blush:

Forgive me, I'm not electrical at all, I'm a software engineer by trade.

Then, you'd know that this comment is crap:

NewSoftSerial cell(2,3);  //Create a 'fake' serial port. Pin 2 is the Rx pin, pin 3 is the Tx pin.

There's nothing fake about a software serial port vs. a hardware serial port.

donghat: This would be ideal, but what I'm not sure of is if you're recieving on the serial port, and stop to write something on the software serial, will I end up missing bytes coming in on the serial port?

Well, at least doing it that way you get a complete transaction in. But if your writing side can't keep up with the reading, then you have problems anyway.

So how would i go about figuring out the write speed of an SPI device, and compare that to my read speed of 9600?

I compared speeds here:

http://www.gammon.com.au/forum/?id=10918

The 9600 baud serial one is easy - each byte takes 10 bits (usually) so that is 960 per second.

I timed SPI at around 333,333 bytes per second, but it would depend on the device a bit what speed it could accept, I think.

I compared speeds here:

Gammon Forum : Electronics : Microprocessors : Comparison of transfer protocols

Thanks Nick! That is a fantastic explanation. I understand a lot more. One thing that is still lacking for me is the clock. What does the clock speed synchronise to? Is this set in code? Or does it somehow synch with the master/slave? If you have any links explaining how the clock affects speed of transfer, that would be fantastic. Just trying to understand the process fully before I go making and mistakes.

For SPI, as I recall, the clock speed is simply associated with the processor clock speed (some divisor of the processor clock). Judging by the timings on my SPI page, you get 8 bits of clock in about 2 uS (ie. 4 clocks in 1 uS), which on a 16 MHz processor would mean it is clocking out at about 1/4 of the processor clock. That sounds about right.

SPI doesn't wait for acknowledgement, which makes it fast, but protocols need to check that the other end actually received or did something with the data. I think the SD shields can handle that (indeed I believe the SD cards are SPI devices themselves).

http://en.wikipedia.org/wiki/Flash_memory

Thanks again Nick, I dont suppose you know a good site that explains this clock business?

Didn't I explain it? What more do you want to know about the clock exactly?