Open ikarus23 opened 4 months ago
The first is a non-issue - as there is no signal (and parity is disabled), it's just informing you that there were n framing errors... UARTs are typically idle-high, and if the line is low for an extended period then it is either a break (technically also a framing issue), or an invalid signal.
https://en.wikipedia.org/wiki/Universal_asynchronous_receiver-transmitter#Break_condition
Yes, this I understand. Just wasn't expecting "warnings" when doing nothing. Also, the fill up the screen fast. But true, receiving nothing (idle-high) could technically be interpreted as framing errors. I guess the easy way is just to change the log level, right?
Just wasn't expecting "warnings" when doing nothing.
I consider this the desired behavior since it's an abnormal state indicating a connection error, a faulty transmitter, or some other condition you want to be aware of. I do not consider it a concern that when you are not actually using the applet for its only purpose you're getting what may seem to be spurious warnings.
2. If I run the applet in pty mode, canceling with CTRL+\ q is terminating the program with a core dump
If you run it in PTY mode it does not instruct you to use Ctrl+\ q
because that kills the application with a core dump. Ctrl+\ is SIGQUIT; it's used in the TTY mode because it's difficult to find an escape character that's not otherwise used. This is expected behavior.
3. If I run the applet in pty mode, canceling with CTRL+C is terminating the program with errors
That seems like a bug.
This is expected behavior.
(That said, I'm wondering if we should switch to a different escape sequence and/or trap SIGQUIT and make it synonymous to SIGINT normally because training users to do a thing that most of the time coredumps is bad.)
I consider this the desired behavior
It was just new to me because other USB to UART converters (e.g. FTDI, etc.) don's show that. But fair enough, I understand you point.
If you run it in PTY mode it does not instruct you to use
Ctrl+\ q
Correct. I just tired it because Ctrl+c
did not work either. I did not know that it sends a SIGQUIT.
That seems like a bug.
Ok. :)
Thank you for the hard work on the project. Feel free to close this issue or to change its title to something more appropriate (e.g. "Bug when closing UART applet in PTY mode using Ctrl+c").
It was just new to me because other USB to UART converters (e.g. FTDI, etc.) don's show that. But fair enough, I understand you point.
One thing we can do is simply add a pullup on the RX line.
So reading through this issue with a fresh pair of eyes:
So I think there's actually three issues here, but it's a little more subtle than what it looked at first.
Is it worth the (small, I think) effort to change the message to not mention parity errors if parity is none? FWIW, I also like that it informs me when the DUT stops pulling it's transmit line high.
Is it worth the (small, I think) effort to change the message to not mention parity errors if parity is none?
Yes, happy to merge a PR right away.
@whitequark FWIW, no I don't care about a warning message :) And I also only use my revABs with custom applet anyway.
@smunaut Thanks. n=1 isn't a lot but it's better than n=0, so I'll go with an unconditional pullup and we can fix it later.
Anyone in this thread wants to add the pullups? You can glean how from the I2C applet.
We are now unconditionally enabling pulls on the UART applet: https://github.com/GlasgowEmbedded/glasgow/pull/583
This leaves SIGQUIT and the deadlock on Ctrl-C as the remaining issues.
Hi. My Glasgow just arrived today and I'm very exited. I've just tested the UART applet with nothing connected and made some observations. Not sure of what to make of them. Maybe they will help with development.
none
by default.[ Nothing happens after the first CTRL+C ]
^C Traceback (most recent call last): File "/home/ikarus/.local/bin/glasgow", line 8, in
sys.exit(run_main())
^^^^^^^^^^
File "/home/ikarus/Programs/glasgow/software/glasgow/cli.py", line 937, in run_main
[...]
KeyboardInterrupt
[ Nothing happens, lets press CTRL+C a third time ]
^CException ignored in: <module 'threading' from '/usr/lib/python3.12/threading.py'> Traceback (most recent call last):
[...]
KeyboardInterrupt: