Question regarding this library's use of malloc...

Projects Programming
1

I'm considering implementing the following buffered serial library on my current project to communicate with a few RS232 devices...

I understand everything the library is doing with the exception of its use of malloc in its BufferedSerial constructor at lines 35-37 of BufferedSerial.cpp.

BufferedSerial::BufferedSerial(unsigned int in_buf_size, unsigned int out_buf_size){
	serial_in_checksum = 0;

	incoming_buffer = (ByteBuffer*)malloc(sizeof(ByteBuffer));
	outgoing_buffer = (ByteBuffer*)malloc(sizeof(ByteBuffer));
	temp_buffer = (ByteBuffer*)malloc(sizeof(ByteBuffer));

	incoming_buffer->init(in_buf_size);
	outgoing_buffer->init(out_buf_size);
	temp_buffer->init(10);

	byte1 = 0;
	byte2 = 0;
	byte3 = 0;
	byte4 = 0;

	handlePacketFunction = 0;
}

I have read up on malloc enough to know that I don't fully understand the implications of it, specifically the perils of using it improperly. I have therefore followed the advice of those more knowledgeable than me and have simply avoided using it.

I only plan on instantiating the BufferedSerial class once in my sketch. The incoming and outgoing buffers will need to be 256 bytes each, and I'm using a Mega2560 with 8KB of SRAM. So even with four additional global arrays of 256 bytes each, I should be nowhere near depleting my available RAM. Therefore my feeling is that dynamically allocating memory for the serial buffers is completely unnecessary in my case. Would you consider that to be true? And if so, would you recommend altering the library so that it simply statically allocates the 256 byte serial buffers instead of using malloc?

Thanks in advance.

2

The Arduino Serial library has 64 bytes buffer for incoming and outgoing data. It is interrupt driven. That means you don't need an extra buffer. That library add an extra layer of complexity that you don't need.

If you make a good sketch (without delay) that can keep up with incoming data, then you can read a few serial devices at the same time. As long as you use the hardware serial ports and not the SoftwareSerial library.

The global variables are assigned to a certain memory location. The sram that is not used for variables will be used by the heap and by the stack.
The heap starts at the bottom and can grow upward. The malloc() allocates a new block from the heap.
The stack starts at the top and grows downward.
More information in this tutorial by Adafruit: You know you have a memory problem when... | Memories of an Arduino | Adafruit Learning System.

3

Yes, you're quite right that I don't need to use this library. However using/modifying/breaking/fixing existing libraries is one of the ways I learn the most, even if that means adding unnecessary layers of complexity at times.

That said, am I correct that the library's use of malloc seems completely unnecessary in my case and that statically allocating the 256 byte buffers would be a better idea?

Thanks.

4

Since none of those calls to malloc check for success, replacing them with static buffers seems like a good idea.

5

A possible advantage of malloc over static allocation would be that, having used the buffer, say to collect data, you could then drop the buffer to free up ram. However, whether or not that is useful depends on the application and actively using heap storage like that brings its own risks.

6

ironhalo:
Yes, you're quite right that I don't need to use this library. However using/modifying/breaking/fixing existing libraries is one of the ways I learn the most.

I think you should learn to write a good sketch, or make your own ringbuffer in a sketch, or make your own library, or make your own serial protocol, or try malloc() and free(). Show us what you have made and we can give tips.

7

The main advantage of the library linked in the original post seems to be methods for sending ints, floats, etc in binary, rather than converted to text (which Serial.print() does.)
You can do this now in the core Arduino code using "Serial.write()" - for example, Serial.write(&mylong, siizeof(long)) should work. (six years ago - the last time that library was edited - I'm not sure that Serial.write(b, n) existed yet.)

It should have used overloaded "put" instead of having separate methods for each data type. IMO.

8

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.