UARTClass::begin modeReg = config & 0x00000E00; ???????

Hardware Arduino Due
1

On avr
HardwareSerial *p = Serial1;// for ex mega2560
p->begin(9600, SERIAL_8E1); // builds
...
p->write(...);
What goes out TX1 is 8E1.

For due, above doesn't build,
as code is in UARTClass.cpp, changed into

#ifdef ARDUINO_SAM_DUE
UARTClass *u = &Serial1;
u->begin(9600, UARTClass::UARTModes::Mode_8E1);
#else
p->begin(9600, SERIAL_8E1);
#endif
...
p->write(scounter++);

What goes out on TX1 is not 8E1 (framing errors, parity errors, etc)

Using
USARTClass *u = &Serial1;
u->begin(9600, USARTClass::USARTModes::Mode_8E2);
what goes out TX1 is 8E2.

https://github.com/arduino/Arduino/blob/master/hardware/arduino/sam/cores/arduino/UARTClass.cpp
line 43
void UARTClass::begin(const uint32_t dwBaudRate, const UARTModes config)
{
uint32_t modeReg = static_cast<uint32_t>(config) & 0x00000E00;
init(dwBaudRate, modeReg | UART_MR_CHMODE_NORMAL);
}

Why is there & 0x00000E00 ?

This sets anything above US_MR bit 12 to zero
and bit9,10,11 PAR to 111 which is not listed in SAM3X / SAM3A spec (page 828 )
(0 EVEN Even parity
1 ODD Odd parity
2 SPACE Parity forced to 0 (Space)
3 MARK Parity forced to 1 (Mark)
4 NO No parity
6 MULTIDROP Multidrop mode)

2 
void UARTClass::begin(const uint32_t dwBaudRate, const UARTModes config)

{
 uint32_t modeReg = static_cast<uint32_t>(config) & 0x00000E00;
 init(dwBaudRate, modeReg | UART_MR_CHMODE_NORMAL);
}



Why is there & 0x00000E00 ?

This makes sure that the user didn't set bits other than those that affect the mode. After all, you COULD say something like "u.begin(9600,1200); // Try to get split bitrates" and it might have bad results if you just copied that second parameter to the uart mode register.

This sets anything above US_MR bit 12 to zero

Yes. The parity control is bits 9, 10, and 11, so that's all we want.

and bit9,10,11 PAR to 111

No, it doesn't. "and" never sets bits to 1. It leaves the relevant mode bits in the argument at 1 if they were 1, and clears all the other bits.

Now. This is AWFUL code. Mixing "magic numbers" (0xE00) with symbolic constants (UART_MR_PAR_NO).
And this code:

      Mode_8N1 = US_MR_CHRL_8_BIT | US_MR_NBSTOP_1_BIT | UART_MR_PAR_NO,

Is mixing definitions from the USART device with definitions from the UART device, which are rather different. (or at least they are documented as different. The UART apparently doesn't have Stopbit or character length options! (which is ... weird.)) CHRL_8_BIT in particular sets bits that are not documented for the UART (NBSTOP_1_BIT is 0, so it doesn't matter.)

But, as it turns out, Serial1 is a USART and not a UART, so it makes sense that if you treat it as a UART it doesn't work correctly. On Due, only "Serial" is a UART. This is in the variant.cpp file for the Due:

UARTClass Serial(UART, UART_IRQn, ID_UART, &rx_buffer1, &tx_buffer1);
USARTClass Serial1(USART0, USART0_IRQn, ID_USART0, &rx_buffer2, &tx_buffer2);
USARTClass Serial2(USART1, USART1_IRQn, ID_USART1, &rx_buffer3, &tx_buffer3);
USARTClass Serial3(USART3, USART3_IRQn, ID_USART3, &rx_buffer4, &tx_buffer4);

(The difference between a UART and a USART is that a USART has more configuration options, including various "Synchronous" modes, which is where the "S" comes from.)

Now, I also think it's a flaw in the Arduino core that "Serialx" is sometimes a UART, sometimes a USART, and sometimes some sort of USB thing. The user-visible object types ought to be abstracted so that they are all of the same type regardless of underlying hardware. But I'm not familiar enough with C++ inheritance and such to quite wrap my mind around how you'd achieve that while also maintaining the "stream" inheritance properties... (sigh.)

3

Thanks