This may well be intended behavior, but I wanted to check. I'm updating pdportal to support the exciting new msg serial command. The current version uses ASCII Record and Unit Separator characters to delimit arguments and commands sent from Playdate to pdportal. This works as expected.
I was planning to use these characters in a similar way for communicating from pdportal to Playdate in the new release, but it appears those characters are dropped when sent with the msg command. For example, logging the length of the received string in my serialMessageReceived handler for this command gives 9 instead of the expected 10. The easiest way I know to visually see the US character in this string is to copy it to the Chrome console:
msg helo world
The character is also dropped if you try to paste it into the Playdate Simulator's console, unfortunately.
I'm currently working around this by using a multi-character delimiter instead, but It'd be great to be able to use these control codes if possible.
I spent some more time looking into this today, and there definitely appears to be something weird going on. Specifically, the device and simulator behavior seems to differ. I put together a minimal example: GitHub - paulstraw/pd-sdk-bug-16443. Apologies for the readme formatting, I seem to have confused GitHub a bit
When I send the same !msg s e command (which contains both a RS and US between the "s" and "e"), it's received as expected on sim, but not device.
I also wanted to note that even though these control chars are invisible in the Simulator Console window, they are present and send/receive fine. I was just confused originally because I hadn't tested sending messages to sim, only hardware.
Somewhat related (can be demonstrated with the same sample code), it seems that you can send msg commands of arbitrary length to the simulator, but not the device. Device messages cap at 251 characters (255 - 'msg ', I guess), but I've been able to send msg commands over 1.5 KB to the simulator.
Like with the ASCII control characters, I can get by either way if this is intended behavior. I think it'd be good to at least have the behavior match on sim and device, if possible.
I’m interested in this as well. I am excited about the msg command because once I get MicroPython going it should allow me to have a REPL on the device. However, to be maximally useful, it would need to be able to transfer arbitrary binary messages, even ones containing LF (0x0A) (which when sent literally seems to terminate a message), CR (0x0D) (which seems to be dropped), zeros and other bytes like your RS and US (which I haven’t tried yet). I wonder, will I have to build my own protocol on top of msg for that, or does it include a previously undocumented way already?
