Perseverance pays off, I finally got it working.
Match continuous mode works very much like receive mode, and receive mode works like this:
o the shifter is initially cleared to all zeros.
o bits are shifted in on each clock.
o when the timer shift count reaches zero:
o the shifter value is transferred to the SHIFTBUF register.
o the shifter is cleared to all zeros to prepare for new data.
Match continuous mode works the same way except instead of transferring data to the SHIFTBUF, it compares data with the SHIFTBUF. But is still CLEARS THE SHIFTER WHEN THE SHIFT TIMER REACHES ZERO. This is true, even though the timer never disables. It will continue shifting in new data, but the previous data is lost after each timeout. I was not expecting this since it doesn't make much sense in this mode (this is match CONTINUOUS mode), and even in receive mode this behavior is undocumented, though somewhat obvious if you think about it. I had been mostly ignoring the shift count, so in all of my previous efforts, the shifter had been clearing before I had my data fully shifted in.
In my opinion, this is a bug, but it can be worked around by using the Reset feature of the timer. Just using a long shift count might work in some cases, but I am watching for a sync pattern that could occur at any time. Though reset sounds like just the opposite of what we want to do, reset actually returns the timer count to its initial value of TIMCMP, so by carful use of this feature, we can prevent the timer from ever reaching zero and the shifter will shift forever.
Another minor issue is that since the shifter is pre-loaded with zeros, zeros will immediately match for bits that have not been shifted in yet. So for example, a pattern of 0xff00 and an input of all 1's, will match when the pattern is shifted half way in (MSB first), because the zeros are already in the shifter. This is only an issue for the first bits after the shifter is cleared, but still might need a work around to prevent a false match.
My working configuration is shown here.
This circuit produces a trigger on each rising edge of the input, which should be a relatively slow square wave. Timer2 produces the shift clock, Timer3 is the shift count, Timer4 resets Timer3 before it reaches zero (so there isn't really a "shift count", but the timer is still required). Timer1 and Timer7 are just there so that we can see something happen. The shifter flag can not be directly routed to a pin, but it can trigger timers, so these timers just produce some visible activity when triggered.
Be aware that this "reset" trick does not work with the timer configured as a dual baud/counter. In this mode, Reset only effects the "baud" half of the timer, but it is the "shift count" that we need to reset.
My source code for this configuration is attached.
Perseverance pays off, I finally got it working.
Match continuous mode works very much like receive mode, and receive mode works like this:
o the shifter is initially cleared to all zeros.
o bits are shifted in on each clock.
o when the timer shift count reaches zero:
o the shifter value is transferred to the SHIFTBUF register.
o the shifter is cleared to all zeros to prepare for new data.
Match continuous mode works the same way except instead of transferring data to the SHIFTBUF, it compares data with the SHIFTBUF. But is still CLEARS THE SHIFTER WHEN THE SHIFT TIMER REACHES ZERO. This is true, even though the timer never disables. It will continue shifting in new data, but the previous data is lost after each timeout. I was not expecting this since it doesn't make much sense in this mode (this is match CONTINUOUS mode), and even in receive mode this behavior is undocumented, though somewhat obvious if you think about it. I had been mostly ignoring the shift count, so in all of my previous efforts, the shifter had been clearing before I had my data fully shifted in.
In my opinion, this is a bug, but it can be worked around by using the Reset feature of the timer. Just using a long shift count might work in some cases, but I am watching for a sync pattern that could occur at any time. Though reset sounds like just the opposite of what we want to do, reset actually returns the timer count to its initial value of TIMCMP, so by carful use of this feature, we can prevent the timer from ever reaching zero and the shifter will shift forever.
Another minor issue is that since the shifter is pre-loaded with zeros, zeros will immediately match for bits that have not been shifted in yet. So for example, a pattern of 0xff00 and an input of all 1's, will match when the pattern is shifted half way in (MSB first), because the zeros are already in the shifter. This is only an issue for the first bits after the shifter is cleared, but still might need a work around to prevent a false match.
My working configuration is shown here.
This circuit produces a trigger on each rising edge of the input, which should be a relatively slow square wave. Timer2 produces the shift clock, Timer3 is the shift count, Timer4 resets Timer3 before it reaches zero (so there isn't really a "shift count", but the timer is still required). Timer1 and Timer7 are just there so that we can see something happen. The shifter flag can not be directly routed to a pin, but it can trigger timers, so these timers just produce some visible activity when triggered.
Be aware that this "reset" trick does not work with the timer configured as a dual baud/counter. In this mode, Reset only effects the "baud" half of the timer, but it is the "shift count" that we need to reset.
My source code for this configuration is attached.
The configuration is shown here, it is also attached to the original post as a jpeg. I can send code if you like, but it is quite a lot.
-bill
