Quick update:
working:
- Putty
- Tera Term
- pqcom
- Realterm
not working:
- hterm
- YAT
- my C# (most important! )
Noone any ideas?
using HTERM with RP2040
C# Serial Connection to RP2040 (was Re: using HTERM with RP2040)
Now that's a completely different question.
How are you generating the output on RP2040 MicroPython that you want to read with C#? If you're using print(), it should be sending UTF-8 characters (with no BOM) + LF. C#'s SerialPort.ReadLine looks like it's expecting the same (unless you've redefined C#'s Newline, that is).
If you're using write() from MicroPython, it doesn't append any LF automatically, so ReadLine in C# won't be happy.
I don't know how C# handles UTF-8. The last time (long time ago) I had to use anything MS-derived, it forced all I/O to UTF-16, which made me sad.
Re: using HTERM with RP2040
It's not a problem of coding chars, because data is perfectly received as 8bit-ASCII e. g. with 'pqcom'.
Python works perfect on Windows as well, but not C#. C# detects the connection, opens the port, but does not receive anything (class System.IO.Ports.SerialDataReceivedEventArgs).
Python works perfect on Windows as well, but not C#. C# detects the connection, opens the port, but does not receive anything (class System.IO.Ports.SerialDataReceivedEventArgs).
Re: using HTERM with RP2040
but what about the C# equivalent of readline? If it can't read incoming characters, but Python can, then there are bigger problems with your system.
You don't accidentally have the device opened by another process, do you?
You don't accidentally have the device opened by another process, do you?
Re: using HTERM with RP2040
The type of a serial input is always byte, but C# simply doesn't even trigger that event.
Well, yes, I also thought about a different task blocking that, especially because the USB of the RP2040 may provide different services. That's why I also tried the Zadic driver (https://zadig.akeo.ie/), but the result is the same.
Well, yes, I also thought about a different task blocking that, especially because the USB of the RP2040 may provide different services. That's why I also tried the Zadic driver (https://zadig.akeo.ie/), but the result is the same.
Re: using HTERM with RP2040
Finally it was totally simple: It was the handshake! OMG, how could I oversee that
Normally, it's allways no handshake on a physical interface because 2 lines are less efford than for lines , but the RP2040/Micropyhton obviously uses (virtual) HW handshake by default. Enabling flow control and setting DTR high soved the problem with HTerm and most likely it'll work with C#, too, of course.
Thank you for all the ideas!
Normally, it's allways no handshake on a physical interface because 2 lines are less efford than for lines , but the RP2040/Micropyhton obviously uses (virtual) HW handshake by default. Enabling flow control and setting DTR high soved the problem with HTerm and most likely it'll work with C#, too, of course.
Thank you for all the ideas!
Re: using HTERM with RP2040
I completely disagree. In my early days in IT EVERY serial connection (Modem, Terminals, even my 300Bd acoustic coupler) used RTS, CTS and DTR.
A visit to a customer required two handful of breakout boxes, zero-modem adapters and 9 to 25 converters.
A few hours of debugging might save you from minutes of reading the documentation!
My repositories: https://github.com/karfas
My repositories: https://github.com/karfas
Re: using HTERM with RP2040
Ok, in my EARLY days as well.. I remember I put an optocouper to the RI line to detect incoming FAX.. Oh my god - I'm old!
In fact, I was talking about µC and serial. When handshake is used today, it is used as PIO for reset or entering programming mode, altough the classic usecase may still be useful for some applications. Honestly I never saw one, but I'm more focussed on RS485 and CAN.
In fact, I was talking about µC and serial. When handshake is used today, it is used as PIO for reset or entering programming mode, altough the classic usecase may still be useful for some applications. Honestly I never saw one, but I'm more focussed on RS485 and CAN.