Using UART1 on Bela Mini

so what you could do is parsing the received string from the auxiliary task and set several global variables. Then from render() you either call libpd_float() multiple times (each with a different receiver), or construct a list. Let me know if you need help.

giuliomoro why using libpd_symbol() instead of libpd_float() gives the error: no matching function for call to 'libpd_symbol' ?

libpd_symbol() requires a char* as the second argument:

int libpd_symbol(const char *recv, const char *symbol)

how are you calling it ?

Well, if gSerialValue is still a float, then what you are doing is you are setting in turn to the value of each byte which is received from the UART. render() will only see the latest value that it has been set to and that's pretty meaningless. A different approach would be to make serialBuffer a global variable and use libpd_symbol(gSerialReceiverName, serialBuffer), however in this case you will occasionally send to Pd a corrupted string: if render() runs halfway through a UART receive, the first part of the string will be from from the new reading and the second part of the string will be from the previous reading.

A more thread-safe approach is to use a Pipe to send the string value from serialReadTask() to render(). In the Communication/Serial example there is a Pipe to send one character at a time from the AuxiliaryTask to render(). If the width of the string is constant, you can just create a std::array<char, 84> at both ends of the pipe and pass data as follows:

Pipe gSerialPipe;
void serialReadTask(void*)
{
	while(!Bela_stopRequested())
	{
		unsigned int maxLen = 512;
		char serialBuffer[maxLen];
		// read from the serial port with a timeout of 100ms
		int ret = gSerial.read(serialBuffer, maxLen, 100); 
		if (ret > 0) {
			gSerialPipe.writeNonRt(serialBuffer, ret);
			usleep(gSerialReadSleepMs * 1000);
		}
	}
}
/// in setup()
{
...
	gSerialPipe.setup("serialpipe", 1024);
...
}

/// in render()
{
..
	char serialBuffer[maxLen];
	size_t len = gSerialPipe.readRt(serialBuffer, maxLen);
	if(len > 0) {
		serialBuffer[len] = 0; // ensure the string is appropriately null-terminated, or the line below may crash
		libpd_symbol(gSerialReceiverName, serialBuffer)
	}
...
}

Thanks for the help @giuliomoro!

Is there any reason why my GPS module looses coordinates values as soon as I run the software? Does this code send anything back to the module via uart4?

Tree Does this code send anything back to the module via uart4?

as far as I can tell that code doesn't use UART at all. In the code I wrote above we are not writing via UART either, so I don't see how the code could be responsible of malfunctioning of the GPS module as it does not write to it.

Tree Is there any reason why my GPS module looses coordinates values as soon as I run the software?

Not sure what that means.

that code still doesn't send anything to UART4.

Tree loses coordinates as soon as I run the software

I am not sure how that can happen, considering that your software is not affecting the state of the GPS module (I cannot see any place where it is writing to the UART, but you have not posted the full code and not even all the relevant one. Namely: post at least the relevant global variables, the relevant initialisations and the code of the AuxiliaryTask). I would guess that if you were to print the data from within the AuxiliaryTask you'd see that the data is received appropriately.

One issue you have is that the return values from reading the pipes are size_t, which is an unsigned type. The return value from Pipe::readRt() is: a positive integer is the number of bytes read, or a negative error value otherwise. When no new data from the Pipe is available, it will return -EAGAIN (i.e.: a negative integer). In this case the following tests (e.g.: if(lenLat > 0 )) will always return true because an unsigned value is always positive. This only becomes an issue if the Pipe is read less often than its written to, so the render() thread finds it empty sometimes.
In the converse case, where you read from the pipe slower than the data is written into it by the AuxiliaryTask, you will also end up in trouble. As you are only reading once from each pipe, you may be reading old (and increasingly older) data from it. This is fixed by reading multiple times until the pipe is empty (returns a negative value). However, as in your case you are passing arbitrary length data and message boundaries are not preserved in the PIpe, I think if this was the issue you'd have noticed that already.
Last, I am not sure it's convenient to have three different pipes, but I'd need to see the AuxiliaryTask code to confirm that.