Go Down

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

fat16lib

Forty years ago we knew strong coupling between receive and transmit in communications software caused problems.

There is no fundamental reason the receive ISR and buffers need to be loaded when you only need transmit.  I have written C++ classes to do it but it would change the Serial api.

I suspect"Tiny Debug Serial" would works fine.

The problem really needs to be fixed in the standard Arduino distribution and that's not likely to happen.







Coding Badly


Why are serial recieve and serial send bound together?  The only technical reason I can find is initialization.  From a resource perspective, it would certainly make sense to separate them.  Should they be split?  Would it be too confusing?

@fat16lib: For debugging would "Tiny Debug Serial" help?  It's a write-only software serial.

westfw

In recent Arduino cores, a lot of changes were added to support additional processors, mostly by making feature inclusion dependent upon the definitions defined by the processor include files, instead of on the processor name.  So while the old HardwareSerial.cpp code would contain
Code: [Select]
#if defined(__AVR_ATmega1280__) || defined(__AVR_ATmega2560__)
ring_buffer rx_buffer1 = { { 0 }, 0, 0 };
ring_buffer rx_buffer2 = { { 0 }, 0, 0 };
ring_buffer rx_buffer3 = { { 0 }, 0, 0 };
#endif

While the new code does  
Code: [Select]
#if defined(UBRRH) || defined(UBRR0H)
 ring_buffer rx_buffer  =  { { 0 }, 0, 0 };
#endif
#if defined(UBRR1H)
 ring_buffer rx_buffer1  =  { { 0 }, 0, 0 };
#endif
#if defined(UBRR2H)
 ring_buffer rx_buffer2  =  { { 0 }, 0, 0 };
#endif
#if defined(UBRR3H)
 ring_buffer rx_buffer3  =  { { 0 }, 0, 0 };
#endif

So support for a particular serial port is only included if the constants for that particular serial port are included in the definition associated with the cpu named passed from the compile line (assuming normal avr-gcc usage.)

The intent of the RAMSIZE conditional you found is almost certainly to support the arduino serial code on CPU that have even less memory than any of the "real" Arduinos, while keeping the behavior on the real Arduinos the "same as it always was."

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

Ah.  That would be an issue that is only peripherally related; your user's code would have crashed with any of the older versions of the core as well.
Since the allocated buffer will be used by the ISR regardless of whether the user ever calls Serial.read(), it's a bit hard to omit.  The compile/link isn't smart enough to exclude the rx ISR based on the fact that the user never calls the user-level read functions.

Quote
I started fighting serial I/O in 1971 ...  I guess my struggle with serial I/O will never end.

:-) Ah.  Another expert in "legacy technology."  Even older than me!  (supdup and xmodem for tops10, circa 1979)  Hah!  No, I don't expect it to ever end.  At least USB made it easier for users.  Mostly.  Sort of.  Fewer cable problems, anyway...

stimmer

Why not write an alternative hardware serial library, one with adjustable/optional buffers? (Is there some technical reason why that would not work? ie is Arduino tied to its own Serial class somehow?)

fat16lib

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