Attached is (A) a sketch that measures timings for adc reads, digital read, write, toggle, shortest pulse, and interrupt latency measured as time from edge assertion to the user supplied ISR, and (B) a header file generated by the sketch that lists the measured timings. The timings are measured by the processor cycles counter and some where checked with a scope (see the image below).
The latency is the issue I would like to inquire about. The ARM documentation describes 12 cycles to get to a non vectored interrupt. But the measured time in the tests is and average of 104 cycles and a maximum of 123 cycles (173 nsecs to 205 nsecs). That is incredibly slow and the jitter is incredibly large for a real time platform.
The ARM documents describe what sounds like a very nice realtime oriented interrrupt facility, with an easy interface to c code and a rapid context save to stack, as is the case in most processors designed for realtime applications. So, it seems like we ought to be able to get to something close to spec on the latency.
The question then is:
How do we setup an ISR so that we have faster entry, ideally - close to the spec, and with minimal jitter?
Here is the promised scope image produced by the latency test. Two pins are bridged, the isr is attached to one, and triggered by writing high to the other. The isr reads the cycle counter and returns the digital level to low. We see the duration as 210 secs, similar to the reported maximum duration.
The latency is the issue I would like to inquire about. The ARM documentation describes 12 cycles to get to a non vectored interrupt. But the measured time in the tests is and average of 104 cycles and a maximum of 123 cycles (173 nsecs to 205 nsecs). That is incredibly slow and the jitter is incredibly large for a real time platform.
The ARM documents describe what sounds like a very nice realtime oriented interrrupt facility, with an easy interface to c code and a rapid context save to stack, as is the case in most processors designed for realtime applications. So, it seems like we ought to be able to get to something close to spec on the latency.
The question then is:
How do we setup an ISR so that we have faster entry, ideally - close to the spec, and with minimal jitter?
Here is the promised scope image produced by the latency test. Two pins are bridged, the isr is attached to one, and triggered by writing high to the other. The isr reads the cycle counter and returns the digital level to low. We see the duration as 210 secs, similar to the reported maximum duration.