fasteddy516 / simplyserial Goto Github PK

See mu-editor/mu#1371. SimplySerial may be able to do something similar as far as identifying boards using the port's friendly name rather than the USB PID/VID craziness.

Sometimes I need to paste a large text (e.g. to upload intel hex), and it seems that SimplySerial adds artificial delay that makes pasting anything more than a dozen lines painful or even impractical. Artificial pace is a useful feature, but please consider making it optional and user adjustable.

According to an official Adafruit learn guide, the recommended default baud rate for CircuitPython devices is 115200, not 9600 as currently used by SimplySerial. Lots of other devices (at least the ones I interface with) use 9600 as the default, however, so I think SimplySerial should switch to 115200 baud for known CircuitPython devices, and stick with 9600 for unknown devices.

It would be useful to apply our own label to the shell tab instead of the com port info. Just a simple command line input with string. When multiple terminals are open it would be easier to identify with longer labels.

I am using this program very well.
However, I want to output Korean on a serialized window,
The beta support is only up to UTF8, so it doesn't output normally, but is there a future support plan?
I don't intend to distribute it, but can I modify the code and try it?
Thanks.

Hello,

Thanks for a wonderful app. My use case is to run this from Windows Terminal to connect to a proprietary hardware device over RS232 using a USB to Serial adapter. Everything works great except sending arrow keys for the (somewhat) menu based navigation on the device. I think I need to just send arrow keys, but I'm not 100% sure. Unfortunately, I can't provide a lot of detail regarding the device itself, but can test.

Running SimplySerial 0.7.0 on WIN10

Hi eddy,
Would you consider adding support for input configuration file? I have it working on my local machine. I used -i:input.txt, where the input.txt contains the line separated options.

Regards,
Kiran Francis

I almost always have multiple CircuitPython devices connected, which means I almost always have to run ss.exe with the -c command-line option to specify which device to connect to. If there is more than one com port available, SimplySerial should - by default - display a list of com ports and allow the user to choose which one to connect to.

I'm not sure how they do it in Mu (haven't looked at the source code at this point), but it would be awesome to auto-detect CircuitPython boards on machines where there are multiple COM ports.

PuTTY has a set of terminal options that would be handy to implement in SimplySerial:

• Implicit CR in every LF
• Implicit LF in every CR

These options help with readability when dealing with devices/protocols that only send one or the other (typically just CR, I believe) and end up just overwriting the same line over and over again.

The "nothing written for 10 seconds" log timeout introduced in 0.5.0-beta.2 doesn't actually work as intended since it will only be triggered if there is also no incoming serial traffic for that duration.

Window 8.1, dot net 4.8. Wemos Mini D1 with latest micropython 1.19

Unhandled Exception: System.Management.ManagementException: This method is not implemented in any class
at System.Management.ManagementException.ThrowWithExtendedInfo(ManagementStatus errorCode)
at System.Management.ManagementObject.GetMethodParameters(String methodName, ManagementBaseObject& inParameters, IWbe
mClassObjectFreeThreaded& inParametersClass, IWbemClassObjectFreeThreaded& outParametersClass)
at System.Management.ManagementObject.InvokeMethod(String methodName, Object[] args)
at SimplySerial.SimplySerial.GetSerialPorts()
at SimplySerial.SimplySerial.Main(String[] args)

It would be cool if other baud rates than the predefined list was supported. Is there a technical reason why it is limited like this?

Hi, I really like your work.
I use it for Pi serial monitor, but have issue with auto connecting to my LTE modem that I have in my thinkpad.
Could you add something like blacklist so autodetection and connection would't connect to those COM ports?
They don't change number of port so it would be easy to separate.

I'm not familer with C#,so I would preciate if you can tell me the whole process of building the compilation environment，such as what IDE to use and how to import your source code to compile.

It would be useful to allow modifying the default startup parameters. Possibly using the config XML system built into .net (rather than registry stuff). Would require two new command-line arguments, one to store settings, one to show defaults, maybe a third option to reset to original values. Could also indicate that default values are modified somewhere in the connection header.

Built-in (on-board, whatever you want to call them) serial ports seem to have a different hardware naming convention that doesn't match up with the VID/PID identifiers we expect from USB devices. This results in a messy connection header and -list printout.

Since scoop is getting more and more popular on windows platform, I think we can leverage it so make it easier for people to install your excelent tool.

Please consider this
Please let me know if I can help.

Check in teminals below:

1. Windows Terminal
2. CMD

I have no idea what the feasibility of this is, but having an actual VSCode plugin that exposes SimplySerial as its own window/panel/terminal type/whatever without hijacking the standard terminal window would be lovely.

I would love to have SimplySerial installed through a traditional setup/installation wizard that allows the user to choose the installation folder, gives them the option to add the location to the system path, etc.

I briefly looked as NSIS, and Inno Setup, but didn't wait to jump down any of those rabbit holes at the time.

The available ports list needs more robust filtering - SS thinks that it's ok to try to connect to parallel (LPT) ports, and who knows what else. We should - at the very least - enforce a "if it doesn't have 'COM' in the name, don't consider it a valid COM port" rule.

Is there a reason for the system .msi installer to block on Windows Server 2022? The .exe from the stand-alone .zip releases executes just fine.

I'm trying to figure out how to get SS to display extended character sets and am not 100% sure that I'm even doing this right. I'm running under Terminal on Windows 11 and I note that SS does not seem to be able to render anything apart from the first 127 chars of ASCII character set. High ASCII block drawing chars and UTF-8 don't seem to be working correctly.

Here's some output as it appears in PuTTY, utilizing CaskaydiaCove Nerd Font Mono which should be a reasonably-complete character set:

Note that °F, µg/m³, and m/s² all render correctly here

Here's an example of similar output utilizing SS.exe in Windows Terminal, again with CaskaydiaCove Nerd Font Mono. Note the text being sent as 66.20000 °F renders as 66.20000 ??F in SS. Other not-7-bit-ASCII chars all similarly render as ??.

Now I hit Ctrl+X to exit SS.exe, and in the same terminal session I copy/paste from PuTTY to spit output back to the screen.

This suggests that Windows Terminal is able to correctly display these glyphs when asked to do so.

Right now, if the active COM port connection drops (i.e. CircuitPython device gets disconnected, etc.), SimplySerial will stop gracefully on a System.IOException error.

Ideally, SimplySerial could keep track of the specified COM port, and - if it re-appears (i.e. CircuitPython device gets re-connected), it would automatically restart the serial session.

I'd like to use this to monitor several embedded devices connected over COM ports to my Windows box. This works great for getting the data into a terminal window, but I'd like a way to specify a file where all the received bytes can also be written for later analysis. I'd suggest

• -log:<path to logging file>
• -logappend:<path to logging file>

with -log replacing the file and -logappend appending to an existing file

With multiple COM ports available, auto-detection correctly connects to the first available serial port when starting/running the first instance of SimplySerial. Running a second instance should automatically connect to the next available port, but it just stops and waits for the first port to become available.