Welcome to Chopin's homepage!
bleeding-edge-toolchain (r)evolution?
Written by Freddie Chopin   
Wednesday, 12 October 2016 12:07

As I grew tired of solving problems caused by bizarre workflow of ARM employees and also realized that solving incompatibilities between various Linux distributions is probably impossible, I decided to make a next step. So I present you a preview of a new all-in-one shell script for toolchain compilation, which is supposed to slightly change current form of bleeding-edge-toolchain.

For now I've tested this script on Linux only (on my PC, on a different machine and in Travis-CI system - Ubuntu 12.04.5 LTS "precise"), but soon I'm going to test it on Windows. It's quite possible that even now this script would work in MSYS2 on Windows, but this was not tried yet. The idea is to stop distributing toolchains for Linux in "binary" form - this script will allow anyone to build the toolchain that will work for sure on given distribution. I know that such compilation doesn't last 30 seconds, but it also doesn't last half a day - in here everything (including download of all sources) took 22 minutes. On very slow Travis-CI virtual system it took 80 minutes. I think such amount of time can be sacrificed once every few months, especially that you can do anything else during the compilation [; If someone wants to make this time much shorter, then just find a line with "--with-multilib-list=armv6-m,armv7-m,armv7e-m,armv7-r" in the script and remove what you don't use (WARNING - there are two identical lines in the script, they both must stay identical!). Windows versions will most likely be still distributed in "binary" form, as this platform has no such issues with library compatibility.

Anyway - the script generally does everything that is required - it downloads the sources of the toolchain and required libraries in proper versions, extracts them and then configures & compiles each in proper order. This idea is obviously not new and there are many scripts like this one, but all that I know of are either not developed anymore or just not entirely the way they should be. The script should not require anything fancy to work, the standard set present in any Linux distribution should be enough - the only exception are the tools needed to generate documentation ("makeinfo", which usually is a part of a package like "texinfo"). I encourage anyone to try it out, if something doesn't work as expected let me know - either here in the comments or file an issue at GitHub. I'll also be very happy to hear that it is working correctly (;

Current versions of toolchain components are - obviously - most recent (; More recent than in the toolchain from ARM <:

  • gcc-6.2.0 + multilib patch
  • newlib-
  • binutils-2.27
  • gdb-7.12
  • expat-2.2.0
  • gmp-6.1.1
  • isl-0.16
  • libelf-0.8.13
  • mpc-1.0.3
  • mpfr-3.1.5
  • zlib-1.2.8
Last Updated on Friday, 14 October 2016 10:33
First version of distortos published!
Written by Freddie Chopin   
Thursday, 10 March 2016 16:39

Less than two weeks ago, after 584 days since I started working on distortos system, I finally published first version - 0.1.0. List of functionalities included in this release can be found in the change log and packages with source code can be found on http://distortos.org/ in Downloads section. In the same place you can also download packages with project template and example applications that were published on the same day. This second package currently has just the "classic" LED blinker which uses static or dynamic threads. I've even recorded a short video featuring this application (;

As a small incentive - a little bit of "magic" code, which asynchronously calculates result of sine function for four different numbers in four separate threads. It is a complete and working code of application - you don't need to add anything else!

#include "distortos/board/leds.hpp"
#include "distortos/chip/ChipOutputPin.hpp"
#include "distortos/StaticThread.hpp"

void sinWrapper(const double operand, double& result)
  result = sin(operand);

int main()
  const double operands[4] {0.9867816015, 0.4641984149, 0.4665572273, 0.8926178650};
  double results[4] {};
  auto sinThread0 = distortos::makeAndStartStaticThread<512>(1, sinWrapper, operands[0], std::ref(results[0]));
  auto sinThread1 = distortos::makeAndStartStaticThread<512>(1, sinWrapper, operands[1], std::ref(results[1]));
  auto sinThread2 = distortos::makeAndStartStaticThread<512>(1, sinWrapper, operands[2], std::ref(results[2]));
  auto sinThread3 = distortos::makeAndStartStaticThread<512>(1, sinWrapper, operands[3], std::ref(results[3]));

  // do something while the threads are calculating results...

  // make sure the threads are done

  // results are ready!
Last Updated on Thursday, 10 March 2016 17:55
distortos - official website and support for all STM32F4 chips
Written by Freddie Chopin   
Saturday, 26 December 2015 13:57

A few weeks ago distortos project - advanced real-time operating system - got its own website, which is available at http://distortos.org/. For now it contains only a few short news articles, a few useful links and source code documentation generated with doxygen tool, but the amount of useful content will constantly increase.

On the other hand, complete support for all 115 chips from the STM32F4 family was added to the Kconfig configuration system and to the source code of the project. Two more example configurations for popular boards with STM32F4 chips were also added, so there are now three tested, ready to run configurations:

All these configurations run the test application at the max possible system clock frequency. Whole configuration of the clock system frequency and some details from the power system is done with the Kconfig configuration tool, presented on the screenshots below.

Kconfig, STM32F4
Kconfig, STM32F4
Kconfig, STM32F4
Kconfig, STM32F4
Kconfig, STM32F4
Kconfig, STM32F4

The correctness of the selected configuration is verified partly in the Kconfig tool and partly in the source code, using only compile-time methods (static_assert(…) or preprocessor).

Last Updated on Saturday, 26 December 2015 23:47
distortos is one year old!
Written by Freddie Chopin   
Thursday, 23 July 2015 22:11

One year and one day passed since I started writing my own RTOS. distortos project is still evolving and - as of today - has 1542 commits. Since previous news article only two new features were implemented, but both of them are rarely seen in other RTOSes. One of them is OnceFlag class with callOnce() function - which are equivalents of std::once_flag class and std::call_once() function from C++11 standard or pthread_once_t structure and pthread_once() function from <pthread.h>.

Second new feature is an implementation of POSIX signals. Signals can be handled both by synchronous waiting - with ThisThread::Signals::wait(), ThisThread::Signals::tryWait(), ThisThread::Signals::tryWaitFor() andThisThread::Signals::tryWaitUntil() functions - and by asynchronous signal handlers - using ThisThread::Signals::setSignalAction() function. As in the established standards, delivery of signal causes interruption of some blocking functions (like Semaphore::wait() or MessageQueue::pop()), which return EINTR error code in that case. Looking at this feature from the other side - from the "source" of the signal - it is possible to "generate" the signal (ThreadBase::generateSignal()) or "queue" the signal with a value (ThreadBase::queueSignal()). Obviously, the signals can also be masked and ignored.

All of that is - still - possible without a single byte of dynamically allocated memory! In case of static threads (StaticThread instances) it is necessary to state whether the thread can receive the signals at all, how many signals can be queued simultaneously and how many different SignalAction objects can be used at the same time.

Stay tuned!

██╗  ██╗ █████╗ ██████╗ ██████╗ ██╗   ██╗
██║  ██║██╔══██╗██╔══██╗██╔══██╗╚██╗ ██╔╝
███████║███████║██████╔╝██████╔╝ ╚████╔╝ 
██╔══██║██╔══██║██╔═══╝ ██╔═══╝   ╚██╔╝  
██║  ██║██║  ██║██║     ██║        ██║   
╚═╝  ╚═╝╚═╝  ╚═╝╚═╝     ╚═╝        ╚═╝   

██████╗ ██╗██████╗ ████████╗██╗  ██╗██████╗  █████╗ ██╗   ██╗
██╔══██╗██║██╔══██╗╚══██╔══╝██║  ██║██╔══██╗██╔══██╗╚██╗ ██╔╝
██████╔╝██║██████╔╝   ██║   ███████║██║  ██║███████║ ╚████╔╝ 
██╔══██╗██║██╔══██╗   ██║   ██╔══██║██║  ██║██╔══██║  ╚██╔╝  
██████╔╝██║██║  ██║   ██║   ██║  ██║██████╔╝██║  ██║   ██║   
╚═════╝ ╚═╝╚═╝  ╚═╝   ╚═╝   ╚═╝  ╚═╝╚═════╝ ╚═╝  ╚═╝   ╚═╝   


██████╗ ██╗███████╗████████╗ ██████╗ ██████╗ ████████╗ ██████╗ ███████╗
██║  ██║██║███████╗   ██║   ██║   ██║██████╔╝   ██║   ██║   ██║███████╗
██║  ██║██║╚════██║   ██║   ██║   ██║██╔══██╗   ██║   ██║   ██║╚════██║
██████╔╝██║███████║   ██║   ╚██████╔╝██║  ██║   ██║   ╚██████╔╝███████║
╚═════╝ ╚═╝╚══════╝   ╚═╝    ╚═════╝ ╚═╝  ╚═╝   ╚═╝    ╚═════╝ ╚══════╝
Last Updated on Thursday, 23 July 2015 23:29
distortos - 7 months & 0x3FF commits!
Written by Freddie Chopin   
Sunday, 22 February 2015 20:52

distortos project - mentioned in previous news article - is still evolving. Today it is exactly 7 months since the first commit in the repository, and the total number of these commits reached a nice value of 1023. Many readers - at least those who are a bit into RTOSes for microcontrollers - may wonder "who needs another RTOS project?". Answer to this question is very complex and I could write a separate article about that, so for now a link to README file - in which I tried to explain the main reasons for this project's existence - must suffice. I think that at least the huge emphasis placed on C++ and C++11 support makes this project worthwhile, although this feature should not diminish other advantages (some of which are of course "future" (; ), important for people who don't intend to use C++ (this feature is one of the "future" ones for sure, as for now only C++11 API is available).

There are still many features missing, but these 7 months were well spent - quite a lot was done, and these things work remarkably well (;

The most important features are obviously threads (Thread, StaticThread and ThreadBase classes), which can accept any number of arguments of any type - thanks to new features of C++11 standard - not only the void* known from other RTOSes. Moreover - regular functions, member functions, functors or lambdas can be used as thread's function.

All of these features are also present in software timers (SoftwareTimer class).

Scheduler supports full preemption based on thread's priority (there are 256 priority levels), and when several threads with the same priority are present, they are scheduled according to FIFO or round-robin algorithm (selected for each thread individually).

Semaphore (Semaphore class) is probably the most basic synchronization object. It is possible to configure maximal value the semaphore can "have", so this object can also be used as binary semaphore. Semaphores can be "posted" from interrupts.

Mutex (Mutex class) is one of more advanced synchronization mechanisms. Just as in POSIX standard, it can be configured to use any of the three "modes" - normal, error-checking or recursive - and any of the three "protocols" - normal, priority inheritance or priority protocol (also known as priority ceiling). Unlike many other RTOSes, priority inheritance protocol works with no limitations: through any number of inheritance "levels" and with any number of mutexes locked by threads in any order (diagram and description of test case of this particular feature).

Classic condition variable (ConditionVariable class) is a mechanism which extends functionality of mutexes.

Queues can be used for standard communication between threads and interrupts (in any combination). There are four variants of queues:

Messages added to queues which don't support priorities (...FifoQueue) are ordered in FIFO order, while queues which do support priorities (...MessageQueue) allow adding messages with one of 256 priority levels. Queues without support for objects (...Raw...) copy the messages with memcpy() function, while queues with support for objects use all operations required in such scenario (construction, destruction, assignment operator, swap, emplace, ...).

All blocking operations are also available in non-blocking variants and in blocking versions with timeout (absolute or relative), which - thanks to C++11 std::chrono - can be easily expressed in any unit (like seconds, minutes, hours, ... - link), not only in system "ticks".

All errors are signaled with error codes - functions use neither errno variable, nor C++ exceptions.

The only supported architecture - for now - is ARMv7-M, so ARM Cortex-M3 (ARM Cortex-M4 can be used without enabling FPU) (added 20.03.2015) and ARM Cortex-M4(F), and the only "officially" supported chip is STM32F407VG (known from STM32F4Discovery board), although using any different chip with proper core would be trivial.

I saved the best part (I hope) for the end - use of all functionalities mentioned above is possible without dynamic memory allocation. All previously described objects can be constructed as global variables or on stack.

I'm sure I forgot to mention some more interesting features...

Feel encouraged to test the code, ask questions, post comments, send suggestions and cooperate (; Stay tuned!

Last Updated on Friday, 20 March 2015 09:47

Page 1 of 9