Dear Huber,
I think that there is limitation using RTEMS profiling feature, too.
Instead of this method, I am using hardware assitance method using GPIO
signal as like below;
void bsp_interrupt_dispatch(void)
{
volatile gic_cpuif *cpuif = GIC_CPUIF;
uint32_t icciar = cpuif->icciar;
rtems_vector_number vector = GIC_CPUIF_ICCIAR_ACKINTID_GET(icciar);
rtems_vector_number spurious = 1023;
if (vector != spurious) {
uint32_t psr = _ARMV4_Status_irq_enable();
gpio01_19_high(); /* Signal High */
bsp_interrupt_handler_dispatch(vector);
gpio01_19_low(); /* Signal Low */
_ARMV4_Status_restore(psr);
cpuif->icceoir = icciar;
}
}
When I check GPIO signal using digital scope, I can check average duty
cycle.
Do you think that it is good method ?
There is additional question.
I think that CPU time percentage using "cpuuse" is CPU time consuming value
except interrupt handler consuming time.
Is it correct ?
Best Regards,
Thomas
2018-01-12 15:03 GMT+09:00 Sebastian Huber <
sebastian.hu...@embedded-brains.de>:
> On 12/01/18 02:38, Thomas Kim wrote:
>
>> Dear Sir,
>>
>> As I checked until now, thread(task, pthread) cpu load analysis method
>> using "cpuuse" is perfect !
>>
>> At this time, I am doing multiple device interrupt hander stress testing.
>> but, there is not CPU load anaysis method about multiple device interrupt
>> handler.
>>
>> Is there any method for checking CPU load about multiple device interrupt
>> handlers ?
>>
>
> The is limited support for this. You can try to use enable the profiling
> option:
>
> cpukit/sapi/include/rtems/profiling.h
>
> For interrupt profiling a BSP support is necessary. I think it is only
> implemented on ARM, PowerPC and SPARC currently.
>
> The RTEMS trace linker is also an option.
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>
_______________________________________________
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
