Some interesting finds...
Not sure what you meant by the suggested code. With the default block as you had it enc would never change and so the code would do nothing.
I have minimised my code
Code: Select all
void encoder_task()
{
int enc;
while(TRUE) {
select {
case p_encoder when pinsneq(enc) :> enc :
p_pll <: 1;
p_pll <: 0;
break;
}
}
}
This produces the following.
There is now a 60ns lag and a 10ns pulse produced. As well as by minimising the code, I previously got the result by using an [[ordered]] select with the p_encoder case first. Interestingly, changing the SystemFrequency in the XN file has some interesting effects. This result is at the default 500MHz. Changing it to 300 or 600 makes the lag 90ns, with an inconsistent pulse width of 10 or 20ns. 800MHz has a 60ns lag but a 20ns wide pulse. i.e. fast System clock gives a slower response, which is somewhat not expected.
Now, with default:
Code: Select all
void encoder_task()
{
int enc;
while(TRUE) {
select {
default:
p_pll <: 1;
p_pll <: 0;
break;
}
}
}
This produces a strange result. Firstly it produces a reasonable square wave with a 50ns between pulses and a 10ns pulse. This is consistent with the triggered behaviour, implying that the select:case takes 50ns to run. However, every so often (random, but averaging ~30s) it switches mode. The other mode has a 50ns space and 30ns pulse. i.e. the code behaviour is inconsistent, but it appears to run in one of two modes.
So,
QUESTIONS:
1) Is this as fast as the response to an event can be?
My next plan is to play with pin clock timing, but I only expect that to shorten the pulse width, not to affect the response time by more than 10ns.
2) Any explanation of the two modes of pulse width in default mode?
Could this be the system clock PLL and the pin PLL coming into and out of sync?