Announcement

Collapse
No announcement yet.

Serial buffer size mega2560 (and other arduinos)

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Serial buffer size mega2560 (and other arduinos)

    The default buffer size is 64 bytes for the hardware setial ports and in some cases, be it NMEA data not read on time while doing other tasks, or xbee modules sending more than 64bytes data wirelessly, or in my case, even though I section off screen writes to genie on a PER FORM basis, I am doing a gauge project that uses streaming canbus data directly from spi bus on mega to display, writing multiple data at high speed can sometimes cause an overflows in this scenario, I found out after having to add another writeobject for a userled. Anyways all you need to do is add these #defines near the top of your sketches. The default is 64, I would recommend 128 though. Everything is working great so heres the code

    Code:
    #define SERIAL_RX_BUFFER_SIZE 128
    #define SERIAL_TX_BUFFER_SIZE 128
    Thats it! simple. This is what I am working on, animated shift lights with about 15 live streaming pids in constant poll mode

    https://www.youtube.com/watch?v=qErO...&nohtml5=False

    It's being benchtested with sample code that I quickly wrote to get values cycling and test out the functionality of animated gifs for shiftlight usage, however, the code I already implemented in the car already has data linked to display so now I can just tweak out what effect I'm willing to do with the lights later. millis() will be used to control the gif animation through the display cycles

    Without increasing the buffer size on this kind of high traffic data, the library couldn't process the event handler because of the data corruption/lost by overflow (only the RX buffer crashed, the TX was sending strong!), which i quickly found out after cutting back 2 genie.WriteObject commands, once the buffer was increased, I put back the 2 additional writes, plus added more.

    Also, when I say PER FORM basis, every form change on the lcd I have it report to the HOST, the HOST takes that number and saves it as a global variable. I call it
    Code:
    int genieFORM;
    In the Arduino code there are if statements that check for form activations, because really, if im not on a specific form on lcd, why write data to something your not looking at in background?
    I actually use the form change response for that as well as for, like my gauges, controlling the canbus filters and masks, to filter out un-needed bandwidth, once the form exits/changes, the filters/masks restore to allow all traffic as opposed to specific when we went into the form.

    anyways if you need more traffic and possibly higher baud rates, play with the buffers, you shouldnt need more than 128, going higher than that would be a waste of sram.
    also be aware that on mega2560, or any other arduino with multiple hardware serial ports, the TX and RX buffer increases for all of the ports.

  • #2
    Be careful, This buffer size is 'chosen' by Arduino, it is their 'default' in their serial libraries.

    It is like that for many reasons, one being the small size of most Arduino's RAM, another being that many Arduino's serial buffer 'code' will break if you use a number larger than 64.
    Mark

    Comment


    • #3
      It breaks because its small to begin with, like i said above people with xbee modules have no choice in some setups, and even the mega has enough ram that you wont notice this much as you would with uno. The fact that the tx signal from lcd overflows the rx buffer in arduino means the screen is sending more than 64 bytes (of ACKS?) before eventhandler can make use of it. Sure, you *could* use an ISR, but thats not necessary, especially if you are using some already, or, perhaps delaying live data to compensate for the overflow, there are tradeoffs for everything, but ill tell you why in this scenario it will not work:

      The way the ecu data is layed out and because of its instant response, when the 29bit address is being requested for data, each 2-3 pids PER request is sent and read sequencially one after another before returning to the loop, this happens so fast that you wont notice it, so, while that happened, DoEvents doesnt run for 1 cycle, which is too late since the acks overflowed. An ISR will not necessarily help in some setups, as the data requested from canbus can be lost while your handling the ISR.

      Im in no way offending you or the product, only giving people solutions that other people use that not necessarily use your product, but others as well. My setup runs with 11 i2c 9 spi, 3 serial, (with your lcd) 30k code and 37% memory usage, it didnt change percent tho when i increased buffer tho, so take it with a grain of salt

      Comment

      Working...
      X