gillham/logic_analyzer

trigger triggers for any single matching bit, not for a set of matching bits

dhiltonp opened this issue · 1 comments

```while ((trigger_values ^ (logicdata[logicIndex] = CHANPIN)) & trigger) {```

should be more like:
while ((trigger | (logicdata[logicIndex] = CHANPIN)) != trigger | trigger_values) {
Unfortunately, that hangs indefinitely, but I think it conveys the point.

Also, for 6-channel systems, we need to make sure we mask all 8 bytes from CHANPIN; something like:

#ifndef CHAN7
      if(trigger) {
        trigger |= 0xC0; // mask the top 2 bits, too
      }
#endif

I've created a "triggered" branch with these changes, but it doesn't work.

The spec calls for triggering on a match for all enabled bits/channels in "parallel" mode. I only trigger on one level ("Stage 1" in the client) of trigger values. Meaning you can look for b00000101 (lines 0 & 2 high (or low depending on the trigger value)) and both have to be high (or low) to match the trigger. It can't be any one of them are matching. While I can see the benefit of triggering on "either one of these lines match the trigger value" that isn't my interpretation of the protocol.

With the SUMP protocol the client knows how many channels are available on the AGLA. In the trigger configuration it only allows you to check off the bits/channels for those that exist.
So the trigger mask for a 6 channel with all 6 channels enabled for triggers would look like:
b00111111
So bits 6 and 7 are not enabled for triggers so their values will be ignored.
In the case of someone commenting out CHAN5 (making this a 5 channel AGLA) then the client will get the metadata that says only 5 channels are supported and the trigger mask (if all channels had trigggers enabled) should be:
b00011111

It is possible I guess for a person to build a 5 channel and the client not use the metadata and think it is 6, but I think that is unlikely since the client reads the metadata. OLS client, not sure on Sigrok.

If you create some test code (maybe C on Linux) that can demonstrate a bug or not following the protocol please reopen this or open a new one. Thanks.