I’m looking to write a decoder for a SPI based protocol that has a few OOB signals (a data/control signal being one of them but also a reset and a cs). Is there a way I can use the time of the message (eg the start time) to query the value of another channel to include it in the decode?
I’d also like to be able to provide timing context of the messages wrt the digital channels, perhaps there is something to search for an edge in a certain direction from a timestamp too?
I’m trying to reverse engineer a reference implementation driving a small lcd module similar to https://learn.adafruit.com/adafruit-mini-tft-0-dot-96-inch-180x60-breakout - I have the basics right and it works 80% of the time but the timing wrt to CS/DC/Reset and power on are all important to me.
Thanks for the HLA capabilites, it’s a great feature.
Hi @TomKeddie - sorry for maybe butting in here. But first I second the idea of maybe having the SPI allow another signal like DC(Data/Command) as there are lots of devices (especially displays) which use this concept.
For what it is worth on the Teensy (T3.x, T4.x, T-LC) We do have the support for this display in our library (ST7735_t3/ST7789_t3) and of course Adafruits library supports it as well. Again not sure if it would help. But the PR into that library which added it was:
Note: for me the Reset pin does not matter much here. I do include it often, but it either works or not and only done once…
Again I don’t know any of your details here, like which actual display, which processor, are you using SPI library or rolling your own. If rolling your own does your hardware allow using something like hardware FIFO for SPI or double buffering. The biggest things I have run into with issues like you mention, is having the code change either the DC or CS pin while the SPI is still in the middle of a transferring bits…
Good luck, and again I do like the idea of having more support either directly within the SPI low level analyzer or allowing an HLA to support additional pins.
We’d like to support both multiple analyzer inputs and inputs from digital channels, but unfortunately I don’t have a timeline for when that will happen. The process for working with LLAs is not as convenient as HLAs, but our LLAs are open-source, so you could add extra functionality that is specific to your use-case. The SPI LLA is at https://github.com/saleae/spi-analyzer/tree/alpha - that specifically links to the alpha branch, which has support for HLAs (via FrameV2). I’m happy to help if you decide to go down that path.
That’s awesome that you’ve open sourced the LLA for spi, I’ll take a look. Now I can add the timestamp delta feature I’ve been wanting (delat rather than time since start of capture). I’ll look at adding support for the digital channels I need too.