Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

FreeRTOS module improvements

Ouverte
  • Quelque chose ne va pas ?
#880 0 commentaires 1 réaction 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
14/100
Type d'issue
Fonctionnalité
Clarté
À clarifier
Activité
À l'abandon
Stack technique
c
Domaine
build-system, embedded-iot

Piste de recherche

This is a roadmap of several separate tasks, not one change. Start with the FreeRTOS module's Zig wrapper in modules/freertos/src/root.zig and the RP2040 config in modules/freertos/config/RP2040/FreeRTOSConfig.h. Done would mean one sub-item (for example, wrapping one more FreeRTOS API function) is finished with maintainers agreeing on the approach first, since the multicore and port questions are still open design decisions.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

enhancement good first issue help wanted

#871 introduced FreeRTOS integration for RP2040 and RP2350 ARM targets but there is still more things to do.

More Zig wrapping functions

At this moment only few FreeRTOS API functions are wrapped in zig module, would be nice to add all of them.

More config options in build

Right now all FreeRTOS configs are set in FreeRTOSConfig.h file, would be nice to extract some of this option to zig build file. For example:
configTOTAL_HEAP_SIZE
configSUPPORT_STATIC_ALLOCATION
configNUMBER_OF_CORES

Allocator selection

Current implementation support just on default FreeRTOS heap allocator / strategy: heap_1.c We should allow in build config to select this by configuration option and expose all 5 standard allocators + add extra option where custom zig allocator could be provided.

Multicore support

Current ports for RP2xxx do not support multicore operation because the following functions remain unimplemented: multicore_launch_core1, multicore_reset_core1, and multicore_doorbell_claim_unused.

The main question is where these functions should be implemented: in Zig itself, or in C glue code that utilizes the Pico SDK implementation, similar to how IRQ handling is currently done. This confusion arose because the current Zig HAL already has an implementation of multicore_launch_core1, but its quality and correctness are unclear. Or maybe there should be build option to say which elements should be provided by C code?

RP2350 RISC-V port

I tried to add this port but finally get stuck with 2 missing symbols: __StackOneTop and __StackTop. In PicoSDK those are defined in liner script so microzig target would have to introduce something similar.

ESP32 C3 port

First, the base version used there is an older FreeRTOS release (V10.5.1) with custom patches. The current FreeRTOS version (V11.2.0) used by the MicroZig module already includes these patches and changes, so the only relevant parts are likely located here.

This code can either be reused directly or copied and slightly modified as needed. Don't know if generic RISC-V target from FreeRTOS repository can be used in this case directly.

CH32V port

Probably good place to start is this repo. It looks like those ports are using generic RISC-V port from FreeRTOS-Kernel repository and only thing that have to be included is additional header from chip_specific_extensions folder? All the rest code in linked repo looks like copy/paste from FreeRTOS.

Langage dominant
Zig
Étoiles
2.3k
Forks
198
Merge moyen
1 j 17 h
PR mergées (30 j)
25

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de ZigEmbeddedGroup/microzig

Toutes les issues de ZigEmbeddedGroup/microzig

Issues similaires

Plus d'issues Build System

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.