[PATCH] bsp/lpc1768_mbed: Disable unsupported tests

[Sebastian Huber]

On 26/02/2019 00:03, Joel Sherrill wrote:
>
>     > OPERATION_COUNT is usually the number of objects (e.g. tasks,
>     semaphores,
>     > etc) created so it is the maximum object count. For example,
>     tm03 has this:
>     >
>     >
>     https://git.rtems.org/rtems/tree/testsuites/tmtests/tm03/system.h#n29
>     >
>     > |#define CONFIGURE_MAXIMUM_TASKS (3 + OPERATION_COUNT) |
>     >
>     >
>     > So when Sebastian changed this,  it went from a run-time to a
>     link time failure.
>     >
>
>     Ah ok, it is nice to see the error on these targets at link time.
>

Yes, the space for fixed count objects (not unlimited) is now allocated 
by the linker. So, an INTERNAL_ERROR_TOO_LITTLE_WORKSPACE changed into a 
linker error.

>
>     > The intent of OPERATION_COUNT was to be able to scale the timing
>     tests down
>     > to the hardware platform. Dropping OPERATION_COUNT to 10 for
>     these BSPs
>     > will resolve almost all of the tm and psxtm linking issues from
>     what I can tell.
>
>     What about a way to set this value in the `.tcfg` files and then
>     provide it on
>     the command line as a compile option?
>
>
> This would be awesome! OPERATION_COUNT is an area where our old
> build system person didn't want to tread. Much like the entire tcfg 
> system.

Yes, moving the test suite specific OPERATION_COUNT from the bsp.h to 
the *.tcfg would be good. However, I would like to resolve the build 
errors as soon as possible. So, change the patch to define 
OPERATION_COUNT to 10 and adjust the *.tcfg accordingly?

-- 
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.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.