Exploring the serial I/O of a 40+ year old uP / MPU / SBC / TTL device

To cut to the chase:

Question: What do I do wrong that Espruino Pico's

Serial1.setup(300, {rx:B7, tx:B6, parity:"o"});

gets nothing for me but framing and parity errors?

To be more helpful, first some TL;DR:

I'd like to reuse - and showcase the device - but being it in the context and connectivity of more recent peripherals.

For exploration and possibly future interfacing, I picked Espruino Pico, because I have access to the device's TTL signal levels before it's fed into RS-232 drivers that do the typical -12V/+12V business or into FSK (Frequncy Shift Keying) communication over regular copper phone lines as of that time for remote operation. Commisurate with the means at that time is the speed: about 300 baud or 300 bps (bits per second) - Baud from French Baudot 5-bit code, invented 150+ years ago for telegraphy...

Espruino and Pico are a good match, for easy coding and quick to apply, and has TTL / 5V signal compatibility. Espruino software supports Serial communication with configuration option for number of data, parity and stop bits.

Unfortunately, for yet unknown reason, the code below

  Serial1.setup(300, {rx:B7, tx:B6, parity:"o", errors:true});
  Serial1.on('data', function (data) { print(data); });
  if (errs) {
    Serial1.on('parity',  ()=>console.log('P'));
    Serial1.on('framing', ()=>console.log('F'));
  }

prints nothing but Fs for framing and Ps for parity errors for a block of 0x20 0xAA and another block of 0x20 0x55. Looking a the signal timings, it shows that a bit is around 0.003148 seconds, yielding a rate of 318 bps. 18 is about a 6% error, over the 10-1/2 sampling times this makes worst case 63% 'off-beat'. Center sampling can at best handle a 40%..45% off-beat situation, so no surprise it failed... But I'm in for a greater surprise: even with setup adjusted to 318 bps, the result is equally depressing: PF.

Since the 40+ year old device is so slow, I just used Pico and a few lines of code to find the timings including baud rate AND visualization of the signal shape... The code looks like this:

var baudFindWId = null   // baud find watch ID
  , ths, lst             // this and last bit's Espruino getTime()
  , SOD = B7             // USART1 B7 rx - watching device's Serial Out Data
  ;
function findBaud() {
  unfindBaud();
  pinMode(SOD,"input");
  lst = getTime();
  baudFindWId = setWatch( function(s) {
      console.log(
          ( (s.state)
               ? "|_"         // low signal for...
               : "_|" )       // high signal for...
        , (ths=getTime())-lst // ...t sec(s) before switching to high, rsp low
        ); 
      lst=ths;
    }, SOD, {repeat:true, edge:"both", bounce:10} );
  log("made SOD watched");
}
function unfindBaud() {
  if (baudFindWId) { 
    baudFindWId = clearWatch(baudFindWId);
    log("made baud unfound");
  } else {
    log("baud is (already) unfound");
  }
}

The device was setup to transmit this sequence of 0x20 0x##s bytes (ignore var t=... js, it overcome render challenges of fixed font text blocks in forum... how to <pre> w/ line # but w/o coloring?):

var t=`
Byte# 0x##: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 .. 1f
Value 0x##: 00 01 02 04 08 10 20 40 80 00 00 00 FF FF 0F F0 00 .. 00
CRC   0x##: FC
;`

The generated out put in console looks like this:

var t=`
_| 9.82303428649 // <--- A) idle, since setup / before tx and
|_ 0.02833652496            before start of 1st byte 0x00
_| 0.00949668884 // <--- B) before start of 2nd byte 0x01
|_ 0.00314712524
_| 0.00315475463
|_ 0.02518844604
_| 0.00633430480 // <--- C) before start of 3rd byte 0x20
|_ 0.00630855560
_| 0.00314426422
|_ 0.02202987670
_| 0.00633335113 // <--- D) before start of 4th byte 0x40
|_ 0.00944900512
_| 0.00314807891
|_ 0.01888561248
_| 0.00635814666 // <--- E) before start of 5th byte 0x80
|_ 0.01259136199
_| 0.00315093994
|_ 0.01572895050
_| 0.00633239746 // <--- F) before start of 6th byte 0x10
....
....
_| 0.00948810577
|_ 0.02837276458
                  // <--- G) unknown idle time after transmission
`; 

Since in above 'graph' the signal level line show NOT to time, I manually extended them according the times measured. I commented start bit, data bits 0 thru 7, odd parity bit, stop bit and the idle or byte separation 'bit'. With the extension, the signal lines make it very obvious what is going on:

var t=`
Signal Level TTL Low 0
|Signal Level TTL High 1
|| Bit type or value (start, value, stop, idle/'space'(:))
|| | Bit # 0 (LSB) thru 7 (MSB)
|| | |     Byte# - last is CRC - and Byte value 0x##
|| | |     |     seconds of equal signal level
|| | |     |     |              (n) number of average
|| | |     |     |              |   time units of one bit
VV V V     V     V              V
 | :
_| :          
|  start   #00
|  0 0
|  0 1
|  0 2
|  0 3
|  0 4
|  0 5
|  0 6
|_ 0 7     00    0.02833652496 (9)
 | odd
 | stop
_| :             0.00949668884 (3)
|_ start   #01   0.00314712524 (1)
_| 1 0           0.00315475463 (1)
|  0 1
|  0 2
|  0 3
|  0 4
|  0 5
|  0 6
|  0 7     01
|_ odd           0.02518844604 (8)
 | stop
_| :             0.00633430480 (2)
|  start   #02
|_ 0 0           0.00630855560 (2)
_| 1 1           0.00314426422 (1)
|  0 2
|  0 3
|  0 4
|  0 5
|  0 6
|  0 7     02 
|_ odd           0.02202987670 (7)
 | stop
_| :             0.00633335113 (2)
|  start   #03 
|  0 0
|_ 0 1           0.00944900512 (3)
_| 1 2           0.00314807891 (1)
|  0 3
|  0 4
|  0 5
|  0 6
|  0 7     04
|_ odd           0.01888561248 (6)
 | stop
_| :             0.00635814666 (2)
.....
.....
.....
|_ 0.02839469909 (9) [#1D](https://forum.espruino.com/search/­?q=%231D)
_| 0.00951004028 (3)
|_ 0.02837276458 (9) [#1E](https://forum.espruino.com/search/­?q=%231E)
_| 0.00948810577 (3)
|_ 0.02837276458 (9) [#1F](https://forum.espruino.com/search/­?q=%231F)
 | odd
 | stop
_| :             0.01068019866 (3+...) - prep CRC
|  start  CRC
|  0 0
|_ 0 1           0.00946521759 (3)
 | 1 2
 | 1 3
 | 1 4
 | 1 5
 | 1 6
 | 1 7    FC    
 | odd
 | stop
 | :
 | :
`;

End of TL;DR and back to the question:

What is wrong with my setup of Serial1?

Bitbanging shows that the device produces what it states... with the minor adjustment of the baud rate (which btw does not really matter, since the partner device is of the same make in hard and software (but I consider changing the device's code to be as close as possible to the 300 - or configurable - bps... after all, it does bit banging too, but no unpredictability by garbage collect or interrupts...). Bitbanging will also get me reading the device, but 40+ and the 32 Bit ST ... what ever should have outgrown that need... after all.

The device in today's money is about $1120... $290 then... Espruino Pico today cost about $25. Considering these numbers just from a point of money, would it be fair to conclude: You get what you pay for ? - The answer to that is an easy: no.

What do I do wrong in my Serial1 setup and use?