16F1828 SEROUT2 works badly, but works fine on 16F886 on same hardware

[CuriousOne]

Here is better explanation - the top row shows how data should look, and bottom row shows what actually is delivered.
It looks like for each 32 bytes, 1st bit has it's value increased by 8.

Very strange.

00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00 81 82 83 84 85 86 87 88 89 8A 8B 8C 8D 8E 8F


10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
00 81 82 83 84 85 86 87 88 89 8A 8B 8C 8D 8E 8F


20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F
90 91 92 93 94 95 96 97 98 99 9A 9B 9C 9D 9E 9F


30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F
90 91 92 93 94 95 96 97 98 99 9A 9B 9C 9D 9E 9F

[CuriousOne]

I did a bruteforce approach - sumbitted variable changing from 1 to 65535 to SEROUT2 mode selection, sent fixed set of bytes and watched serial port for them to appear in proper order. 89 worked well. Strange, why for 886F 84 is fine but here we need 89.

[CuriousOne]

89 was for FTDI chip.
For CH340 it needs 92.
Very strange, why this is happening...

[tumbleweed]

Send a capital 'U' ($55) and measure the bit timing. 9600 baud should be 104us/bit.