Difference between revisions of "RTOS"
m (add link to ERIKA RTOS projects repo on Github) |
m (Add section "Scheduling Mechanisms".) |
||
(One intermediate revision by the same user not shown) | |||
Line 2: | Line 2: | ||
[[Unix_and_Linux_config|Unix and Linux config]] :: [[Containers_and_virtual_machines|Containers]] :: [[Zephyr_device_driver_model|Zephyr device drivers]] :: [[Device_tree|Device Tree]] <!-- <link> --> | [[Unix_and_Linux_config|Unix and Linux config]] :: [[Containers_and_virtual_machines|Containers]] :: [[Zephyr_device_driver_model|Zephyr device drivers]] :: [[Device_tree|Device Tree]] <!-- <link> --> | ||
</center> | </center> | ||
+ | |||
+ | Real Time Operating Systems | ||
+ | |||
+ | Page started 2021-02-02 Tuesday | ||
+ | |||
+ | |||
+ | <!-- odne komentar --> | ||
<span id="nn_keywords__local_page__RTOS"></span> | <span id="nn_keywords__local_page__RTOS"></span> | ||
{| | {| | ||
|- | |- | ||
− | |Keywords: | + | |Keywords: [[#anchor_devzone_forum_posts|Nordicsemi Devzone posts]] : [[#anchor_nn_yaml_notes|YAML notes]] : popular RTOS variants 2021 : RTOS comparison |
|} | |} | ||
− | + | == Scheduling Mechanisms == | |
+ | |||
+ | Blocking versus asynchronous code design: | ||
+ | |||
+ | https://stackoverflow.com/questions/2625493/asynchronous-and-non-blocking-calls-also-between-blocking-and-synchronous | ||
+ | |||
+ | <!-- odne komentar --> | ||
+ | |||
+ | |||
+ | |||
+ | |||
* [https://slashdot.org/software/real-time-operating-systems-rtos/ 2023 RTOS comparisons at Slashdot] | * [https://slashdot.org/software/real-time-operating-systems-rtos/ 2023 RTOS comparisons at Slashdot] |
Latest revision as of 17:57, 11 November 2024
Unix and Linux config :: Containers :: Zephyr device drivers :: Device Tree
Real Time Operating Systems
Page started 2021-02-02 Tuesday
Keywords: Nordicsemi Devzone posts : YAML notes : popular RTOS variants 2021 : RTOS comparison |
Contents
Scheduling Mechanisms
Blocking versus asynchronous code design:
Some specific Real Time Operating System references:
^ ChibiOS
A brief history of ChibiOS development:
How to create static threads and dynamic threads, in ChibiOS:
How to choose thread's working area or memory size:
^ ChibiOS ports
This section dedicated to references and notes on ChibiOS ports to processors outside of the immediate, STM32xxx families of parts.
Adding this Nordicsemi Devzone article link regarding ChibiOS port to nRF9160 System In Package:
^ Zephyr RTOS
Introduction to Zephyr and some guides . . .
- https://docs.zephyrproject.org/latest/introduction/index.html
- https://docs.zephyrproject.org/latest/guides/dts/index.html#dt-guide
- https://docs.zephyrproject.org/latest/guides/dts/intro.html
Example code . . .
- https://docs.zephyrproject.org/latest/samples/hello_world/README.html
- https://docs.zephyrproject.org/latest/samples/philosophers/README.html
A tutorial for setting up support and build environment for Zephyr, and for flashing and testing on yet undetermined targets:
Zephyr demo supported boards
YAML data serialization language
- https://www.tutorialspoint.com/yaml/yaml_basics.htm
- https://yaml.org/spec/history/2001-08-01.html
- https://yaml.org/spec/1.2/spec.html
There appears to be an important high-level tool called west
which Zephyr developers and community use. It's also mentioned as the build tool for one or more of Nordic Semiconductor's nRF9160 example projects. A link to the github west
documentation is,
The west
project top level Github URL:
^ To configure Zephyr SDK
2021-07-27 Tuesday
While configuring Zephyr SDK for Linux command line builds having trouble with basic build after following Nordic Semi 'Getting Started' instructions. Meta-tool west
complains "not able to find toolchain.":
ted@localhost:~/zephyrproject/zephyr$ west build -b nrf9160dk_nrf9160@1.0.0 ./samples/basic/blinky -- west build: generating a build system Including boilerplate (Zephyr base (cached)): /home/ted/zephyrproject/zephyr/cmake/app/boilerplate.cmake -- Application: /home/ted/zephyrproject/zephyr/samples/basic/blinky -- Zephyr version: 2.6.99 (/home/ted/zephyrproject/zephyr), build: zephyr-v2.6.0-1460-g17d2e9d084b2 -- Found west (found suitable version "0.11.0", minimum required is "0.7.1") -- Board: nrf9160dk_nrf9160, Revision: 1.0.0 (Active: 0.14.0) -- Cache files will be written to: /home/ted/.cache/zephyr -- Using toolchain: zephyr 0.12.4 (/opt/zephyr-sdk-0.12.4) -- Found dtc: /usr/bin/dtc (found suitable version "1.5.0", minimum required is "1.4.6") -- Found toolchain: cross-compile (arm-unknown-linux-gnueabi-) CMake Error at /home/ted/zephyrproject/zephyr/cmake/compiler/gcc/generic.cmake:8 (message): Zephyr was unable to find the toolchain. Is the environment misconfigured?</font> <-- from generic.cmake User-configuration: ZEPHYR_TOOLCHAIN_VARIANT: cross-compile Internal variables: CROSS_COMPILE: arm-unknown-linux-gnueabi- TOOLCHAIN_HOME: Call Stack (most recent call first): /home/ted/zephyrproject/zephyr/cmake/generic_toolchain.cmake:42 (include) /home/ted/zephyrproject/zephyr/cmake/app/boilerplate.cmake:570 (include) /home/ted/zephyrproject/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:24 (include) /home/ted/zephyrproject/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:40 (include_boilerplate) CMakeLists.txt:4 (find_package) -- Configuring incomplete, errors occurred! FATAL ERROR: command exited with status 1: /usr/bin/cmake -DWEST_PYTHON=/usr/bin/python3 -B/home/ted/zephyrproject/zephyr/build -S/home/ted/zephyrproject/zephyr/samples/basic/blinky -GNinja The pattern "Found toolchain:" comes from one of the following cmake files: ted@localhost:~/zephyrproject$ grep -nr "Found toolchain:" ./* ./zephyr/cmake/toolchain/host/generic.cmake:9:message(STATUS "Found toolchain: host (gcc/ld)") ./zephyr/cmake/toolchain/llvm/generic.cmake:32:message(STATUS "Found toolchain: host (clang/ld)") ./zephyr/cmake/toolchain/cross-compile/generic.cmake:31:message(STATUS "Found toolchain: cross-compile (${CROSS_COMPILE})") ./zephyr/cmake/toolchain/gnuarmemb/generic.cmake:32:message(STATUS "Found toolchain: gnuarmemb (${GNUARMEMB_TOOLCHAIN_PATH})") ./zephyr/cmake/toolchain/xtools/generic.cmake:40:message(STATUS "Found toolchain: xtools (${XTOOLS_TOOLCHAIN_PATH})") ./zephyr/cmake/toolchain/oneApi/generic.cmake:46:message(STATUS "Found toolchain: host (clang/ld)") ./zephyr/cmake/toolchain/xcc/generic.cmake:44:message(STATUS "Found toolchain: xcc (${XTENSA_TOOLCHAIN_PATH})") ./zephyr/cmake/toolchain/espressif/generic.cmake:21:message(STATUS "Found toolchain: espressif (${ESPRESSIF_TOOLCHAIN_PATH})")
^ edit point
Questions:
(1) what is in this file: /home/ted/zephyrproject/zephyr/cmake/compiler/gcc/generic.cmake
?
(2) where originates this string pattern: arm-unknown-linux-gnueabi
?
Answers:
(2) the pattern 'arm-unknown-linux-gnueabi-' does not appear to original in ~/zephyrproject/zephyr
:
ted@localhost:~/zephyrproject/zephyr$ grep -nr 'arm-unknown-linux-gnueabi-' ./* ./build/CMakeCache.txt:53:CROSS_COMPILE:PATH=arm-unknown-linux-gnueabi-
Unsure whether this is correct but we have these newly drafted environment variables set:
ted@localhost:~/zephyrproject/zephyr$ set | grep ZEPHYR ZEPHYR_SDK_INSTALL_DIR=/opt ZEPHYR_TOOLCHAIN_VARIANT=zephyr
^ generic cmake
Zephyr project file generic.cmake
looks to be the most likely source of the fatal error message above. A search for part of the message text pattern gives:
ted@localhost:~/zephyrproject$ grep -nr 'unable to find the toolchain' ./* ./zephyr/cmake/compiler/xcc/generic.cmake:8: message(FATAL_ERROR "Zephyr was unable to find the toolchain. Is the environment misconfigured? ./zephyr/cmake/compiler/gcc/generic.cmake:8: message(FATAL_ERROR "Zephyr was unable to find the toolchain. Is the environment misconfigured? ./zephyr/doc/releases/release-notes-2.0.rst:1230:* :github:`15587` - Zephyr was unable to find the toolchain ./zephyr/doc/releases/release-notes-2.1.rst:663:* :github:`19802` - Zephyr was unable to find the toolchain after update to zephyr version 1.13.0 ted@indulkana:~/zephyrproject$
The content of generic.cmake
raises a question, how and where may we as users set the variable ${TOOLCHAIN_HOME}
? Here is the cmake file, line 5 catches our attention because TOOLCHAIN_HOME is passed to a function as the only path set to search for Zephyr project's build tools:
1 # SPDX-License-Identifier: Apache-2.0 2 3 set_ifndef(CC gcc) 4 5 find_program(CMAKE_C_COMPILER ${CROSS_COMPILE}${CC} PATHS ${TOOLCHAIN_HOME} NO_DEFAULT_PATH) 6 7 if(CMAKE_C_COMPILER STREQUAL CMAKE_C_COMPILER-NOTFOUND) 8 message(FATAL_ERROR "Zephyr was unable to find the toolchain. Is the environment misconfigured? 9 User-configuration: 10 ZEPHYR_TOOLCHAIN_VARIANT: ${ZEPHYR_TOOLCHAIN_VARIANT} 11 Internal variables: 12 CROSS_COMPILE: ${CROSS_COMPILE} 13 TOOLCHAIN_HOME: ${TOOLCHAIN_HOME} 14 ") 15 endif() 16 17 execute_process( 18 COMMAND ${CMAKE_C_COMPILER} --version 19 RESULT_VARIABLE ret 20 OUTPUT_QUIET 21 ERROR_QUIET 22 ) 23 if(ret) 24 message(FATAL_ERROR "Executing the below command failed. Are permissions set correctly? 25 '${CMAKE_C_COMPILER} --version' 26 " 27 ) 28 endif()
Locating Zephyr SDK toolchain compilers, there appear to be multiple of them:
ted@localhost:/opt/zephyr-sdk-0.12.4$ ls aarch64-zephyr-elf arm-zephyr-eabi info-zephyr-sdk-0.12.4 nios2-zephyr-elf sdk_version sysroots xtensa arc-zephyr-elf cmake mips-zephyr-elf riscv64-zephyr-elf sparc-zephyr-elf x86_64-zephyr-elf
^ Successful example code build
ted@indulkana:~/zephyrproject/zephyr$ west build -b nrf9160dk_nrf9160@1.0.0 ./samples/basic/blinky -- west build: generating a build system Including boilerplate (Zephyr base (cached)): /home/ted/zephyrproject/zephyr/cmake/app/boilerplate.cmake -- Application: /home/ted/zephyrproject/zephyr/samples/basic/blinky -- Zephyr version: 2.6.99 (/home/ted/zephyrproject/zephyr), build: zephyr-v2.6.0-1460-g17d2e9d084b2 -- Found west (found suitable version "0.11.0", minimum required is "0.7.1") -- Board: nrf9160dk_nrf9160, Revision: 1.0.0 (Active: 0.14.0) -- Cache files will be written to: /home/ted/.cache/zephyr -- Using toolchain: zephyr 0.12.4 (/opt/zephyr-sdk-0.12.4) -- Found dtc: /usr/bin/dtc (found suitable version "1.5.0", minimum required is "1.4.6") -- Found toolchain: cross-compile (arm-unknown-linux-gnueabi-) -- Found BOARD.dts: /home/ted/zephyrproject/zephyr/boards/arm/nrf9160dk_nrf9160/nrf9160dk_nrf9160.dts -- Found devicetree overlay: /home/ted/zephyrproject/zephyr/boards/arm/nrf9160dk_nrf9160/nrf9160dk_nrf9160_0_14_0.overlay -- Generated zephyr.dts: /home/ted/zephyrproject/zephyr/build/zephyr/zephyr.dts -- Generated devicetree_unfixed.h: /home/ted/zephyrproject/zephyr/build/zephyr/include/generated/devicetree_unfixed.h -- Generated device_extern.h: /home/ted/zephyrproject/zephyr/build/zephyr/include/generated/device_extern.h Parsing /home/ted/zephyrproject/zephyr/Kconfig Loaded configuration '/home/ted/zephyrproject/zephyr/boards/arm/nrf9160dk_nrf9160/nrf9160dk_nrf9160_defconfig' Merged configuration '/home/ted/zephyrproject/zephyr/samples/basic/blinky/prj.conf' Configuration saved to '/home/ted/zephyrproject/zephyr/build/zephyr/.config' Kconfig header saved to '/home/ted/zephyrproject/zephyr/build/zephyr/include/generated/autoconf.h' -- The C compiler identification is GNU 10.2.0 -- The CXX compiler identification is GNU 10.2.0 -- The ASM compiler identification is GNU -- Found assembler: /opt/zephyr-sdk-0.12.4/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc -- Configuring done -- Generating done -- Build files have been written to: /home/ted/zephyrproject/zephyr/build -- west build: building application [1/145] Preparing syscall dependency handling [138/145] Linking C executable zephyr/zephyr_prebuilt.elf [145/145] Linking C executable zephyr/zephyr.elf Memory region Used Size Region Size %age Used FLASH: 16736 B 1 MB 1.60% SRAM: 4 KB 88 KB 4.55% IDT_LIST: 0 GB 2 KB 0.00% ted@indulkana:~/zephyrproject/zephyr$
Changes to generic.cmake:
1 # SPDX-License-Identifier: Apache-2.0 2 3 set_ifndef(CC gcc) 4 5 ## 2021-07-28 - Ted adding local assignment to empty variable: 6 ## Reference: https://cmake.org/cmake/help/latest/command/set.html 7 set_ifndef(TOOLCHAIN_HOME /opt/zephyr-sdk-0.12.4/arm-zephyr-eabi/bin) 8 #unset(CROSS_COMPILE) 9 set(CROSS_COMPILE arm-zephyr-eabi-) 10 11 find_program(CMAKE_C_COMPILER ${CROSS_COMPILE}${CC} PATHS ${TOOLCHAIN_HOME} NO_DEFAULT_PATH) 12 13 if(CMAKE_C_COMPILER STREQUAL CMAKE_C_COMPILER-NOTFOUND) 14 message(FATAL_ERROR "Zephyr was unable to find the toolchain. Is the environment misconfigured? _ zztop _ 15 User-configuration: 16 ZEPHYR_TOOLCHAIN_VARIANT: ${ZEPHYR_TOOLCHAIN_VARIANT} 17 Internal variables: 18 CROSS_COMPILE: ${CROSS_COMPILE} 19 CC: ${CC} 20 TOOLCHAIN_HOME: ${TOOLCHAIN_HOME} 21 ") 22 endif() 23 24 execute_process( 25 COMMAND ${CMAKE_C_COMPILER} --version 26 RESULT_VARIABLE ret 27 OUTPUT_QUIET 28 ERROR_QUIET 29 ) 30 if(ret) 31 message(FATAL_ERROR "Executing the below command failed. Are permissions set correctly? 32 '${CMAKE_C_COMPILER} --version' 33 " 34 ) 35 endif()
^ Devzone posts
- https://devzone.nordicsemi.com/f/nordic-q-a/78008/how-to-set-toolchain_home-in-command-line-ubuntu-based-zephyr-sdk
- https://devzone.nordicsemi.com/f/nordic-q-a/78827/nrf1960-and-out-of-tree-zephyr-new-driver-development
Library newlibc
needed to print floating point values in Zephyr app:
2021-09-23 Following post mentions way to "un-brick" an nRF9160 Feather development board, by updating [Nordic] modem firmware on the dev board through a feature named "tag connect". This un-bricking strategy may come in handy:
A post on Segger Embedded Studio global macros syntax:
Post number 4 content:
* nRF Command Line Tools 10.13.0, 10.12.0 missing JLinkARM.dll Hello Nordic Devzone Community, I'm having some trouble install nRF Command Line Tools on a 64-bit Linux host. From Nordic's page https://www.nordicsemi.com/Products/Development-tools/nrf-command-line-tools/download I've downloaded version 10.13.0, and then 10.12.0. SHA256 sums verify correctly. For some reason 10.14.0 is not available even though there is a selectable radio button for this version. These tools install in /opt. Updating my $PATH variable I can confirm the version of nrfjprog which is now installed: $ nrfjprog --version nrfjprog version: 10.12.2 JLinkARM.dll version: 6.88a When I attempt to program a Zephyr app to a sparkfun_thing_plus_nrf9160 development board, I keep seeing the error message "JLinkARM.dll . . . JLink Both 10.13.0 and 10.12.0 show this behavior. When working in a Linux environment is it not correct to follow the install steps?: * unzip nRF-Command-Line-Tools_10_12_2_Linux-amd64.zip * tar xvzf nRF-Command-Line-Tools_10_12_2_Linux-amd64.tar.gz * sudo dpkg -i JLink_Linux_V750a_x86_64.deb nRF-Command-Line-Tools_10_13_0_Linux-amd64.deb Dragging and dropping full log file here . . . - Ted
^ Device Tree Binary Paradigm and Zephyr RTOS
This section to cover device tree binaries and the systems in place for writing and compiling them. Zephyr RTOS project has a multi-part introductory documentation on this topic:
- https://docs.zephyrproject.org/latest/guides/dts/intro.html . . . DTS Zephyr guide, latest version
- https://docs.zephyrproject.org/1.14.0/guides/dts/index.html . . . DTS Zephyr guide, v1.14.0
- https://docs.zephyrproject.org/latest/guides/dts/howtos.html#dt-howtos . . . DTS How-to
DTS stands for Device Tree Source. The DTS specification is detailed in PDF files, with a latest version, at DeviceTree dot org's web site:
- 2021-08-07 SAT -
An important page and starting point to understand Device Tree Source (.dts) files. Text excerpt included here as there's instructions for quickly reviewing the merged sum of all device tree source files in a west-managed Zephyr project:
* https://docs.zephyrproject.org/2.5.0/guides/dts/howtos.html
Zephyr RTOS docs excerpt from above linked page:
-
"
Get your devicetree and generated header
A board’s devicetree (BOARD.dts) pulls in common node definitions via #include preprocessor directives. This at least includes the SoC’s .dtsi. One way to figure out the devicetree’s contents is by opening these files, e.g. by looking in dts/<ARCH>/<vendor>/<soc>.dtsi, but this can be time consuming.
If you just want to see the “final” devicetree for your board, build an application and open the zephyr.dts file in the build directory.
Tip
You can build Hello World to see the “base” devicetree for your board without any additional changes from overlay files. "
Device Tree Overlay files are important:
^ Zephyr RTOS and I2C
This section contains notes from search effort to find Zephyr RTOS I2C configuration and API call examples.
First of these URLs points to Nordic's page with many tens of example Zephyr projects. Second URL points to example project that appears to talk to the LIS2DH accelerometer . . .
^ General RTOS Considerations
- http://locolabs.com/how-to-choose-the-right-firmware-architecture-for-your-iot-device-2/
- https://resources.sw.siemens.com/en-US/white-paper-moving-from-an-rtos-to-linux?cmpid=13526
- https://lwn.net/Articles/824029/
^ References
Zephyr Device Tree deep dive . . .
Project Soli embedded radar