Création d'un fichier de liste pour votre plateforme à partir du modèle CMakeLists.txt - FreeRTOS

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Création d'un fichier de liste pour votre plateforme à partir du modèle CMakeLists.txt

ACMakeLists.txtest fourni avec FreeRTOS, sousfreertos/vendors/vendor/boards/board/CMakeLists.txt.

Le fichier de modèle CMakeLists.txt se compose de quatre sections :

Suivez les instructions pour modifier ces quatre sections du fichier de liste pour qu'elles correspondent à votre plateforme. Vous pouvez consulter les fichiers CMakeLists.txt pour d'autres cartes qualifiées sous freertos/vendors à titre d’exemple.

Deux principales fonctions sont appelées dans le fichier :

afr_set_board_metadata(name value)

Cette fonction définit les métadonnées pour la console FreeRTOS. La fonction est définie dans freertos/tools/cmake/afr_metadata.cmake.

afr_mcu_port(module_name [<DEPENDS> [targets...]])

Cette fonction définit la cible de la couche portable associée à un module FreeRTOS (c'est-à-dire une bibliothèque). Une cible GLOBAL INTERFACE IMPORTED CMake est créée, dont le nom se présente sous la forme AFR:module_name::mcu_port. Si DEPENDS est utilisé, les cibles supplémentaires sont liées avec target_link_libraries. La fonction est définie dans freertos/tools/cmake/afr_module.cmake.

Métadonnées de la console FreeRTOS

La première section du fichier de modèle définit les métadonnées utilisées pour afficher les informations d'une carte dans la console FreeRTOS. Utilisez la fonction afr_set_board_metadata(name value) pour définir chaque champ répertorié dans le modèle. Ce tableau fournit une description de chaque champ.

Nom de champ Description
ID ID unique pour la carte.
DISPLAY_NAME Nom de la carte tel que vous souhaitez le voir affiché sur la console FreeRTOS.
DESCRIPTION Brève description de la carte pour la console FreeRTOS.
VENDOR_NAME Nom du fournisseur de la carte.
FAMILY_NAME Nom de la famille de microcontrôleurs de la carte.
DATA_RAM_MEMORY Taille de la RAM de la carte, suivie des unités abrégées. Par exemple, utilisez Ko pour kilo-octets.
PROGRAM_MEMORY Taille de la mémoire programme de la carte, suivie des unités abrégées. Par exemple, utilisez Mo pour mégaoctets.
CODE_SIGNER Plateforme de signature de code utilisée pour les mises à jour OTA. Utilisez AmazonFreeRTOS-Default pour l’algorithme de hachage SHA256 et l’algorithme de chiffrement ECDSA. Si vous souhaitez utiliser une autre plateforme de signature de code, contactez-nous.
SUPPORTED_IDE Liste délimitée par points virgule répertoriant les ID pour les IDE pris en charge par la carte.
IDE_ID_NAME Nom de l'IDE pris en charge. Remplacez ID par l'ID répertoriée pour l'IDE dans le champ SUPPORTED_IDE.
IDE_ID_COMPILER Liste délimitée par points virgule des noms des compilateurs pris en charge pour l’IDE pris en charge. Remplacez ID par l'ID répertoriée pour l'IDE dans le champ SUPPORTED_IDE.
KEY_IMPORT_PROVISIONING

Définissez sur TRUE si le projet de démonstration de carte importe les informations d'identification à partir duaws_clientcredential_keys.h ; dans ce cas,Connect rapidesera activé dans la console FreeRTOS.

Définissez la valeur FALSE si le mécanisme de provisionnement du conseil d'administration prévu est JITR/JITP ou l'enregistrement de plusieurs comptes ; dans ce cas,Connect rapidesera désactivé dans la console FreeRTOS.

Paramètres du compilateur

La deuxième section du fichier de modèle définit les paramètres du compilateur pour votre carte. Pour créer une cible qui contient les paramètres du compilateur, appelez la fonction afr_mcu_port avec compiler au lieu de module_name pour créer une cible INTERFACE avec le nom AFR::compiler::mcu_port. Le noyau renvoie publiquement vers cette cible INTERFACE afin que les paramètres du compilateur soient transitivement renseignés pour tous les modules.

Utilisez les fonctions CMake standard intégrées pour définir les paramètres du compilateur dans cette section du fichier de liste. Lorsque vous définissez les paramètres du compilateur, suivez ces bonnes pratiques :

  • Utilisez target_compile_definitions pour fournir des définitions et des macros compilées.

  • Utilisez target_compile_options pour fournir des indicateurs du compilateur.

  • Utilisez target_include_directories pour fournir des répertoires d’inclusion.

  • Utilisez target_link_options pour fournir des indicateurs d’éditeur.

  • Utilisez target_link_directories pour fournir des répertoires linker-search.

  • Utilisez target_link_libraries pour fournir des bibliothèques auxquelles se lier.

Note

Si vous définissez les paramètres du compilateur ailleurs, vous n'avez pas besoin de dupliquer les informations de cette section du fichier. Au lieu de cela, appelez la fonction afr_mcu_port avec DEPENDS afin d’intégrer la définition cible depuis un autre emplacement.

Exemples :

# your_target is defined somewhere else. It does not have to be in the same file. afr_mcu_port(compiler DEPENDS your_target)

Lorsque vous appelez la fonction afr_mcu_port avec DEPENDS, cela appelle target_link_libraries(AFR::module_name::mcu_port INTERFACE your_targets), qui remplit les paramètres du compilateur requis pour la cible AFR::compiler::mcu_port requise.

Utilisation de plusieurs compilateurs

Si votre carte prend en charge plusieurs compilateurs, vous pouvez utiliser la variable AFR_TOOLCHAIN pour sélectionner de façon dynamique les paramètres du compilateur. Cette variable est définie sur le nom du compilateur que vous utilisez, qui doit normalement être identique au nom du fichier de la chaîne d'outils sous freertos/tools/cmake/toolchains.

Exemples :

if("${AFR_TOOLCHAIN}" STREQUAL "arm-gcc") afr_mcu_port(compiler DEPENDS my_gcc_settings). elseif("${AFR_TOOLCHAIN}" STREQUAL "arm-iar") afr_mcu_port(compiler DEPENDS my_iar_settings). else() message(FATAL_ERROR "Compiler ${AFR_TOOLCHAIN} not supported.") endif()

Paramètres avancés du compilateur

Pour définir des paramètres du compilateur plus avancés, tels que la configuration d’indicateurs du compilateur en fonction du langage de programmation, ou la modification de paramètres pour les différentes configurations de débogage et de version, vous pouvez utiliser des expressions du générateur CMake.

Exemples :

set(common_flags "-foo") set(c_flags "-foo-c") set(asm_flags "-foo-asm") target_compile_options( my_compiler_settings INTERFACE $<$<COMPILE_LANGUAGE:C>:${common_flags} ${c_flags}> # This only have effect on C files. $<$<COMPILE_LANGUAGE:ASM>:${common_flags} ${asm_flags}> # This only have effect on ASM files. )

Les expressions du générateur CMake ne sont pas évaluées à l’étape de configuration, lors de laquelle CMake lit les fichiers de liste. Ils sont évalués lors de la phase de génération, lorsque CMake termine de lire les fichiers de liste et génère les fichiers de build pour le système de build cible.

Couches portables FreeRTOS

La troisième section du fichier de modèle définit toutes les cibles de couche portables pour FreeRTOS (à savoir les bibliothèques).

Vous devez utiliser leafr_mcu_port(module_name)pour définir une couche portable cible pour chaque module FreeRTOS que vous prévoyez d'implémenter.

Vous pouvez utiliser les fonctions CMake de votre choix, tant que l'afr_mcu_portcrée une cible dont le nom fournit les informations requises pour créer le module FreeRTOS correspondant.

La fonction afr_mcu_port crée une bibliothèque cible GLOBAL INTERFACE IMPORTED, dont le nom se présente sous le format AFR::module_name::mcu_port. En tant que cible GLOBAL, elle peut être référencée dans les fichiers de liste CMake. En tant queINTERFACE, elle n'est pas générée sous la forme d'une bibliothèque ou d'une cible autonome, mais elle est compilée dans le module FreeRTOS correspondant. En tant que cible IMPORTED, son nom comprend un espace de noms (::) dans le nom cible (par exemple, AFR::kernel::mcu_port).

Les modules sans cibles de couche portable correspondantes sont désactivés par défaut. Si vous exécutez CMake pour configurer FreeRTOS, sans définir de cibles de couches portables, le résultat suivant devrait apparaître :

FreeRTOS modules: Modules to build: Disabled by user: Disabled by dependency: kernel, posix, pkcs11, secure_sockets, mqtt, ... Available demos: Available tests:

Lorsque vous mettez à jour laCMakeLists.txtavec les cibles de couches de portage, les modules FreeRTOS correspondants sont activés. Vous devriez également être en mesure de construire n'importe quel module FreeRTOS dont les exigences de dépendance sont satisfaites par la suite. Par exemple, si la bibliothèque CoreMQTT est activée, la bibliothèque Device Shadow est également activée, car sa seule dépendance est la bibliothèque CoreMQTT.

Note

La dépendance du noyau FreeRTOS est une exigence minimum. La configuration CMake échoue si la dépendance du noyau FreeRTOS n'est pas satisfaite.

Configuration de la cible de portage du noyau

Pour créer la cible de portage du noyau (AFR::kernel::mcu_port), appelez la fonction afr_mcu_port avec le nom de module kernel. Lorsque vous appelez afr_mcu_port, spécifiez les cibles pour le code du pilote et la couche portable FreeRTOS. Une fois que vous avez créé la cible, vous pouvez fournir les informations de dépendance ainsi que le code du pilote et la couche portable FreeRTOS pour la cible à utiliser.

Suivez les instructions ci-dessous pour configurer la cible de portage du noyau.

Pour configurer la cible de portage du noyau

  1. Créez une cible pour le code du pilote.

    Par exemple, vous pouvez créer une cible de bibliothèque STATIC pour le code du pilote :

    add_library(my_board_driver STATIC ${driver_sources}) # Use your compiler settings target_link_libraries( my_board_driver PRIVATE AFR::compiler::mcu_port # Or use your own target if you already have it. # PRIVATE ${compiler_settings_target} ) target_include_directories( my_board_driver PRIVATE "include_dirs_for_private_usage" PUBLIC "include_dirs_for_public_interface" )

    Ou vous pouvez créer une cible de bibliothèque INTERFACE pour le code du pilote :

    # No need to specify compiler settings since kernel target has them. add_library(my_board_driver INTERFACE ${driver_sources})
    Note

    Une cible de bibliothèque INTERFACE n'a pas de sortie de génération. Si vous utilisez une cible de bibliothèque INTERFACE, le code du pilote est compilé dans la bibliothèque du noyau.

  2. Configurez la couche portable FreeRTOS :

    add_library(freertos_port INTERFACE) target_sources( freertos_port INTERFACE "${AFR_MODULES_DIR}/freertos_kernel/portable/GCC/ARM_CM4F/port.c" "${AFR_MODULES_DIR}/freertos_kernel/portable/GCC/ARM_CM4F/portmacro.h" "${AFR_MODULES_DIR}/freertos_kernel/portable/MemMang/heap_4.c" ) target_include_directories( freertos_port INTERFACE "${AFR_MODULES_DIR}/freertos_kernel/portable/GCC/ARM_CM4F" "${include_path_to_FreeRTOSConfig_h} )
    Note

    Vous pouvez également configurer la couche portable FreeRTOS en spécifiant ces fichiers sources et leurs répertoires d’inclusion directement dans la cible AFR::kernel::mcu_port.

  3. Créez la cible de la couche de portage du noyau :

    # Bring in driver code and freertos portable layer dependency. afr_mcu_port(kernel DEPENDS my_board_driver freertos_port) # If you need to specify additional configurations, use standard CMake functions with # AFR::kernel::mcu_port as the target name. target_include_directories( AFR::kernel::mcu_port INTERFACE "${additional_includes}" # e.g. board configuration files ) target_link_libraries( AFR::kernel::mcu_port INTERFACE "${additional_dependencies}" )
  4. Pour tester votre fichier de liste et votre configuration, vous pouvez écrire une application simple utilisant le port du noyau FreeRTOS. Pour de plus amples informations sur le développement et la création d'applications FreeRTOS avec CMake, veuillez consulterGénération de FreeRTOS avec CMake.

  5. Une fois que vous avez créé la démonstration, appelez les fonctions add_executable et target_link_libraries dans le fichier de liste et compilez le noyau en tant que bibliothèque statique afin de vérifier que la couche portable du noyau est correctement configurée.

    add_executable( my_demo main.c ) target_link_libraries( my_demo PRIVATE AFR::kernel )

Configuration des cibles de portage pour les modules FreeRTOS

Une fois que vous avez ajouté la cible de couche portable pour le noyau, vous pouvez ajouter des cibles de couche portable supplémentaires pour d'autres modules FreeRTOS.

Par exemple, pour ajouter la couche portable pour le module Wi-Fi :

afr_mcu_port(wifi) target_sources( AFR::wifi::mcu_port INTERFACE "${AFR_MODULES_DIR}/vendors/vendor/boards/board/ports/wifi/iot_wifi.c" )

Cet exemple de couche portable de module Wi-Fi n'a qu'un seul fichier d’implémentation, basé sur le code du pilote.

Si vous souhaitez ajouter la couche portable pour le module FreeRTOS Secure Sockets, le module dépend de TLS. Cela rend sa cible de couche portable légèrement plus complexe que celle du module Wi-Fi. FreeRTOS fournit une implémentation TLS par défaut basée sur mbedTLS que vous pouvez lier à :

afr_mcu_port(secure_sockets) target_sources( AFR::secure_sockets::mcu_port INTERFACE ${portable_layer_sources} ) target_link_libraries( AFR::secure_sockets::mcu_port AFR::tls )

Dans cet exemple de code, la fonction target_link_libraries CMake standard indique que la couche portable Secure Sockets dépend de AFR::tls.

Vous pouvez référencer tous les modules FreeRTOS à l'aide de leur nom cibleAFR::module_name. Par exemple, vous pouvez utiliser la même syntaxe pour indiquer également une dépendance sur FreeRTOS-Plus-TCP :

target_link_libraries( AFR::secure_sockets::mcu_port AFR::freertos_plus_tcp AFR::tls )
Note

Si votre plateforme gère TLS par elle-même, vous pouvez directement utiliser le code de votre pilote. Si vous utilisez votre code de pilote directement pour TLS, vous n'avez pas besoin d'appelertarget_link_libraries, car tous les modules FreeRTOS dépendent implicitement du noyau qui inclut le code de votre pilote.

Étant donné que tous les modules FreeRTOS non-noyau dépendent implicitement du noyau, leurs couches de portage n'exigent pas que vous spécifiiez le noyau en tant que dépendance. Le module POSIX est cependant défini comme un module noyau facultatif. Si vous voulez utiliser POSIX, vous devez l'inclure explicitement dans votre couche portable du noyau. Exemples :

# By default, AFR::posix target does not expose standard POSIX headers in its public # interface, i.e., You need to use "freertos_plus_posix/source/FreeRTOS_POSIX_pthread.c" instead of "pthread.h". # Link to AFR::use_posix instead if you need to use those headers directly. target_link_libraries( AFR::kernel::mcu_port INTERFACE AFR::use_posix )

Démonstrations et tests FreeRTOS

La dernière section du fichier de modèle définit les cibles de démonstration et de test pour FreeRTOS. Les cibles CMake sont créées automatiquement pour chaque démonstration et test qui satisfait aux exigences de dépendance.

Dans cette section, définissez une cible exécutable avec la fonction add_executable. Utilisez aws_tests comme nom cible si vous compilez des tests, ou aws_demos si vous compilez des démonstrations. Il est possible que vous ayez besoin de fournir d'autres paramètres de projet, tels que des scripts d’éditeur et des commandes post-build. Exemples :

if(AFR_IS_TESTING) set(exe_target aws_tests) else() set(exe_target aws_demos) endif() set(CMAKE_EXECUTABLE_SUFFIX ".elf") add_executable(${exe_target} "${board_dir}/application_code/main.c")

La fonction target_link_libraries est ensuite appelée pour lier des cibles de démonstration ou de test CMake disponibles vers votre cible exécutable.

Note

Vous devez toujours modifier aws_demos/config_files/aws_demo_config.h et aws_tests/config_files/aws_test_runner_config.h pour activer les démonstrations et les tests.

Exécution des commandes post-build

Pour plus d'informations sur l'exécution de commandes post-build, consultez add_custom_command. Utilisez la deuxième signature. Exemples :

# This should run an external command "command --arg1 --arg2". add_custom_command( TARGET ${exe_target} POST_BUILD COMMAND "command" "--arg1" "--arg2" )
Note

CMake prend en charge de nombreuses opérations courantes et indépendantes de la plateforme pour créer des répertoires, copier des fichiers, etc. Pour plus d'informations sur les opérations de ligne de commande CMake, consultez la documentation de référence sur l'outil de ligne de commande CMake. Vous pouvez référencer l'outil de ligne de commande CMake à partir d'un fichier de liste CMake avec la variable intégrée ${CMAKE_COMMAND}.