I participated in the development of a RTOS for an embedded DSP core with a distributed memory architecture and many levels of parallelism. The OS kernel was less than 700 words, but it had the ability to overlay code and data, schedule multiple concurrent threads, respond to I/O interrupts quickly, and it abstracted the DMA engine so the user did not have to write complex DMA transactions by hand.
My primary responsibilities were to help design and develop the host side component of the RTOS. The host component was basically an API that a programmer could use to perform various functions such as, load modules on to the DSP core, communicate with the DSP, interrupt the DSP, perform I/O with the DSP, and schedule threads for execution. Due to the fact that the RTOS was going to be used with many different host environments I also developed a very low level general I/O API that I ported to every host environment that BOPS supported (eCos, Windows, and Linux). This low level API made it very easy to develop BOPS DSP applications (such as the RTOS) that were targeted at more than one host system.
I also helped develop the tool used to compile the binary image that was loaded onto the DSP core and executed. This tool worked by reading all of the necessary data in the object files produced from compiling the core software. Then it produced a binary image with all of the data from the object files formated in the way the DSP OS kernel expected.
As a side project I wrote a small interactive visualization application for this RTOS (screenshot 1). It simply interpreted the binary image produced from the RTOS build tool and displayed the memory regions in an OpenGL window. This was helpful because the module memory regions were not relocatable, which meant that in order to use memory most efficiently the programmer had to make sure that there were few memory spaces between modules (i.e. no memory fragmentation). This visualization tool showed the module layout in memory, and any fragmentation was easily identified. The programmer could then change the module layout to minimize the fragmentation.