OrgZephyr/zephyr
OrgZephyr
/
zephyr
mirror of https://github.com/zephyrproject-rtos/zephyr.git
1
0
Fork 0
Code Issues Releases Wiki Activity
zephyr/tests/cmsis_rtos_v1/prj.conf

9 lines
141 B
Plaintext
Raw Normal View History

tests/cmsis_rtos_v1: Introduce tests to make use of Thread APIs Some test programs to illustrate the usage of thread APIs. Signed-off-by: Rajavardhan Gundi <rajavardhan.gundi@intel.com>
2018-06-19 12:05:35 +08:00
CONFIG_ZTEST=y
lib/cmsis_rtos_v1: Fix some Kconfig inconsistencies Fixed some Kconfig inconsistencies around THREAD_CUSTOM_DATA, POLL and NUM_PREEMPT_PRIORITIES. Signed-off-by: Rajavardhan Gundi <rajavardhan.gundi@intel.com>
2018-09-28 12:26:22 +08:00
CONFIG_THREAD_CUSTOM_DATA=y
CONFIG_POLL=y
tests/cmsis_rtos_v1: Introduce tests to make use of Thread APIs Some test programs to illustrate the usage of thread APIs. Signed-off-by: Rajavardhan Gundi <rajavardhan.gundi@intel.com>
2018-06-19 12:05:35 +08:00
CONFIG_CMSIS_RTOS_V1=y
tests: set CONFIG_MAX_THREAD_BYTES for a few tests Some tests instantiate a lot of thread objects. These were not tagged with __kernel, and CONFIG_APPLICATION_MEMORY was enabled, so the kernel was not adding them to the kernel object database. However, with CONFIG_APPLICATION_MEMORY disabled, this overflowed the default max number of thread objects (16). Increase the max to 32 for these particular tests. Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2019-02-01 07:09:41 +08:00
CONFIG_MAX_THREAD_BYTES=4
tests: cmsis_rtos_v1: Add additional test scenarios Add additional test scenarios to validate signal event APIs such as setting signal from ISR, setting/clearing each unique flag and few negative test cases too. Signed-off-by: Praful Swarnakar <praful.swarnakar@intel.com>
2018-09-08 07:30:35 +08:00
CONFIG_IRQ_OFFLOAD=y
tests: Mass SMP disablement on non-SMP-safe tests (Chunk 1 of 3 - this patch was split across pull requests to address CI build time limitations) Zephyr has always been a uniprocessor system, and its kernel tests are rife with assumptions and outright dependence on single-CPU operation (for example: "low priority threads will never run until this high priority thread blocks" -- not true if there's another processor to run it!) About 1/3 of our tests fail right now on x86_64 when dual processor operation is made default. Most of those can probably be recovered on a case-by-case basis with simple changes (and a few of them might represent real bugs in SMP!), but for now let's make sure the full test suite passes by turning the second CPU off. There's still plenty of SMP coverage in the remaining cases. Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
2019-02-23 03:45:23 +08:00
CONFIG_SMP=n