I’m trying to write a custom HLA for TFT displays using SPI as the LLA. I’ve already managed to identify some commands sent to the display. Nevertheless I don’t know how to check the status of the line “Data/Command” that is not part of SPI. Any guides on this regard?
@maurosmartins Sorry for the late reply! We’re just returning from the holidays now. For your question below:
Nevertheless I don’t know how to check the status of the line “Data/Command” that is not part of SPI. Any guides on this regard?
Can you let me know a little more about the “Data/Command” line? Our HLAs are limited to working with the frames that the underlying LLA produces. It unfortunately doesn’t have the ability to check the status of channels that are not attached to the LLA.
For your question on the analyzer bubble text output, I’ll review it with the team here and will follow up with you.
There are lots of SPI based displays like: ILI9341, ILI9488, ST7735, ST7789, … That use a D/C pin as part of their communications, that use this pin like logically an SPI 9 bit communications, where the pin (or 9th bit) signifies if the byte is a command or data bytes associated with the pin. For example from the ILI9341 manual:
thank you for your reply, I’ll be waiting for the comments on the analyzer bubble.
regarding previous question, as @KurtE explained (thank you), the “Data/Command” line is an extra line that tells the display if current information on SPI is Data or a command. Can’t the raw status of all channels be checked when running the “decode” function?
@KurtE Thanks for jumping in! The image helped a ton. It makes sense now.
@maurosmartins To my best knowledge, the raw status of any channel cannot be checked by HLAs. In addition to your other question about the analyzer bubble, I’m going to double check this with the team here to see if they know of a workaround.
Apologies in advance as I most likely won’t be able to review this with the team until early next week due to the New Year holidays coming up. I’ll follow up again once I’ve had a chance to discuss this with them.
In the meantime, you would need to modify the C++ SPI analyzer to include the extra channel, and to indicate the channel state in the FrameV2 object that’s passed up into the HLA.
We’re in the process of making the C++ FrameV2 API public right now, however it can be used to day simply by looking at the existing SPI analyzer source code, which is already using the new API feature: GitHub - saleae/spi-analyzer at alpha
Unfortunately, this is a good bit more complicated than just adding a few extra lines of code to your python HLA. We’re focused on analog features at the moment, and unfortunately won’t be back on extension development for a while. (Our SW team is 3 developers)
Sounds like an interesting approach, which I have thought of wanting for awhile, who knows maybe at some point will take a look. Wonder how common it is for devices to use this… As I mentioned earlier have seen it on many displays.
New user to Saleae. First use case is exactly what’s being described here. Analyzing SPI communications for TFT LCD and e-paper displays.
In addition to the MISO, MOSI, CS and CLK signals, most displays also use D/C and RST (reset) lines for control. E-paper displays also output a BSY (busy) signal when they are updating the contents of the display (shouldn’t try to access the display when it’s busy).
Being able to separate out commands and data in the trace and data tables would be a very good add, either by extending the existing SPI analyzer or creating a “Displays” extension on top of it that would qualify the data.
Right now I’ve kind of faked it by defining the DC line as the MISO signal so it shows up in the the data table, but it’s be nice to be able to include any other signal as part of the SPI group and send that directly to the table.
@xylopyrographer Since you brought up your workaround of defining the DC line as a MISO signal, I’m now wondering if it may be possible to simply add 2x SPI analyzers while configuring both to take a look at the DC line as the EN line. One SPI analyzers would be configured with an active low EN, and the other configured as an active high EN like in the image below.
So question to self or others:
a) Can I store it as a bit in mFlags (That is what I am trying now),
b) store as lets say high bit in data1 or 2… and punt on handling 64 bit transfers working with DC… But I never do that anyway so…
Also is there a way to run this under debugger these days? Running on Windows 10.
Hey @KurtE, we haven’t documented nor fully verified the ability to debug custom analyzers on Logic 2. We only have this documented for the older Logic 1.1.18 software, which unfortunately can’t be used with our Gen2 hardware (Logic 4, Logic 8, Logic Pro 8, and Logic Pro 16).
However, a community user seems to have found some success with getting debugging working on Logic 2. Their forum post on this topic can be found below:
But if I click on the 3 dot it shows that I should be outputting HEX… so question is do I
need to encode the values: to a hex string, and where do I in the Python code get what the
user wants the output format to be?
Also side comments. I started the python code in one directory… Can I move it to another directory? If so How do I update the list?
Also side question, If I look at some published HLAs, they may mention to customize it, clone the project… And then click the local button… Not sure how to do that…