Logic Analyzer support to Sigrok
kartikaysharma01 opened this issue · comments
This issue will act as a plan page for the Logic Analyzer integration. All the steps and discussions can be documented here.
The first step would be to create a new driver by the name PSLab Logic Analyzer.
The next step would be to implement the device scan for the driver.
I think we should discuss the configs to avoid future blockage and confusion. I have identified the following:-
- channels to capture events on
- no of events to capture
SR_CONF_LIMIT_SAMPLES - timeout - how long the acquisition should run
SR_CONF_LIMIT_MSEC - e2e_time - the maximum time between events in seconds SR_CONF_SAMPLE_INTERVAL
- logic_mode SR_CONF_PATTERN_MODE
- trigger_channel
SR_CONF_TRIGGER_SOURCE - trigger_mode SR_CONF_TRIGGER_PATTERN
@bessman Is there something else the user can set?
@bessman I have added links to the config keys I will be using(and am not completely sure about), it'll be great if you can have a look at them. Will also discuss these with the sigrok community, if there are any views from them.
About e2e_time, what would be the ideal/expected range of input values for it?
timeout - how long the acquisition should run
SR_CONF_LIMIT_MSEC
The documentation for this key says:
/**
* The device supports setting a sample time limit (how long
* the sample acquisition should run, in ms).
*/
Which is not exactly the case. The device itself does not support this, it is handled in the driver. I.e. if the timeout is reached the acquisition is stopped by the driver by sending STOP_LA. The key may still be appropriate to use, however.
e2e_time - the maximum time between events in seconds SR_CONF_SAMPLE_INTERVAL
From the documentation, I think this key is meant for somethjing like the timegap of e.g. our oscilloscope than the e2e_time. What e2e_time actually does is set a prescaler to slow down the logic analyzer's timers. But I can't find a better match for what we want to do. I guess technically we can just use any key for any purpose? Check with the sigrok community if they have a better suggestion, otherwise go ahead.
Alternatively, I been playing around with the idea of setting this automatically. Since this is only used in 3- and 4-channel mode, we could use 2-channel mode to find the largest expected e2e_time for each channel before starting the actual capture. In other words, something like this:
- User wants four channels (let's say LA1-4).
- Use 2-channel mode with remapping to check first LA1-2 and then LA3-4 and find the largest event-to-event timegap.
- Set prescaler accordingly.
The problem with this is that step 2 takes a while. Since the largest timegap we support in 3- and 4-channel mode is 262 ms, we would need to capture a least twice that long, twice. With some overhead, that's almost a second of preparation before every capture. Perhaps doing so could be the default, with a way to disable it? That would require a bunch of extra config keys though...
logic_mode SR_CONF_PATTERN_MODE
Similar to the previous comment, this one seems like it's intended for a signal generator instrument rather than a logic analyzer.
trigger_mode SR_CONF_TRIGGER_PATTERN
This looks right, but I'm unsure how it relates to sr_trigger_match.
I've been thinking that perhaps we should combine the trigger_mode and logic_mode settings into a single setting. The value of being able to set a different trigger event than the event type to capture is questionable, and it's obviously quite confusing. We can discuss it during the next meeting.
@bessman Is there something else the user can set?
That should be it.
From the documentation, I think this key is meant for somethjing like the
timegapof e.g. our oscilloscope than thee2e_time. Whate2e_timeactually does is set a prescaler to slow down the logic analyzer's timers.
The reason we used samplerate for oscilloscope instead of timegap is that we can only input integer values for the configs SR_CONF_SAMPLE_INTERVAL and with the oscilloscope, it was very important to let the user set float values of timegap. But I believe e2e_time does not pose us with a necessity to input float values.
That brings me back to my previous question, What would be the expected range of input values for e2e_time? This would further clarify if we can/should use SR_CONF_SAMPLE_INTERVAL or not
I guess technically we can just use any key for any purpose? Check with the sigrok community if they have a better suggestion, otherwise go ahead.
Yes, it is not ideal but we can use any key for any purpose. I will see if the sigrok community has some suggestions on the same.
Perhaps doing so could be the default, with a way to disable it? That would require a bunch of extra config keys though...
This seems interesting. Let's follow up on this in the next meeting.
logic_mode SR_CONF_PATTERN_MODE
Similar to the previous comment, this one seems like it's intended for a signal generator instrument rather than a logic analyzer.
Yes, But I could not find a more appropriate config_key for this and looking at its usage in the demo device tempted me to go for it.
trigger_mode SR_CONF_TRIGGER_PATTERN
This looks right, but I'm unsure how it relates to sr_trigger_match.
From what I understand, sr_trigger_match would require us to use the config SR_CONF_TRIGGER_MATCH but that I believe would restrict us to using these which is not our use case.
That brings me back to my previous question, What would be the expected range of input values for e2e_time? This would further clarify if we can/should use
SR_CONF_SAMPLE_INTERVALor not
Expected values are between 1024 µs < x <= 262 ms. If the time between events is less than or equal to 1024 µs the default prescaler (1) is optimal. If the time is greater than 262 ms 3- and 4-channel mode cannot be used.
We have 7 digital input channels -- "LA1", "LA2", "LA3", "LA4", "RES", "EXT", "FRQ"
The device allowing capturing events on 4 channels simultaneously, we can capture on any one particular channel or any two channels from the 7. But if we have to capture more than two channels, it has to be in the order "LA1", "LA2", "LA3", "LA4"
@bessman Is this correct?
In case the user wishes to capture on "LA1", "LA2", "RES" or "RES", "EXT", "LA3", "LA4" we must throw an error? Especially in the second case, can we map the "RES", "EXT" channels?
The first two channels can be freely remapped, so "RES", "EXT", "LA3", "LA4" is possible. However, we should remove the ability to select "EXT" as a digital input.
"EXT" is a bit of a mystery to me. It may have been connected to an external pin in an earlier revision of the hardware, but it isn't any longer. In the next revision, it is connected to the SD-card reader, which should not be exposed via the logic analyzer in this manner.
Since the pin number is currently the same as the channel index in the list ("LA1", "LA2", "LA3", "LA4", "RES", "EXT", "FRQ"), we need to be careful to make sure "FRQ" is remapped correctly when we remove "EXT".
OK, after checking the firmware, it turns out it does not support channel remapping in 3- and 4-channel mode. You are correct, "RES", "EXT", "LA3", "LA4" is NOT possible and we must throw an error if the user requests it.
It is unclear if this is merely a limitation of the firmware, or if there is an underlying hardware limitation. If not, the new firmware may not have this problem. But for now, this is what we have to work with.