Testing
On the unit level, mostly standalone libraries are tested (i.e. queues, allocators). Components that are tightly bound together were often neglected. The most prominent issue is the event system. Channels and synchronization primitives can be tested, as long as they do not interact with the event system. To test these modules as well dependencies need to be weakened inside the kernel. One solution would be to introduce traits for components and a kernel builder. The builder could inject mocks for testing.
Between the last project and this thesis the system-level testing method was changed from instruction tracing to signals using pins. Using the Digilent Digital Discovery proved to be much more straightforward and more suitable for automation. Tracing still required manually evaluating instruction counts. Using a logic analyzer instead of an instruction tracing device is also more approachable because of the price difference. The test setup was used to evaluate interrupt latency and context switching time from a semaphore event. These limited tests prove that the method works and serve as a basis for further test cases.
The testing concept does not yet support the user in any way. As a first step, traits should be introduced for the complete kernel API. By mocking or stubbing kernel calls, the user could test individual threads. For an integration test of multiple threads or processes on the host system, a kernel emulation would be necessary. Though, the emulator is considered nice to have.