8 bits Dysfonctionnement ABL avec firmware TinyMachines

[Nunki0]

Bonjour à tous!

Je possède depuis un an environ une CR10s-Pro. Après un problème de hotend, je me suis décidé à monter un extrudeur H2, et tout va bien de ce côté. Mon capteur d'origine m'a également lâché peu après, donc je l'ai changé pour un bltouch et je suis passé sur un firmware TinyMachines, la version 10SProV2_UBL_DW7.4.7. Je me suis dit que maintenant que ma machine est en direct drive, peut-être que le firmware de v2 correspondrait mieux. Après, entre UBL et BIL, je ne savais pas trop, je n'avais jamais vraiment compris les spécificités de chacune de ces méthodes, mais le UBL m'avait l'air plus abouti donc je suis parti dessus.

Après quelques tests, voici le résultat: le bltouch fonctionne parfaitement, et j'ai enfin mon endstop z tant attendu (j'en avais vraiment marre des home z manuels...), mais quand je lance la prise des 25 points de mesure sur le plateau, les choses se corsent. Le premier point se fait normalement, mais lorsque la machine passe au suivant, elle ne redéploie pas le pin du bltouch, et la tête tape le plateau... Heureusement, d'une façon ou d'une autre le firmware le détecte très rapidement et la tête remonte et tout s'arrête... du moins la plupart du temps. Parce que quelques fois, après cela, la machine lance un g26 et là, c'est à nouveau le drame: les axes x et y vont en butée pour le home mais ils "rebondissent" sur les endstops sans valider leur position, et l'extrudeur se met à tourner de façon erratique, en faisant tout un bruit de cliquetis très désagréable.

Je me suis donc dit que c'était peut-être une histoire de configuration, que peut-être que le UBL n'était pas vraiment compatible, et que je pourrais essayer de revenir sur le mode BIL qui avait l'air plus simple. Le truc c'est qu'entre temps, j'ai bêtement cassé le port USB de la machine (n'entrons pas dans les détails, c'est un sujet douloureux...). J'ai essayé de le ressouder, mais je n'ai ni l'expérience ni le matos pour le faire, et de plus j'ai l'impression que quand le port s'est arraché, il est parti avec les pistes de cuivre... Enfin quoi qu'il en soit, il me semblait que c'était possible de flasher le firmware par carte sd. Je mets donc le firmware compilé sur la carte que j'utilise habituellement, je démarre l'imprimante et rien ne se passe. Après quelques recherche je tombe sur des histoires de bootloader, mais il me semblait que cette machine en avait un. Peut-être une histoire de format? (j'ai essayé avec les .hex fournis sur le github de tinymachines)

Enfin bref, je sèche sur ces deux problèmes, donc si quelqu'un a quelques idées, je suis preneur!

A bientôt...

PS: l'imprimante fonctionne parfaitement par ailleurs, et je peux toujours faire le levelling manuel donc ce n'est pas trop grave, mais je me disais que tant qu'a avoir un bltouch, ça aurait été sympa d'utiliser tout son potentiel!

[pommeverte]

Salut,

Tu as plusieurs solutions pour flasher le firmware:

• utiliser un module USBASP comme celui-ci pour transférer le firmware
• utiliser un module USBASP pour changer le bootloader (programme de chargement) qui te permettra de flasher le firmware via le lecteur de carte µSD
• souder un nouveau connecteur mini USB. Est-ce que tu peux fournir une photo pour voir l'ampleur de dégâts ? Par chance, il ne semble pas y avoir de via (trous métallisés) mais seulement des pistes "relativement faciles" à refaire

Pour tes soucis de nivellement, as-tu pensé à initialiser l'eeprom après le flashage?

[Nunki0]

Bonjour,

Merci pour ta réponse !

J'ai essayé de réinitialiser l'eeprom, c'est vrai que je n'y avais pas pensé. Malheureusement ça n'a rien changé... J'ai aussi fait un reset bltouch mais toujours rien. Je suis vraiment perplexe face à ça parce que le reste du temps tout fonctionne, donc je n'imagine qu'un problème logiciel. Mais c'est bizarre qu'un tel bug soit passé comme ça, donc ça doit être un peu plus compliqué que ça... Est-ce que le mode ubl versus bil peut avoir un impact?

Pour souder un nouveau part USB, c'est toujours le même problème. J'ai essayé... J'ai aussi tenté de refaire les connexions avec de petits fils de cuivre, mais ce n'était pas facile à mettre en place, et malgré les points de colle sur le nouveau port pour bien le sécuriser, il a sauté dès la première fois que j'ai essayé de la brancher ! J'essaierai de faire une photo demain. Et hop, c'est re (re-re...)parti pour retirer toutes les vis du dessous !

Par rapport au module USBASP, c'est donc la seule façon de se passer du port USB ?

Edit: je suis tombé sur cette vidéo en faisant des recherches, c'est assez intéressant. Si j'active le mode HS, ça devrait régler le problème non? Le truc c'est que ça ne résout pas la question quant à transférer le firmware...

Modifié (le) Mars 20, 2023 par Nunki0

[pommeverte]

Salut,

Il y a 13 heures, Nunki0 a dit :

Par rapport au module USBASP, c'est donc la seule façon de se passer du port USB ?

Disons que c'est le plus simple. Comme je l'ai écrit, avec le module, tu pourras

• soit flasher un nouveau firmware
• soit changer le bootloader pour, à l'avenir, flasher le firmware avec une carte µSD

Il y a 13 heures, Nunki0 a dit :

Si j'active le mode HS, ça devrait régler le problème non?

je ne pense pas car dans les commentaires Marlin, on peut lire:

Disable if your probe sometimes fails. Only suitable for stable well-adjusted systems.

Par contre, tu peux activer le mode SW. Toujours dans Marlin:

Feature: Switch into SW mode after a deploy. It makes the output pulse longer. Can be useful
  //          in special cases, like noisy or filtered input configurations.

ainsi que la tempo BLTOUCH_DELAY qui pourrait passer à 1000 ms

 

[Nunki0]

Voici la petite photo de l'état du port USB. C'est moche... 

[Nunki0]

Bonjour,

Le 20/03/2023 at 15:02, pommeverte a dit :

changer le bootloader (programme de chargement) qui te permettra de flasher le firmware via le lecteur de carte µSD

j'ai suivi les instructions et j'ai réussi à mettre à jour le bootloader avec ma carte arduino. Cependant, ça n'a pas changé grand chose. Je n'arrive toujours pas à flasher avec la micro SD... Le truc c'est que je n'ai aucune preuve que le bootloader que j'ai mis est bien le nouveau et non pas celui par défaut dans Arduino IDE, donc c'est dur de savoir d'où vient le problème exactement. En plus, maintenant l'imprimante ne reste bloquée sur l'écran de démarrage, impossible d'atteindre le menu habituel!

En ce qui concerne le téléversement direct du nouveau firmware par l'ISP, de ce que j'ai compris cela se fait en même temps que la compilation, via Arduino IDE par exemple. Mais par contre, je ne trouve aucune façon de mettre un fichier déjà compilé. Or je n'ai trouvé que les versions compilées du firmware tinymachines pour mon imprimante. Il y a beaucoup d'autres configs, mais aucune pour la machine qui m'intéresse... Même lorsque je cherche en dehors, je ne trouve que très peu de sources pour la CR10s-PRO, et la plupart sont assez anciennes, ce qui pourrait j'ai l'impression poser problème quant au branchement du bltouch. J'ai aussi la dernière version générique de marlin, mais je ne pense pas être capable de tout configurer...

Enfin bref, je me perd un peu dans tout ça!

[pommeverte]

Salut,

il y a une heure, Nunki0 a dit :

maintenant l'imprimante reste bloquée sur l'écran de démarrage, impossible d'atteindre le menu habituel!

Ca, je dirais que c'est plutôt une bonne nouvelle, ça veut dire que le programme de la carte-mère a changé .

Ensuite, il faut compiler un nouveau firmware (Tinymachine par exemple) avec la ligne du fichier configuration_adv.h décommentée:

  //#define SD_FIRMWARE_UPDATE

C'est ce que j'ai fait avec les dernières sources V7.4.7. J'ai été obligé de supprimer la fonction M500 et passer en AutoBedLeveling puisqu'il n'est plus possbile d'enregistrer des données dans l'eeprom. Ça veut dire que tu seras obligé de palper ton plateau systématiquement.

Voici le firmware que j'obtiens pour une CR10S Pro V2 standard. J'ai tout de même appliqué les options que j'ai indiquées dans ce message.

10SProV2_BIL_DW7.4.7.hex Configuration_adv.h Configuration.h

Sinon, si tu veux flasher un firmware normal avec ton arduino, je dois avoir la procédure quelque part

Modifié (le) Mars 23, 2023 par pommeverte

[Nunki0]

Salut,

Wow, merci pour tout ça, c'est super ! Je vais essayer au plus vite.

C'est drôle, je n'avais jamais vu ce #define là... Par contre, pourquoi est-ce que tu dis qu'on ne peut pas écrire dans l'eeprom? Tu crois que c'est possible d'enregistrer un mesh du plateau directement dans le firmware, et remettre à jour de temps en temps ?

En tout cas, je croise les doigts que ça règle le problème !

[pommeverte]

Salut,

Je vais être honnête, je n'avais jamais testé cette fonctionnalité (flashage de carte 8bits via le lecteur de carte SD/µSD).

Il y a 4 heures, Nunki0 a dit :

Par contre, pourquoi est-ce que tu dis qu'on ne peut pas écrire dans l'eeprom?

Lorsque j'ai compilé le firmware, j'ai eu un message d'erreur lié à l'adresse d'écriture dans l'eeprom : "SD_FIRMWARE_UPDATE_EEPROM_ADDR collides with EEPROM settings storage" . Pour ne plus l'avoir, j'ai désactivé la sauvegarde dans l'eeprom (M500) puisque la condition pour afficher cette erreur est d'avoir: SD_FIRMWARE_UPDATE et EEPROM_SETTINGS. Ceci ensuite m'a obligé à passer en ABL au lieu de l'UBL, puisque la sauvegarde de la matrice n'est plus possible.

Il y a 4 heures, Nunki0 a dit :

Tu crois que c'est possible d'enregistrer un mesh du plateau directement dans le firmware, et remettre à jour de temps en temps ?

La réponse est donc non pour l'enregistrement mais tu peux le faire "manuellement":

1. tu palpes le plateau et tu affiches la matrice
2. tu recopies la matrice dans le Gcode de démarrage avec des M421 I0 J0 Z...

Sinon, si tu ne t'amuses pas à changer le firmware toutes les semaines, tu flashes le firmware avec ton arduino en écrasant le bootloader, ce qui te permet de retrouver la fonction Sauvegarde dans l'eeprom.

Il y a une autre solution qui devrait fonctionner, c'est de souder un module bluetooth sur les entrées UART de la carte-mère. Tu pourrais alors flasher comme tu le veux la carte avec un dongle bluetooth. Là encore, je n'ai jamais essayé mais, en théorie, ça devrait fonctionner. Il faudrait peut-être déporter le module bluetooth à l'extérieur de la cartérisation, si elle fait cage de Faraday

 

Modifié (le) Mars 24, 2023 par pommeverte

[pommeverte]

Salut @Nunki0 ,

Il est sûrement trop tard, mais j'ai retrouvé ce tuto pour programmer ta carte en utilisant un arduino.
Attention, à la fin, la fonction "téléverser avec un programmateur" est désormais dans le menu croquis. C'est l'autre solution:

Le 20/03/2023 at 20:02, pommeverte a dit :

utiliser un module USBASP comme celui-ci (EDIT: ou un arduino) pour transférer le firmware

 

[Nunki0]

Bonjour!

Alors, après presque 1 semaine... Eh ben j'ai bien galéré, mais ça a l'air de fonctionner! Comme je le disais plus tôt, je n'ai jamais réussi à faire fonctionner le bootloader, donc j'ai laissé tomber ce côté. J'ai essayé de compiler le firmware avec arduino ide, mais rien a faire, ça ne veut pas. J'ai eu toutes sortes d'erreurs, des trucs vraiment incompréhensibles du style qu'il ne trouvait pas un fichier à tel chemin alors que quand je copie colle le chemin je tombe pile dessus, des trucs pas définis, enfin le gros bazar. En parallèle j'essaie de faire fonctionner autobuild marlin mais là encore, rien à faire, malgré tous les tutos. J'essaie aussi en passant directement par platform IO, il compile mais pas moyen de téléverser avec programmeur. J'ai épluché tout ce que je pouvais trouver, mais rien, je n'arrive pas! En plus pour ne rien arranger j'ai commencé à me mélanger dans les configs entre celles par défaut de Tinymachines, celles d'une autre version de Marlin, celles que tu m'as fourni @pommeverte, enfin bref.

J'étais en train d'abandonner, très frustré d'avoir une solution à portée de main sans pouvoir l'utiliser, mais j'ai essayé une dernière fois en téléchargeant à nouveau un dossier propre, et j'ai lancé Arduino IDE, et cette fois-ci pas d'erreur bizarre, juste une bibliothèque manquante (U8glib-HAL). Je télécharge la bibliothèque, ça plante à nouveau, mais cette fois je me rends compte que c'est simplement parce que je n'ai pas défini de machine . J'essaie à nouveau et cette fois, ô magie, tout fonctionne! Ca prend un temps infini à compiler et téléverser mais ça fonctionne! Je ne sais pas vraiment ce que j'ai fait différemment de la première fois, mais enfin. Là je me suis fait un petit repo git et je suis en train de paramétrer deux trois trucs. Le dernier test que j'ai fait n'a pas voulu téléverser: 
avrdude: verification error, first mismatch at byte 0x2fdc
         0xe6 != 0xee
avrdude: verification error; content mismatch
avrdude: verification error; content mismatch

Je ne sais pas trop pourquoi, mais je vais revenir à la dernière version stable et faire une modif à la fois. En tout cas j'espère que tout ça va régler mes problèmes de levelling, parce qu'un fait c'est de là que tout ça vient... L'IDE m'indique aussi qu'il ne me reste plus beaucoup de mémoire (le croquis prend 68% de l'espace programme et 76% de mémoire dynamique). Ca ne me paraît pas tant que ça, mais je vais essayer de retirer des trucs, à commencer par toutes les fonctionnalités en lien avec la communication USB.

Par rapport au module bluetooth, faut voir si ça peut permettre de téléverser plus vite. Sinon, je ne vois pas trop d'intérêt. J'essaierai un jour. Pour l'instant, j'ai décommenté la ligne pour la mise à jour par carte sd. Je préfère garder l'eeprom, d'autant plus que j'ai l'impression que désactiver cette commande empêche aussi de réinitialiser la mémoire, ce qui est un peu pénible. En plus, ils précisent que ça ne fonctionne qu'avec un bootloader compatible (dont celui que j'ai essayé), une fois que le firmware est installé. Mais j'ai lu que lorsque l'on utilise un programmeur, ça efface vraiment toute la mémoire, dont le bootloader, donc dans ce cas je ne vois pas trop comment avoir en même temps sur la carte un bootloader et le firmware avec cette option activée.

 

Enfin voilà où j'en suis, je pense que le plus dur est fait... En tout cas merci @pommeverte pour tes réponses, c'est sympa!

Nunki
 

[pommeverte]

Salut,

Honnêtement, je ne comprends pas pourquoi tu utilises arduino IDE alors qu'il est clairement préférable de compiler avec Visual studio code, comme le préconise les développeurs de Marlin 2.x (voir ce tuto)

Il y a 12 heures, Nunki0 a dit :

L'IDE m'indique aussi qu'il ne me reste plus beaucoup de mémoire (le croquis prend 68% de l'espace programme et 76% de mémoire dynamique). Ca ne me paraît pas tant que ça, mais je vais essayer de retirer des trucs, à commencer par toutes les fonctionnalités en lien avec la communication USB.

Ne t'embête pas avec ça. Tant que tu ne dépasses pas ~97% des 2 mémoires, tu peux continuer, pas de soucis.

Il y a 12 heures, Nunki0 a dit :

Par rapport au module bluetooth, faut voir si ça peut permettre de téléverser plus vite. Sinon, je ne vois pas trop d'intérêt

L'avantage du module bluetooth, c'est que tu n'auras plus besoin de te brancher sur le port ICSP. Tu reviendras à une solution "souple" comme avec l'USB, le câble en moins et avec la même vitesse de communication de 115.2 kbauds. Tu installes le bootloader pour Atmega2560 via l'ICSP (voir le tuto de mon précédent message) et ensuite, tu pourras communiquer, flasher le firmware,... comme avec n'importe qu'elle liaison série (USB,...).

 

[Nunki0]

il y a une heure, pommeverte a dit :

Honnêtement, je ne comprends pas pourquoi tu utilises arduino IDE alors qu'il est clairement préférable de compiler avec Visual studio code, comme le préconise les développeurs de Marlin

En fait je n'ai juste pas réussi. J'ai passé beaucoup de temps là dessus et je n'ai jamais réussi à le faire tourner comme je voulais. Au début, tout compilait proprement mais je ne pouvais pas téléverser avec l'ISP. J'ai cherché comment régler ce problème, mais je n'ai pas vraiment réussi. Il paraît qu'il fallait modifier le platformio.ini, mais ça ne réglait pas le problème. En plus, dans les derniers tests que j'ai fait, ça ne compilait plus. J'avais une erreur qui disait qu'il n'arrivait pas à résoudre les #include du début... C'est pour cela que j'ai laissé tomber. Je vais essayer un jour de m'y replonger, c'est vrai que ça a l'air plus pratique, mais je dois dire que là j'en ai un peu assez de ce truc ! Mais c'est clair que c'est vraiment à cause de l'absence de port USB, sinon tout se serait fait en 2sec avec vscode.

Il y a 1 heure, pommeverte a dit :

L'avantage du module bluetooth, c'est que tu n'auras plus besoin de te brancher sur le port ICSP. Tu reviendras à une solution "souple" comme avec l'USB

Je vais regarder de ce côté, effectivement c'est intéressant. Je suppose qui doit y avoir un paramétrage de platformio à faire, j'espère que ça fonctionnera cette fois !

[pommeverte]

Il y a 5 heures, Nunki0 a dit :

Il y a 7 heures, pommeverte a dit :

L'avantage du module bluetooth, c'est que tu n'auras plus besoin de te brancher sur le port ICSP. Tu reviendras à une solution "souple" comme avec l'USB

Je vais regarder de ce côté, effectivement c'est intéressant.

Histoire d'être sûr que je ne t'ai pas vendu du rêve , j'ai fait un test avec:

• un module HC-05: je te conseille d'utiliser un HC-06 qui n'aura pas besoin d'être paramétré puisqu'il ne fonctionne qu'en esclave
• un module USB bluetooth: CSR 4.0 (dispo ici ou là )

Le câblage est celui-ci:

Citation

J'ai ajouté un pont diviseur de tension pour que le signal d'entrée sur RX du module soit de 3.3V (ici, avec une résistance de 1.8 kohms et de 3.3 kohms)

un petit détail coté carte-mère:

Citation

La communication s'est établie sans problème (envoi de commandes et réception de réponses OK).

Je ne suis pas allé jusqu'à programmer la carte avec VS code mais il ne devrait pas y avoir de soucis.

Il y a 5 heures, Nunki0 a dit :

Je suppose qui doit y avoir un paramétrage de platformio à faire

Il est possible que tu sois obligé de spécifier le port du module Bluetooth dans l'environnement choisi :

upload_port = COMx    # x étant le n° du module USB Bluetooth
(info trouvée ici)

 

Modifié (le) Mars 30, 2023 par pommeverte

[Nunki0]

ok, merci beaucoup pour les infos!

Il y a 3 heures, pommeverte a dit :

Il est possible que tu sois obligé de spécifier le port du module Bluetooth dans l'environnement choisi :

upload_port = COMx    # x étant le n° du module USB Bluetooth

Ca va, je craignais pire... Dans ce cas je devrais m'en sortir! 

Je vais m'en commander un, et je te dirai si ça fonctionne. Par contre, le temps que ça arrive ici...

[pommeverte]

Salut,

Dans ce cas, ne perds pas de temps , tu peux appliquer la solution 1: flasher avec le port ICSP:

1. tu flashes le bootloader standard des Atmega2560 sur la carte mère (voir le tuto précédent)
2. tu compiles ton firmware avec VSCode
3. tu récupères le firmware (.hex) dans le dossier .pio\build\mega2560
4. tu décompresses ce fichier avrdude.zip dans un dossier C:\CR10Spro , par exemple
5. tu ouvres une console windows (touche "windows" + x -> terminal windows)
6. tu tapes ou tu colles cette ligne que tu valides avec la touche Entrée:

C:\CR10Spro\avrdude -Cavrdude.conf -v -patmega2560 -carduinoisp -Uflash:w:mon_firmware.hex:i
où mon_firmware.hex est le firmware généré par VSCode et que tu auras copié dans le dossier C:\CR10Spro

[Nunki0]

Salut,

Merci encore pour tes conseils, je vais essayer tout ça. J'espère que ça va permettre de tester des trucs plus facilement. Là, mon souci c'est que le firmware ne reconnait carrément plus le bltouch, alors que j'ai bien spécifié ce qu'il faut dans la config. II s'allume, se déploie, mais le machine ne s'arrête pas lorsqu'il touche quelque chose. J'ai aussi vérifié les connexions, et tout est clean. L'avantage c'est qu'avec ta méthode je pourrai revenir à la version "officielle" de TM ou autres, au cas où j'ai loupé un truc quelque part. 

Bref, je vais essayer de démêler tout ça...

Modifié (le) Avril 1, 2023 par Nunki0

[pommeverte]

Salut,

J'ai poursuivi les tests, ou plutôt la réparation de la carte-mère puisque j'ai arraché la métallisation  d'une des 2 résistances sur laquelle j'ai soudé un fil relié eu module USB.

J'ai donc constaté que:

1. comme tu l'as dit, le flashage du bootloader est inutile si tu flashes un nouveau firmware via l'ICSP, à moins d'utiliser la version avec bootloader, je pense (...with_bootloader.hex)
2. je n'ai pas réussi à flasher la carte mère en utilisant le module bluetooth (HC05) , contrairement à ce que j'espérais. Il ne pourra donc servir qu'à échanger des informations
3. le flashage du bootloader n'a été possible qu'en utilisant une ancienne version d'arduino IDE (1.6.0). Je n'ai pas réussi avec la dernière version V1.x (V1.8.19)

[fran6p]

il y a 41 minutes, pommeverte a dit :

à moins d'utiliser la version avec bootloader, je pense (...with_bootloader.hex)

C'est une question que je m'étais posée pour laquelle je n'ai jamais eu de certitude car il me semble (ça fait longtemps) que la version .hex avec le nom «with_bootloader» était plus petite en taille ce qui ne me paraissait pas «logique» (firmware+bootloader normalement > firmware seul, non ?).

[pommeverte]

Salut,

Il y a 6 heures, fran6p a dit :

il me semble (ça fait longtemps) que la version .hex avec le nom «with_bootloader» était plus petite en taille

C'est bizarre, avec grbl, c'est assez cohérent. Je constate que:

• le firmware sans bootloader fait 87Ko
• le firmware avec bootloader fait 105Ko

sachant que le bootloader fait 21Ko

[fran6p]

Je viens de tester avec un vieil Arduino (1.8.7) portable et pour un Marlin compilé c'est l'inverse chez moi :

Bizarre

[pommeverte]

Salut,

J'ai compilé un Marlin V1.1.9 avec arduino IDE V1.8.3. Effectivement, la version sans bootloader pèse 306 Ko (313 885 octets) contre 305 Ko ( 312 488 octets) pour la version avec bootloader.

En ouvrant les firmwares dans notepad++, on s'aperçoit que le début du firmware avec bootloader contient la totalité du firmware sans bootloader. Le bootloader se situant à la fin du fichier.

En utilisant l'extension Hex Editor, on constate qu'à chaque fin de ligne du firmware sans bootloader, il y a les caractères CR + LF alors que seul le LF est présent sur le firmware avec bootloader. Cette différence explique "l'écart négatif" de taille des fichiers (le nombre de CR est supérieur à la taille du bootloader).

Dans mon test avec le firmware GRBL, le nombre de CR est inférieur à la taille du bootloader, d'où "l'écart positif".

 

Modifié (le) Avril 5, 2023 par pommeverte

[fran6p]

Bizarre tout de même la manière de procéder d'Arduino, un coup le fin de ligne est codé (CR+LF) l'autre coup (LF)

Donc avec Arduino sur les deux fichiers .hex, celui portant le nom «with_bootloader» contient le chargeur de démarrage en plus du firmware.

Je n'ai pas testé avec VSC s'il a le même comportement lors du build du firmware pour des microcontrôleurs ATMega1284/2560.

[Nunki0]

Bonjour!

Ca fait un moment que je n'ai pas eu le temps de regarder tout ça! 

Le 31/03/2023 at 06:52, pommeverte a dit :

C:\CR10Spro\avrdude -Cavrdude.conf -v -patmega2560 -carduinoisp -Uflash:w:mon_firmware.hex:i
où mon_firmware.hex est le firmware généré par VSCode et que tu auras copié dans le dossier C:\CR10Spro

J'ai essayé, et avrdude ne fonctionnait pas lorsque je l'appelais comme ça. Message d'erreur très succinct, aucune info. Je l'ai réinstallé depuis le github officiel, j'ai ajouté les fichiers demandés et maintenant ça tourne mais ça ne trouve pas le programmeur:

        Using Port                    : usb
         Using Programmer              : arduinoisp
avrdude usbtiny_open() error: cannot find USBtiny device (0x2341/0x49)
avrdude main() error: unable to open programmer arduinoisp on port usb

avrdude done.  Thank you.

J'ai essayé les deux ports USB de l'ordi, j'ai aussi tenté de modifier le "default_serial" mais ça ne change rien, pas même le message d'erreur.

 

Quoi qu'il en soit, ce n'est pas le plus grave, tant que ça fonctionne avec Arduino IDE. Le vrai truc que je ne comprends pas c'est pourquoi la machine ne s'arrête pas lorsque la sonde touche quelque chose...

[pommeverte]

Salut,

Désolé, j'ai un peu perdu le fil . Tu utilises quel firmware?

Est-ce que tu penses recevoir le module bluetooth dans les prochains jours? il sera utilise pour faire des tests.

Au niveau du flashage du firmware:

• avec quel arduino fais-tu les tests?
• est-ce que tu peux décrire le câblage?

Ce serait intéressant de pouvoir flasher le firmware sans passer par arduino IDE.

Modifié (le) Avril 13, 2023 par pommeverte