gillham
commented
11 years ago I've fixed this, but it appears that triggers are not quite as reliable on PORTD, but I am still testing. I input the same square wave on two pins and set them to opposite trigger values and occasionally the trigger still fires. It shouldn't fire as the pins should always be the same value, either up or down and the trigger is asking for opposite values. Anyway, by defining USE_PORTD (just uncomment it) you can use PORTD and triggers do seem to work generally. I set the default back to PORTB with CHAN5 (LED pin 13) enabled by default as well. PORTB seems more reliable right now but I will keep testing it. Thanks for you bug report and apologies for not getting this simple fix into the main code for so long, but I had to order a replacement OpenBench Logic Sniffer and get setup again.
When using bits 2-7 (6 channels) of port D on an (e.g. Arduino) no trigger events were acknowledged. Looking at the code this appears to be because the SUMP/OLS channels are 0 based while the port D assignments start at bit 2.
I tested this with the OLS/SUMP client from J.W. Janssen at lxtreme.nl. And an Arduino UNO.
I made a simple change on the "trigger=" and "trigger_values=" processing of the SUMP commands: case SUMP_TRIGGERMASK: / * the trigger mask byte has a '1' for each enabled trigger so \ we can just use it directly as our trigger mask. / getCmd(); trigger = cmdBytes[0]<<2; break; case SUMP_TRIGGERVALUES: / * trigger_values can be used directly as the value of each bit * defines whether we're looking for it to be high or low. */ getCmd(); trigger_values = cmdBytes[0]<<2; break;
I suspect the correct implementation should correctly determine whether to shift of not based on the configuration.
Rick Sorensen rick.sorensen@gmail.com