Change baud on the fly

[GermanSheepDog]

Hello,

I like to change baudrate for an ESP32 on the fly to communicate with a VC0706.

My idea is:

1. HardwareSerial Serial2(2);
2. Serial2.begin(38400);
3. ...do something with VC0706 -> This worked
4. Serial2.end(); -> Here stopped the program!
5. delay(1000);
6. Serial2.begin(115400);
7. delay(1000);
8. ..do something with VC0706

-> It didn't not work. The ESP32 stopped at line 4.)

My idea of an very easy test was:

1. HardwareSerial Serial2(2);
2. Serial2.begin(38400);
3. ...do something with VC0706
4. Serial2.end();
5. delay(1000);
6. Serial2.begin(38400); -> same baud as in line 1.!!!
7. delay(1000);
8. ..do something with VC0706

Is this an issue?

[jestebanes]

Hi @Papengut , try
Serial2.flush();
delay(2);
before the fourth point

[GermanSheepDog]

Hi @jestebanes,
thank you for your approach. I tried:

1. HardwareSerial Serial2(2);
2. Serial2.begin(38400);
3. ...do something with VC0706
4. Serial2.flush();
5. delay(1000); -> More delay isn't wrong
6. Serial2.end(); -> Here stopped the program!
7. delay(1000);
8. Serial2.begin(38400); -> same baud as in line 1.!!!
   9 delay(1000);
9. ..do something with VC0706

Same result at Serial2.end()! Program stopped execution.

[me-no-dev]

I'll have a look at the end command, but you do not need to call it. Just Serial2.begin(new baud) should do

[GermanSheepDog]

Hi @jestebanes,
thank you for your new approach. I tried:

1. HardwareSerial Serial2(2);
2. Serial2.begin(38400);
3. ...do something with VC0706
4. Serial2.begin(38400); -> same baud as in line 2.!!!
5. delay(1000);
6. ..do something with VC0706 -> nothing send and/or received from VC0706

Result of my test: The program didn't stop execution, but Serial2 didn't work in line 7.
In the next test I removed line 4 and now the VC0706 worked fine in line 6. But so I can't change the baud value!

[eroom1966]

I have a very similar issue regarding changing the baud rate
do you have a solution to this ?
#476

E

[copercini]

What about this?

void setup() {
  Serial.begin(115200);
  Serial.println("loool1");
  Serial.flush();
  delay(1000);
  Serial.begin(9600);
  Serial.println("loool2");
  Serial.flush();
  delay(1000);
  Serial.begin(115200);
  Serial.println("loool3");
}
void loop() {
}

[eroom1966]

@copercini
Tried your example which did not help too much,b ut it did push me to look at some alternatives.
As far as I can see - this is totally broken

I first setup the serial @9600baud, perform some read/writes then
I setup @57600baud
I have a packet length of 24 bytes that I send once every 2 seconds (@57600baud)
When I start sending this I see 5 packets of garbage come out the serial,
then I see my packets appear
But this is with a 10 second latency !!!

So I am guessing there is a FIFO involved here and it is only emptying the FIFO
when Full, and only at the same rate that data goes into the FIFO.
so it is not emptying asynchronously at the 57600 baud rate

Not sure what is magical about 5 x 24 - default buffer size perhaps ?

This only seems to occur when the baud rate has been configured at 9600, then changed
to 57600

Something is very wrong, but I think it must be down in the driver detail somewhere

E.

[copercini]

@eroom1966 please post some code, how are you testing it? via computer serial?

[jestebanes]

Hello @eroom1966, When you write to serial, the low-level functions are asynchronous, look into esp32-hal-uart.c functions uartWrite and uartWriteBuf, they only put your bytes in a FIFO buffer and then exit.
For this reason, I previously suggested making a flush operation before changing the baud rate.

But now I see in line 194 of esp32-hal-uart.c -> uartFlush(uart); inside the begin operation, then apparently there isn't a necessity of making a flush previous to the new Begin operation.
Then the only possible failure according to the temporal behavior you are seeing is an error in the implementation of uartFlush function in line 294 of esp32-hal-uart.c

JEE

[eroom1966]

@jestebanes
Good pointer!

OK, I am no expert on this Architecture, but this looks very suspicious at line 300

UART_MUTEX_LOCK();
while(uart->dev->status.txfifo_cnt);
...
UART_MUTEX_UNLOCK();

This looks like deadlock code
I wait until I have locked the mutex, then I loop indefinitely while the txfifo_cnt is non-zero

I presume another thread is emptying (and decrementing) this counter, using the same mutex, unfortunately, you now have a deadlock, because this mutex is not released until the count is zero,
but nothing to decrement the count

Hmmm, seems like a better approach is a condvar (assuming this library has such a feature)

E.

[eroom1966]

Hi All

I have the perfect testcase to show this issue - if anybody can make this work, that would be wonderful

#476

[me-no-dev]

Should be OK now! Please test and confirm :)

[lonerzzz]

@Papengut Are you able to test this issue?