Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Input & Output data encoding #3

Open
phoddie opened this issue Apr 5, 2024 · 3 comments
Open

Input & Output data encoding #3

phoddie opened this issue Apr 5, 2024 · 3 comments
Assignees
Labels
enhancement New feature or request

Comments

@phoddie
Copy link

phoddie commented Apr 5, 2024

Let's discuss how the payloads for read and write are handled.

For write, you convert the input string to a UTF-8 encoded buffer with "\n" appended:

this.#serial.write(ArrayBuffer.fromString(msg.payload + "\n"))

For read, you read all the bytes into a buffer, interpret that as UTF-8 to generate a JavaScript string, and then trim any whitespace from the end (including carriage returns):

let msg = String.fromArrayBuffer(this.read());
msg = msg.trimEnd()

These are both reasonable behaviors. But there are other reasonable behaviors. Node-RED provides many options

image

It provides a binary option, for situations where the data is not text. This is definitely useful, as many devices that use serial communicate in binary.

Node-RED doesn't use UTF-8. Instead, it uses ASCII. Serial is so old, it pre-dates Unicode so this is probably reasonable even if it seems old-fashioned.

Node-RED has an option to add a character at the end of a write ("Add character to output messages"). But, it is optional. This seems important since sometimes the app wants to control all the data.

Node-RED also has "framing" options -- "Optionally wait for a start character of " and "Split input". These are useful, but complicated.

Anyway... I think you might want to support some of the same options as Node-RED. Most are pretty straightforward to implement (I am happy to help) except for framing. But, I think first you should decide which capabilities are a priority.

@404background 404background self-assigned this Apr 6, 2024
@404background
Copy link
Owner

Thank you @phoddie !
I see, the binary option seems necessary.

For the options, I think it would be a good idea to implement it with reference to node-red-node-serialport.
It will be easier for users if it can be used just like a serial node on a PC.

Here is the config option for the serial-port node:
serial-port

I have one question.
The "Serial Port" setting is different for serial communication between a microcontroller and a PC.
Are there any other differences?

I will implement the binary option as a priority.

@404background 404background added the enhancement New feature or request label Apr 6, 2024
@phoddie
Copy link
Author

phoddie commented Apr 6, 2024

Binary definitely makes sense as a next step.

But... have you seen this work by @ralphwetzel? I just discovered it today!

@404background
Copy link
Owner

I also discovered it today!
In v1.5 of node-red-mcu-plugin , it says "Support for node-red-node-serialport on MCU's".
https://github.com/ralphwetzel/node-red-mcu-plugin/releases/tag/v1.5

There seems to be some differences from node-red-node-serialport.
I also will try to implement my node with reference to node-red-node-serialport!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

When branches are created from issues, their pull requests are automatically linked.

2 participants