[TUTO] Ma manière de travailler avec de multiples versions du firmware Marlin

[fran6p]

En préliminaire, ce document n'est que la description de ma méthode de travail pour préparer un firmware basé sur Marlin. D'autres méthodes existent, l'important est de trouver celle qui vous sied le plus.

Ce tutoriel ne s'adresse pas dans un premier temps à de purs débutants. Toutefois, en acceptant de s'y mettre et en faisant vos propres essais / erreurs (principe de tout apprentissage) la réussite peut être en vue (la courbe d'apprentissage n'est pas extrêmement pentue mais la route qui y mène n'est pas aussi droite comme l'avait judicieusement remarqué J.-P. Raffarin en son temps).

AU COMMENCEMENT

Quand j’ai commencé à préparer mes propres firmwares pour mes imprimantes, je reproduisais la méthode décrite dans bon nombre de tutoriels (écrits ou vidéos) : je récupérais le fichier compressé de la version de Marlin sur laquelle je me basais pour faire mes modifications (platformio.ini, configuration.h et configuration_adv.h.

Si parmi les exemples de modèles fournis par l’équipe du Marlin existait l’imprimante à préparer, la tâche était facilitée :

1. copier les configuration.h et configuration_adv.h (et éventuellement s’ils étaient également fournis, _Statusscreen.h et _Bootscreen.h) puis les coller dans le dossier Marlin en remplacement de ceux par défaut.
2. ensuite l’étape de compilation
   - correction des erreurs,
   - retour à l’étape 2 (compilation)
3. finalement la compilation étant réussie alors dernière étape, flasher le firmware.

Si une nouvelle version stable de Marlin était disponible, il fallait répéter les étapes précédentes depuis la récupération du Marlin compressé jusqu’au flashage.

La gestion des différences entre les fichiers de configurations pouvait être facilitée par l’utilisation de Winmerge (ou Notepad++ et l’ajout d’un greffon ou encore avec Visual Studio Code).

S’il fallait préparer des versions différentes de firmware (modèle d’imprimante différent, variation de carte mère, présence d’un ABL, type d’ABL, détection de fin de filament, …) alors il était nécessaire d’organiser les dossiers, de les nommer correctement sinon le troisième élément de la trilogie : hardware, software … foutoir ne tardait pas à surgir (loi de Murphy oblige).

En gros c’était pour le moins fastidieux et nécessitait une bonne organisation De plus ça finissait par occuper de la place sur l’unité de stockage.

En résumé :

Un outil de gestion de versions : GIT

C’est là que j’ai découvert qu’on pouvait «bénéficier» d’outils de gestion de versions : Git (son créateur n’est autre que Linus Torvald également connu pour avoir au milieu des années 1990 développé le système Linux).

Pour aller plus loin dans l’utilisation de GIT :

• https://www.mcorbin.fr/posts/2020-06-26-git-introduction/

• https://rogerdudler.github.io/git-guide/index.fr.html

• un cours assez complet

• la cheat sheet (PDF)

Git est pratique pour travailler localement mais pour pouvoir diffuser, modifier et faire bénéficier d’autres utilisateurs de ce travail, un système distant comme github augmente les possibilités.

Utiliser github.com (ou gitlab si Microsoft vous hérisse le poil) nécessite la création d’un compte uniquement si vous voulez créer vos propres dépôts.

Créer son compte Github (gratuit) en cliquant sur «Create a free orgaization» :

Un formulaire s’affiche qu’il suffit de compléter :

Ne pas oublier la phase de vérification de l’email saisi lors de la création du compte.

Quelques termes à connaître, le glossaire github (en anglais)

Une fois le compte créé et validé, on peut créer ses propres dépôts directement en ligne ou en local sur son ordinateur (ligne de commandes).

Cependant un logiciel très pratique permet de faciliter les différentes tâches : Github Desktop (GD) interface en anglais uniquement et pas de version pour les linuxiens .

Télécharger puis installer GD via le lien précédent. Ce logiciel utilisera vos identifiants (pseudo / mot de passe) pour se souvenir de qui vous êtes, ils vous seront demandés à la fin de l’installation.

Pour une documentation malheureusement uniquement en anglais, consulter ce lien.

Ma méthode de travail avec Marlin

En ligne, sur le dépôt github de Marlin, en étant connecté avec votre compte, on va réaliser un «fork» du projet originel (Marlin) (=copie préservant les liens vers le dépôt originel): aller sur https://github.com/MarlinFirmware/Marlin

Cliquer sur le bouton FORK :

Vous venez de créer une copie identique du dépôt Marlin dans votre compte github précédemment créé

Votre dépôt distant contient une copie exacte y compris toutes les branches (variantes) du Marlin originel. Désormais, le dépôt Marlin originel sera dénommé «UPSTREAM», la version de votre dépôt, elle, sera appelée «ORIGIN».

Le fork pour le moment n’est présent que dans notre dépôt Github. Pour réaliser les modifications des fichiers de configuration de Marlin, je trouve plus pratique de travailler en local sur son propre ordinateur. On va donc récupérer le contenu de notre dépôt distant.

J’ai pris depuis longtemps l’habitude d’organiser et regrouper mes dossiers / répertoires sur mes disques durs (ça facilite les sauvegardes ) => création d’un nouveau répertoire sur une unité de stockage pour accueillir nos futurs «développements» ( C:\GITHUB par exemple )

Première option :

Via le site github.com de notre dépôt (notre compte), clic sur le bouton «Code» puis => Open with Github Desktop

Seconde option :

Via GD, menu principal, «Clone repository…»

Saisir l’URL du dépôt à cloner (notre «ORIGIN») dans l’onglet URL, modifier éventuellement le chemin d’accès (Local path) pour correspondre au lieu de stockage prévu puis clic «Clone»

Une barre de progression signale le transfert en cours. A la fin du processus de copie en local, on nous demande comment on souhaite contribuer au développement du dépôt cloné (contribuer au projet parent ou pour son propre usage). Si par exemple on pense proposer des corrections / modifications au projet originel (pull request), il est préférable d’indiquer que l’on contribuera au projet parent.

Que ce soit avec la première option ou la seconde, toutes les branches du dépôt cloné sont maintenant accessibles sur notre matériel local (origin/x,x,x).

Désormais, Github Desktop nous permet d’accéder à notre dépôt distant (View on Github [1]) ou à notre emplacement local (Show in Explorer [2]) et également d’utiliser notre éditeur de code (VSC) en cliquant (Open in visual Studio Code [3]) ; il est évidemment possible d’indiquer un autre éditeur que VSC via les préférences du logiciel ou en cliquant «options» (4).

Création d’une nouvelle branche locale

Je souhaite créer un firmware basé sur la version stable de Marlin pour une nouvelle imprimante :

• Choix de la branche (version) qui servira de base (Current branch)

• nommer cette branche puis clic sur «Create branch»

La branche est désormais créée sur notre disque localement :

On peut maintenant via notre éditeur (VSC) faire toutes les modifications manuellement dans les fichiers configuration.h et configuration_adv.h ou quand le modèle d’imprimante dispose de fichiers exemples fournis par l’équipe de Marlin, recopier les fichiers nécessaires en remplacement de ceux du clonage.

Les modifications seront automatiquement détectées dans GD

• détection changements dans GD

• le contenu des modifications est précisé (history), rouge / vert avant / après modifications :

Pour le moment, toutes ces modifications n’existent qu’au niveau local, il reste à synchroniser avec github. => Publish branch

L’intérêt de la publication de cette branche sur github est :

• rendre accessible notre dépôt à d’autres utilisateurs en leur donnant le lien vers celui-ci et vers une branche particulière
• en cas de problème matériel en local (expérience vécue lors de la perte d’un disque dur), il suffira de cloner localement notre dépôt distant pour récupérer nos développements

Maintenir à jour la version de Marlin

Marlin est régulièrement mis à jour (bugfixes (plusieurs fois par jour) et stable (moins souvent)). On peut tenir notre dépôt local également à jour en suivant les modifications du dépôt originel (UPSTREAM) et en les répercutant dans nos branches.

Réalisations par étapes : Upstream => local

1) Dans GD, choix de la branche à mettre à jour soit :

- via le menu, onglet «Branch» => Merge into current branch

- ou depuis la branche sélectionnée, Choose a branch to merge into branche-sélectionnée

- indiquer la version «Upstream» qui servira à fusionner :

Dans l’exemple ci-dessus, la version de Marlin étant la version stable, il n’y pas eu de changements (message : this branch is up to date with upstream/2.0.x)

Exemple avec la version «bugfixes» dont les mises à jour sont quotidiennes voire plusieurs fois par jour :

Le nombre de modifications est précisé, il suffit de cliquer le bouton «Create a merge commit» pour fusionner ces changements dans notre branche locale (Origin). La majorité du temps il n’y a pas de conflits.

CAS lors de «conflits»

De temps en temps, la fusion (merge) ne peut se faire automatiquement seule. Github Desktop nous indique alors le nombre de fichiers pour lesquels existent un/des conflit(s) :

En cliquant sur le bouton «Merge upstream/… into Branch», une nouvelle fenêtre nous précise quels fichiers sont concernés :

En cliquant sur le bouton permettant d’accéder à l’éditeur «Open in Visual Studio Code», le (les) conflits seront signalés, un choix devra lors être réalisé par l'utilisateur :

On pourra soit :

• ne pas mettre à jour notre branche avec les modifications de la nouvelle version (Accept Current Change)

• mettre à jour notre branche (Accept Incoming Change)

• avoir les deux dans notre fichier pour pouvoir les comparer (Accept Both Changes). Il faudra ensuite faire les modifications manuellement en évitant de réaliser des doublons évidemment.

Une fois le (les) conflit(s) résolu(s), ne pas oublier d’enregistrer le fichier modifié dans VSC (clic sur l’icone «disquette»)

 

GD détectera notre choix et continuera la fusion (merge). Nos versions de Marlin seront alors à jour. Ne restera plus qu’à compiler notre nouveau firmware «up to date» puis à le flasher sur la carte de l’imprimante. Sans oublier, évidemment de le tester  

Voilà, on arrive au terme de ce long document qui relate ma manière de travailler quand je propose des firmwares aux utilisateurs de  ce forum. D’autres méthodes, procédures existent ; à vous de trouver celles avec lesquelles vous avez le plus d’affinités.

L'idée de ce document provient d'une vidéo du Youtubeur australien TeachingTech. N'étant pas un adepte des vidéos pour un apprentissage, j'ai donc créé cette alternative au format écrit.

PS: si vous avez des questions concernant ce tutoriel, n'hésitez pas à les formuler en gardant à l'esprit :

1. ce n'est que ma méthode de travail
2. je n'ai pas réponse à tout
3. ma patience a parfois des limites donc évitez de polluer ce sujet par des HS ou des questions «maltapropo»

Modifié (le) Décembre 30, 2021 par fran6p

[mch]

Git et github sont devenus des outils incontournables du développement. Et en effet leur utilisation est le meilleur moyen de garder les différentes versions de fichiers.

Par contre, pourquoi ne pas avoir seulement les fichiers de configuration dans ton git. Cela prend moins de place et sur ton PC et sur les serveurs. C'est un peu l'idée de MarlinFirmware quand ils ont dissocié le dépôt des sources et celui des configurations.

[fran6p]

il y a une heure, mch a dit :

Cela prend moins de place et sur ton PC

Le «versioning» permet de ne pas prendre tant de place que ça (et j'ai des disques durs à foison (y compris de très vieux de quelques dizaines de Méga)).

il y a une heure, mch a dit :

et sur les serveurs

Pour une fois que le «cloud» est pratique et ne coûte pas grand chose, pourquoi s'en priver ? Inutile de me dire que ça contribue au dérèglement climatique. Aucun de mes prénoms n'est Greta.

[mch]

il y a 10 minutes, fran6p a dit :

Aucun de mes prénoms n'est Greta.

Moi non plus, mais pour mon fils, je fais un effort... fini. je m’arrête sur le sujet.

[Kachidoki]

De toute façon, c'est joli de versionner, mais il faut que toute la chaine suive.

Dernièrement j'ai voulu recompiler un Marlin qui n'avait pas bougé d'un iota depuis un an sur mon PC. Ben la compilation a échouée, parce que beaucoup de libs pointent sur.... master au lieu d'une version tagguée.

Résultat, mon Marlin 2.0.5.3 compilé il y a un an, n'est plus re-compilable tel quel aujourd'hui car les libs sont devenue incompatibles. Bon j'en ai profité pour passer au 2.1.2, mais c'est pénible car j'ai du me taper le merge des configs, qui ont beaucoup évolués en un an, alors que je voulais seulement changer un paramètre sur une config qui fonctionnait bien...

 

(Et puis dans le cloud, j'espère bien qu'il font de la déduplication  )

[fran6p]

Il y a 15 heures, Kachidoki a dit :

j'espère bien qu'il font de la déduplication

Dans les Datacenter d'OVH pour «plus de sécurité»

Ce n'est que mon avis: Marlin est devenu une usine à gaz or en ces temps de pénuries il faut apprendre à s'en passer car «quand le Gaspard, c'est la morsure» (je sais c'est nul comme jeu de mots mais je suis trèèèèèèèèèèèèèèèèèèèès fatigué).

[Kachidoki]

il y a 28 minutes, fran6p a dit :

Dans les Datacenter d'OVH pour «plus de sécurité»

  La déduplication n'empêche pas la redondance, c'est paradoxal je sais, mais c'est bien ça. Redondance de "disques" ou plutôt de nœuds, mais déduplication des données. C'est juste pas la même couche. D'ailleurs sur les hyperviseurs ça se fait aussi pour la RAM qui est beaucoup plus coûteuse.

 

Pour Marlin je suis d'accord que c'est une usine à gaz. Seulement ça ne l'est pas devenu, ça l'a toujours été.

A une époque tout était à plat dans un dossier, puis ça s'est organisé, mais dans le même temps la complexité a augmenté, etc... La structuration est assez mal faite. Par exemple le concept de fichier header global de config devient pénalisant, la moindre virgule modifiée oblige la recompilation de l'intégralité du code source. (Ca, ça consomme plus de temps et de ressources que de l'espace de stockage froid.) Il pourrait y avoir une segmentation en libs et ainsi avoir une compilation incrémentale. Mais c'est hyper complexe de maintenir du code qui est touché par des dizaines de barbus pas toujours expérimentés ou habitués à l'environnement. Et les néophytes ne s'en sortiraient plus s'il y avait toute une ribambelle de fichiers de configs séparés.

Il y a aussi l'intrusivité de tas de bouts de fonctions particulières ou de niches. Par exemple il y a du code pour le Touch-Mi dont je pense que le gars au fond du Texas ne sait même pas ce que c'est (malheureusement pour lui). Si demain j'inventais un super capteur de diamètre de filament pour utiliser du filament que j'aurai extrudé à partir de bouteilles, je pourrais écrire du code et l'intégrer dans Marlin, même si seule une poignée de makers l'utiliserait (ou pas). Je n'aurais probablement fait que gonfler la masse de code et rendu plus illisible des parties sensibles comme l'extrusion, l'avance linéaire ou que sais-je?

Bref, l'open source c'est génial, mais c'est vite le bazar. 

[fran6p]

il y a 53 minutes, Kachidoki a dit :

c'est vite le bazar. 

Ça me rappelle ESR et son essai la cathédrale et le bazar

Concernant les «bouts» de code ajoutés, encore faut-il passer sous les fourches caudines de certains développeurs ( @thinkyheadet autres) pas toujours «accueillants».