Ami du micrologiciel Prusa

Copain

Ce référentiel comprend le code source et les versions du micrologiciel pour les imprimantes 3D Original Prusa basées sur les microcontrôleurs ARM 32 bits.

Les modèles actuellement pris en charge sont :

• Prusa MINI/MINI+ d'origine
• Prusa MK3.5 originale
• Prusa MK3.9 originale
• Prusa MK4 originale
• Prusa XL originale

Commencer

Exigences

• Python 3.8 ou version ultérieure

Cloner ce référentiel

Exécutez git clone https://github.com/prusa3d/Prusa-Firmware-Buddy.git .

Building (sur toutes les plateformes, sans IDE)

Exécutez python utils/build.py . Les binaires vont ensuite être stockés sous ./build/products .

• Sans aucun argument, il créera une version du micrologiciel pour toutes les imprimantes et paramètres du chargeur de démarrage pris en charge.
• Pour générer des versions .bbf du micrologiciel, utilisez : ./utils/build.py --generate-bbf .
• Utilisez --build-type pour sélectionner les configurations de build à construire ( debug , release ).
• Utilisez --preset pour sélectionner pour quelles imprimantes le micrologiciel doit être construit.
• Par défaut, il construira le firmware en "mode préversion" défini sur beta . Vous pouvez modifier la version préliminaire en utilisant --prerelease alpha ou utiliser --final pour créer une version finale du micrologiciel.
• Utilisez --host-tools pour inclure les outils hôtes dans la build ( bin2cc , png2font , ...)
• Trouvez plus d'options en utilisant l'indicateur --help !

Exemples :

Construisez le firmware pour MINI et XL en mode debug :

python utils/build.py --preset mini,xl --build-type debug

Créez le firmware pour MINI en utilisant une version personnalisée de gcc-arm-none-eabi (disponible dans $PATH ) et utilisez Make au lieu de Ninja (non recommandé) :

python utils/build.py --preset mini --toolchain cmake/AnyGccArmNoneEabi.cmake --generator ' Unix Makefiles ' 

Dépannage de Windows 10

Si Python est installé et dans votre PATH mais que vous obtenez toujours l'erreur cmake Python3 not found. Essayez d'exécuter python et python3 depuis cmd. Si l'un d'entre eux ouvre le Microsoft Store au lieu d'ouvrir l'interpréteur Python ou de se plaindre 'python3' is not recognized as an internal or external command, operable program or batch file. Ouvrez manage app execution aliases et désactivez l’association App Installer avec python.exe et python3.exe .

Développement

Le processus de construction de ce projet est piloté par CMake et build.py n'est qu'un wrapper de haut niveau autour de celui-ci. Comme la plupart des IDE modernes prennent en charge une sorte d’intégration CMake, il devrait être possible d’utiliser presque n’importe quel éditeur pour le développement. Vous trouverez ci-dessous quelques documents décrivant comment configurer certains éditeurs de texte populaires.

• Code de Visual Studio
• Vim
• Eclipse, STM32CubeIDE
• Autres IDE basés sur LSP (Atom, Sublime Text, ...)

Contribuer

Si vous souhaitez contribuer à la base de code, veuillez lire les directives de contribution.

XL et chiots

Avec le XL, la situation devient un peu plus complexe. Le firmware de XLBuddy contient des firmwares pour les chiots (Dwarf et Modularbed) afin de les flasher si nécessaire. Nous prenons en charge plusieurs manières de gérer ces firmwares lors du développement :

1. Créez automatiquement le firmware Dwarf/Modularbed et flashez-le au démarrage par XLBuddy (par défaut)

   • Le firmware Dwarf & ModularBed sera construit à partir de ce référentiel.
   • Les chiots vont être flashés au démarrage par le XLBuddy. Les chiots doivent exécuter le Puppy Bootloader.

2. Construisez Dwarf/Modularbed à partir d'un répertoire source donné et flashez-le au démarrage par XLBuddy.

   • Spécifiez la variable de cache DWARF_SOURCE_DIR / MODULARBED_SOURCE_DIR CMake avec le dépôt local que vous souhaitez utiliser.
   • L'exemple ci-dessous créerait le micrologiciel de Modularbed à partir de /Projects/Prusa-Firmware-Buddy-ModularBed et l'inclurait dans le micrologiciel xlBuddy.

    cmake .. --preset xl_release_boot -DMODULARBED_SOURCE_DIR=/Projects/Prusa-Firmware-Buddy-ModularBed
   

   • Vous pouvez également spécifier le répertoire de build que vous souhaitez utiliser :

    cmake .. --preset xl_release_boot 
       -DMODULARBED_SOURCE_DIR=/Projects/Prusa-Firmware-Buddy-ModularBed  
       -DMODULARBED_BINARY_DIR=/Projects/Prusa-Firmware-Buddy-ModularBed/build
   

3. Utilisez le micrologiciel Dwarf/Modularbed pré-construit et flashez-le au démarrage par xlBuddy

   • Spécifiez l'emplacement du fichier .bin avec DWARF_BINARY_PATH / MODULARBED_BINARY_PATH .
   • Par exemple

    cmake .. --preset xl_release_boot -DDWARF_BINARY_PATH=/Downloads/dwarf-4.4.0-boot.bin
   

4. N'incluez aucun firmware pour chiot et ne flashez pas les chiots par XLBuddy.

    -DENABLE_PUPPY_BOOTLOAD=NO
   

   • Avec ENABLE_PUPPY_BOOTLOAD défini sur false, le projet désactivera le flashage et l'interaction de Puppy avec les chargeurs de démarrage Puppy.
   • A vous de flasher le bon firmware aux chiots (variante noboot).

5. Conservez les chargeurs de démarrage mais n'écrivez pas de firmware au démarrage.

    -DPUPPY_SKIP_FLASH_FW=YES
   

   • Avec PUPPY_SKIP_FLASH_FW défini sur true, le projet désactivera le clignotement de Puppy au démarrage.
   • Vous pouvez conserver les autres chiots qui ne sont pas débogués dans le même état qu'auparavant.
   • Utilisez la configuration de build de chiot avec des chargeurs de démarrage (par exemple xl-dwarf_debug_boot ) sur un ou plusieurs chiots.
   • Recommandez un point d'arrêt à la fin de puppy_task_body() pour empêcher votre ami de réinitialiser le chiot immédiatement lorsque le chiot s'arrête au point d'arrêt.

Voir /ProjectOptions.cmake pour plus d'informations sur ces variables de cache.

Exécution de tests

mkdir build-tests
cd build-tests
cmake ..
make tests
ctest .

Le moyen le plus simple de déboguer (pas à pas) un test est de spécifier CMAKE_BUILD_TYPE lors de la configuration cmake -DCMAKE_BUILD_TYPE=Debug .. , de le construire avec make tests comme indiqué précédemment, puis d'exécuter le test avec gdb par exemple gdb tests/unit/configuration_store/eeprom_unit_tests .

Firmware personnalisé clignotant

Pour installer un firmware personnalisé, vous devez casser l'annexe sur la carte. Découvrez comment procéder dans l'article suivant https://help.prusa3d.com/article/zoiw36imrs-flashing-custom-firmware.

Retour

• Demandes de fonctionnalités de la communauté

Crédits

• Marlin - Pilote principal d'impression 3D
• Klipper - code de shaper d'entrée basé sur Klipper

Licence

Le code source du micrologiciel est sous licence GNU General Public License v3.0 et les graphiques et la conception sont sous licence Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0). Les polices sont sous licence différente (voir LICENCE).