UART question

With the standard HardwareSerial, is the following use expected to work:

Serial1.begin(19200);
Serial1.begin(9600);

Are those 2 back to back Serial1.begin() ok ? What is the expected behaviour (first set 19200 baud and then set 9600 baud, or set 19200 baud, and then ignore the 2nd call, as there was already a Serial1.begin()) ?

For any answer/opionion, is there “official” documentation/reference available that would substantiate this ?

The question look like a quiz …

Looking quickly at the F4 sources, the “official” reference, it looks like both calls will be honoured and the last one will be the winner.

martinayotte wrote:The question look like a quiz …

Looking quickly at the F4 sources, the “official” reference, it looks like both calls will be honoured and the last one will be the winner.

I think we should ideally honour all calls so we can switch rates as long as we wish.
I don’t know if there is “official” references for that, even on arduino.cc, maybe some searches will reveal something.
We can also do some tests on different boards, but “time is the missing ingredient” …

In my experience, such things are not well documented.

Normally people refer back to what the AVR Arduino’s do, and use that as the defacto standard.

In this case I agree with Martin. I would expect the second call to be honored.

I can think of plenty of instances where changing the baud rate would be required.

e.g. Some peripherals initialise at a slow baud rate, e.g 9600, but can be sent an AT command to switch to a higher baud rate.
Hence the MCU would need to switch to the higher rate after telling the peripheral to change rate.

I have no idea whether this works on the libmaple core, but I have not had any bug reports to say it doesn’t do this

RogerClark wrote:In my experience, such things are not well documented.

Normally people refer back to what the AVR Arduino’s do, and use that as the defacto standard.

In this case I agree with Martin. I would expect the second call to be honored.

I can think of plenty of instances where changing the baud rate would be required.

e.g. Some peripherals initialise at a slow baud rate, e.g 9600, but can be sent an AT command to switch to a higher baud rate.
Hence the MCU would need to switch to the higher rate after telling the peripheral to change rate.

I have no idea whether this works on the libmaple core, but I have not had any bug reports to say it doesn’t do this

Calling Serial.end() seems logical, so I can’t see anyone complaining about that

… Unless it happens to work on the AVR just by calling another Serial.begin()

I know you are using the Arduino Zero as your benchmark for comparability, but in my experience, unfortunately, the AVR Arduino is used as the defacto standard, whether we like it or not.

This means, that with libmaple, we end up, having to do things, like setting the pinMode to Analog Input, when people use analogeRead() because on the Uno they have defined a set of pins to be analogue inputs, and hence the user doesn’t need to call pinMode

Personally, I wouldn’t care much if Arduino is a defacto-standard or not.
The stm32duino can lead in some way like the current Serial.begin() behaviour.
If some call to Serial.end() is needed (that still need to be proven on both F1 and F4), than Serial.begin() could call it if a internal flag “already_initialized” is been set.
I’m volunteer to give it a look on F4 when “time ingredient become back in stock” …

I agree that having an additional flag would not be a big issue, as no one is going to be calling Serial.begin() over and over again in some time critical code, where the additional if statement would slow things down.

martinayotte wrote:… when “time ingredient become back in stock” …

ahull wrote:Send me a few bushels of it when it does come back in, I’ll reimburse you… at a later date naturally.

martinayotte wrote:ahull wrote:Send me a few bushels of it when it does come back in, I’ll reimburse you… at a later date naturally.

Andy

I dont need Scotch to make time disappear. Just sitting down to fix a minor bug seems to cause time to speed up.

One of my managers had a good way to predict how long it would take to fix a bug..

Take the time estimated by the programmer, and multiply it by PI

I’ve found this is generally not too far off the mark

But PI is defined number, is that true with SCOTCH number ?

martinayotte wrote:But PI is defined number, is that true with SCOTCH number ?