Modification bootloader

Salut à tous !

J’ai réussi à esquiver jusqu’à maintenant mais voudrais modifier le bootloader d’un atmega328 (virer la LED 13 qui clignote au reset notamment) mais je trouve pas grand chose de concret sur google … Si quelqu’un a un lien ou quelque chose sur windows je le remercie d’avance :slight_smile:

Salut,

B@tto:
J'ai réussi à esquiver jusqu'à maintenant mais voudrais modifier le bootloader d'un atmega328 (virer la LED 13 qui clignote au reset notamment) mais je trouve pas grand chose de concret sur google ... Si quelqu'un a un lien ou quelque chose sur windows je le remercie d'avance :slight_smile:

La toolchain : winAVR (prendre la derniére version)
http://sourceforge.net/projects/winavr/files/WinAVR/

Le bootloader : optiboot (utilise un client mercurial pour récupérer les sources à jour : http://mercurial.selenic.com/downloads/)
http://code.google.com/p/optiboot/source/browse

La modif pour la led : ton cerveau et de solide connaissance en avr-c :wink:
--> Fait gaffe à la taille final du programme tu est limité par la zone réservé pour le bootloader
--> ne touche pas aux déclarations et aux attributs .init9, naked, etc ... sinon ton bootloader sera corrompu.
--> plus généralement fait gaffe à tous ce que tu modifie, copie les lignes avant modifications et met les en commentaires pour garder une trace

La programmation : programmateur d'AVR ICSP + fichier makefile + éditeur intelligent (genre notepad++)
--> Fait ton choix pour le programmateur il en existe des 100aine
--> n'oublie pas de modifier le makefile suivant ta configuration (programmateur, carte cible, fonctionnalités STK500, etc ...)
Moi j'utilise un AVR pocket de sparkfun : http://skyduino.wordpress.com/2011/08/23/test-pocket-avr-programmer/

Outch je voyais ça un peu plus simple ^^'

Jvois ça la semaine prochaine et jdonne mon retour :wink:

Je vois pas bien la nécessité de modifier le bootloader.

La led en PIN 13 ne perturbe en rien le fonctionnement ni en entrée ni en sortie. Tu peux l'éteindre dans le setup de tes applications.

Le clignotement de cette Led est très utile car elle indique que le reset a eu lieu correctement par la séquence suivante :

  • clignotement
  • extinction
  • allumage

Si tu supprimes cela tu ne sais jamais si le reset a eu lieu. C'est pourtant utile dans un sens ou dans l'autre (avec l'Arduino en ISP cela permet de voir qu'on a oublié la capa de 10 uF ou qu'elle n'est pas bien connectée).

JLB

A propos de la del pin 13 avez vous remarqué que depuis la révision 3 (Uno et Mega) elle n'est plus câblée directement sur la pin 13.
Elle est maintenant commandée par l'ampli opérationnel qui était disponible mais non utilisé, l'ampli est câblé en suiveur de tension.

Ce qui fait que maintenant la pin 13 n'est plus chargée à basse impédance : Del + 300ohms.
Par là même la del ne tire plus son courant au travers de la pin 13 mais directement sur l'alimentation 5V.
Cela rend l'usage de la résistance de tirage au +5V (pull-up) sur la sortie 13.

jihelbi:
Je vois pas bien la nécessité de modifier le bootloader.

La led en PIN 13 ne perturbe en rien le fonctionnement ni en entrée ni en sortie. Tu peux l'éteindre dans le setup de tes applications.

Sauf si tu t'en sers ... :0

Et le reset dans bien des applications t'en a rien à faire, d'ailleurs à y penser je ne m'en sers jamais !

Ca relève du TOC ton besoin d'éteindre cette LED...

Tu n'as qu'à mettre un ATmega sur une breadboard et le programmer avec ArduinoISP et tu feras ce que tu veux.

Ensuite le reset tu n'en as pas besoin jusqu'au jour où... Et pourquoi tous les processeurs en ont-il un ??? Tu raisonnes comme un débutant en deni de l'expertise des concepteurs des cartes Arduino.

La carte Arduino est un système de développement. Ensuite tu fais ta board avec le chip que tu veux (moi j'aime bien les ATtiny à 8 pattes). Tout est prévu pour cela dans l'environnement et tu peux rajouter des types à volonté dans le répertoire Arduino\hardware de "Mes documents". Il faut juste régler dans les fichiers boards.txt la variante de MCU, sa fréquence, sa taille de flash et les fuse bits qui vont bien selon ce que tu veux faire (datasheets ATMEL indispensables).

C'est l'intelligence du concept Arduino qui fait que nous sommes ici à discuter sur ce forum alors pourquoi le remettre en cause. La Rev 3 de la carte UNO résoud efficacement le problème de la Led 13.

Sinon il y a une autre solution : Pose sur la led un petit bout de scotch noir...

JLB

Bonjour,

Je suis désolé de ne pas suivre l’avis général, mais je vais encourager B@tto à la bidouille !
Peu importe ce qu’il veut faire, même si c’est pour juste éteindre le clignotement d’une led. Regarder/modifier votre bootloader, c’est aussi savoir ce qu’il y a dans vos machines, et essayer de l’apprivoiser.
donc, B@tto, je te recommande de :

  1. Avoir deux Arduino (un qui te permettra de flasher/reflasher le deuxième, et qu’il ne faudra pas toucher)
  2. faire une copie de save du répertoire ./hardware/arduino/bootloaders
  3. savoir/apprendre comment compiler un programme en C avec make/avr-gcc (tutos pour arduino disponibles partout)
  4. dans le dossier optiboot, éditer optiboot.c
  5. remarquer dans le header “LED_START_FLASHES”, la fonction flash_led et leurs rapports.
  6. regarder dans le makefile si tu ne trouves rien d’interessant qui soit relié à ça.
  7. faire les modifications idoines
    8 ) faire un make clean
  8. recompiler en fonction de la cible voulue "make <cible_voulue>
  9. charger le nouveau bootloader.

et si ça n’a pas marché :
11) remplacer le répertoire par le répertoire de save, flasher un bootloader correct, s’assurer que tout marche, et recommencer au 1)

Bonne journée :slight_smile:


Stéphane.

Sauf qu’une réponse a déja été faite dans ce sens et que B@tto a répondu "Outch je voyais ça un peu plus simple ^^’ "…

Bien évidemment dans une communauté open source les améliorations sont bienvenues mais je pense que cela concerne des développeurs confirmés qui apporteront quelque chose à la communauté et pourront proposer réellement une version différente et fiable de bootloader (même si je n’y vois aujourd’hui aucune nécessité).

Je pense qu’il lui serait plus profitable d’apprendre à faire ses boards avec des chips ATMEL divers et variés et profiter du fait que l’environnement Arduino lui permet de faire cela sans rien apprendre de l’environnement AVR et de continuer à programmer comme sur une carte Arduino avec la même simplicité sur un tiny ou un mega48V (que l’on trouve à pas cher).

Je persiste à considérer que l’intérêt d’Arduino est d’être un système de développement et que dans ce contexte l’extinction de la Led 13 est vraiment secondaire.

JLB

Je comprends tout à fait le principe du "ça marche, je touche pas, c'est trop compliqué de toute manière".
Sauf que là le but n'est pas de faire une meilleure version, juste de s'amuser à éteindre une led. Ce n'est pas une nécessité, c'est de la bricole fun :slight_smile:

Sauf qu'une réponse a déja été faite dans ce sens et que B@tto a répondu "Outch je voyais ça un peu plus simple ^^' "...

On va rendre caduque tout ça, pour faire ce que B@tto veut faire, il y a UNE seule ligne à modifier.

Et comme je le disais, si il fait des betises, il recharge ses répertoires sauvegardés puis son bootloader et c'est reparti :slight_smile:
Il ne faut pas avoir peur d'aller trifouiller VRAIMENT sous le capot, c'est fait aussi pour ça un microcontrôleur.


Stéphane.

Je suis d'accord avec toi Snootlab, un microcontroleur c'est fait pour cela. J'ai bien dit un microcontroleur pas une carte Arduino qui est un système de développement.

Bien sur si les acheteurs d'Arduino achètent une carte Arduino pour chaque projet c'est mieux pour certains... Alors que s'ils se contentent d'une carte pour développer et achètent ensuite des ATMELs sur Ebay...

Maintenant le monde est fait de tout... Les concepteurs de cartes PC font même des cartes pour "jouer" à overclocker... alors que !..

Je pense surtout que B@tto a plein de choses à apprendre et que c'est vraiment pas le plus urgent que de modifier un bootloader sans comprendre ce que l'on fait juste en suivant les directives d'un forum.

JLB

Snootlab:
Je suis désolé de ne pas suivre l’avis général, mais je vais encourager B@tto à la bidouille !

Je ne suis pas ici pour encourager ou non B@tto dans sa manip, je lui fourni juste les info brute de forme, à lui de décider si il se lance ou pas.
Je peut parraitre un peu “voila tu va devoir faire ça ça et ça, fait gaffe c’est pas si simple que ça” mais c’est pour qu’il sachent à quoi s’attendre.

Snootlab:

  1. Avoir deux Arduino (un qui te permettra de flasher/reflasher le deuxième, et qu’il ne faudra pas toucher)
  2. faire une copie de save du répertoire ./hardware/arduino/bootloaders
    3) savoir/apprendre comment compiler un programme en C avec make/avr-gcc (tutos pour arduino disponibles partout)
  3. dans le dossier optiboot, éditer optiboot.c
  4. remarquer dans le header “LED_START_FLASHES”, la fonction flash_led et leurs rapports.
  5. regarder dans le makefile si tu ne trouves rien d’interessant qui soit relié à ça.
    7) faire les modifications idoines
    8 ) faire un make clean
  6. recompiler en fonction de la cible voulue "make <cible_voulue>
  7. charger le nouveau bootloader.
  1. cette seul étape demande (au moins) une semaine de documentation pour un non initié.
    Quand on sait utiliser un makefile et gcc en ligne de commande c’est certes d’une évidence désobligeante.
    Mais quand on débute la subtilité du -Wl ou du -Os par exemple ne vient pas d’elle même à l’esprit.
    De même la tabulation en début de ligne dans un makefile n’est pas inné.
    Et dans le cadre d’un bootloader ce n’est pas envisageable de travailler ainsi.

Snootlab:

Sauf qu’une réponse a déja été faite dans ce sens et que B@tto a répondu "Outch je voyais ça un peu plus simple ^^’ "…

On va rendre caduque tout ça, pour faire ce que B@tto veut faire, il y a UNE seule ligne à modifier.

Dans le cadre d’un bootloader il y a tout la partie fusibles à gérer, l’adresse de début du bootloader, la taille en “mots” et en octets (à bien différencier) qui ne doit pas dépasser celle alloué.
Le bootloader optiboot est basé sur énormément de suppositions (états des registres, etc …) et d’attribut spécifique à avr-gcc.
Il n’y as peut être qu’une seul ligne à modifier dans le code, mais il faut s’assurer que cela n’as pas corrompu l’intégrité du reste du code.

Snootlab:
Et comme je le disais, si il fait des betises, il recharge ses répertoires sauvegardés puis son bootloader et c’est reparti :slight_smile:
Il ne faut pas avoir peur d’aller trifouiller VRAIMENT sous le capot, c’est fait aussi pour ça un microcontrôleur.

Arduino est conçu pour être simple et “superficielle” d’un point de vue code, les actions bas niveaux n’ont jamais était vu comme de l’arduino.

C’est vrai qu’il ne faut pas avoir peur de regarder un peu plus en profondeur, mais il faut le faire avec du recule et un minimum de connaissances.
(Au moins de quoi sauver le matériel en cas d’erreur)

Sur un microcontrôleur AVR il est extrêmement simple d’activer un fusible critique par erreur (c’est du reste un point récurent qui en fait le point faible des AVR).
Un microcontrôleur avec ISP désactivé ? Ou une broche reset désactivé (Attiny) ?
Sans un programmateur “HVSP” celui ci est bon à jeter !

attiny45-16.name=ATtiny45 - 16 MHz clock (Arduino as ISP)
attiny45-16.upload.protocol=stk500
attiny45-16.upload.maximum_size=4096
attiny45-16.upload.speed=19200
attiny45-16.upload.using=arduinoisp
attiny45-16.bootloader.low_fuses=0xe1
attiny45-16.bootloader.high_fuses=0xdf
attiny45-16.bootloader.extended_fuses=0xff
attiny45-16.build.mcu=attiny45
attiny45-16.build.f_cpu=16000000L
attiny45-16.build.core=arduino:arduino
attiny45-16.build.variant=tiny8

attiny45-8.name=ATtiny45 - 8 MHz clock (Arduino as ISP)
attiny45-8.upload.protocol=stk500
attiny45-8.upload.maximum_size=4096
attiny45-8.upload.speed=19200
attiny45-8.upload.using=arduinoisp
attiny45-8.bootloader.low_fuses=0xe2
attiny45-8.bootloader.high_fuses=0xdf
attiny45-8.bootloader.extended_fuses=0xff
attiny45-8.build.mcu=attiny45
attiny45-8.build.f_cpu=8000000L
attiny45-8.build.core=arduino:arduino
attiny45-8.build.variant=tiny8

attiny45.name=ATtiny45 - 1 MHz clock (Arduino as ISP)
attiny45.upload.protocol=stk500
attiny45.upload.maximum_size=4096
attiny45.upload.speed=19200
attiny45.upload.using=arduinoisp
attiny45.bootloader.low_fuses=0x62
attiny45.bootloader.high_fuses=0xdf
attiny45.bootloader.extended_fuses=0xff
attiny45.build.mcu=attiny45
attiny45.build.f_cpu=1000000L
attiny45.build.core=arduino:arduino
attiny45.build.variant=tiny8

Avec ca dans le board.txt tu peux faire un burn bootloader avec ArduinoISP et changer la fréquence du Tiny. Attention ce qui change la fréquence ce sont les fuse bits pas le build.f_cpu qui ne fait qu'adapter les fonctions de Arduino.h qui s'occupe du temps et utilisent le timer 0.

JLB

Jihelbi tu ne sais absolument rien de moi et de mon projet, et tu viens me juger ... Sur le seul fait que je ne sais pas modifier un bootloader ... Renseigne toi avant de prendre les gens de haut. Je traine sur ce forum depuis bien plus longtemps que toi :wink: Et mon TOC viens du simple fait que sur mon PCB où est montée mon Atmega en standalone (oh mon dieu, sacrilège, un Atmega qui utilise le langage Arduino !!), et bien je commande des électrovannes, pilotée par le pin ... 13 ! Et forcement ces dernières font des castagnettes au démarrage.

Je conçois de A à Z des appareils de labo, et la plateforme arduino me permet de largement répondre à tout mes besoins. J'ai démonté assez d'appareil commerciaux pour me rendre compte que beaucoup d'electroniciens pro doivent vraiment s'emmerder dans leur atelier pour tout bordéliser ainsi. J'ai un ami qui fait des études dans les microcontroleurs, il arrive en 5ème année et il ne sait toujours pas ce que c'est que l'i2c ... Mais c'est un peu pareil dans tous les domaines tu me diras.

EDIT : en plus je viens de mater l'optiboot, y'a quoi de sorcier ???

B@tto

rien de sorcier en effet, pas de tabou ou d'interdit !!!

Il se pourrait même qu'optiboot.c soit déjà conçu (lignes 630 à 644) pour n flashs de led , n pouvant être nul !!

sans toucher au code il suffirait (conditionnel car non testé avant de poster !!) de remplacer LED_START_FLASHES=3 par LED_START_FLASHES=0 dans le fichier make en ligne 222 (si c'est bien la config equivalente à ta carte)

atmega328: CFLAGS += '-DLED_START_FLASHES=3' '-DBAUD_RATE=115200'

Quelqu'un peut-il confirmer, infirmer, signaler un 'effet de bord'...... ?

On ne va quand même pas tomber içi dans le "dites moi ce que vous voulez, je vous montrerai comment vous en passer" !!

B@tto:
Et mon TOC viens du simple fait que sur mon PCB où est montée mon Atmega en standalone (oh mon dieu, sacrilège, un Atmega qui utilise le langage Arduino !!), et bien je commande des électrovannes, pilotée par le pin ... 13 ! Et forcement ces dernières font des castagnettes au démarrage.

Je me demande bien pourquoi tu as mis une Led sur la pin 19 de ton ATmega standalone ????????????????????????
Je me demande bien pourquoi tu as mis une Led sur la pin 19 de ton ATmega standalone ????????????????????????
Je me demande bien pourquoi tu as mis une Led sur la pin 19 de ton ATmega standalone ????????????????????????
Je me demande bien pourquoi tu as mis une Led sur la pin 19 de ton ATmega standalone ????????????????????????
Je me demande bien pourquoi tu as mis une Led sur la pin 19 de ton ATmega standalone ????????????????????????

Je me demande bien pourquoi tu ne fais pas un FULL FLASH de ton ATmega ce qui supprime le bootloader ??????????????????????
Je me demande bien pourquoi tu ne fais pas un FULL FLASH de ton ATmega ce qui supprime le bootloader ??????????????????????
Je me demande bien pourquoi tu ne fais pas un FULL FLASH de ton ATmega ce qui supprime le bootloader ??????????????????????
Je me demande bien pourquoi tu ne fais pas un FULL FLASH de ton ATmega ce qui supprime le bootloader ??????????????????????
Je me demande bien pourquoi tu ne fais pas un FULL FLASH de ton ATmega ce qui supprime le bootloader ??????????????????????

JLB

B@tto je crois que ton problème c'est de conserver le bootloader sur ta carte standalone. Il faut la programmer en ICSP et donc créer dans Mes documents\Arduino\hardware\Atmega un fichier boards.txt.

Je te fournis le contenu de ce fichier pour faire du Full Flash en ICSP. Il n'y a pas besoin de faire de burn du bootloader pour cette config car on ne change pas les fuse bits. On informe le programmateur (ici ArduinoISP mais tu peux changer la ligne correspondante pour un programmateur reconnu) sur les locks bits uniquement. Par contre tu peux faire un burn bootloader avec cette config de carte et cela fonctionne pour remettre un chip en état Arduino.

Je suis le premier à promouvoir l'usage d'Arduino pour programmer des chips autre que l'ATmega328P. Je m'efforce même souvent de n'utiliser que les fonctions Arduino sans aucun accès direct à des fins pédagogiques (voir mon post sur la réception RC5 ultra concise sous interruption entièrement en Arduino et qui tourne sur ATtiny25).

Voici une boards.txt qui va bien :

atmega48-20.name=ATmega48V 20 MHz FULL FLASH (Arduino as ISP)
atmega48-20.upload.protocol=stk500
atmega48-20.upload.maximum_size=4096
atmega48-20.upload.speed=19200
atmega48-20.upload.using=arduinoisp
atmega48-20.bootloader.low_fuses=0xff
atmega48-20.bootloader.high_fuses=0xdd
atmega48-20.bootloader.extended_fuses=0x00
atmega48-20.bootloader.unlock_bits=0x3F
atmega48-20.bootloader.lock_bits=0x0F
atmega48-20.build.mcu=atmega48
atmega48-20.build.f_cpu=20000000L
atmega48-20.build.core=arduino:arduino
atmega48-20.build.variant=standard

atmega48.name=ATmega48V 16 MHz FULL FLASH (Arduino as ISP)
atmega48.upload.protocol=stk500
atmega48.upload.maximum_size=4096
atmega48.upload.speed=19200
atmega48.upload.using=arduinoisp
atmega48.bootloader.low_fuses=0xff
atmega48.bootloader.high_fuses=0xdd
atmega48.bootloader.extended_fuses=0x00
atmega48.bootloader.unlock_bits=0x3F
atmega48.bootloader.lock_bits=0x0F
atmega48.build.mcu=atmega48
atmega48.build.f_cpu=16000000L
atmega48.build.core=arduino:arduino
atmega48.build.variant=standard

atmega328.name=ATmega328P 16 MHz FULL FLASH (Arduino as ISP)
atmega328.upload.protocol=stk500
atmega328.upload.maximum_size=32768
atmega328.upload.speed=19200
atmega328.upload.using=arduinoisp
atmega328.bootloader.low_fuses=0xff
atmega328.bootloader.high_fuses=0xdd
atmega328.bootloader.extended_fuses=0x05
atmega328.bootloader.path=arduino:optiboot
atmega328.bootloader.file=optiboot_atmega328.hex
atmega328.bootloader.unlock_bits=0x3F
atmega328.bootloader.lock_bits=0x0F
atmega328.build.mcu=atmega328p
atmega328.build.f_cpu=16000000L
atmega328.build.core=arduino:arduino
atmega328.build.variant=standard

JLB

Je ne fais pas de full flash pour la simple et bonne raison que ... c'est la première fois que j'en entend parler !! Mais j'ai le programmateur donc pourquoi pas ... Cependant je vais perdre la possibilité de mettre mon appareil à jour simplement par l'USB, ce qui est problématique pour moi.

@al1fch : je pense que tu as raison, perso je vais quand même essayer de virer toutes les ligne en relation : le passage en OUTPUT et la fonction de flash.

Question substancielle : que devient le watchdog avec la plateforme arduino ? Un redémarrage en cas de plantage je suis preneur ...

al1fch:
Il se pourrait même qu'optiboot.c soit déjà conçu (lignes 630 à 644) pour n flashs de led , n pouvant être nul !!

sans toucher au code il suffirait (conditionnel car non testé avant de poster !!) de remplacer LED_START_FLASHES=3 par LED_START_FLASHES=0 dans le fichier make en ligne 222 (si c'est bien la config equivalente à ta carte)

atmega328: CFLAGS += '-DLED_START_FLASHES=3' '-DBAUD_RATE=115200'

Quelqu'un peut-il confirmer, infirmer, signaler un 'effet de bord'...... ?

Je confirme l'effet de cette macro :slight_smile:

Elle est déjà présente dans le bootloader Arduino d'origine (pré-Optiboot). Je me souviens l'avoir éliminée sans souci. Il n'y a pas de réel effet de bord mais il y a un gros piège : certes Arduino fournit les sources et le makefile, mais comme ils n'indiquent pas toujours quelle version du compilateur ils ont utilisée et que ses options peuvent avoir un effet et des performances variables selon la version, tu peux te retrouver avec un bootloader compilé sensiblement différent de l'original, y compris sur des parties auxquelles tu ne voulais pas toucher au départ.

Un article qui peut être utile pour comprendre le makefile : Optimisations of AVR programs using avr-gcc

De mon expérience personnelle, si tu prends les sources du bootloader Arduino d'origine avec le makefile fourni et que tu compiles tel quel avec un avr-gcc récent, le binaire produit dépasse légèrement les 2kB, et donc ne tient plus dans la zone NRWW d'un ATmega168 par exemple.

B@tto si je comprends bien tu as mis un port USB sur ton ATmega standalone donc avec un 16U2 que tu as programmé par ICSP. Si tu as su faire cela tu sauras sans difficulté faire de l'ICSP sur un ATmega328P.

Si ta carte n'utilise l'USB que pour se reflasher il est aussi simple de le faire en ICSP avec un connecteur 6 points. Dans ce cas tu récupères les bit 0 et 1 du port D qui ne servent plus comme TX et RX, ca te fait deux I/O de plus.

Sans le bootloader tu feras ce que tu veux y compris en langage Arduino comme tu dis. La seule façon de bien maîtriser les conceptions standalone c'est d'étudier soigneusement la datasheet ATMEL (448 pages). Tu y verras comment fonctionne le watchdog.

Ensuite tu n'as pas besoin de programmateur car le sketch ArduinoISP fonctionne parfaitement. Tu peux laisser l'Arduino en permanence en programmateur en laissant en place la capa de 10 uF sur le reset.

JLB