点击 这里 查看中文版。

  RMP is a small hobbyist real-time operating system which focuses on formal reliability and simplicity. It achieves reliability by deployment of formal techniques(not completed yet; only whitebox testing with 100% branch coverage done. The kernel can be regarded as pre-certified IEC 61508 SIL2, or EAL 4). All the basic functionalities that are necessary for RTOSes are provided, but nothing more. This guarantees that the system is the minimum possible kernel and is also suitable to be used as a guest operating system when hosted on virtual machine monitors.

  This operating system is much leaner than any other RTOSes, especially when compared to FreeRTOS or RT-Thread, and understanding it should be simple enough. Yet it provides a complete set of functions that you may need during resource-constrained microcontroller development, such as efficient memory management, anti-aliasing graphics, and various helper functions. All these features come in a single .C file, and are without any extra RAM consumption!

  The manual of the operating system can be found here.

  Read Contributing and Code of Conduct if you want to contribute, and Pull Request Template when you make pull requests. This software is an official work of EDI, and thus belongs to the public domain. All copyrights reserved by EDI are granted to all entities under all applicable laws to the maximum extent.

  For vendor-supplied packages and hardware abstraction libraries, please refer to the M0A00_Library repo to download and use them properly.

  Existing RTOSes can be divided into three categories: enterprise, hobbyist and teaching. Enterprise systems are usually developed for real-world deployment and are great all-round, yet they at least put all verification documents and techniques behind a paywall, if code itself is free. Hobbyist systems are numerous with new repositories created nearly every day, but they lack long-term commitment and are frequently abandoned after a while. Teaching systems are built for college students, and lack depth when it comes to advanced topics such as verification.

  To this end, RMP seeks to build a fully open, capable and understandable system that is certified to the teeth. You can use the repository in three ways: (1) modify and deploy it in real-world environments, (2) follow its code and documents to get a full understanding of all details of the technologies involved, and (3) throw the system away and roll your own with the knowledge gained from this project.

  The construction of the system will proceed in three stages. In the first stage, we refrain from writing a formal specification beforehand but develop the system like any other hobbyist system. We port the system to as many architectures as possible to validate the flexibility of its abstraction, and run as many application classes as possible to guarantee the usability of its interface. In the second stage, we use the first implementation as a guide to retrovert a formal specification of the system, and prove the system model have certain desirable properties. In the last stage, we develop a formal semantics of the chosen C subset and rewrite the entire kernel according to the formal model while producing the required documents for functional safety (specifically, IEC 61508 SIL 4 and ISO 26262 ASIL D, maybe EAL as well, and we focus on the former first), and put the entire process (excluding those that we don't have copyright on, i.e. the standards) in public domain.

  No specific timetables are set for the development of the system. Currently the first stage is currently considered complete, and the second stage is a ongoing process. If you are interested in the project, please feel free to join; unlike other projects, beginners are welcome here.

  Compile the 32-bit linux binary here and watch the benchmark results!

  Download the precompiled "game" here, load it into your favorite emulator (or a flashable Namco 163 mapper cartridge and plug it into the real console), and watch the benchmark results!

  The Namco 163 is not optional, as the system relies on it to provide IRQ timers for performance measurement. Namco 163 is the only mapper that featured a readable timestamp counter, and can be found on cartridges that also originally host famous games such as "Star Wars" and "Sangokushi II: Hanou no Tairiku (三国志II 覇王の大陸)". The chip is sometimes also known as Namcot 163, or iNES mapper 019.

Create a thread

    RMP_Thd_Crt(&Thd_1            /* Thread control block */,
                Func_1            /* Thread entry */,
                &Stack_1          /* Stack address */,
                sizeof(Stack_1),  /* Stack size */,
                (void*)0x12345678 /* Parameter */,
                1                 /* Priority */, 
                5                 /* Timeslices */);

Delete a thread

    RMP_Thd_Del(&Thd_1            /* Thread control block */);

Suspend a thread

    RMP_Thd_Suspend(&Thd_1        /* Thread control block */);

Resume a thread

    RMP_Thd_Resume(&Thd_1         /* Thread control block */);

    void Func_1(void* Param)
    {
        RMP_LOG_S("Parameter passed is ");
        RMP_LOG_H((ptr_t)Param);
        RMP_LOG_S("\r\n");
        while(1)
        {
            RMP_Thd_Delay(30000);
            RMP_LOG_S("Delayed 30000 cycles\r\n\r\n");
        };
    }

    void RMP_Init_Hook(void)
    {
        RMP_Thd_Crt(&Thd_1, Func_1, &Stack_1, sizeof(Stack_1), (void*)0x12345678, 1, 5);
    }

    void Func_1(void* Param)
    {
        ptr_t Time=0;
        while(1)
        {
            RMP_Thd_Delay(30000);
            RMP_Thd_Snd(&Thd_2, Time, RMP_SLICE_MAX);
            Time  ;
        };
    }

    void Func_2(void* Param)
    {
        ptr_t Data;
        while(1)
        {
            RMP_Thd_Rcv(&Data, RMP_SLICE_MAX);
            RMP_LOG_S("Received ");
            RMP_LOG_I(Data);
            RMP_LOG_S("\n");
        };
    }

    void RMP_Init_Hook(void)
    {
        RMP_Thd_Crt(&Thd_1, Func_1, &Stack_1, sizeof(Stack_1), (void*)0x12345678, 1, 5);
        RMP_Thd_Crt(&Thd_2, Func_2, &Stack_2, sizeof(Stack_2), (void*)0x87654321, 1, 5);
    }

    void Func_1(void* Param)
    {
        while(1)
        {
            RMP_Thd_Delay(30000);
            RMP_Sem_Post(&Sem_1, 1);
        };
    }

    void Func_2(void* Param)
    {
        ptr_t Data;
        while(1)
        {
            RMP_Sem_Pend(&Sem_1, RMP_SLICE_MAX);
            RMP_LOG_S("Semaphore successfully acquired!\r\n\r\n");
        };
    }

    void RMP_Init_Hook(void)
    {
        RMP_Sem_Crt(&Sem_1,0);
        RMP_Thd_Crt(&Thd_1, Func_1, &Stack_1, sizeof(Stack_1), (void*)0x12345678, 1, 5);
        RMP_Thd_Crt(&Thd_2, Func_2, &Stack_2, sizeof(Stack_2), (void*)0x87654321, 1, 5);
    }

    /* Initialize memory pool */
    RMP_Mem_Init(Pool, Pool_Size);

    /* Allocate from the pool */
    Mem=RMP_Malloc(Pool, Alloc_Size);

    /* Free allocated memory */
    RMP_Free(Pool, Mem);

  The absolute minimum value for RMP is about 1.6k ROM and 432 byte RAM, which is reached on the STM32F030F4 (Cortex-M0) port, and this number even included the 60-byte thread control block and 256-byte stack of the first thread, and a 64-byte kernel interrupt response stack. The OS kernel and the stripped down HAL only consumes 52 bytes of memory combined. If you are willing to push this limit even further, then the manufacturer HAL is a rip-off for you and you can roll your own.

  The current minimal proof-of-concept implementation that can finish the benchmark test is achieved with ATMEGA328P. It only has a meager 32k Flash and 2k SRAM.

  The timing performance of the kernel in real action is shown as follows. All compiler options are the highest optimization (usually -O3 with LTO when available) and optimized for time, and all values are average case in CPU cycles; the WCET registered in test header files is roughly equivalent to this value plus the tick timer interrupt interference.

• Yield : Yield from one thread to another.
• Mail : Mailbox communication from one thread to another.
• Sem : Semaphore communication from one thread to another.
• FIFO : FIFO read/write pair within a single thread.
• Msgq : Message queue communication from one thread to another.
• Bmq : Blocking message queue communication from one thread to another.
• Mail/I : Send to a mailbox from interrupt.
• Sem/I : Post to a semaphore from interrupt.
• Msgq/I : Send to a message queue from interrupt.
• Bmq/I : Send to a blocking message queue from interrupt.
• Mem : A pair of memory pool malloc/free.
• Alrm : Average processing time of five periodic alarms triggered every 1/2/3/5/7 ticks.

  The difference between Msgq and Bmq is, in Msgq, only the receiver may block, whereas in Bmq both may block.

• V : Virtualization overhead of normal operations.
• V/I : Virtualization overhead of interrupt operations.

  In contrast, RT-Linux 4.12's best context switch time on Cortex-M7 is bigger than 25000 cycles (it has to run from FMC SDRAM due to its sheer size, so this is not a fair comparison). This is measured with futex; if other forms of IPC such as pipes are used, this time is even longer.

  No cheating methods (such as toolchain-specific peephole optimizations that harm portability, cooperative switches that don't invoke the scheduler, scheduler designs that are fast in average case but have unbounded WCET, or even RMS-style stackless coroutine switches) are used in the experiments, and the reported WCETs in test headers are real. Despite the fact that we list the average case values for generic comparisons, it is important to realize that only WCETs matter in a RTOS; optimizations that help the average case but hurt the worst-case are never suitable for such kernels. If maximum speed is your utmost goal, no system is faster than RMS or DOS; the theoretical context switch time of the RMS is zero (when all tasks have a single state and are inlined), while DOS does not need context switches altogether because it only allows one execution flow.

  This RTOS focuses on microcontrollers and will never support microprocessors. Multi-core support is also considered out of scope, because most multi-core microcontrollers are not symmetric, and have neither atomic instructions nor no cache coherency; even if RMP would support them, they pose challenges for unaware programmers. For multi-core microcontrollers, it is recommended to boot one RMP instance on each core, and the different instances may communicate with each other through Inter-Processor Interrupts (IPIs).

  These instructions will get you a copy of the project up and running on your board for development and testing purposes.

  You need a microcontroller development kit containing on of the chips above to run the system. STM32 Nucleo boards and MSP430 Launchpad boards are recommended. Do not use QEMU to test the projects because they do not behave correctly in many scenarios.

  If you don't have a development board, a x86-based Linux port of RMP is also available. However, running RMP on top of linux uses the ptrace system call and signal system, thus it is not particularly fast. Just run the example and observe benchmark output.

  Other platform supports should be simple to implement, however they are not scheduled yet. For Cortex-A and other CPUs with a memory management unit (MMU), use RME Real-Time Multi-Core Microkernel instead; RME supports some microcontrollers as well.

  The Makefile, Keil, CCS and MPLAB projects for various microcontrollers are available in the Project folder. Refer to the readme files in each folder for specific instructions about how to run them. However, keep in mind that some examples may need vendor-specific libraries such as the STMicroelectronics HAL. Some additional drivers may be required too. These can be found in M0A00_Library repo.

  To run the sample programs, simply download them into the development board and start step-by-step debugging. Some examples will use one or two LEDs to indicate the system status. In that case, it is necessary to fill the LED blinking wrapper functions.

  To use the graphics library and other advanced features, please refer to the user manual.

   When deploying this into a production system, it is recommended that you read the manual in the Document folder carefully to configure all macros correctly.

• GCC/Clang-LLVM
• Keil uVision (ARMCC/ARMCLANG)
• Code Composer Studio
• MPLAB X XC16/XC32

  Other toolchains are not recommended nor supported at this point, though it might be possible to support them later on.

  Please read CONTRIBUTING.md for details on our code of conduct, and the process for submitting pull requests to us.

• M5P01 R6T1

• Leifeng Song - ARM Cortex-M3/4/7 assembly port.
• Runsheng Hou - ARM Cortex-M4/7 RVM port and lwIP demo.
• Yihe Wang - Stable x86/linux/ptrace port.
• Ran Zhang - C28x DSP port.
• Kai Zhang - White-box testing.
• Haotian Liu - RL78 port.