P2 CEM-L does not like CAN_L_PIN driven by interrupts at all.
Waiting for my new logic analyzer...
P2 CEM-L does not like CAN_L_PIN driven by interrupts at all.
Might be able to stabilize it further. The Cortex-M7 is the first ARM microcontroller to use Branch Prediction. Turning off Branch Prediction might result in more stable latency measurements.
Thanks. STD maybe a tad more stable with BP turned off, but the code still has to poll pin 2 directly (no interrupt). This is understandable: Renesas is much faster than old Motorola, needs higher precision. What I still don't understand is why 719/720 cracks only with latency measurement (pin 2) driven by interrupt, which is far less precise.RickHaleParker wrote: ↑01 Mar 2022, 14:52 Might be able to stabilize it further. The Cortex-M7 is the first ARM microcontroller to use Branch Prediction. Turning off Branch Prediction might result in more stable latency measurements.
Found this code snip which is said to turn off Branch Prediction. No idea how to turn it back on but figure you code guys can figure it out.
void branchPredictionOff(){
SCB_CCR &= ~SCB_CCR_BP;
Serial.println("set branch prediction off!") ;
}
Found it here.
Hum ... we don't really need precise measurements what we need is "relative precision". The difference is what we are looking for not the magnitude. What effects would a interrupt have on "relative precision" .
Because the chip spends most of its time in delayMicrosecond(), it probably goes into lower power mode, which means lowering frequency, turning off some circuits, flushing all kinds of caches, etc.RickHaleParker wrote: ↑02 Mar 2022, 03:26 What effects would a interrupt have on "relative precision" .
The person that was experimenting with Predictive Branching did not get the results they where looking for. The last line in the post is " Can it be data-cache filling?" . The flushing of caches might be the answer.
In 719/720 case the key is to round up unlock message intervals to ~2ms. It is cracking happily with CAN FIFO interrupts enabled, etc, just needs a pause. The latency distribution looks very differently: in our old high-speed mode the latency groups in 2-3 buckets near average latency, in 2 ms delay mode it spreads almost evenly across a dozen or more buckets. So the CEM's MCU "relaxes" and allows some sort of cold start of the pin compare routine, which yields more distinguishable latency for the good subsequence.RickHaleParker wrote: ↑02 Mar 2022, 15:27 The interrupt does seems to have the effect I was hoping for. Eliminating or reducing overhead interference which induces random artificial delays in the latency measurement. Consistent artificial delays would not be a problem, it is the inconsistent ones that give us grief.
In the context you are using. What exactly is a bucket?