You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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):
These are both reasonable behaviors. But there are other reasonable behaviors. Node-RED provides many options
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.
The text was updated successfully, but these errors were encountered:
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:
I have one question.
The "Serial Port" setting is different for serial communication between a microcontroller and a PC.
Are there any other differences?
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:
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):
These are both reasonable behaviors. But there are other reasonable behaviors. Node-RED provides many options
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.
The text was updated successfully, but these errors were encountered: