search

fossasia / libsigrok

Read-only mirror of the official repo at git://sigrok.org/libsigrok. Pull requests welcome. Please file bugreports at sigrok.org/bugzilla.
https://sigrok.org/wiki/Libsigrok
GNU General Public License v3.0
333 stars 8 forks source link

Logic Analyzer support to Sigrok #11

Open kartikaysharma01 opened 3 years ago

kartikaysharma01 commented 3 years ago

This issue will act as a plan page for the Logic Analyzer integration. All the steps and discussions can be documented here.

kartikaysharma01 commented 3 years ago

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.

kartikaysharma01 commented 3 years ago

I think we should discuss the configs to avoid future blockage and confusion. I have identified the following:-

@bessman Is there something else the user can set?

kartikaysharma01 commented 3 years ago

@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?

bessman commented 3 years ago

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:

  1. User wants four channels (let's say LA1-4).
  2. Use 2-channel mode with remapping to check first LA1-2 and then LA3-4 and find the largest event-to-event timegap.
  3. 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.

kartikaysharma01 commented 3 years ago

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.

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.

kartikaysharma01 commented 3 years ago

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.

bessman commented 3 years ago

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

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.

kartikaysharma01 commented 3 years ago

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?

bessman commented 3 years ago

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".

bessman commented 3 years ago

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.