I like the color scheme in the Demo video! I don’t think it’s hard to read as you mentioned.
This kind of low contrast is very easy on the eyes, mine at least.
Default dark modes in other apps often display too much contrast, and turn out to hurt more than light themes. I’d consider keeping this palette as a “dark low contrast”, I think it’s great!
Interesting, thanks!
The reason I was so negative on it in the video is because several people have complained mightily about it. Personally, I can’t read it in the sunlight or show off features across a conference room table - otherwise imo it’s not bad.
Ultimately we will allow total end-user customization of colors. It’s only waiting on some UI design and it’s a lower priority than getting a couple of solid themes.
Hi,
You say you will allow for color customization.
Does this include HLA through the data dictionary?
Would be useful either to grab the underlying analyzer’s color and spit same or related color, but I have also in mind using this for analyzing (low level or hi level) adressable leds without effectively lighting them all the time. HLA side, I would think about some virtual pixel panel from python to export colors into an external GUI.
Hi Jean!
These aren’t set in stone, but there are 2 improvements that we have discussed internally:
)Like I said, these aren’t set in stone, so any other thoughts or suggestions you might have would be helpful!
Ryan
Hi Ryan,
I am currently working on a HLA for a device driven through serial.
Nothing rocket scientist, but since a serial has RX and TX wires, I have to use 2 inputs, then 2 HLAs (One for command, other for response).
One thing that is really annoying is the fact the HLA bubbles will always go on top of the screen, although you can drag it close to its input, you have to do this every time when you restart Logic.
I am wondering a way to remember the stack order to avoid this cumbersome mouse clicks and drags, as well as setting the color based ( or not) on the input color.(another use case for user coloring)
Of course, if I had a way to associate 2 serial data lines in one super HLA, it would be easier, but I understand it is probably too complex to manage.
I am also wanting to debug this somewhat complex HLA using VSCode, tried to attach the python file debug session to the Logic 2 process(es) but doesn’t works because no symbols attached to python class file.
I wrote test python and debug as is out of Logic, but it is difficult (and tedious) to simulate times for detecting gaps, timeouts… any idea for debugging in Logic thread?
Many thanks
Jean
Le mer. 18 mars 2020 à 22:14, Ryan via Saleae - Logic 2 saleae@discoursemail.com a écrit :
Hi Jean,
These are great ideas - I added them to our feature request board:
If you have a chance, please upvote them!
I am wondering a way to remember the stack order to avoid this cumbersome mouse clicks and drags, as well as setting the color based ( or not) on the input color.(another use case for user coloring)
We’ll probably end up adding the ability to customize colors from the HLA first, but basing it on the input color is really interesting. Differentiating the analyzers might be become less clear, but we will consider it.
Of course, if I had a way to associate 2 serial data lines in one super HLA, it would be easier, but I understand it is probably too complex to manage.
This is something we have talked about, but decided to skip for V1 of HLAs. We’ll definitely reconsider it in the future, but we don’t currently have a timeline for it.
I am also wanting to debug this somewhat complex HLA using VSCode, tried to attach the python file debug session to the Logic 2 process(es) but doesn’t works because no symbols attached to python class file.
I wrote test python and debug as is out of Logic, but it is difficult (and tedious) to simulate times for detecting gaps, timeouts… any idea for debugging in Logic thread?
I agree, debugging HLAs is a weak point right now. We’d like to, at a minimum, make it easy to view output from an HLA within the UI somewhere. I had briefly tried using ptvsd (GitHub - microsoft/ptvsd: Python debugger package for use with Visual Studio and Visual Studio Code.) to remote debug from VS Code, but haven’t had a chance to return to it. I’ll spend a little more time on it soon and see if there’s a path there to ship with support for ptvsd.
Since you have the full power of python within HLAs, you could try opening a log file from within your HLA and write debug output to it. It’s not ideal, but might be a sufficient interim solution until we add better support for debugging HLAs.
Thanks for the feedback!
Ryan
Thanks for the infos, very useful!
I found a solution to debug my HLA using unittest, and debugging Python from unittest with VSCODE insiders.
Additional value is to use TDD, which is far better for code quality
As you say, the timing stuff is a bit tricky, but I think I can simulate Logic2 behaviour quite accurately since the data structure, at least for serial, is quite easy to manage and inject.
Works fine so far.
Great idea! If you want real data for your tests, you could also try writing the data coming into your HLA’s decode function to a file, and then use that for unit tests.
Hi Ryan,
I am just working now on enhancing my 1st design, and this include taking account serial link errors (what I neglected at 1st to concentrate on application level messages). This is the hard part, since such errors are random and really difficult to track, and this randomness is generally what will make our life miserable in the real world.(see KurtE message elsewhere on Dynamixel protocol)
I am therefore planning to synthetize serial data from the same test script, injecting framing or parity errors to further refine and bullet proof the design. Obviously this has a bias, as I will not necessarily inject really random errors.
This has obvioulsy a big minus: I don’t use Logic in the test loop since I use unittest!
Then the question is “'how to put Logic in the unittest loop?”
Ideally, taking a “real” data from Logic2 and flipping one bit randomly would do the job and simulate closely what could happen in a noisy environment for instance. Test suite should be then:
Solution 1: Create test file based on existing capture sla file plus random bit flipping, load it into Logic, run Logic with this file (.sla) and HLA connected, and check the result either through unittest or visually.
Solution 2: Load real sla file, use Logic API (not available in Logic2 so far) to inject test data during unittest setUp() phase, then run the test and assert what is to be asserted.
In both case I’ll need to be able either to access sla file, or acces Logic internal data structure.
For instance, Logic Demo mode use some predefined or synthetized data out of device connection to demo purpose. Could it be possible to inject some data using this (now hidden) API?
Non intrusive way can be using .sla data file synthesis. Is sla file structure documented somewhere?
What do you think should be the best approach?
Hi Jean,
Unfortunately we don’t currently expose an API for injecting data in Logic 2 yet (as you mentioned), and the .sal format itself isn’t a documented format. Would it be possible to add real noise to the signal that is coming into the Logic device itself? If you do that, you could then write the frames that creates to a file, and use that in your unit tests. If I come up with any other ideas I’ll let you know!
Ryan,
Simplest idea is sometimes better!
I’ll try and let you know the outcome when I can proceed to the test.
Many thanks
Jean