salut a tous!
j'essaie d'utiliser les 328PB d'ATmega, mais rien a faire, je n'arrive pas a charger un vrai bootloader 328PB. j'ai pu faire fonctionner en 328p.
j'ai passé ma soirée a essayer de flasher avec le nouveau core "Minicore"
https://www.upesy.fr/blogs/tutorials/use-extra-features-of-atmega328pb-from-upesy-one-board
qui prends en charge les nouvelles fonctionnalités mais rien a faire... quelqu'un a tenté avec succès?
Bonjour,
Tu as essayé le package de support pour ces familles?
Il y a un wiki
avec un lien vers des explications pour préparer la carte ic.
@fdufnews j'eu essayé l'année dernière sans succès, il faudrait que je m'y remette. mais sauf erreur ou évolution ils intègrent pas les fonctions spécifiques au PB.
il faudrait que je change celui que j'ai sur ma carte là, je l'ai surement trituré un peu trop a force d'essais, refonte soudures etc etc. j'ai un boot qui va dedans mais SPI1 et Serial1 ne fonctionnent pas.
je bloque toujours sur l'identification du proc au moment du flash ISP, il réponds a cette demande par une mauvaise série de caractère (qui en plus n'est pas fixe, elle change)
en prenant le MiniCore il faudrait peut-être que j'aille voir dedans et mettre une identité que le proc envoie en ISP, histoire de forcer le flash. a voir la réaction.
C'est toujours mystérieux pour moi : que vient faire le bootloader dans le fait que SPI1 et Serial1 ne fonctionnent pas ?
J'ai compris qu'un bootloader c'est pour permettre la programmation par l'interface série pour éviter le mode "natif" des micros avr qui est l'ISP.
Dans certains micros les bootloaders sont fixes et il peut en exister plusieurs, non effaçables, qui utilisent l'UART, l'I2C, etc.
Pour moi Arduino sème la confusion en faisant un horrible mélange de mots avec le bootloader et la configuration des fuses.
Les SPIs et les UARTs, a ce que j'ai compris, ne sont gérés que par les fonctions du framework (est-ce le bon mot ?) de l'IDE. Tant que ce "framework" restera celui du 328p, il ne les gèrera jamais.
C'est ce que j'ai compris, dites moi où j'ai faux.
Dans la série "mistères" il y a aussi la (ou plutôt le) RTC :
Dans la deuxième page de la documentaton de l'ATmega328/P, on peut lire :
… En page 2 Power-save Mode: 0.75μA (Including 32kHz RTC)…
On aurait bien aimé mais en fait il n'y a aucune Real Time Clock dans ce microprocesseur
il s'agit juste d'un Real Time Counter
L'ID du 328PB est 0x1e9516. Il n'y a aucune raison que cela change.
J'ai déjà chargé un bootloader dans un 328PB mais en ligne de commande :
Paragraphe 2
c'est vrai, moi aussi je me pose ces questions, c'est comme charger un Boot de UNO dans un NANO, les broches A6 et A7 seraient inutilisables car non sorties sur le UNO. a cause du Bootloader.
je pense que c'est en rapport avec l'environnement Arduino et les facilités qu'il offre, ces commandes simples doivent avoir des "chemins", "balises" pour se mettre bien en place lors du chargement par la liaison série... je ne saurais pas en dire plus mes compétences sont limitées...
pas mal celle là 
les STM32 ont la RTC intégrée (ouais du coup là c'est "la" 
)
je suis d'accord c'est pour ça que je précise le phénomène. je ne suis pas bien sur que mon 2560 Mega Pro soit pleinement opérationnel en tant que programmateur ISP, faudrais peut-etre que j'essaie un NANO, ça sa peux être testé rapidement.
j'ai lu quasiment tout et c'est fort sympathique. justement, il met en avant des différences concernant les MEGA, en tant que Target, mais c'est peut-être aussi diffèrent en programmateur. ou peut-etre juste le mien qui est merguez, il en a vu. il me semble avoir chargé avec mon UNO sur mes travaux précédents (déclaré décédé il y a quelques semaines 
)
EDIT: testé avec un NANO, c'est pareil. j'ai pas la bonne définition du processeur donc partant de là... je pense que c'est le probleme a regler en premier.
EDIT2: c'est mon 328PB qui est HS, ou le bootloader chargé auparavent fait barrage a l'identification... je sais pas. mais avec un nano 328p ça marche. je vais mettre quelques 328PB dans mon prochain panier Mouser quitte a en poser un sur une vieille planche NANO qui traine pour les essais.
Faux.
Dans l'univers Arduino (heureusement Atmel n'a pas attendu Arduino pour savoir programmer ses propres produits) les pins par carte sont définis dans le fichier pinArduino.h.
Un bootloader n'est absolument obligatoire pour programmer une carte.
D'ailleurs en sortie d'usine il n'y a pas de bootloader puisque c'est un programme et que le micro est nu, comment ferait-on pour charger le bootloader sur un avr si un avr nu n'a pas de bootloader ?
On le fait comme pour n'importe quel programme : en mode ISP.
Les STM32 sont différents : les bootloaders sont écrits en mémoire morte, on peut ajouter un bootloader, mais ceux qui existent ne sont pas modifiables.
Regarde le contenu du répertoire :
/home/b/.arduino15/packages/arduino/hardware/avr/1.8.6
Note : je suis sous Linux-Debian
Et tu y trouveras des fichiers sources qui forment le "package avr"
Ces fichiers sont recompilés à chaque lancement de l'IDE.
Regarde aussi le fichier main.cpp qui est le vrai fichier qui est envoyé au compilateur.
@68tjs je n'est jamais dit qu'il fallait absolument un bootloader pour bosser sur un Atmel, ni même qu'il y avait besoin d'Arduino pour cela. j'ai dit que les bootloader UNO et NANO étaient différents, c'est tout. c'était une simple anecdote.
vu la multitude d'utilisations du 328, a petite ou grande série, heureusement que les mecs s'arrêtent pas sur un bootloader 
on est qu'une bande de gamins qui jouent au docteur maboul a coté de certains et ça je le sais très bien, c'est le but d'Arduino, vulgaire (mais ingénieux) système logiciel, de rendre ça simple et accessible, et non le but d'Atmel.
Le bootloader est un programme comme un autre. Il est possible de modifier les registres du micro pour l'utilisation d'un bus que ce soit pour identifier la présence ou non d'un composant ou simplement pour identifier la version du hard. Si ces modifications ne sont pas remises en ordre avant le démarrage du soft celui ci ne fonctionnera pas ou mal (sauf si le soft a été conçu pour fonctionner avec ce boot). En professionnel le boot effectue souvent des opérations de contrôle basique qui indique à l'opérateur, si le test n'est pas bon, qu'il est inutile de charger le soft et que le produit doit sortir de la chaine
Je crois qu'il y a méprise.
Le bootloader ne sert qu'a la programmation. Si on change des paramètres c'est la taille mémoire Flash (pour savoir où placer le code téléchargé) le port utilisé pour la programmation (lorsqu'il y en a plusieurs) c'est pour ça que tu trouveras, par exemple, un optiboot pour atmega8, atmega168, atmega328.
Lorsque tu installes un nouveau package, il arrive avec ses propres bootloader.
En ce qui concerne l'usage des SPI, I2C, UART dans les applications, c'est dans les fichiers pin_arduino.h, qui se trouvent dans le sous-répertoire variants, que l'on trouve la définition de ceux-ci. Les packages supplémentaires que l'on ajoute pour le support des nouvelles cartes apportent justement des fichiers pin_arduino.h propres aux cartes.
Les packages apportent aussi les librairies nécessaires
Etant donné que la signature lue vaut 0x800000, soit le 328PB est mort, soit il y a un pb de câblage.
la signature valais 0x800000 a cet essai, mais a valu 0x0ff000, puis 0x080f00... mais en réessayant plusieurs fois ça fini toujours par m'afficher 0x000000 indéfiniment.
le test de flash sur mon NANO cobaye a été fait avec le même programmateur et les mêmes fils Dupont, donc c'est soit le MCU HS, ou alors un problème sur le PCB du dit MCU (carte perso pour la réception et l'envoi de messages Canbus automobile) mais étant donné que j'avais déjà réussi a le flasher, ça me parait peu probable.
En quoi? Le bootloader peut ne pas se contenter de programmer les fusibles et de faire un jump vers le programme
pour moi, c'est le Boot qui réponds au STK500 par exemple. comme dit @68tjs , il y a forcement au moins un sans blanc de Boot d'origine pour orchestrer l'ISP entre autre. nous on charge un Boot "de confort" en remplacement, histoire que le MCU réponde aux commandes Arduino et fasse ce que le Core choisi exige. donc je te rejoins sur ta théorie, a savoir que mon écrit ne vaux pas grand chose n'étant qu'un vulgaire débutant.
ça expliquerait pourquoi mon 328PB ne réponde pas bien a la demande d'identification, j'ai toujours trouvé douteux le Bootloader que j'avais utilisé, le flash d'avant avais pas posé probleme, il n'est peut-etre pas HS mais corrompu et a mon niveau je pourrais pas le récupérer (puis vu le tarif du MCU ça vaut pas le coup d'essayer)
Ce n'est pas semblant de boot : c'est la procédure de démarrage du microcontrôleur voulue par son concepteur et qui n'est pas modifiable.
De même est gravé dans le silicium qu'au démarrage toutes les IO sont configurées en entrée haute impédance et que les entrées faussement appelées analogiques par arduino sont reliées à un port numérique et ne sont pas en état de faire des mesures analogiques (sur le 328p des deux appelées PAR ARDUINO A6 et A7 sont particulières).
Dans le 328pB A6 et A7 sont numériques au démarrage du micro.
Oui, je pense qu'il n'y a rien qui interdise de faire ce que tu dis,
C'est plutôt réservé à des sociétés qui vendent des produits finis dans lesquels ils incorporent un microcontrôleur dont ils veulent contrôler les mises à jour.
On est plus dans du protectionnisme industriel que dans le développement open source.
Ce programme peut-il encore s'appeller un bootloader
N'est-ce pas plutôt un "verrou_loader" ou un "security_loader" ?
j'utilise peut-être mal le mot Boot mais ça rejoins plus ou moins mon affirmation.
on parle bien de PE2 PE3, l'utilisation du gras est un peu "diminutrice" 
bon j'ai réussi a lui faire passer l'identification mais ça bloque plus loin comme on pouvais s'en douter, et je n'arrive pas a solutionner la suite. je vais attendre d'avoir des 328PB neufs, je vous tiendrais au courant.
Même le boot arduino le fait en faisant clignoter 3 fois la LED builtin sur le port B
problème résolu, j'ai pu tout flasher avec le Minicore sur 328PB, carte de test (un Nano auquel j'ai retiré le 328P pour mettre un 328PB) mon PCB perso en question et même un autre système que je viens d'assembler, en oscillateur interne 8Mhz et sans bootloader car ISP direct, et ça marche.
sur mes voies RESET j'ai toujours mis un condo en série, les DTR fonctionnent comme ça (CH340 par exemple). sauf que pour l'ISP ça va pas. condo shunté, tout flashe nickel chrome.
merci pour votre aide
Devant la disparition du p au profit du pb je pense qu’un tuto ordonné serait apprécié 
