LogicAnalyzer V6.0

[DeeJay]

Congratulations on the Release of V6.0 of the LogicAnalyzer tools today.

Thank you for your continued efforts.

I am content for Issues #135 and #137 / #138 opened in my name to be closed as "Won't fix - superceded."

[gusmanb]

Thanks :)

Closed issues.

[DeeJay]

Should there be a V6.0 release of the Pico firmwares?

There doesn't seem to be anything like that ( .uf2 ) bundled with the linux-arm64 all-in-one zip.

[gusmanb]

Sorry, the fw files didn't got uploaded. Fixed.

[kd7eir]

Is there a firmware for the Pimoroni Pico 2 W Plus?

[gusmanb]

No, only Pico, Pico W, Pico 2 and Pico zero.

[DeeJay]

This may be premature in the absence of documentation, so mentioned here for discussion or feedback, not as a Bug Report...

Download for linux-arm64, running under 64-bit RasPiOS Bookworm on an RPi[5] board.

TerminalCapture app starts and creates a blue text-mode gui display. Any input (keystroke or mouse movement) other than Alt-C or Alt-D causes the gui display to dissappear but control is not returned to the shell from which TerminalCapture was initiated.

[gusmanb]

Thanks for the report.

I use Terminal.GUI as the main framework for the terminal app and it is using under the hood ncurses, I had myself problems with ncurses and raspbian in the past so it is possible that it could cause problems.

Try this build: https://mega.nz/file/3SB0BLzZ#7Fn3IVdMv8vKKyxlB22Lp3SXWzJ4SqjGVzWxOqEddMQ

Terminal.GUI has multiple drivers and it autodetects the best one for each OS, but I can force another driver, in this build I have forced the purely managed driver based only in .net itself.

[DeeJay]

That build of TerminalCapture seems stable under the circumstances I described.

[gusmanb]

Excellent :)

I will test next week under other OSes if the net driver does not cause any problem and if it works well then I will publish a fix version using only this driver.

[gusmanb]

New version published, TerminalCapture now uses by default the .net driver and as an option another driver can be selected via command line.

[DeeJay]

Re: Protocol Decoder Menu

Only tested on linux-arm64 release of LA 6.0 under 64-bit RasPiOS Bookworm.

There is a Search box at the top of the Decoders panel at the right side of the LA GUI.

This search option is active and usable when no external LA probe device has been configured, and also when such a device has been specified and connected.

But the Search dialogue box ceases to accept typed input once a Capture has been acquired.

A decoder can still be found and activated by using the drop-down menus below the Search box.

The Sigrok decoders for serial uart, pwm and ws281x all seem to correctly decode captured data as expected.

[gusmanb]

I've tried to reproduce it in Windows and Linux (Debian) and I'm unable, after capturing the box is still working as expected.

Did you take any extra steps before capturing?

[DeeJay]

I can confirm that the issue is still present in today's v6.0.0.1 release.

It is present in the linux-arm64 version shipped in the all-in-one bundle.

It is not present under Windows_x86 at the previous v6.0.0 release.

But I may have been mistaken about the pre-conditions for triggering it.

I can reliably reproduce the error if I use the ( i ) Device Information panel. A live capture is not a prerequisite.

(I assume I was using the Information panel to check on valid capture conditions in my previous test/report.)

The inability to enter text into the Decoder search box can also be triggered by using the Color Picker tool in the Capture dialog. Again, proceeding to acquire a capture is not needed to exhibit the problem.

In this respect it has some commonality with the 'feature' in Avalonia you dealt with a few months ago regarding 'Sticky Selections.'

[gusmanb]

Tried again using the device info and the color picker in Windows and Linux and still not able to reproduce, so it must be something explicitly in the arm64 version or in raspbian itself...

Next week will try to get a Pi in order to test it.