==Characterization and performance tests==
TBDWith the system configured as described above, we run some basic test to verify if and how the non real-time world may influences the real-time world. We did the following tests:* Linux side:** idle** Google stressapptest <ref name="SAT">https://code.google.com/p/stressapptest/"</ref>, stressing memory and SD I/O* RTOS side:** idle** memory intensive task The RTOS memory task access an array in main memory of two different size:* the smaller is half of L1 size (16KiB)* the larger is 4 times the L1 size(128KiB) The main task on the RTOS side is the ''latencystat'' demo provided with [[AN-BELK-001:_Asymmetric_Multiprocessing_(AMP)_on_Bora_–_Linux_FreeRTOS|AN-BELK-001]]<ref name="AN-BELK-001"></ref>, which:* program PS TTC timer as freerun, triggering an interrupt on overflow* inside the overflow ISR it read the TTC counter: this counter reports the number of ticks passed between the event (overflow) and the handler itself, in other words our latency* after a while the TTC is reprogrammed and interrupt enabled again, to trigger another event* those ''latency counter'' are collected into an array* the Linux-side application, by default after 10 seconds, stop the RTOS task which sends the array data over RPMS* the Linux-side application collect the data and display the mininum, maximum and average latency measured The following table summarize the test results {| class="wikitable"|-! Lantecy !! Linux idle<br/>RTOS idle !! Linux SAT<br/>RTOS idle !! Linux SAT<br/>RTOS 16k !! Linux SAT<br/>RTOS 128k|-|}
==Conclusions and future work==
