Go Down

Topic: wiring_serial.c - some suggestions for the Serial (Read 10973 times) previous topic - next topic


Ok, here's the final optimized wiring_serial.c with output buffer that can be completely disabled by setting #define TX_BUFFER_SIZE 0

I had earlier pondered how this sort of #define trick could set the RX_BUFFER_SIZE also, since it's fairly large for most of the sketches that we see on the boards, but necessary for real workhorse applications that require constant serial attention.

The downside to this situation is that it actually depends on the LIBRARY to be rebuilt when the SKETCH uses it.  It's no longer a shared library implementation, and a makefile might not establish that relationship.  I would think you'd have to keep deleting the library .o files whenever you want to readjust the buffer size.

Am I wrong on this?


@mtz: just call
Code: [Select]
Serial.begin(1000000L); This version uses exactly the same functions as the original one. It's transparent for the programmer.

@halley: I'm not sure how the makefile is written, but in my case, whenever I change the wiring_serial.c file it is automatically recompiled. It'd be awesome if one could put the
Code: [Select]
#define RX_BUFFER_SIZE yourvalue
at the beginning of the sketch file so there's no need to edit the library. With a smart code in the library:
Code: [Select]

#define RX_BUFFER_SIZE 128


After this great size and speed improvement to the serial library, why not upgrade the Serial.begin() function as well?

How about

Code: [Select]

The buffer sizes could be optional and default to sensible values.


Thanks mekon83...

But I have another question: in the code you put, there is a "L" after the speed, is that right?


Yep, it tells the compiler that 1000000L is a long constant, not an int. Maybe 1000000UL, unsigned long, that's even better.


@madworm: Unfortunately, this is not possible. The buffers are static arrays, compiler needs to know their size when compiling. It *could* be done with dynamic arrays but that introduces so many problems that the static solution is the best, in my opinion. It's simply too much to ask with 1kB SRAM.


Does this modification work with ATmega328?

Ironically I'm using code that @westfw helped develop for the HT1632 chip and am running up against the limits to which I can feed the Arduino data to push into the HT1632 chips. (currently at 115,200, I can push about 10KB/sec into the chips.)

I'd love to jump it up to 20 or 40KB/sec which would allow me to double or quadruple the number of Sure Electronics 2416 boards I can feed from a single arduino.

I'm a bit of a newbie, so I'm hesitant to overwrite my existing serial library without a little guidance. I'm using Arduino 0017

Go Up