dimitris wrote:Dear Sethu,
thank you for your reply. I have tried your solution before and it still gives the same results.
Sethu's code is better for slow signals (like you have), since the thread
will go to sleep while waiting for the input to change, saving power.
It however will take an extra thread cycle for the thread to wake up,
which is fine for slow signals.
Here are some images taken from the oscilloscope. The first is an example at 800KHz and the second at 2MHz.
You can see that the output(yellow) reacts to the input(red) but not copying it. This is where my question focuses.
Yes, that is very curious. Both pieces of code should copy the input
(with some delay and some jitter).
For a slow signal like yours, the rise/fall of the output isn't nearly as
steep as expected, and the input isn't exactly clean either. I would
suspect the measurement setup and the circuitry in general.
On the bottom left you can also see that the delay between the signals is the same on both occasions. Also the pulse width of the output (yellow) signal is always the same ~110ns too.
My idea is that the output should follow the input with a small delay. However the output rises with a delay of 80ns and then after 110ns it falls back to zero. Instead of copying the signal, this code is doing clock edge detection. Which is useful but not for what i need. :-)
PS: The ~90ns delay between input and output is by far more than expected since these actions are single instruction ones. So I see another task here. How fast does the XMOS react to input after all?
First, the signal is synchronised to the system clock (2.5ns, assuming
a 400MHz clock). The I/O block normally processes things on the
reference clock (100MHz, so 10ns). Your code will have at least four
core cycles between instructions (more if more than four threads are
running), so that's 10ns per instruction. For the output, you have
pretty much the same thing (in the opposite order). This doesn't add
up to 90ns. My first suspect is your code is too slow -- did you do an