I finally got around to working on some hobby stuff this weekend. This time around I decided to play with the HLA plugin framework. Where I developed an HLA for the Silicon Labs Si4735 radio chip. Right now I only focused on enumerating FM command and properties; but I will likely expand on this to fully enumerate the FM RDS information and the AM radio commands/propertiesâŚbut its a start. I will likely focus on supporting the Si4707 Weatherband features before this though.
Comments on HLA
First off, this is a pretty great experience once you wrap you head around the framework. Here are some ideas/suggestions on this:
-
Provide a python test script to simulate some very basic frame sequences that the Logic software may send to the python module (depending on the DLL analyzer plugin being used).
- This would help to self document the normal communication flow of an HLA plugin but also provide some means for newcomers to debug their plugin. Maybe there is another way to debug I am not aware of (I am far from a python expert)?
- This could double as a standard unit test (pytest, unittest, etc) for the module which is probably a good idea anyways.
-
It seems there is a bug in passing the first I2C frame data in a capture to the HLA. I assume this may be specific to the I2C DLL analyzer plugin itself but I have not looked into this yet. I think you can see this behavior even in the provided HLA examples *.sal captures such as the gyroscope_hla capture.
-
With my Si4735 HLA, I notice that when zooming out, the frames that I use to convey a full transaction (write command, read response) become difficult to visually separate multiple transactions joined/squished together. On the normal DLL/C++ plugin framesâ a special bubble will be displayed on top of the frames indicating how many frames exist in the space. This also exists in the HLA but it activates way too late in my opinion to be useful in this case.
- If an example capture is desired I can produce one. I will likely create a public GIT repo for my HLA soon.
- One possibility to combat this could be to alternate the tint of the frames or uses ellipsis to indicate that the strings are truncated (which I think would be nice in any case). I made mock-ups in the image below.
- Also is there any plan to support multi-layered bubble text in the HLAs? This could also aid in readability, but I am not sure if there are any technical issues with this.
-
As I was developing the Si4735 HLA I noticed the I2C DLL analyzer plugin seems to report ânullâ in Decoded Protocols. I believe these exist due to accommodations made to support sending âstartâ and âstopâ frames to the HLA which do not include any clocked data. See image below.
-
If an HLA returns a frame data strings containing â=â (there are other special characters as well such as â>â) it will not be handled properly and be converted to â=â. I suppose there is some escape logic that may need to be included. Or maybe there is a way to do this already on the python HLA module?
-
A word of advise to anyone developing HLA modules for I2C. Be sure to offer address filtering support so that the HLA can coexist with other HLAs that are handling other address on the bus.
NOTE: I believe the Saleae HLA examples do not present this idea which I think the gyro example should probably be setup for.
Using the hla_gyroscopeâs Hla.py as the basis for my Si4735 HLA I included a check when receiving the âaddressâ frame which is based on a user setting. Since most I2C slaves offer some flexibility over the addresses, I provided a âchoicesâ option for this slave address for the acceptable addresses for this slave. See python code snippet.
Python Code Snippet
address = frame['data']['address'][0]
# Ignore transactions not associated with specified address
if (address & 0xFE) != (self.address << 1):
self.current_transaction = None
else:
self.current_transaction.address = address
self.current_transaction.is_read = (address & 0x01) == 1
P.S. If anyone is is carefully inspecting my images that is familiar with the Si4735 chip, take note that my plugin at the time of taking these screenshots had the interrupt flag for RSQ and RDS swapped. =)
Other Misc Comments
Glitch Filter
It seems V2âs support for glitch filtering is much more restrictive than V1âs implementation.
- Is there a plan to improve this to be as flexible as V1?
Specifically, V1 was able to set the filter in units of time (ms/us). It was also possible to set this on a per channel basis. The combination of these improves the flexibility of mixing high frequency analysis with low frequency. For instance capturing a slow 200 kHz I2C bus along side of high speed SPI @ 20-40MHz. With I2C glitches can be a problem when sampling as high frequencies so it would be nice to have the ability to only set the filter for I2C but not for the high speed SPI.
Also, V1 would reprocess the current capture when the filter settings were changed. I found this useful when trying to tune a filter setting based on current observations.
Marker Snapping
Another hopefully small request. In V1 when using markers, the marker would snap to not only edges (which V2 does) but also to sample points. In V2 it seems to allow for moving the marker seamlessly down to the nanosecond level. While in some cases this can be nice, I find V1âs behavior in general more useful since it helps to relay the actual sample points. If you sample at a really slow frequency then it becomes difficult to know where the âreal dataâ is versus the âinterpolatedâ.
- Maybe there can be an option to switch between behaviors here?
Analog Anti-Aliasing Filter
Is there a possibility to allow the user to disable anti-aliasing filtering done on the Analog signals?
I assume if the input waveform does not consist of frequencies well below the cutoff that the voltages indicated in the captured analog waveform cannot really be relied upon.
Currently with the filtering, I do not feel comfortable in trusting the voltage measurements unless the sample rate is around 5-10x faster than the highest frequency in the waveform. With an option to disable filtering we would not have any such limitation. Of course the waveform could be nonsensical when the signalâs frequencies exceed Nyquist rate. But even in such cases, the unfiltered voltage information could be useful data to have.
Effect of changing sample rate on the filtered signalâs reported voltage levels:
There is another topic of concern over the analog interfacesâ underlying bandwidth through the probes/jumpers to the ADCs and at these frequencies there may be end more substantial crosstalk⌠but if we can assume this is a non-issue, then one use-case of this is to take a long capture to develop some statistics over the waveform this does require some care on the userâs part to pick a good sampling frequency and maybe the Logic is not flexible enough in selecting a desired sample rate for this to be practical.
Aliasing in Drawing Analog Waveform Lines
Not to be confused with the previous section above, it seems the âanalog drawing processâ has some aliasing issues (for lack of a better word). Below you can see the waveform has missing segments. See image below.
I see the general use case of this is to take long analog captures to build up a statistical model of the voltage levels that have been sampled. And to be clear this isnât necessarily dealing with really high frequency signals, it could just be to deal with minimizing RAM utilization on the host PC (or dealing with scenarios where the PC cannot keep up with the sample rate requested).
On a somewhat related note to my comment above on âMarker snappingâ:
- Is there any plan to add the marker-dots that V1 had for displaying the sample points on the analog waveform? I suppose this information is already conveyed to some extend when you have âmeasurementsâ turned on and hover over the waveform.
Stream to Terminal
This hamburger menu option on a loaded plugin does not seem to do anything unless you recapture. Is this intended behavior? It is not an issue in either case, but I was sort of expecting it would regenerate the terminal outputâŚbut maybe this is not desirable for other reasons.
for another release fixing reported bugs very quickly and some neat new UI features.
