[ARM] [C++11][Cortex-M3/M4] - distortos - another RTOS for microcontrollers

Status
Not open for further replies.

Freddie Chopin

Advanced Member level 4
Joined
Dec 7, 2007
Messages
104
Helped
9
Reputation
18
Reaction score
3
Trophy points
1,298
Location
Poland / Zawiercie
Activity points
1,923
Hello!

I finally decided to start a thread about a project I've been doing for the past 8 months. Currently it can be considered "alpha" or maybe "early beta" stage, but - despite literal meaning of these terms - the things that are already done (and there's quite a lot of them) work pretty well and are thoroughly tested. The only architecture supported at the moment is ARMv7-M, so ARM Cortex-M3 and ARM Cortex-M4(F). The only "officially" supported chip is STM32F407VG (the one found on the first STM32F4DISCOVERY board).

The whole project is written in C++11 and there is no C API. Such C API is of course planned and it will be pthread, maybe one more, a bit more "native", which would allow better/easier access to unique features of this project. Anyway - the C++11 API that is currently available aims for 100% compatibility with POSIX (in features, not in names). It is worth noting that the code DOES NOT use dynamically allocated memory, so EVERYTHING (especially threads and their stacks) can be constructed as local variables (on stack), global variables or however you like it.

Another important thing worth noting is that this project doesn't aim to be "the smallest" and/or "the fastest" RTOS. As the time passed (and as powerful chips with with lots of RAM got more popular and cheaper (; ) I came to a conclusion that all extreme measures taken in other projects just to save a few clock cycles or 10 bytes of memory are not justified at all. What I'm saying here doesn't mean that this code runs pathetically slow and uses whole available memory (; I just don't devote all my attention to such optimizations - I focus on these matters in the "right" proportion (;

Here is a link to github repository:
https://github.com/DISTORTEC/distortos

And here's an article I wrote on my page about the current state of this project:
https://www.freddiechopin.info/en/articles/34-news/94-distortos-7-miesiecy-i-0x3ff-commitow (it is also available in Polish).

I'm pasting the article below, but anyone interested is encouraged to visit the link above, because the original text has a lot of clickable links to relevant source files in the repository.


An finally - a small news article with a teaser - https://www.freddiechopin.info/en/articles/34-news/93-work-in-progress

The simplest thread doesn't require ANY configuration, because main() function is already a thread! So here's the immortal LED blinker in the shortest form:

Code:
#include "distortos/ThisThread.hpp"
 
int main()
{
	// --- configure your GPIO pin here ---
 
	while (1)
	{
		// --- toggle the state of GPIO here ---
 
		distortos::ThisThread::sleepFor(std::chrono::milliseconds(500));
	}
}

Compilation result
Code:
   text      data       bss       dec       hex   filename 
   4924       100      4840      9864      2688   ./output/distortos.elf

2kB of RAM is the stack for main() and another 2kB is the stack for interrupts. These two numbers are obviously too much for such a simple program, so they can be reduced with no problems.

If you'd like to have a separate thread it's still pretty simple:

Code:
#include "distortos/StaticThread.hpp"
#include "distortos/ThisThread.hpp"
 
void blinkFunction()
{
	// --- configure your GPIO pin here ---
 
	while (1)
	{
		// --- toggle the state of GPIO here ---
 
		distortos::ThisThread::sleepFor(std::chrono::milliseconds(500));
	}
}
 
int main()
{
	auto blinkThread = distortos::makeStaticThread<512>(1, blinkFunction);
	blinkThread.start();
	return blinkThread.join();
}

Size of stack for the thread (512 bytes) and its priority (1) are not based on any deep reasoning - just some two values that will make the code work in an expected way (unless the GPIO configuration or toggling would use functions that use a lot of stack). The priority can be changed in 0-255 range, but 0 is not a very good option, as it's the priority of idle thread.

Code:
   text      data       bss       dec       hex   filename 
   6084      1144      4880     12108      2f4c   ./output/distortos.elf

Most of the used RAM (almost everything above the 2kB + 2kB for stacks mentioned above) is used by newlib's module with maloc() and free(), which is pulled into the link because of free(). This code doesn't allocate a single byte of memory from the heap.

Regards,
FCh
 

Status
Not open for further replies.

Similar threads

Cookies are required to use this site. You must accept them to continue using the site. Learn more…