espruino / Espruino

The Espruino JavaScript interpreter - Official Repo
http://www.espruino.com/
Other
2.76k stars 741 forks source link

UART options not working #2324

Closed estallio closed 1 year ago

estallio commented 1 year ago

Hi,

I'm currently trying to let my Puck.js communicate with an UART device. For test purpose, I connected the Puck.js to a serial-to-USB adapter and accessed the serial interface via Tera Term and Hercules Terminal. All worked fine when setting the options to 8N1 or leaving it blank. However, when I turned on parity or switched to 7 bytesize, the bytes I'm receiving from Tera Term are messed up. Interestingly, the output/shift of the characters is constant and the difference is the same. For this reason, I think there is some bytesize/parity issue in the UART code.

My code (working as expected without parity errors):

Serial1.setup(9600, {
  rx: D29,
  tx: D28,
  bytesize: 8,
  parity: 0, // same as null or default
  stopbits: 1,
  errors: true
});

Serial1.on('data', function (data) { console.log("<Serial> "+ data); });

Serial1.on('parity', function() {
  console.log("Partity Error");
});

setTimeout(() => {
  Serial1.print("Hello World abcdefghijklmnopqrstuvwxyz");
}, 5000);

This code also works:

Serial1.setup(9600, {
  rx: D29,
  tx: D28,
  bytesize: 8,
  parity: 'e', // same as 2 or 'even'
  stopbits: 1,
  errors: true
});

Serial1.on('data', function (data) { console.log("<Serial> "+ data); });

Serial1.on('parity', function() {
  console.log("Partity Error");
});

setTimeout(() => {
  Serial1.print("Hello World abcdefghijklmnopqrstuvwxyz");
}, 5000);

However, this code does not work:

Serial1.setup(9600, {
  rx: D29,
  tx: D28,
  bytesize: 8,
  parity: 'o', // same as 1 or 'odd'
  stopbits: 1,
  errors: true
});

Serial1.on('data', function (data) { console.log("<Serial> "+ data); });

Serial1.on('parity', function() {
  console.log("Partity Error");
});

setTimeout(() => {
  Serial1.print("Hello World abcdefghijklmnopqrstuvwxyz");
}, 5000);

Here some images from the WebIDE and Hercules Terminal:

image

image

My usecase is to communicate with 7E1. Especially with 7 bytesize, it does neither work with even, nor with odd or no parity. However, with no parity in 7E1 I don't get an error, but the serial output is wrong. Here are some screenshots from this setting:

image

image

When I look into the bits of the message or print them with data.charCodeAt(0), the characters á has an ascii number of 225. The expected character a has an ascii number of 97. The bitmasks of 97 is 1100001 and the bitmask of 225 is 11100001. Same error occurs with Tera Term or other characters. Most likely there is a parity issue somewhere.

Puck.js v2: v2.16 Google Chrome: v110.0.5481.78 Espruino WebIDE: v0.76.4 Tera Term: v4.106 Windows 11: v22621.1105 Hercules Terminal v3.2.8

PS: I also randomly get serial readings when I power the Puck.js with a CR2032 battery. No issues when I power it with an external energy source.

Thanks in advance!

gfwilliams commented 1 year ago

Hi,

Sorry for the delay - I've just looked into this, and unfortunately the actual UART hardware on the nRF52832 chip doesn't support 7 bit or non-even parity: https://infocenter.nordicsemi.com/pdf/nRF52832_PS_v1.4.pdf

I'm wondering what the best way of handling this is... 7 bit + parity is effectively transmitted/received the same as 8 bit without parity, so I guess we could detect if 7 bit is specified and if so could mask of the received data to 7 bits - parity wouldn't be checked but at least you'd get the right data.

Do you need to be able to send data as well? If so then we'd have to calculate the parity bit inside Espruino and then set the top bit of the data we send to that, but it could work...

PS: I also randomly get serial readings when I power the Puck.js with a CR2032 battery

Have you got ground connected as well as serial RX/TX? If not then that could explain the bad readings?

gfwilliams commented 1 year ago

Ok, just added 7 bit support via software. If you use one of the latest cutting edge builds I think this should be fixed.

It should all be fine apart from 8O1 which will now error, as this can't be done with the chip's hardware

estallio commented 1 year ago

Thanks! It works now :)