Go Down

Topic: RAMEND bug in HardwareSerial.cpp? (Read 7 times) previous topic - next topic


Looks like the mod was done by Mark Sproul.

There is a comment about the atmega8535 so it could be for that processor.

Bug or not it would be nice to use a smaller buffer on processors with 1K of RAM.

Coding Badly

Do you think the original programmer meant to use RAMSIZE rather than RAMEND?

My suspicion is that RAMEND was used because of an eccentricity in the the header files.  There's an E2END (EEPROM_END) but no E2SIZE.  If the developer was familiar with the EEPROM constant, I can see how one would assume there is a RAMEND but no RAMSIZE.

It does seem to be a bug to compare a memory address with a number. RAMSIZE would be the actual memory size,

I agree.  RAMSIZE is the correct constant to use.

RAMEND just happens to be the last address and could be anywhere depending on the internal memory map.

I believe on the AVR processors, RAMEND is always RAMSIZE - 1.

Bug or not it would be nice to use a smaller buffer on processors with 1K of RAM.



Unfortunately it seems that RAMSIZE isn't always defined for each processor. What is and isn't defined is a bit hit and miss :(

I can't see an easy way to improve on the code that's already there. Using RAMEND is a reasonable compromise if RAMSIZE isn't available.

Coding Badly

Code: [Select]
[glow]#if ! defined( RAMSIZE )
#define RAMSIZE ( RAMEND + 1 )

#if (RAMSIZE <= 1000)
 #define RX_BUFFER_SIZE 32
 #define RX_BUFFER_SIZE 128



I started this topic after helping a user of one of my libraries with a common problem.

The user put a Serial.println() debug statement in a sketch that will not use the UART after it is finished.  The user has a 168 Arduino.

An extra 128 bytes of receive buffer is allocated even though no serial data is read.  The use of this extra RAM caused his sketch to crash.

Too bad no buffer is allocated unless you used a serial input function like Serial.read or Serial.available.

I am working on a GPS logger where I would like more than 128 bytes for the serial buffer.  I have enabled every possible NMEA sentence from the GPS and it blasts out about 600 bytes at the start of every second.

A simple way to override the default receive buffer would help.

I started fighting serial I/O in 1971 when I designed a large terminal concentrator at one of the national labs.  I guess my struggle with serial I/O will never end.

Go Up