Miosix Wiki - Recent changes [en]

Adding support for a new STM32 board in Miosix

Daniele.cattaneo — Thu, 09 Apr 2026 17:04:58 GMT

Outline what is yet to be written

← Older revision		Revision as of 17:04, 9 April 2026
Line 52:		Line 52:
	\| interfaces_private/userspace.h \|\| arch/cpu/<cpu_name>/interfaces-impl/userspace_impl.h \|\| Yes \|\| Implementation of memory protection primitives		\| interfaces_private/userspace.h \|\| arch/cpu/<cpu_name>/interfaces-impl/userspace_impl.h \|\| Yes \|\| Implementation of memory protection primitives
	\|}		\|}

			TODO:
			* what to copy past and from where, new chip vs old chip vs new chip that is similar to old
			* makefiles/cmake
			For new chips:
			* clock configuration code & PLL
			* os_timer
			* gpio (sometimes)
			* serial port configuration
			For new boards:
			* BSP init
			* arch_registers (to be moved!!!)
			extras:
			* sdmmc

Adding support for a new STM32 board in Miosix

Daniele.cattaneo — Thu, 09 Apr 2026 16:58:35 GMT

Start writing a porting guide

New page

Miosix's main target platform is, naturally, STM32 microcontrollers by ST Microelectronics, in part for historical reasons, but mainly because STM32 chips (and their clones) are extremely popular for both the industry and hobbyists.

However, the success of the STM32 line has spawned an abundance of different chips, all with different sets of built-in peripherals, Flash sizes, Ram sizes, CPU cores, and so on. Fortunately, most STM32 chips are similar enough that it is usually easy to port a new STM32 board to Miosix.

== Components of a Miosix port ==

The core of the Miosix kernel is platform-independent. The contact point between the platform-independent part of Miosix and the platform-dependent parts consist in a set of '''interfaces''' that need to be fully implemented for a board to function.

The header files that define these interfaces are in the miosix/interfaces and miosix/interfaces_private directories. The implementations are in the arch directory, split by board, chip and cpu.

The Miosix build system makes sure that the correct board/chip/cpu-specific header files and source code files for the selected board are used during the compilation.

A port of Miosix to a new board needs to provide the files required for the missing interfaces implementations.

=== Miosix interfaces ===

Miosix's interfaces are usually implemented either at CPU level, at chip level, or board level, depending on the case.

{| class="wikitable sortable"
|+ Caption text
|-
! Header !! Typical Implementation !! Private !! Description
|-
| interfaces/arch_registers.h || arch/board/<board_name>/interfaces-impl/arch_registers_impl.h || No || Register definitions for the chip.
|-
| interfaces/atomic_ops.h || arch/cpu/<cpu_name>/interfaces-impl/atomics_ops_impl.h || No || Implementation of atomic primitives
|-
| interfaces/bsp.h, interfaces_private/bsp_private.h || arch/board/<board_name>/interfaces-impl/{bsp_impl.h,bsp.cpp} || In part || Board Support Package: configuration of the board at boot, board reboot and shutdown
|-
| interfaces/cpu_const.h || arch/cpu/<cpu_name>/interfaces-impl/cpu_const_[smp_]impl.h || No || Low-level CPU architecture parameters, such as the number of CPU cores, configurables regarding the behavior during context switches, and so on. (SMP file only for SMP platforms)
|-
| interfaces/delays.h || arch/chip/<chip_name>/interfaces-impl/delays.cpp || No || Low-level delays implemented by CPU spinning (no timers allowed, used early at boot)
|-
| interfaces/endianness.h || arch/cpu/<cpu_name>/interfaces-impl/endianness_impl.h || No || Optimized implementation of byte-swapping primitives, for big endian support
|-
| interfaces/gpio.h || arch/chip/<chip_name>/interfaces-impl/gpio_impl.h || No || Gpio class implementation for this chip. Usually just includes one of the Gpio drivers in arch/drivers/gpio.
|-
| interfaces/interrupts.h || arch/cpu/<cpu_name>/interfaces-impl/interrupts_impl.h || No || Implementation of primitives for enabling or disabling interrupts, and for registering IRQ vectors.
|-
| interfaces/poweroff.h || arch/chip/<chip_name>/interfaces-impl/poweroff.cpp || No || Chip reboot and shutdown
|-
| interfaces_private/cpu.h || arch/cpu/<cpu_name>/interfaces-impl/{cpu_impl.h,cpu.cpp} || Yes || Context switching primitives
|-
| interfaces_private/os_timer.h || arch/drivers/os_timer/... || Yes || Timer driver for context switches and general kernel timekeeping
|-
| interfaces_private/sleep.h || arch/drivers/sleep/... || Yes || CPU sleep and deep sleep (deep sleep is implemented in arch/chip or arch/board)
|-
| interfaces_private/smp_locks.h || arch/chip/<chip_name>/interfaces-impl/smp_locks_impl.h || Yes || Implementation of spinlocks (SMP platforms only)
|-
| interfaces_private/smp.h || arch/chip/<chip_name>/interfaces-impl/smp.cpp || Yes || Initialization of other CPU cores and SMP primitives (SMP platforms only)
|-
| interfaces_private/userspace.h || arch/cpu/<cpu_name>/interfaces-impl/userspace_impl.h || Yes || Implementation of memory protection primitives
|}

User:Daniele.cattaneo

Daniele.cattaneo — Thu, 09 Apr 2026 15:54:37 GMT

← Older revision		Revision as of 15:54, 9 April 2026
Line 17:		Line 17:
	[[mxgui qtsimulator on windows]]		[[mxgui qtsimulator on windows]]

	[[Adding support for a board in Miosix]]		[[Adding support for a new STM32 board in Miosix]]

Linux Debugger configuration

Daniele.cattaneo — Wed, 08 Apr 2026 09:22:11 GMT

Use extended-remote

← Older revision		Revision as of 09:22, 8 April 2026
(One intermediate revision by the same user not shown)
Line 1:		Line 1:
	The debugging of Miosix on Linux can be done through [http://openocd.~~net~~/ OpenOCD], that creates a bridge between GDB and the JTAG device.		The debugging of Miosix on Linux can be done through [http://openocd.org/ OpenOCD], that creates a bridge between GDB and the JTAG device.

	== Setting up OpenOCD ==		== Setting up OpenOCD ==
Line 32:		Line 32:
	The default socket is listening on port 3333 in the loopback interface of your computer. So you can use the default command:		The default socket is listening on port 3333 in the loopback interface of your computer. So you can use the default command:
	<source lang="bash">		<source lang="bash">
	(gdb) target remote :3333		(gdb) target extended-remote :3333
	</source>		</source>

User:Daniele.cattaneo

Daniele.cattaneo — Tue, 07 Apr 2026 11:15:58 GMT

← Older revision		Revision as of 11:15, 7 April 2026
(One intermediate revision by the same user not shown)
Line 4:		Line 4:

	Github (personal): Secret		Github (personal): Secret

			MInimal Operating System with posIX

	[[Miosix in emulation]]		[[Miosix in emulation]]
Line 14:		Line 16:

	[[mxgui qtsimulator on windows]]		[[mxgui qtsimulator on windows]]

			[[Adding support for a board in Miosix]]

Mxgui qtsimulator on windows

Daniele.cattaneo — Wed, 01 Apr 2026 15:11:37 GMT

← Older revision		Revision as of 15:11, 1 April 2026
Line 60:		Line 60:
	You can also install git inside MSYS2 by executing <code>pacman -S git</code>. However, this installs a different and separate version of Git, which exists simultaneously and independently from Git for Windows. By default you can't use Git for Windows inside a MSYS2 shell, or MSYS2-installed git in a Windows shell.		You can also install git inside MSYS2 by executing <code>pacman -S git</code>. However, this installs a different and separate version of Git, which exists simultaneously and independently from Git for Windows. By default you can't use Git for Windows inside a MSYS2 shell, or MSYS2-installed git in a Windows shell.
	</div>		</div>

			Then, change directory to the mxgui repository's root.

			<div style="margin: 0 0; background: #e0f7e0; padding: 0 10px; border: 1px solid #c0d0c0">
			'''Tip''': Instead of typing the path manually, you can drag the directory on the terminal window to insert the path automatically.
			</div>
			<div style="margin: 0 0; background: #f7e0e0; padding: 0 10px; border: 1px solid #d0c0c0">
			'''Warning''': MSYS2 natively accepts only Unix-style paths with forward-slashes. Windows style paths with backslashes usually don't work.
			</div>

			<pre>
			cd /c/Users/me/Documents/mxgui
			</pre>

	Change directory to <code>_tools/code_generators</code>:		Change directory to <code>_tools/code_generators</code>:
	<pre>		<pre>
	cd ~~../../~~_tools/code_generators		cd _tools/code_generators
	</pre>		</pre>

Mxgui qtsimulator on windows

Daniele.cattaneo — Thu, 26 Mar 2026 18:22:02 GMT

Page created

New page

On windows, an easy way to compile the mxgui qtsimulator is to use the MSYS2 toolchain, which provides a Unix-like environment for Windows development.

== 1. Install MSYS2 ==
Download the MSYS 2 toolchain by downloading the prebuilt packages from the official site https://www.msys2.org. Then, follow the instructions on the website to install it.

=== Different toolchains in MSYS2 ===

MSYS2 itself is just a unix-like environment running on Windows, like its predecessor Cygwin. Within this environment, MSYS2 provides multiple toolchains which target different architectures (x86_64 or ARM), use different main compilers (GCC or clang), or a different C runtime library (UCRT or mingw).

The recommended toolchain by the MSYS2 project at the current time is '''UCRT64''', which targets x86_64, uses the GCC compiler and the UCRT runtime. [https://learn.microsoft.com/en-us/cpp/windows/universal-crt-deployment?view=msvc-170 UCRT] is a modern C runtime for Windows, included with the OS since Windows 10, which removes the need to install the C runtime separately when distributing a program (as previously required).

<div style="margin: 0 0; background: #e0f7e0; padding: 0 10px; border: 1px solid #c0d0c0">
'''Trivia''': Before UCRT was introduced, the previous standard C runtime for MSYS2 was mingw. However, mingw was simply a wrapper augmenting an old Microsoft C runtime (''msvcrt.dll'') which for binary compatibility reasons is frozen in time since the release of Windows 95<ref>https://devblogs.microsoft.com/oldnewthing/20140411-00/?p=1273</ref>. As a result, mingw always had serious compatibility problems and bugs.
</div>

MSYS2 adds menu items to the Start menu which launch bash shells with pre-configured paths ('''environments''') for each one of the toolchains.

<div style="clear: both">
[[File:Msys2 toolchains.png|frame|center]]
</div>

All of the following steps are intended to be executed using the shell opened by clicking on '''MSYS2 UCRT64'''.

== 2. Install build tools and prerequisites ==

Open the '''MSYS2 UCRT64''' shell and perform an upgrade:
<pre>
pacman -Syuu
</pre>
Answer Yes to all prompts. If a "base system upgrade" was needed, at this point the shell will close. In this case, just open it up again.

Install the toolchain (including gcc and binutils):
<div style="margin: 0 0; background: #f7f7e0; padding: 0 10px; border: 1px solid #d0d0c0">
'''Note''': The ''mingw-w64-ucrt-x86_64'' prefix in the package name identifies the toolchain and ''usually'' needs to be specified for all packages. Some packages that work the same way for all toolchains are exceptions to this rule.
</div>
<pre>
pacman -S mingw-w64-ucrt-x86_64-toolchain
</pre>

Install build automation tools (note that only CMake has a special version depending on the toolchain here):
<pre>
pacman -S make difftools mingw-w64-ucrt-x86_64-cmake
</pre>

Install the dependencies for the simulator and the code generation tools:
<div style="margin: 0 0; background: #f7f7e0; padding: 0 10px; border: 1px solid #d0d0c0">
'''Note''': When installing qt5 type enter to install all packages.
</div>
<pre>
pacman -S mingw-w64-ucrt-x86_64-qt5 mingw-w64-ucrt-x86_64-libpng mingw-w64-ucrt-x86_64-zlib mingw-w64-ucrt-x86_64-boost
</pre>

== 3. Build the code generation tools ==

Let us assume you already cloned mxgui's repository somewhere on your filesystem. If you haven't, do it now.

<div style="margin: 0 0; background: #e0f7e0; padding: 0 10px; border: 1px solid #c0d0c0">
'''Tip''': For using git on Windows, we recommend the official distribution (Git for Windows: https://git-scm.com/install/windows) and TortoiseGit for shell integration and GUI support (https://tortoisegit.org).

You can also install git inside MSYS2 by executing <code>pacman -S git</code>. However, this installs a different and separate version of Git, which exists simultaneously and independently from Git for Windows. By default you can't use Git for Windows inside a MSYS2 shell, or MSYS2-installed git in a Windows shell.
</div>

Change directory to <code>_tools/code_generators</code>:
<pre>
cd ../../_tools/code_generators
</pre>

Build the code generators with CMake.
<pre>
mkdir build
cd build
cmake ..
make
</pre>
<div style="margin: 0 0; background: #f7f7e0; padding: 0 10px; border: 1px solid #d0d0c0">
'''Note''': If you want to make the compilation faster by using all the CPU cores in your machine, instead of just typing <code>make</code> type <code>make -j4</code> where 4 stands for the number of CPU cores you have.

Of course you can do this any time you use make to compile something, not just for this one case.

If you don't know how many cores your CPU has, check in Task Manager.
</div>

== 4. Build the simulator ==

Now we only need to build the simulator. Change directory to the simulator's root:
<pre>
cd ../../qtsimulator
</pre>

Then build it like we did for the code generators:
<pre>
mkdir build
cd build
cmake ..
make
</pre>

Now you should be able to run the simulator!
<pre>
./qtsimulator.exe
</pre>

<div style="clear: both">
[[File:Mxgui simulator on Windows 11.png|frame|center]]
</div>

<div style="margin: 0 0; background: #f7e0e0; padding: 0 10px; border: 1px solid #d0c0c0">
'''Warning''': If you double-click on the <code>qtsimulator.exe</code> executable in Windows Explorer, it probably won't work because of some missing DLLs. This is normal. The missing DLLs are located in <code>C:\msys64\ucrt64\bin</code>, a directory that the MSYS2 shell configuration adds to the PATH variable automatically, but is not normally included in PATH.

To make the simulator executable work when double-clicked, first check all the required DLLs by executing <code>lld qtsimulator.exe</code> in the MSYS2 shell, and then copy the DLLs located in <code>C:\msys64\ucrt64\bin</code> to the same directory as <code>qtsimulator.exe</code>.

However, unless you want to distribute the compiled simulator, it's much simpler to just always run it from inside an MSYS2 UCRT64 terminal window.
</div>

== References ==

File:Mxgui simulator on Windows 11.png

Daniele.cattaneo — Thu, 26 Mar 2026 18:12:35 GMT

Daniele.cattaneo uploaded File:Mxgui simulator on Windows 11.png

New page

Screenshot of the mxgui simulator on Windows 11

File:Msys2 toolchains.png

Daniele.cattaneo — Thu, 26 Mar 2026 13:47:57 GMT

Daniele.cattaneo uploaded File:Msys2 toolchains.png

New page

Toolchains available in a default installation of MSYS2

User:Daniele.cattaneo

Daniele.cattaneo — Thu, 26 Mar 2026 11:47:47 GMT

← Older revision		Revision as of 11:47, 26 March 2026
Line 12:		Line 12:

	[[Multicore]]		[[Multicore]]

			[[mxgui qtsimulator on windows]]

Miosix Toolchain

Fede.tft — Wed, 25 Mar 2026 22:10:40 GMT

← Older revision		Revision as of 22:10, 25 March 2026
(One intermediate revision by the same user not shown)
Line 13:		Line 13:
	== Latest Unstable version of the Miosix Toolchain ==		== Latest Unstable version of the Miosix Toolchain ==

	~~We are currently working on the release of Miosix 3.0, making changes in the unstable and testing branches that require a more up-to-date compiler version. Here is a snapshot of the compiler:~~		=== Release GCC 15.2.0mp4.2 ===
	* [https://miosix.org/toolchain/MiosixToolchainInstaller15.2.0mp4.1.run GCC 15.2.0mp4~~.1 compiled for Linux] (sha256sum 01c293813e233d0c8f25b4b1af700605f4a728e4c76748fd43c4f1053bfac2d7), last updated March 9th, 2026~~
	* [https://miosix.org/toolchain/MiosixToolchainInstaller15.2.0mp4.1_Intel.pkg GCC 15.2~~.0mp4.1 compiled for Mac OS (Intel)] (sha256sum 8274d52ed931796ca4d32f1311ff189996e8cee5f44dc0905092c05a6c769db7) Contributed by Daniele Cattaneo~~
	* [https://miosix.org/toolchain/MiosixToolchainInstaller15.2.0mp4.1_ARM.pkg GCC 15.2.0mp4.1 compiled for Mac OS (ARM)] (sha256sum b7cf3214efcce543e6ca2a28fc6232963804b0e911db3d1cfcf29dd64cf5139c) Contributed by Daniele Cattaneo
	* Compiled releases for other OSes coming soon...

	As an alternative to installing a binary release, you can build this toolchain from [https://github.com/fedetft/miosix-kernel/tree/unstable/~~miosix/_tools~~/compiler/gcc-15.2.0-mp4.1 sources].		Released '''March 25th, 2026'''. This version:
			* is '''required''' to compile Miosix v2.99 and higher. Compiling older kernels (v2.81 and lower) '''no longer supported''', you'll still need the 9.2.0 release for that.
			* provides C++23 support
			* provides OpenMP support to allow parallelization of algorithms when targeting multicore microcontrollers
			* GCC upgraded to 15.2.0

			_MIOSIX_GCC_PATCH_MAJOR is set to 4, and _MIOSIX_GCC_PATCH_MINOR is set to 2 in this release.

			* [https://miosix.org/toolchain/MiosixToolchainInstaller15.2.0mp4.2.run Miosix Toolchain Linux] (sha256sum 51cf6cb78f2a04341db0d17869bd2074d6c63332612269a4edc8fb4c7469e2dd) This is self-installing shell script, run it with
			<source lang="bash">sh MiosixToolchainInstaller15.2.0mp4.2.run</source>
			* [https://miosix.org/toolchain/MiosixToolchainInstaller15.2.0mp4.2.exe Miosix Toolchain Windows] (sha256sum c67158aa2efb5275e4c460289e7e7514bf57c3dc3ec93161ae32d22d511b269f) This is a self-installing .exe
			* [https://miosix.org/toolchain/MiosixToolchainInstaller15.2.0mp4.2_Intel.pkg Miosix Toolchain Mac OS (Intel)] (sha256sum 59b000631bb69b44f4846653cb3671997a38476c5e67295ade6417344296d7be) Contributed by Daniele Cattaneo, it is a release build of the Miosix toolchain for Mac OS (Intel).
			* [https://miosix.org/toolchain/MiosixToolchainInstaller15.2.0mp4.2_ARM.pkg Miosix Toolchain Mac OS (ARM)] (sha256sum 95a847bbd7991e285a26b3559bca5be33997ca64bf1e9ed71bab5c1dca08650f) Contributed by Daniele Cattaneo, it is a release build of the Miosix toolchain for Mac OS (ARM).

			As an alternative to installing a binary release, you can build this toolchain from [https://github.com/fedetft/miosix-kernel/tree/unstable/tools/compiler/gcc-15.2.0-mp4.2 sources].

	== Latest Stable version of the Miosix Toolchain ==		== Latest Stable version of the Miosix Toolchain ==
Line 33:		Line 43:

	* [https://miosix.org/toolchain/MiosixToolchainInstaller9.2.0mp3.2.run Miosix Toolchain Linux] (sha256sum d71fdac28a6fc4a4c0b41e90fb46c3722805b04e1ddb355d0da2f1b67e50ef3e) This is self-installing shell script, run it with		* [https://miosix.org/toolchain/MiosixToolchainInstaller9.2.0mp3.2.run Miosix Toolchain Linux] (sha256sum d71fdac28a6fc4a4c0b41e90fb46c3722805b04e1ddb355d0da2f1b67e50ef3e) This is self-installing shell script, run it with
	<source lang="bash">sh ~~MiosixToolchainInstaller~~.run</source>		<source lang="bash">sh MiosixToolchainInstaller9.2.0mp3.2.run</source>
	* [https://miosix.org/toolchain/MiosixToolchainInstaller9.2.0mp3.2.exe Miosix Toolchain Windows] (sha256sum 4182788ccb27e42cd56afe65c7146c601aadcab0b758c9882e4a3cf394c6f622) This is a self-installing .exe		* [https://miosix.org/toolchain/MiosixToolchainInstaller9.2.0mp3.2.exe Miosix Toolchain Windows] (sha256sum 4182788ccb27e42cd56afe65c7146c601aadcab0b758c9882e4a3cf394c6f622) This is a self-installing .exe
	* [https://miosix.org/toolchain/MiosixToolchainInstaller9.2.0mp3.2_Intel.pkg Miosix Toolchain Mac OS (Intel)] (sha256sum 5420a4fdb7aee9337350a77bde4820d983d41c7e193cc7bc90612a58287c6010) Contributed by Daniele Cattaneo, it is a release build of the Miosix toolchain for Mac OS (Intel).		* [https://miosix.org/toolchain/MiosixToolchainInstaller9.2.0mp3.2_Intel.pkg Miosix Toolchain Mac OS (Intel)] (sha256sum 5420a4fdb7aee9337350a77bde4820d983d41c7e193cc7bc90612a58287c6010) Contributed by Daniele Cattaneo, it is a release build of the Miosix toolchain for Mac OS (Intel).

Library list

Daniele.cattaneo — Tue, 24 Mar 2026 00:14:55 GMT

Add ST HAL guide link

← Older revision		Revision as of 00:14, 24 March 2026
Line 3:		Line 3:
	* [[mxgui]] is a GUI library for graphic displays		* [[mxgui]] is a GUI library for graphic displays
	* [[mxusb]] is an USB stack, currently targeting stm32f1 microcontrollers only.		* [[mxusb]] is an USB stack, currently targeting stm32f1 microcontrollers only.

			You can also use the [[ST HAL Support in Miosix\|STMicroelectronics HAL code]] (with minimal adaptations) for any peripheral that does not have native Miosix drivers. However this is not recommended as in our experience the HAL often contains buggy or suboptimal drivers.

	[[Category:Libraries]]		[[Category:Libraries]]

ST Hal Support in Miosix

Daniele.cattaneo — Tue, 24 Mar 2026 00:12:37 GMT

Daniele.cattaneo moved page ST Hal Support in Miosix to ST HAL Support in Miosix Misspelled title

← Older revision		Revision as of 00:12, 24 March 2026
(One intermediate revision by the same user not shown)
Line 5:		Line 5:
	'''Note''': Miosix uses C++ instead of C		'''Note''': Miosix uses C++ instead of C

	;1. Follow the [[Quick start]] guide to configure the kernel and ~~installing~~ the ~~needed programs~~		;1. Follow the [[Quick start]] guide to configure the kernel and install all the required tools
	;2. Include "miosix.h" in ~~the~~ main file ~~of the code~~ (remember that the file main file must be named "main.cpp");		;2. Include "miosix.h" in your program's main file (remember that the file main file must be named "main.cpp") and wherever else you need to use Miosix's APIs;
	;3. Remove the clock configuration: Miosix already handles the clock configuration and keeping it in the code would result in a ~~lock~~ of the ~~board~~.		;3. Remove the clock configuration: Miosix already handles the clock configuration and keeping it in the code would result in a lockup of the microcontroller.

	:Usually the clock configuration is generated by STM32Cube and it looks like this:		:Usually the clock configuration is generated by STM32Cube and it looks like this:
Line 37:		Line 37:
	}		}
	}		}
			</pre>
			For some peripherals you might need to adjust peripheral-level clock configuration registers.

	~~</pre>~~
	:If your code contains interrupts refer to the section below.		:If your code contains interrupts refer to the section below.

Line 88:		Line 89:
	;5b. You need to do that also for any Shield that you are using.		;5b. You need to do that also for any Shield that you are using.

	;6. ~~Include also the file wrapper.cpp that handles~~ the function HAL_Delay() ~~for~~ Miosix~~, since Miosix handles~~ the ~~clock~~		;6. Create an implementation of the function HAL_Delay() by using the Miosix primitive Thread::Sleep(). You can put the implementation in a separate file (called for example wrapper.cpp) or wherever else you like.

	:Here the part that you need to modify in the example of the Makefile for the previous example:		:Here the part that you need to modify in the example of the Makefile for the previous example:
Line 119:		Line 120:
	----		----

	=== ~~Interrupt~~ ===		=== Interrupts ===

	Miosix ~~handles interrupts differently than ST~~ and thus the code needs to be adapted.		ST's HAL expects interrupt handler functions to be defined statically with weak symbols, allowing to define an interrupt handler for a given IRQ number by simply defining a function with the correct name. This does not work in Miosix and thus the code needs to be adapted.

	In Miosix ~~interrupts~~ need to be registered in order to be called. This is done by creating a lock and registering the IRQ like ~~this~~ example:		In Miosix interrupt handlers need to be registered at runtime in order to be called. This is done by creating a lock and registering the IRQ like in the following example:

	<pre>		<pre>
Line 134:		Line 135:
	This needs to be done for each interrupt that you have to register.		This needs to be done for each interrupt that you have to register.

	Keep in mind that the ~~lock~~ is ~~made using~~ a RAII style~~, so~~ the lock ~~exist~~ as long the variable exists ~~and the lock~~, thus encapsulating in brackets will ~~deallocate it~~ automatically when ~~no longer needed~~.		Keep in mind that the GlobalIrqLock object is a RAII style acquisition primitive. In other words the lock is held as long the "lock" variable exists, thus encapsulating its declaration in a block (curly brackets) will release the lock automatically when the block ends.

ST Hal Support in Miosix

Filippo.motti — Sat, 21 Mar 2026 10:33:43 GMT

This page contains a guide on how to port code that uses the HAL from ST into Miosix

New page

If you are developing or have existing code that uses the HAL from ST Microelectronics, you can port it fairly easily into Miosix by following this guide:

'''Note''': The content of this page was tested on Miosix v3.

'''Note''': Miosix uses C++ instead of C

;1. Follow the [[Quick start]] guide to configure the kernel and installing the needed programs
;2. Include "miosix.h" in the main file of the code (remember that the file main file must be named "main.cpp");
;3. Remove the clock configuration: Miosix already handles the clock configuration and keeping it in the code would result in a lock of the board.

:Usually the clock configuration is generated by STM32Cube and it looks like this:

<pre>
static void SystemClock_Config(void)
{
RCC_ClkInitTypeDef RCC_ClkInitStruct;
RCC_OscInitTypeDef RCC_OscInitStruct;

/* Enable Power Control clock */
__HAL_RCC_PWR_CLK_ENABLE();

/* The voltage scaling allows optimizing the power consumption when the device is
clocked below the maximum system frequency, to update the voltage scaling value
regarding system frequency refer to product datasheet. */
__HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE3);

/* Enable MSI Oscillator */
RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_MSI;
RCC_OscInitStruct.MSIState = RCC_MSI_ON;
RCC_OscInitStruct.MSIClockRange = RCC_MSIRANGE_5;
RCC_OscInitStruct.MSICalibrationValue=0x00;
RCC_OscInitStruct.PLL.PLLState = RCC_PLL_NONE;
if(HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)
{
/* Initialization Error */
Error_Handler();
}
}

</pre>
:If your code contains interrupts refer to the section below.

:Here an example code of the main.cpp for a blinking led in a Nucleo-L053R8 board:

<pre>
#include "miosix.h"
#include "stm32l053xx.h"
#include "stm32l0xx_hal.h"
#include <interfaces/bsp.h>
using namespace std;
using namespace miosix;

static void MX_GPIO_Init(void);

int main() {
iprintf("Hello world, write your application here\n");
HAL_Init();

MX_GPIO_Init();
for (;;) {
HAL_GPIO_TogglePin(GPIOA, GPIO_PIN_5);
HAL_Delay(500);
}
}
static void MX_GPIO_Init(void) {
__HAL_RCC_GPIOC_CLK_ENABLE();
__HAL_RCC_GPIOA_CLK_ENABLE();

GPIO_InitTypeDef GPIO_InitStruct = {0};

// Configure Led pin
GPIO_InitStruct.Pin = GPIO_PIN_5;
GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP;
GPIO_InitStruct.Pull = GPIO_NOPULL;
GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;

HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);
}
</pre>

;4. Include in the Makefile all the libraries and all the file .c needed to compile the program
Remember to include the HAL libraries and .c files used

;5. add a CFLAGS and CXXFLAGS that defines the type of board that you are using in the Makefile
:(ex: CFLAGS += -DSTM32L053xx and CXXFLAGS += -DSTM32L053xx for a stm32l053-R8).
:If you want, you can instead uncomment the type of the board in the Miosix folder (ex: for an stm32l053-R8, you need to uncomment "#define STM32L053xx" in "miosix/arch/common/CMSIS/Device/ST/STM32L0xx/Include/stm32l0xx.h")

;5b. You need to do that also for any Shield that you are using.

;6. Include also the file wrapper.cpp that handles the function HAL_Delay() for Miosix, since Miosix handles the clock

:Here the part that you need to modify in the example of the Makefile for the previous example:

<pre>
#Prevoius code
SRC :=main.cpp \
STM32CubeL0/Drivers/STM32L0xx_HAL_Driver/Src/stm32l0xx_hal.c \
STM32CubeL0/Drivers/BSP/STM32L0xx_Nucleo/stm32l0xx_nucleo.c \
STM32CubeL0/Drivers/STM32L0xx_HAL_Driver/Src/stm32l0xx_hal_gpio.h \
STM32CubeL0/Drivers/STM32L0xx_HAL_Driver/Src/stm32l0xx_hal_cortex.c \
wrapper.cpp

INCLUDE_DIRS := -ISTM32CubeL0/Drivers/STM32L0xx_HAL_Driver/Inc \
-ISTM32CubeL0/Drivers/BSP/STM32L0xx_Nucleo \
-Imiosix/arch/common/CMSIS/Device/ST/STM32L0xx/Include/ \
-ISTM32CubeL0/Projects/NUCLEO-L053R8/Examples/GPIO/GPIO_IOToggle/Inc

#Other code

CFLAGS += -DSTM32L053xx

CXXFLAGS += -DSTM32L053xx

#Other code
</pre>

;7. Compile and flash the program. This is done by using the command "make" and "make program".

----

=== Interrupt ===

Miosix handles interrupts differently than ST and thus the code needs to be adapted.

In Miosix interrupts need to be registered in order to be called. This is done by creating a lock and registering the IRQ like this example:

<pre>
{
GlobalIrqLock lock; //disable interrupts on the core that acquired the lock (all in single core)
IRQregisterIrq(lock, SPI2_IRQn, &SPIx_IRQHandler); //setup for SPI2, SPIx_IRQHandler is the handler called when the SPI finished sending a message
}
</pre>

This needs to be done for each interrupt that you have to register.

Keep in mind that the lock is made using a RAII style, so the lock exist as long the variable exists and the lock, thus encapsulating in brackets will deallocate it automatically when no longer needed.

User:Filippo.motti

Fede.tft — Tue, 17 Mar 2026 23:03:28 GMT

User account Filippo.motti was created by Fede.tft