Usually when debugging I have a debug UART spitting out information on my boards. It would be really useful if I could take one of the pins from the analyser and use it to receive ASCII text in a separate terminal like window. Saves me having to plug in another usb device, open another terminal program. Is this possible?
Trev
Hey Trev,
I’m not sure that I understand. Would you like the data of each UART channel to be displayed on a different terminal? or would you like to use your own terminal instead of the built-in one?
Thanks for the feedback!
I want the option to display ASCII uart data like a terminal program. So it displays lines of text, \n\r stuff is processed\ etc. You know when you connect to a the debug port of a linux board for example and you get the full boot messages? It would be nice to be able to use a logic analyser to read that data in whilst doing other stuff as well.
Hi, have finally sat down to debug some work and can properly explain the requirement. I have a unit that I am debugging. I have serial data coming out that gives me useful messages. It would be nice to be able to read them properly like a terminal window. The Terminal output doesn’t format well as can be seen from the screenshot.
Being able to use a pin or 2 of the analyzer as a serial connection with properly formatted data would be a nice feature.
You’re absolutely right. The issue is the output format of the analyzers and we’re working on fixing that (Async Serial for a start).
Well if the data could be streamed to a network port maybe something like putty could pick it up and it would save you a job?
We can stream it to a network port, however, I’m not sure how it’d help if the format is “broken”.
Well once fixed if each analyser could output to a port that would be great
Can you elaborate on that? What’s the purpose of streaming it to a network port?
I want to make sure that we’ll build this feature correctly
If its streamed to a port I think putty can pick it up and that means the debug data window is outside of the saleae app. I can resize the putty window and move it to a different display.
Thumb up for the request. It would be incredibily useful and data can be formatted very well with something like YAT or Putty. Actually for windows it so easy: it would be enough that the program would open one or more than one virtual COM port and send everything there. Almost all the necessary is written… could be just an expansion. And with the “stream mode” it would be a extremely nice tool to sniff SPI, I2C, and every existing protocol!
So the feature would be reducted in this sentence: streaming the decoded protocol into a virtual COM port opened “ad hoc”.
This would open a lot of more scenarios for using the logic analyzer.
Interesting! We’ve actually implemented something very similar a few weeks ago, however we haven’t exposed the functionality to users yet. We rewrote the terminal implementation and changed 2 things:
Here is a sample of writing all bytes 0-255 to the new terminal. This has been in the last few releases. The tiny text you can’t quite read are the Unicode control pictures for characters like null. tabs, line feeds and carriage returns are interpreted as the correct control character by the terminal. I think there are still 5 characters that fall back to “?” because there is no displayable version in any encoding scheme.
It is intresting, but redirecting everything to virtual COM port would be:
I wasn’t sure whether to reanimate an old thread or start a new one but the idea above about redirecting the terminal output to a virtual com port is such a good one I though I’d jump on the bandwagon here.
I actually came on to post a suggestion for the terminal window but found this while searching to check if the question had already been asked.
My scenario is that I’m trying to sniff traffic between two devices that use 115,200 async serial to communicate. The standard analyser windows on loop get me what I need but it’s a bit hard to read conversations vertically 
The terminal window would help with that but the devices don’t use ASCII, just predefined control codes that are 5 bytes long.
What would be ideal for me would be if the terminal window could be set to display hex (if that’s already there, I’ve missed it) and to shift to a new line every time the source pin changes which would make it very easy to identify call and response.
However, that’s fairly specific to my requirement and wouldn’t work well in a scenario where there was simultaneous traffic in both directions. Hence the idea of being able to shovel the decoded data out via another com port (or API) would allow people to write their own decoders?
Obviously the output would need to be tagged with the source port in some manner.
I’ve achieved the same with two cheap USB to UART devices but just thought it would be a great additional feature for Logic 2?
Redirecting all data from the serial monitor to a virtual COM port would be a great feature. Since it doesn’t exist in the software (2.3.10) I’ve done it on Windows through my custom High Level Analyzer, a helper C# application and the com0com software. If anyone else also needs this, here’s the summary of what I’ve done:
Then, added this to the top of the HLA code:
PYWIN32PATH = 'C:\\Python38\\Lib\\site-packages\\win32'
if PYWIN32PATH not in sys.path:
sys.path.append(PYWIN32PATH)
import win32pipe, win32file
def pipe_stream(self, data):
try:
pipe = win32file.CreateFile("\\\\.\\pipe\\PipeServer",
win32file.GENERIC_READ |
win32file.GENERIC_WRITE,
0, None,win32file.OPEN_EXISTING,0, None)
some_data = data.encode('ascii')
win32file.WriteFile(pipe, some_data)
except:
pass
and under decode, added this:
self.pipe_stream("Some value")
Then I created a virtual COM port using com0com (COM24 and COM25 in my case). Verified the COM ports were working using PuTTY.
Then, created a pipe listener on C# based on this example: https://www.codeproject.com/Articles/1199046/A-Csharp-Named-Pipe-Library-That-Supports-Multiple
in the pipe listener, I get the data from the HLA:
private static SerialPort port = new SerialPort("COM24", 115200, Parity.None, 8, StopBits.One);
static void Server()
{
while (true)
{
using (var server = new NamedPipeServerStream("PipeServer"))
{
server.WaitForConnection();
var reader = new StreamReader(server);
var received = reader.ReadLine();
port.Write(received.ToString());
}
}
}
and voila, the data is visible on PuTTY.
The drawback of this method is, the pipe cannot handle the speed of the data if the frequency of your data is too high, so some data can be lost in between. You must find some custom way to verify the integrity of your data.
Awesome work! This is exactly the sort of stuff I’m excited to see come from HLAs. I look forward to fixing the module install experience, although unfortunately we won’t be able to get to it for a while.
Interestingly enough, we also use a named pipe in the application to get data from our analyzers into the terminal. We were considering looking at supporting multiple connections, so outside applications could use the same connection, but I think having an HLA do it us much more flexible, since named pipes are only one possible solution for streaming the data, and they are quite finicky to work with.
Other ideas that I think would be interesting: