Serial buffer

Post here first, or if you can't find a relevant section!
edogaldo
Posts: 291
Joined: Fri Jun 03, 2016 8:19 am

Re: Serial buffer

Post by edogaldo » Mon Jan 15, 2018 10:12 am

In my opinion there are 2 weakness in current Serial buffer implementation:
  • the buffer size is not easily configurable via code (anyway it could be changed at board level in boards.txt passing -DUSART_RX_BUF_SIZE=xx -DUSART_TX_BUF_SIZE=yy)
  • if you have N Serial devices (Maple has 3 and other have more), you will have 2*N buffers instantiated, even if you use only one Serial or don't use any at all..
I'd think these are issues that could be addressed in order to make a better core, one option could be moving the buffers in the variant files.

asmallri
Posts: 20
Joined: Fri Oct 06, 2017 12:37 am

Re: Serial buffer

Post by asmallri » Mon Jan 15, 2018 4:51 pm

I could not find a reference to "DUSART_RX_BUF_SIZE" or "DUSART_TX_BUF_SIZE" anywhere including a general google search. Do you have a reference or example?

Thanks, Andrew

edogaldo
Posts: 291
Joined: Fri Jun 03, 2016 8:19 am

Re: Serial buffer

Post by edogaldo » Mon Jan 15, 2018 5:23 pm

asmallri wrote:
Mon Jan 15, 2018 4:51 pm
I could not find a reference to "DUSART_RX_BUF_SIZE" or "DUSART_TX_BUF_SIZE" anywhere including a general google search. Do you have a reference or example?

Thanks, Andrew
In boards.txt you could add, for example, row: <board_name>.build.hs_flag=-DUSART_RX_BUF_SIZE=100 -DUSART_TX_BUF_SIZE=100
i.e.:

Code: Select all

###################### Generic STM32F103C ########################################

genericSTM32F103C.name=Generic STM32F103C series
[...]
genericSTM32F103C.build.hs_flag=-DUSART_RX_BUF_SIZE=100 -DUSART_TX_BUF_SIZE=100
[...]
Anyway consider that, as said, you will have N RX buffers and N TX buffers (where N il the number of available USARTs) each of the specified size..

User avatar
mrburnette
Posts: 2193
Joined: Mon Apr 27, 2015 12:50 pm
Location: Greater Atlanta
Contact:

Re: Serial buffer

Post by mrburnette » Mon Jan 15, 2018 6:51 pm

edogaldo wrote:
Mon Jan 15, 2018 10:12 am
<...>
I'd think these are issues that could be addressed in order to make a better core, one option could be moving the buffers in the variant files.


Yes, the Boards.txt file could be modified to pass a variable from a list of pre-determined buffer sizes. Seems a bit silly, IMHO, since someone could still require a buffer size not identified in the boards.txt

Folks that honestly need a change in the default size "should" be able to correct the problem on-their-own. I am a proponent of users not hacking on the core, so the "fix" really should be a user-defined buffer (again, in my opinion.) This solves the concern about increasing the send buffer when only the receiver buffer needs to be enlarged ... OH, well I guess the boards.txt file could have two (2) variables, one for Tx and one for Rx. Convoluted.

Now, I believe that the 64 byte Arduino values are probably too small for the STM32 as the uC has a faster clock and far more SRAM. But a default is a default ... we just need to figure out if bluesystems numbers are appropriate of if staying with the 64/64 is better because that is what Arduino does.

When we start pulling all of the constants into the boards.txt file, it is very easy to "lose" the actually deployed setting after the fact ... failing to document completely in notes what settings were actually chosen. ArduinoIDE fails on many fronts, but the metadata utilized from all of the soft-settings really should be appended to the source.ino file for documentation purposes.... or to a separate file as far as I am concerned. File exists in current directory, read it and set the values. File does not exist in current directory, set the default values.

Maybe we should just all kick the IDE in the butt and use make? At least that way, settings that are not defaults are documented.

There are so many smart developers here (and I except myself since I was technically never a developer but one of those gosh-darn managers.) We simply cannot go changing the core or the environment every time someone runs into a bit of a rough spot. Roger cannot keep up with the churn.

Why not build a library that allows buffering of any serial port? At least with a library, the source code automatically documents the settings. Caveat

Ray

Post Reply