On 28/03/2018 01:28, Joel Sherrill wrote: > On Tue, Mar 27, 2018 at 8:05 AM, BRIARD Sebastien > <sebastien.bri...@thalesaleniaspace.com > <mailto:sebastien.bri...@thalesaleniaspace.com>> wrote: > > Okay, I realized how I was confusing clock tick (for timekeeping) and > interrupt latency and why the result were not the ones I expected. > I still have one question, is there a macro to choose/impose the processor > frequency ? > > If you mean the actual clock rate of the CPU, then it would be a BSP specific > option and > it would have to match the hardware. All the BSP options for this BSP are in > c/src/lib/libbsp/arm/xilinx_zynq/configure.ac <http://configure.ac>.
The frequency for the Cortex-A9 is exported in the Xilinx headers created when you export the design in Vivado. You need a way to import those defines into your code. A few of the clock related set ups in this BSP use weak symbols so you can provide a version in your code that matches the frequency your designers have set up in Vivado. > For the clock tick length, you have to balance overloading the CPU with clock > tick > interrupts on one extreme and not advancing time on the other. Your 1 > microsecond > per tick is dangerously close to the no forward progress end. At some point, > you > have to consider that it takes a minimum number of instructions to process the > interrupt and from that a minimum length of time. > > At near 1 Mhz, you can probably handle the 1 usec clock ticks alone but there > won't > be much time left to do real work. I experimented years ago on a 400 Mhz > embedded PowerPC and you could go very low on the clock tick but it was > clear from the test code I was running that you lost more and more > non-interrupt > processing time to do application processing. So as the interrupt rate went > up, > the overall application throughput went down. Looking at one interrupt on a Zynq I have at hand I am seeing a minimum time of 1040 nsecs and a max of 3597 nsecs. This is the time from raising the request, getting into the interrupt and acknowledging it in a PL register. These times are measured in the PL so no software or related overheads involved. Chris _______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
