Bureaucrats, dave_user, Administrators
8,204
edits
Changes
no edit summary
{{AppliesToAxel}}
{{AppliesToAxelLite}}
{{AppliesToAXEL Lite AN}}
{{AppliesToSBCX}}
{{InfoBoxBottom}}
{{WarningMessage|text=This application note was validated against specific versions of the kit only. It may not work with other versions. Supported versions are listed in the ''History'' section.}}
|Update for XELK 2.0.0 release
|-
|[httphttps://www.dave.eu/siteslinks/defaultp/files/files/an-xelk-001-amp-linux-freertos.pdf 0qKejH20HFSu3oWn 0.9.3]
|April 2015
|2.0.0
|2.1.0
|Update for '''amp-feat-2.1.0-amp''' branch
|-
|1.0.1
|October 2018
|2.1.0
|Minor improvements
|-
|1.0.2
|October 2018
|2.1.0
|Added some details about <code>latencystat</code> test application
|}
-----------------------------------------------------------
Histogram Bucket Values:
Bucket 666 393 ns (44 26 ticks) had 135 1 frequency Bucket 681 409 ns (45 27 ticks) had 204 475 frequency Bucket 696 424 ns (46 28 ticks) had 335 1058 frequency Bucket 712 439 ns (47 29 ticks) had 371 57 frequency Bucket 727 681 ns (48 ticks) had 66 frequency Bucket 742 ns (49 ticks) had 81 frequency Bucket 757 ns (50 ticks) had 1 frequency Bucket 2075 ns (137 45 ticks) had 1 frequency
-----------------------------------------------------------
Histogram Data:
min: 666 393 ns (44 26 ticks) avg: 696 409 ns (46 27 ticks) max: 2075 681 ns (137 45 ticks)
out of range: 0
total samples: 11941592
-----------------------------------------------------------
</pre>
This application is extremely useful for evaluating measuring interrupt latency and for verifying how it is affected by relevant parameters such as the CPU load on the first core, memory bandwidth utilization, the amount/rate of interrupts to be processed by the first core affects IRQ , operating frequency, etc. For instance, the previous data refer to the following configuration:*[[FAQs_(Axel)#Q:_How_can_I_change_the_CPU_clock_frequency.3F|governor]]: <code>userspace</code>*nominal operating frequency: 800 MHz (actual: 792 MHz)*core #0 (running Linux) lightly loaded with minimal I/O activity. In general, it is strongly recommended to characterize the latencyon the basis of a '''realistic testbed that is as close as possible to the actual use case'''. In It is also worth remembering that, in case of latency does not satisfy the application's real-time requirements, it may be necessary is possible to adjust the arbitration priorities of processor's interconnect subsystemto reduce it.