Programmation Atmega328p via port Serie RS232

Bonjour,

Pour faire bref voici ma question :

(sans passer par la carte Arduino Uno + Sans IDE ARDUINO)
(Alimentation du microcontroleur disponible + fichier HEX disponible compilé + chargement du programme HEX commande AVRdude)

Est ce que si je fournie un port Serie directement au microcontroleur Atmega328p je réussirai à le programmer ? ou c’est nécessaire de passer par le protocole SPI ?

Autrement dit, est ce que je peux programmer le uC à travers TX/RX ou je dois passer per le SPI.

C’est bête mais je perds toutes les notions de la logique je suis perdu j’espère avoir une réponse (ouvert à une proposition pour utiliser un programmer facile pour la conception).
Merci à vous!

Photo jointe

Si l'atmega328 a déjà un bootloader c'est oui.
Si ce n'est pas le cas il utiliser l'ISP pour en mettre un.

La programation par ISP (In Situ Programing) n'a pas besoin de bootloader. Elle utilise les accès SPI mais ce n'est pas tout à fait le même protocole.

Concernant le terme RS232 c'est NON avec un VRAI RS232,
C'est OUI avec ce qu'on appelle improprement RS232 par la force de l'habitude.

Le rs232 c'est un protocole et c'est aussi des signaux électriques.
Ce sont les signaux électriques qui posent problèmes :
Signal positif entre +3V et +20V pour un niveau logique et signal négatif entre -3 V et - 20 V pour l'autre niveau logique.

On utilise plutôt les termes UART ( ou USART s'il y a une horloge) qui ne définissent que le protocole ( celui du rs232 d'où les confusions et la persistance de l'emploi du terme rs232).
Quant aux niveaux électriques ce sont généralement des niveaux CMOS ( 0 V / +Vcc )

Je te remercie 68tjs pour ta réponse,

Seulement c'est toujours pas clair pour moi, peut etre parce que je ne le suis pas

Pour les signaux électriques j'ai utilisé un Max232 (voir photo attachée sur topic)

je vais parler plus en détails, voila si j'ai un fichier .HEX avec un bootloader (parce que généralement on peut compiler deux fichier HEX à partir d'arduino Avec et sans bootloader)

je veux utiliser le atmega328p sans l'arduino, je me suis dit peut être en lui fournissant un port Serie (TX/RX) et en exploitant les commandes AVRdude il y'aura moyen de le programmer sans faire bcp de montages électriques.

  1. si non ? est ce qu'il y'a un autre moyen (un autre port) qui peut accompagner le atmega328p pour avoir accès à le programmer sans faire trop de complexité (Fichier .HEX toujours disponible)

j'ai utilisé un Max232

C'est du vrai RS232. Donc coté Arduino le MAX232 donne les bons niveaux 0V /+5V. Tout va bien.

(parce que généralement on peut compiler deux fichier HEX à partir d'arduino Avec et sans bootloader)

Je n'ai jamais compris comme cela.
C'est le même fichier HEX.

avrdude est un logiciel Atmel qui sert à transférer un fichier HEX dans un micro avr.
Dis toi bien qu'heureusement pour Atmel on n'a pas attendu l'écriture de l'IDE Wiring/arduino pour programmer les micros avr.

avrdude gère parfaitement la programmation par ISP comme la programmation par interface USB/UART(port Série).
Il suffit de lui spécifier le bon programmeur dans la ligne de commande.
Il existe une datasheet pour avrdude, je te conseille de la lire elle est très détaillée.
Attention un micro sortie d'usine est livré dans une configuration particulière. Il y a des mémoires spécifiques à modifier : les fuses.

Pour la programation il existe des petits montages sur Ebay qui permettent de programmer un micro avr à partir de l'USB:

  • les interfaces USB/UART que l'on trouve aussi sous la dénomination USB/TTL --> les "howto" existent, il faut éviter les cartes qui ne fournissent que TX et RX.
    Le micro doit avoir un bootloader, --> je ne pense pas que l'on puisse charger un bootloader avec cette méthode --> à vérifier.

  • les interfaces USB/ISP qui peuvent s'utiliser sur des micros avec ou sans bootloader.

Dans les deux cas les prix tournent autour 2/5 €.

Bonjour,

A mon avis, il y a un problème dans le branchement du Max232, la sortie RS232 est reliée à une sortie du Max et l'entrée RS232 est reliée à une entrée du max

(oui bien vu Kamill mais oublions le Max232)

68tjs
J’ai voulu dire par (Avec Bootloader) Arduino fournit deux fichiers

test.ino.with_bootloader.standard.hex
test.ino.standard.hex

j’utilise celui avec le bootloader
Oui je me suis bien documenté sur le avrdude et je ne veux l’utiliser directement que pour charger le programme sur le microcontroleur.

Après un moment de réflexion voici la solution que je propose :

‘usbtiny (USBtinyISP) programmer’ ou ‘USBasp AVR Programmer’ relié au pc pour configurer les microcontrôleurs

au lieu du port serie j’utilise un “6-pin ICSP connector pinout”

et la commande sur avrdude (programmer) : avrdude -c usbtiny … // avrdude -c

A confirmer ? merci photo attachée je pourrai fournir le fichier ISIS si vous confirmez cette méthode

J'ai voulu dire par (Avec Bootloader) Arduino fournit deux fichiers

test.ino.with_bootloader.standard.hex
test.ino.standard.hex

Quelle version de l'IDE ?

Je viens de vérifier avec la 1.6.5 et la 1.7.8 je n'ai qu'un seul fichier hex.

68tjs:
Quelle version de l’IDE ?

Je viens de vérifier avec la 1.6.5 et la 1.7.8 je n’ai qu’un seul fichier hex.

J’utilise la 1.6.7 (photo attachée)

bl.PNG

Bonjour,

Je pense que c'est uniquement quand on fait outils/exporter les fichiers compilés qu'on a les deux versions.

kamill:
Bonjour,

Je pense que c'est uniquement quand on fait outils/exporter les fichiers compilés qu'on a les deux versions.

Oui

c'est pas confirmé pour le ICSP alors ? il y'a une erreur qlq part ?

C'est à mon tour de ne plus rien comprendre.
Dans le répertoire temporaire où sont logés les fichiers résultants de la compilation il n'y a qu'un seul fichier *hex.
Pourquoi avec l'exportation le fichier avec bootloader est plus gros que le fichier sans bootloader ?

En faisant ainsi recharge-t-on systématiquement le bootloader (qui fait 500 octets) ?

C'est contraire à ce que j'avais compris : le bootloader ne se charge qu'une seule fois.

68tjs:
C'est à mon tour de ne plus rien comprendre.
Pourquoi avec bootloader le fichier est plus gros ?

j'ai pas tout suivi
mais ce ne serait pas tout simplement un hex programme generé et bootlader à injecter par ICSP sur un MCU vierge ?
on se retrouve ensuite avec un MCU chargé avec le prog généré et avec un bootloader ?

J'ai complété mon message pendant ta réponse et je pense qu'on n'est pas loin de penser la même chose.

68tjs:
J'ai complété mon message pendant ta réponse et je pense qu'on n'est pas loin de penser la même chose.

oui , j'au vu
mais chez moi je n'ai pas d'option export ? (1.6.5 1.7.0) c'est où ?

Ben moi aussi et c'est pas proposé
Encore une fuite en avant.
Je reste en 1.6.5 et 1.7.8 sans oublier la debian 1.0.5 qui suffit largement avec des avr.

68tjs:
Ben moi aussi et c'est pas proposé
Encore une fuite en avant.
Je reste en 1.6.5 et 1.7.8 sans oublier la debian 1.0.5 qui suffit largement avec des avr.

perso je reste sous 1.6.5
je n'utilise que des 328P (uno/nano)
attiny
digispark
esp8266
pour moi c'est stable et je n'ai pas de surprise avec les boards supplementaires

68tjs il est plus grand parce que tout simplement il comporte le code dédiée pour le bootloader.

En faisant une comparaison entre les deux fichiers (grace à WinMerge) il y a un code écrit en Hex ajouté sur le fichier avec le bootloader.

Artouste:
j'ai pas tout suivi
mais ce ne serait pas tout simplement un hex programme generé et bootlader à injecter par ICSP sur un MCU vierge ?
on se retrouve ensuite avec un MCU chargé avec le prog généré et avec un bootloader ?

Oui c'est bien dans ce sens que j'ai proposé la solution de se contenter juste du ICSP et charger le programme déjà géneré avec un bootloader.

C'est donc juste pour un atmega vierge sortie d'usine. Toute la mémoire serait programmée.

Mais les Fuses il les changent aussi ?
Parce que sortie d'usine c'est oscillateur interne 8 MHz sur réseau RC et diviseur par 8 activé.
Le micro tourne sous 1 MHz très peu précis.
Si on met un quartz il sera ignoré tant que les fuses ne seront pas correctement configurés.

Où est la doc de ce machin ?

Bon je retourne me prendre la tête avec les timers du STM32. Quand il y a trop de possibilité on ne sait plus de quel coté regarder, un avr s'est super simple à coté d'un ARM, et mes neurones fatiguent.