Hi Joel

My customer request me to use RTEMS 4.11.3 so i need to use this version.

Also consider that the FPGA based CortexM3 use a 133 MHz clock so I’m quite 
surprise that there could be problems with this CPU/clock.

Anyway, since by apply little modification to some tests (just like the ones 
I’ve indicated) all test complete correctly, from your point of view this 
solution could be considered valid in order to accept the BSP  ?

At the moment I don’t see any test failed because of a critical issue (such as 
a broken driver or incorrect time measurement): almost all problems are on 
synchronization between tasks, avoidable with minimal modifications on task’s 
source code.

Best Regards.

Dr. Michele Dekleva

Da: Joel Sherrill <j...@rtems.org>
Inviato: mercoledì 25 marzo 2020 14:20
A: Sebastian Huber <sebastian.hu...@embedded-brains.de>
Cc: Michele Dekleva <michele.dekl...@m3t.it>; rtems-us...@rtems.org 
Oggetto: Re: R: sptest SP06 strange behaviour

On Wed, Mar 25, 2020, 8:06 AM Sebastian Huber 
<sebastian.hu...@embedded-brains.de <mailto:sebastian.hu...@embedded-brains.de> 
> wrote:

Hello Michele,

I am not sure if the RTEMS 4.11 test suite works with an interrupt
driven console driver. I would use the RTEMS master for new BSPs anyway.

You should use polled or the buffered test IO option. By using an interrupt 
driven console, you are introducing more scheduling points than the test was 
designed for.

FWIW I have never seen mass failures like yours from an interrupt driven 
console. It is usually just a few oddities in output order. Maybe the M3 is 
slow enough that things are skewed even versus the boards I remember from the 
early 90s.

But switching to the master is always good advice for new BSPs


users mailing list
users@rtems.org <mailto:users@rtems.org>

Questa e-mail è stata controllata per individuare virus con Avast antivirus.
users mailing list

Reply via email to