megaTinyCore
2.6.10 - Critical Bugfix
Nous avons maintenant une section Discussions Github. Lorsqu'un problème est définitivement un défaut central, vous réduirez le temps nécessaire pour le résoudre si vous créez un problème, car je donne la priorité aux problèmes plutôt qu'au rattrapage des discussions.
Cela corrige de nombreux bugs présents dans la version 2.6.x
2.6.x introduit une empreinte Flash améliorée de manière significative tout en ajoutant des fonctionnalités, le fil peut sortir l'esclave du mode veille sans corrompre les données, et bien plus encore, voir le journal des modifications.
Seules les versions de l'IDE Arduino téléchargées depuis arduino.cc doivent être utilisées, JAMAIS depuis un gestionnaire de paquets Linux. Les gestionnaires de paquets disposent souvent de l'IDE Arduino, mais l'ont modifié . Ceci malgré le fait qu'ils ne connaissent rien d'Arduino ou du développement intégré en général, et encore moins de ce dont ils auraient besoin pour le modifier avec succès. Ces versions sont connues pour des problèmes subtils mais sérieux causés par ces modifications imprudentes. Ce noyau ne devrait pas fonctionner sur de telles versions, et aucune modification ne sera apportée dans le but de corriger les versions de l'EDI provenant des gestionnaires de packages pour cette raison.
Il s'agit d'un bug du client Arduino.
Les versions IDE entre 1.8.13 et 2.x ont développé de nouveaux défauts importants. Les versions IDE 1.8.2 et antérieures possèdent cependant des défauts rédhibitoires non corrigés. Je pense qu'ils disposent enfin d'une version fonctionnelle de l'IDE, et je pense que cette dernière est capable d'installer mon noyau correctement.
Avant megaTinyCore 2.6.0, l'installation manuelle de megaTinyCore provoquait le crash de la V1.8.14 de l'EDI en raison de ce bug lorsque vous installiez le noyau manuellement dans votre dossier Arduino. Les utilisateurs de 1.8.14 et versions ultérieures doivent utiliser la version 2.6.0 de megaTinyCore.
J'achète beaucoup de produits électroniques sur AliExpress. C'est un excellent marché pour les produits fabriqués par des entreprises chinoises et qui sont pour la plupart génériques, y compris de nombreux composants qui ne sont pas disponibles autrement pour les particuliers en Occident (par exemple, la commande minimum est une bobine ou quelque chose comme ça - si vous pouvez même trouver un fournisseur de composants qui travaille avec le fabricant de puces chinois sans nom). Ce n’est pas un endroit idéal pour les dernières gammes de produits semi-conducteurs des principaux fabricants occidentaux, surtout au milieu d’une pénurie historique de ces puces. Les appareils AVR modernes, lorsqu'ils sont disponibles via ces canaux, sont fréquemment signalés comme étant faux ou défectueux (comme les ATtiny412 qui pensent qu'ils sont des 416 et peuvent ne pas exécuter correctement la réinitialisation de la mise sous tension). D'ailleurs, vous ne voulez probablement pas acheter de microcontrôleurs AVR sur AliExpress ... Les cartes assemblées, comme les clones Arduino Nano, fonctionnent généralement si vous évitez celles avec les puces LGT8 tierces et faites attention à celles avec l'ATmega168p. au lieu du '328p - mais il y a beaucoup de rapports faisant état de faux microcontrôleurs lorsqu'ils sont vendus sous forme de puces nues (j'ai entendu parler de faux ATtiny85 qui ont en fait été remarqués) ATtiny13 ; il n’y a pas que les AVR modernes qui sont falsifiés). Il existe de nombreuses théories intéressantes sur l’origine de ces fausses puces, et Microchip est resté totalement silencieux sur la question.
Il est préférable de visualiser ce document en ligne (plutôt que d'ouvrir le fichier de démarque dans votre éditeur de texte préféré), afin que les liens soient cliquables et que les images en ligne soient affichées, et probablement plus important encore, pour que les tableaux s'affichent parfois correctement. Encore une fois, ce [document peut être trouvé sur github](https://github.com/SpenceKonde/megaTinyCore](https://github.com/SpenceKonde/megaTinyCore)
Les anciennes versions ne gèrent pas correctement les programmeurs dans le menu Outils -> Programmeurs, ce qui dégrade rapidement l'UX à mesure que le nombre de cœurs installés augmente. Ils ne conviennent pas. Les versions les plus récentes commençant par 1.8.14 (y compris 1.8.17, 1.8.18 et 1.8.19) peuvent générer une erreur « panique : aucune version majeure trouvée » car elles ne parviennent pas à analyser correctement platform.txt. Depuis la version 2.6.0, nous modifions manuellement le fichier platform.txt juste avant la sortie, ce qui pose donc moins de problèmes.
Lorsque megaTinyCore est installé via le gestionnaire de cartes, la version requise de la chaîne d'outils est installée automatiquement. Toutes les pièces de la série 0/1/2 sont prises en charge sans étapes supplémentaires. Jusqu'à la version 2.2.7, nous utilisions la version Arduino7 d'avr-gcc (gcc 7.3.0 et avrlibc 3.6.1) avec les derniers ATpacks en juin 2020. À partir de la version 2.2.7, nous avons commencé à utiliser ma version Azduino de la chaîne d'outils, qui a mis à jour les ATpacks pour toutes les pièces nouvellement prises en charge. La version 2.2.7 utilisait Azduino3, la version 2.3.0+ utilisait Azduino4 et, à partir de la version 2.6.0, nous utilisons Azduino5 (bien que cela ne nous offre aucun avantage, si ce n'est d'économiser un quart de Go d'espace disque dur et 40 Mo de bande passante de téléchargement si vous installez les deux). megaTinyCore et DxCore via le gestionnaire de forum.
L'installation manuelle est plus compliquée, en particulier si vous souhaitez prendre en charge la série 2 ; consultez le guide d'installation pour plus d'informations.
Un noyau Arduino pour les tinyAVR séries 0, série 1 et maintenant série 2. Ces pièces ont une architecture améliorée par rapport aux pièces tinyAVR "classiques" (qui sont prises en charge par ATTinyCore), avec des périphériques améliorés et un temps d'exécution amélioré pour certaines instructions (elles sont similaires en ce qui concerne la série AVR Dx avancée, ainsi que puces megaAVR série 0 comme l'ATmega4809 utilisée sur les versions officielles Nano Every et Uno Wifi Rev. 2 - bien que l'équipe Arduino ait fait de son mieux pour les mettre à genoux) dans un petit format à faible coût. packages typiques de la ligne ATtiny. Toutes ces pièces comportent au moins un UART matériel et une interface SPI et TWI (aucune de ces ordures USI comme, par exemple, l'ATtiny85 n'en a), un système d'événements puissant, une logique personnalisée configurable, au moins un comparateur analogique sur puce. , un oscillateur interne étonnamment précis, et dans le cas de la série 1, un véritable canal de sortie DAC, et dans le cas de la série 2, un CAN différentiel sophistiqué.
De plus, les pièces minuscules de la série AVR 0/1/2 sont bon marché - les pièces les plus haut de gamme, les 3226 et 3227, avec 32 Ko de flash et 3 Ko de SRAM (contre la SRAM 2k comme l'ATmega328p utilisé dans Uno/Nano/ProMini) fonctionnent un peu plus de 1 $ USD en quantité - moins que de nombreuses pièces AVR ATtiny classiques de 8 000 pièces ("jeu d'instructions AVR, à un prix PIC"). Toutes ces pièces sont conçues pour fonctionner à 16 MHz ou 20 MHz (à 4,5-5,5 V) sans cristal externe, et l'oscillateur interne est suffisamment précis pour la communication UART.
Ceux-ci utilisent la programmation UPDI, et non un FAI traditionnel comme le faisaient les parties classiques d'ATtiny. Voir ci-dessous pour plus d'informations. Obtenir un programmeur UPDI est simple - vous pouvez utiliser un Arduino classique basé sur 328p comme programmeur en utilisant jtag2updi - ou pour de meilleurs résultats avec du matériel moins cher, vous pouvez utiliser n'importe quel adaptateur USB-série et une résistance (et de préférence une diode) en utilisant le SerialUPDI inclus. outil, ou vous pouvez utiliser AVRdude avec l'un des programmeurs Microchip (les programmeurs basés sur mEDBG/nEDBG/EDBG sur leur carte de développement, Atmel-ICE ou SNAP) ou toute programmation UPDI outil qui émule l'un d'entre eux (ce qui, à ma connaissance, le font tous - s'il y en a un qu'avrdude prend en charge et que mon noyau ne prend pas en charge, veuillez ouvrir un numéro pour me le faire savoir !).
Un chargeur de démarrage série, Optiboot_x (basé sur la même base de code que le chargeur de démarrage Arduino Uno classique, bien que considérablement modifié depuis) est pris en charge sur ces pièces (le support de la série 0/1 est actuellement en ligne, la série 2 est attendue d'ici la première semaine de mai. ; les ajustements pour les nouvelles pièces sont triviaux), ce qui permet de les programmer via un port série traditionnel. Consultez la section Optiboot ci-dessous pour plus d'informations à ce sujet et les options pertinentes. L'installation du chargeur de démarrage nécessite un programmeur UPDI. Les breakout boards assemblées que je vends sur Tindie sont disponibles pré-démarrées (elles sont démarrées à la demande). Cela étant dit, l'expérience utilisateur avec Optiboot est un peu décevante sur les pièces de la série 0/1 ainsi que sur les pièces de la série 2 à 14 broches, en raison de l'absence de broche de réinitialisation matérielle qui pourrait être utilisée avec le circuit de réinitialisation automatique habituel. pour se réinitialiser automatiquement dans le chargeur de démarrage lorsque le port série est ouvert. Vous devez soit désactiver complètement la programmation UPDI (nécessitant un programmateur HT si les paramètres des fusibles ou du chargeur de démarrage doivent être modifiés après le démarrage initial), soit laisser UPDI activé, mais démarrer tout téléchargement dans les 8 secondes suivant la mise sous tension. Les pièces de la série 2 à 20 et 24 broches prennent en charge une « broche de réinitialisation alternative » leur permettant d'agir davantage comme un Arduino traditionnel.
L'interface de programmation UPDI est une interface monofilaire pour la programmation (et le débogage - Interface universelle de programmation et de débogage), qui est utilisée sur la série tinyAVR 0/1/2, ainsi que sur tous les autres microcontrôleurs AVR modernes. . Bien que l'on puisse toujours acheter un programmeur UPDI spécialement conçu auprès de Microchip, cela n'est pas recommandé lorsque vous utilisez l'IDE Arduino plutôt que l'IDE (très compliqué) de Microchip. De nombreux rapports font état de problèmes sous Linux pour les programmeurs officiels de Microchip. Il existe deux approches alternatives très peu coûteuses pour créer un programmeur UPDI, avec lesquelles la communauté Arduino a plus d'expérience que les programmeurs officiels.
Avant que megaTinyCore n'existe, il existait un outil appelé pyupdi - un simple programme Python permettant de télécharger sur des microcontrôleurs équipés d'UPDI à l'aide d'un adaptateur série modifié par l'ajout d'une seule résistance. Mais pyupdi n’était pas facilement utilisable depuis l’IDE Arduino, et ce n’était donc pas une option. Depuis la version 2.2.0, megaTinyCore introduit une implémentation Python portable, qui ouvre de nombreuses portes ; A l'origine, nous avions prévu d'adapter pyupdi, mais à la demande de son auteur et de plusieurs employés de Microchip, nous avons plutôt basé cette fonctionnalité sur pymcuprog, un outil "plus robuste" développé et "maintenu par Microchip" qui inclut le même téléchargement de port série. fonctionnalité, uniquement sans les optimisations de performances. Si vous effectuez une installation manuelle, vous devez ajouter le package Python approprié à votre système d'exploitation afin d'utiliser cette méthode de téléchargement (une installation du système Python n'est pas suffisante, ni nécessaire).
Lisez la documentation SerialUPDI pour plus d'informations sur le câblage.
Depuis la version 2.3.2, avec les améliorations spectaculaires des performances et la fiabilité éprouvée du schéma de câblage utilisant une diode au lieu d'une résistance, et à la lumière du caractère instable du micrologiciel jtag2updi, il s'agit désormais de la méthode de programmation recommandée. À partir de cette version, la vitesse de programmation a été augmentée jusqu'à un facteur 20, et dépasse désormais de loin ce qui était possible avec jtag2updi (la programmation via jtag2updi est à peu près comparable en vitesse à la programmation via SerialUPDI sur l'option de vitesse "SLOW", 57600 bauds ; la version normale à 230 400 bauds programme environ trois fois plus rapidement que la version SLOW ou jtag2updi, tandis que l'option "TURBO" (fonctionne à 460 800 bauds et augmente la vitesse de téléchargement d'environ 50 % par rapport à la vitesse normale. La version à vitesse TURBO ne doit être utilisée qu'avec des appareils fonctionnant à 4,5 V ou plus, car nous devons exécuter l'horloge UPDI plus rapidement pour suivre le rythme (ce n'est pas non plus prévu). pour être compatible avec tous les adaptateurs série (il s'agit d'un compromis intentionnel pour des performances améliorées), mais il permet le téléchargement et la vérification d'un croquis de 32 Ko en 4 secondes.
Trois conceptions sont en cours d'itération : un adaptateur série à double port où les deux sont des ports série, un adaptateur série à double port où un port est toujours UPDI, et un port unique avec un commutateur pour sélectionner le mode, et une carte d'extension en option pour donner LED indiquant l'état des lignes de contrôle du modem.
Ceux-ci permettront d'utiliser soit un connecteur SMT JST-XH, soit un connecteur Dupont - dans les deux sens avec 6 broches pour la série (brochage FTDI comme indiqué) et 3 broches (pour UPDI).
Tous les trois pourront fournir 3,3 ou Vusb (nom. 5 V), ou déconnecter à la fois Vusb et 3V3 de l'alimentation, et s'attendre à ce que l'appareil cible soit alimenté avec 5,5 V > Vdd > 1,8 V. Les niveaux logiques utilisés dans ce cas seront la tension de tout ce qui est appliqué. Soyez averti que sur les appareils double série, le rail d'alimentation VccIO est partagé ! Ils doivent tous deux fonctionner à la même tension, être le même appareil, ou l'adaptateur doit être réglé pour les alimenter et leur alimentation doit être déconnectée.
Selon le modèle d'adaptateur et le système d'exploitation, il a été constaté que différents paramètres de synchronisation sont requis ; cependant, les paramètres nécessaires pour empêcher même 230 400 bauds d'échouer sous Linux/Mac avec la plupart des adaptateurs imposent une pénalité de temps beaucoup plus importante sous Windows, où la gestion série du système d'exploitation est suffisamment lente pour que rien n'ait besoin de ce délai...
Le « délai d'écriture » mentionné ici est destiné à permettre à la commande d'effacement-écriture de page de terminer son exécution ; cela prend un temps non nul. En fonction de l'adaptateur, la latence USB et le tampon implicite de 2 ou 3 octets (c'est comme un USART, et probablement implémenté comme un seul en interne. Le troisième octet qui arrive n'a nulle part où aller, car le tampon matériel n'a que 2 octets de profondeur) peuvent être suffisant pour lui permettre de fonctionner sans délai explicite. Ou bien, il peut échouer à mi-chemin et signaler une « Erreur avec st ». Plus le délai d'attente de latence de l'adaptateur est rapide et plus la gestion série du système d'exploitation est rapide, plus le risque que cela pose problème est grand. Ceci est contrôlé par le paramètre de ligne de commande -wd si vous exécutez prog.py manuellement. Depuis la version 2.5.6, ce délai d'écriture est plus proche du temps réel demandé (en ms), auparavant il avait une granularité de plusieurs ms, alors que 1 suffisait, et par conséquent, la pénalité qu'il imposait était brutale , en particulier sur Fenêtres.
Guide de sélection :
460 800 bauds ou plus nécessite que la cible fonctionne à 4,5 V+ pour rester conforme aux spécifications (en pratique, elle n'a probablement pas besoin d'être aussi élevée - mais il doit s'agir d'une tension suffisamment élevée pour être stable à 16 MHz. Nous définissons la horloge de l'interface au maximum pour toutes les vitesses supérieures à 230 400 bauds - alors que quelques adaptateurs fonctionnent parfois à 460 800 bauds sans cette étape (ce qui en soi est étrange - 460 800 bauds). bauds est de 460 800 bauds, n'est-ce pas ?), la plupart ne le font pas et SerialUPDI n'a pas de moyen de déterminer quel est l'adaptateur.
Les adaptateurs basés sur CH340 ont une latence suffisamment élevée sur la plupart des plates-formes et fonctionnent presque toujours à n'importe quelle vitesse sans recourir à un délai d'écriture. Toutes les options fonctionnent sans utiliser le délai d'écriture.
Presque tous les adaptateurs fonctionnent sous Windows à 230,4 Ko sans utiliser le délai d'écriture. Rares sont ceux qui ne le font pas, y compris certains microcontrôleurs USB natifs programmés pour agir comme des adaptateurs série (ex : SAMD11C).
Presque rien, à l'exception des adaptateurs basés sur CH340, ne fonctionnera à 460,8 Ko ou plus sans délai d'écriture, quelle que soit la plate-forme.
Sous Windows, de nombreux adaptateurs (même ceux qui devraient vraiment le prendre en charge) ne parviendront pas à passer à 921 600 bauds. Je ne sais pas pourquoi. Le symptôme est une pause au début de quelques secondes pendant la tentative, suivie d'un téléchargement à 115 200 bauds. Le seul avec lequel j'ai eu du succès jusqu'à présent est le CH340, curieusement.
460 800 bauds sous Windows avec le délai d'écriture est souvent plus lent que 230 400 bauds sans ce délai. La même chose n'est pas vraie sous Linux/Mac, et plus la taille de la page est petite, plus les performances dues au retard d'écriture sont importantes.
57 600 bauds doivent être utilisés si les autres options ne fonctionnent pas ou lors de la programmation à Vcc = < 2,7 V.
460 800 bauds fonctionnent sans délai d'écriture sur certains adaptateurs avec une résistance de 10k placée à travers la diode Schottky entre TX et RX, alors qu'ils ne fonctionnent pas sans cela à moins que le délai d'écriture ne soit activé. Non, je ne comprends pas non plus comment cela pourrait être !
Comme vous pouvez le voir ci-dessus, ces informations sont en grande partie empiriques ; on ne sait pas encore comment prédire ce comportement.
Les adaptateurs FTDI (FT232, FT2232 et FT4232, etc.), y compris les faux qui sont disponibles sur eBay/AliExpress pour environ 2 $, sous Windows ont par défaut une période de latence atrocement longue de 16 ms. Même avec tous les efforts déployés pour limiter le nombre de périodes de latence que nous devons attendre, cela prolongera un téléchargement de 2,2 secondes à plus de 15 secondes. Vous devez modifier cela afin d'obtenir des vitesses de téléchargement tolérables :
Ouvrez le panneau de configuration, le gestionnaire de périphériques.
Développer les ports (COM et LPT)
Faites un clic droit sur le port et choisissez les propriétés
Cliquez sur l'onglet Paramètres du port
Cliquez sur "Avancé..." pour ouvrir la fenêtre des paramètres avancés.
Dans la section "Options BM", recherchez le menu "Latency Timer", qui sera probablement réglé sur 16. Remplacez-le par 1.
Cliquez sur OK pour quitter la fenêtre des options avancées, puis à nouveau pour quitter les propriétés. Vous verrez le gestionnaire de périphériques actualiser la liste du matériel.
Les téléchargements devraient être beaucoup plus rapides maintenant.
L’un peut être fabriqué à partir d’un AVR Uno/Nano/Pro Mini classique ; Les clones Nano bon marché sont le choix habituel, étant suffisamment bon marché pour pouvoir être câblés puis laissés comme ça. Nous ne fournissons plus de documentation détaillée pour ces processus ; jtag2updi est obsolète. Si vous l'utilisez toujours, vous devez sélectionner jtag2updi dans le menu outils->programmeur. C’était auparavant notre option recommandée. En raison des bogues persistants de jtag2updi et de sa dépendance à l'égard de l'outil 'avrdude' en grande partie non maintenu (qui, entre autres, insère un faux message d'erreur dans tous les téléchargements UPDI effectués avec lui), cela n'est plus recommandé.
Apparemment, Arduino ne propose pas de versions 32 bits du dernier avrdude. J'ai défini une nouvelle définition d'outil qui est une copie d'arduino18 (la dernière), sauf qu'elle utilise plutôt la version 17 sur Linux 32 bits, car c'est la meilleure disponible pour cette plate-forme. La version arduino17 ne prend pas correctement en charge le téléchargement avec certains outils de programmation Microchip.
Ceci n'est actuellement utilisé que pour les dernières versions et devrait corriger l'erreur avrdude non disponible pour cette plate-forme.
tinyAVR série 2
ATtiny3227,1627,827,427
ATtiny3226,1626,826,426
ATtiny3224,1624,824,424
tinyAVR série 1
ATtiny3217,1617,817,417
ATtiny3216,1616,816,416
ATtiny1614,814,414,214
ATtiny412 212
tinyAVR série 0
ATtiny1607,807
ATtiny1606,806,406
ATtiny1604,804,404,204
ATtiny402 202
Tout ce qui s'appelle "AVR##XX##" où X est une lettre et # est un chiffre - vous voulez mon DxCore pour ceux-là
Toutes les pièces tinyAVR classiques (avant 2016) - elles sont presque toutes prises en charge par l'un de mes autres cœurs ATTinyCore
ATtiny 25/45/85, 24/44/84, 261/461/861, 48/88, les deux petits et un (étranges 43 et 4313/2313), et en 2.0.0, le 26 ainsi que le final -quatre (qui montrent des allusions à l'expérimentation en direction des AVR modernes), l'ATtiny 441/841, 1634 et 828 plus le encore plus étrange 26.
Tout le reste Consultez ce document pour une liste des familles de pièces AVR et des cœurs Arduino avec lesquels ils fonctionnent - presque tout a un noyau qui offre un support, généralement par moi-même ou par MCUdude.
Voir ce document couvrant tous les AVR modernes
| Fonctionnalité | série 0 | 1-série | 1+série | 2 séries |
|---|---|---|---|---|
| Éclair | 2k-16k | 2k-8k | 16k/32k | 4k-32k |
| Pincount | 8-24 | 8-24 | 14-24 | 14-24 |
| SRAM | 128b-1k | 128b-512b | 2k | 512b-3k |
| TCD | Non | Oui | Oui | Non |
| TCB | 1 | 1 | 2 | 2 |
| CDA | 1x10 bits | 1x10 bits | 2x10 bits | 1x12 bits avec PGA |
| Broche VREF | Non | Non | Oui | Oui |
| CA | 1 | 1 | 3 | 1 |
| Événement * | 3 canaux | 6 canaux | 6 canaux | 6 canaux |
| CCL** | 2LUT | 2LUT | 2LUT | 4LUT |
* Les canaux d'événements, à l'exception des tinyAVR de la série 2 (et de tous les AVR modernes non minuscules), sont subdivisés en deux types : synchrone (à l'horloge système) et asynchrone. Tous les générateurs ne peuvent pas être utilisés avec un canal synchrone, et certains utilisateurs d'événements ne peuvent utiliser que les canaux synchrones, et les listes de canaux sont moins cohérentes et plus nombreuses. Cette folie a été abandonnée à la première occasion – même le méga0 avait supprimé cette distinction.
** Seules les séries 2 et les pièces non minuscules peuvent déclencher une interruption basée sur l'état CCL.
Toutes les pièces ont une entrée analogique disponible sur la plupart des broches (toutes les broches sur PORTA et PORTB 0-1 et 4-5). Le deuxième ADC de la série 1+ peut également utiliser les broches du PORTC comme entrées (voir la référence analogique pour plus d'informations sur leur utilisation).
Ce sont les options budgétaires. Bien qu'ils soient pris en charge, ils ne sont pas recommandés. Ceux-ci n'obtiennent jamais le "boost" que la série tinyAVR 1 obtient à 16k, n'ont pas de deuxième TCB dans aucune configuration, pas de TCD, seulement 3 canaux d'événements, dont aucun ne peut transporter de sortie d'événement RTC. Ces pièces disposent de 2 LUT CCL comme la série 1 et sont disponibles avec jusqu'à 16 Ko de flash dans des configurations à 14, 20 et 24 broches (seulement 4 Ko pour les pièces à 8 broches) et jusqu'à 1 Ko de SRAM.
Ceux-ci ont 2k, 4k ou 8k de flash et 128, 256 ou 512b de RAM, tout comme la série 0. Ils n'ont pas le deuxième ADC, la configuration triple AC ou le deuxième TCB, bien qu'ils aient le TCD.
Tout d'un coup, à 16k, les pièces de la série 1 deviennent bien plus intéressantes. Le flash plus grand est accompagné d'un arsenal de périphériques qui semblent adaptés à une puce beaucoup plus grande, et qu'ils soient 16k ou 32k, ils reçoivent tous 2k de SRAM. Le deuxième ADC est unique parmi les AVR. Il semble avoir été le terrain de test de nombreuses fonctionnalités apparues sous une forme raffinée sur la série AVR Dx. Le prix ne semble pas tenir compte des périphériques largement supérieurs de la série 16k 1,
Comme vous pouvez le voir dans le tableau ci-dessus, la série 2 est presque plus une mise à niveau qu’une mise à niveau. Ils ont un ADC bien meilleur, le système d'évènements et les CCL sont "normaux", et ils ont plus de RAM, la partie 14 broches est disponible avec 32k de flash (un 3214 était apparemment prévu, mais ensuite annulé ; il est allé assez loin pour rester dans l'ATPACK pendant un certain temps avant d'être retiré)
J'ai rédigé un bref résumé indiquant quand vous souhaitez utiliser quelle série, si le bon choix n'est pas évident à ce stade.
Dans la définition officielle de la carte Arduino pour leur package matériel "megaavr", ils impliquent que la nouvelle architecture des pièces megaAVR de la série 0 (qui est presque la même que celle utilisée sur les tinyAVR séries 0 et 1) est appelée "megaavr". " - ce n'est pas un terme officiel. Microchip utilise le terme « megaAVR » pour désigner n'importe quelle pièce « ATmega », qu'elle soit dotée d'un style ancien ou de périphériques modernes. Il n'existe pas de terme officiel pour désigner toutes les parties AVR d'une famille ou d'une autre, et un employé de Microchip a même nié l'existence d'un tel terme en interne. Je ne sais pas comment vous pouvez fabriquer deux ensembles de pièces, les pièces de chaque ensemble ayant tant de points communs les unes avec les autres et si peu de points communs avec l'autre ensemble, sans que personne n'invente une expression pour faire référence à l'un ou l'autre.
Dans ce document, avant la version 2.0.2, nous utilisions la convention Arduino, et bien que plus d'un an se soit écoulé depuis, je continue de trouver des endroits où je les appelle mégaAVR. Veuillez signaler cela en utilisant un problème github si vous en voyez. Notez que les termes avr et megaavr sont toujours utilisés en interne (par exemple, dans les bibliothèques, pour marquer les parties avec lesquelles une bibliothèque donnée est compatible, ou pour séparer les différentes versions d'un fichier en fonction de ce sur quoi elles seront exécutées). Cela va continuer - nous devons nous en tenir à cela pour des raisons de compatibilité avec ce que l'équipe Arduino a commencé avec le noyau de l'Uno WiFi Rev. 2 et du Nano Every.
Quoi qu'il en soit, il faut un mot pour désigner les deux groupes et Microchip n'en a pas fourni. En l'absence de terme officiel, j'ai fait référence aux appareils AVR d'avant 2016 (avec registres PORTx, DDRx, etc. pour les broches) comme " AVR classique " et ceux qu'Arduino appelle megaavr comme " AVR moderne ". Il existe également certaines pièces dont les modules d'E/S ressemblent largement davantage aux AVR classiques, mais qui ont également une version nettement pire du jeu d'instructions et des tailles de flash typiques de 1k ou moins. Ceux-ci utilisent la variante AVRrc (pour noyau réduit) d'AVR, alors que la plupart des AVR classiques utilisent AVRe ou AVRe+, et que les AVR modernes utilisent AVRxt. Les pièces AVRrc ne sont pas supportées par ce noyau, et à la malheureuse occasion où j'aurai besoin de discuter de ces pièces profondément décevantes, je les appellerai pièces " Réduire Core AVR ", car c'est leur nom officiel, même si j'ai beaucoup des phrases plus colorées pour eux. Il est recommandé qu'aucune conception n'utilise un AVR à noyau réduit , point final. Non pas qu’ils soient obsolètes, ils sont juste moche. Il est recommandé d'utiliser les " AVR modernes " (ceux dotés des nouveaux périphériques et du jeu d'instructions AVRxt ) - soit la série Ex, la série Dx, tinyAVR 0/1/2 ou mega0 pour toutes les nouvelles conceptions.
Fiche technique de la nouvelle série tinyAVR 2 - Bien que la fiche technique ne « couvre » que les 16 000 pièces, elle indique clairement qu'il n'y a aucune différence de fonctionnalités entre les pièces ayant le même nombre de broches (c'est-à-dire qu'il n'y a pas de pièces « dorées » comme la 16k/32k 1-Series), uniquement entre les pièces avec un nombre de broches différent, et uniquement comme dicté par le nombre de broches (c'est-à-dire qu'une fonctionnalité sur la partie à 24 broches sera sur celle à 14 broches, à moins que celui à 14 broches n'ait pas les broches dont il a besoin, et c'est quelque chose qui ne peut pas être utilisé sans broches). Les pièces à 14, 20 et 24 broches sont toutes répertoriées avec flash 4k, 8k, 16k et 32k ; ces options de taille de flash, respectivement, sont livrées avec 512, 1024, 2048 et 3072 octets de SRAM (c'est-à-dire que les parties 4k et 8k ont le double de la SRAM), les parties 4/8k reçoivent 128 octets d'EEPROM, les plus grandes en reçoivent 256. Les pièces à 14 broches sont disponibles en SOIC et TSSOP, à 20 broches en SOIC (large), SSOP, et ainsi de suite. un tout petit QFN comme le 1616 (cette fois, ils nous ont également donné la partie 32k dans ce package, mais bonne chance pour en obtenir un, il est en rupture de stock partout - je n'ai pas pu en marquer un seul) et 24 broches dans le même VQFN que le 3217.
TWI, SPI, USART0, AC0 sont inchangés, tout comme NVMCTRL (les modifications requises sur le chargeur de démarrage concernaient uniquement la prise en charge du deuxième USART). Options d'horloge inchangées. TCB0 et TCB1 ont été mis à niveau vers la version de la série Dx : option d'événement d'horloge, cascade et bits INTCTRL séparés pour OVF et CAPT - ajouts intéressants, mais rien de pertinent pour le noyau lui-même), et toutes les parties ont les deux TCB. Nous obtenons maintenant 4 LUT CCL et 2 séquenceurs, au lieu de 2 et 1 - et ils peuvent déclencher des interruptions comme les autres parties avec CCL (et contrairement à la série tinyAVR 0/1). L'une des caractéristiques les plus intéressantes est que, comme prévu, ils disposent d'un deuxième USART (le bruit que vous entendez est celui de l'ATtiny841 et de l'ATtiny1634 qui sanglotent dans le coin). Les registres PORTMUX sont désormais nommés comme le reste des AVR modernes - mais nous n'avons pas perdu le contrôle individuel sur les broches de chaque canal TCA WO. EVSYS fonctionne désormais comme il le fait sur les pièces non minuscules de la série AVR-0/1 (ce qui est un changement bienvenu - la série 0/1 était l'intrus, et certaines des façons dont leur EVSYS était différent étaient nuls ). Les fonctionnalités de la série 1 de TCD0, AC1/2, DAC0 et ADC1 ont disparu . À leur place, l'ADC0 est beaucoup plus sophistiqué et presque méconnaissable, le premier nouvel AVR sorti depuis le rachat et doté d'un véritable ADC différentiel. (faites la queue, un autre gémissement d'agonie du pauvre '841, qui possède également un ADC incroyablement sophistiqué avec d'excellentes options différentielles, mais qui semble complètement daté à côté des nouveaux)... à en juger par le volume de messages sur différents sujets que j'ai Il semble que j'ai le sentiment que l'ADC différentiel n'était pas en tête de la plupart de vos listes de souhaits - mais il figurait en tête des listes des principaux clients de puces, et c'est donc ce que nous obtenons. Et il était presque temps d'obtenir un CAN différentiel approprié au lieu de celui de la série Dx. Et c'est vraiment très chic. Voir ci-dessous.
megaTinyCore fournit une implémentation analogRead() et des fonctions plus puissantes pour utiliser le suréchantillonnage et le PGA (voir la section sur les fonctionnalités analogiques ci-dessous).
Oh, et encore une chose... la configuration des broches UPDI a les anciennes options - UPDI, I/O ou Reset... et une nouvelle : UPDI sur PA0, avec broche matérielle RESET sur PB4 ! Optiboot sera enfin une option viable et confortable au moins sur les pièces dotées d'un PB4, c'est à dire pas sur les pièces à 14 broches. Ce qui se trouve également être (si les ventes de mon magasin Tindie sont une indication) le type le plus populaire.
Pensez-vous qu'il y aura une série 3 ? Non. DD et les EA les poursuivent clairement et prennent des positions stratégiques autour du petit territoire d'AVR. Je pense que ce n'est qu'une question de temps avant que la marque soit éliminée comme ils l'ont fait megaAVR après la série megaAVR 0. Ce n'est pas nécessairement une mauvaise chose : toutes les pièces des séries Dx et EA sont très similaires en termes de mappage de broches et de comportement, ce qui est très agréable. Les Tinies sont moins systématiques, même s'ils distribuent les broches à davantage de périphériques. Le principe directeur semble avoir été "aucun périphérique laissé pour compte". Contraste avec les mappages de broches des séries Dx et EA où tout suit un plan directeur fixe. Les pièces ont ou non une broche donnée, et si ce n'est pas le cas, cette fonction n'est pas disponible. Dans les deux grands groupes, je pense qu'il y a un chef de produit dont le travail consiste à fouetter les ingénieurs qui envisagent de faire une "exception" au Holy Brochage (puisque ces exceptions prolifèrent inévitablement et c'est ainsi que nous nous sommes retrouvés avec les affectations de broches de cible aux yeux bandés sur tinyAVR classique)
La numérotation des broches est étrange sur les tinyAVR, et c'est la faute de Microchip - ils ont étrangement numéroté les broches dans les ports : cela commence dans l'ordre, sauf que PA0 est UPDI et généralement inutilisable, puis les broches de PORTB sont numérotées dans l'ordre inverse, puis PORTC revient à la même numérotation dans le sens inverse des aiguilles d'une montre que PORTA. Donnez-moi une pause ! Puisque la tradition est d'utiliser la broche 0 pour la première broche et que le dernier numéro soit la broche que vous ne pouvez pas utiliser sans définir un fusible qui rend la puce difficile à programmer. J'aurais de loin préféré pouvoir les numéroter dans le sens inverse des aiguilles d'une montre en commençant par A0 sans enfreindre les conventions non écrites du code Arduino. On peut affirmer que j'ai pris une mauvaise décision concernant les mappages de broches - ils auraient peut-être dû commencer par PA0 (inutilisable à moins que le fusible ne soit activé, auquel cas la puce est difficile à programmer) comme broche 0, puis numéroter les broches dans le sens inverse des aiguilles d'une montre. Mais vous ne pourriez toujours pas faire le genre de trucs que vous pourriez faire si tous les ports étaient en ordre, à moins de numéroter les broches PORTB à l'envers. Si vous parvenez à vous débarrasser de l'attente selon laquelle toutes les broches doivent être numérotées dans l'ordre (et à utiliser uniquement la notation PIN_Pxn), des économies significatives pourraient être réalisées.
Je prédis que dans 2 à 4 ans, il y aura un AVR DA, DB, DD. Pièces DU (celle USB), EA et D/E/F jusqu'à un nombre de broches de 8 (ou au moins 14) et pièces à 64 broches avec flash 128k et le nouvel ADC. Et rien d'autre de marque ATtiny. La plus grande question qui reste est peut-être de savoir s'ils vont un jour remplacer l'ATmega2560 par un AVR moderne avec 100 broches au total (dont probablement 80 à 88 sont des E/S) et des options de flash jusqu'à 256 Ko ; Cela présenterait trois problèmes : premièrement, au-delà de 56 broches d'E/S, il n'y a plus de registres VPORT - l'espace d'E/S faible est plein de 28 VPORT et 4 GPIOR. Comment vont-ils gérer les 4 ports supplémentaires ? (sur le 2560, il s'agissait simplement de ports de seconde classe auxquels on accédait plus lentement et qui n'avaient pas d'accès en un seul cycle. J'ai quelques réflexions à ce sujet et sur la faisabilité du peu d'opcodes disponibles dans l'annexe A ici. et deuxièmement, pour violer la barrière des 128k en flash, il faut passer à un compteur de programme 17 bits. Tous les sauts prennent un cycle supplémentaire et tous les retours prennent un cycle supplémentaire. Enfin, si le ratio ram AVR DB a été conservé, cela. "D x Part à 256k de Flash aurait 32k de RAM. Maintenant, rappelez-vous comment progmem fonctionne sur DX - ils ne pourraient pas aller jusqu'à 32. 24k RAM est certainement possible, peut-être même 28, mais à 32k, plus 32k pour Flash mappé, ne laisse aucune place pour les SFR, qui sont dans le même espace d'adressage.
Je vends des planches à cassoires avec le régulateur, l'en-tête Updi et l'en-tête série dans ma boutique Tindie, ainsi que les planches nus. L'achat dans mon magasin aide à soutenir le développement ultérieur au cœur et est un excellent moyen de commencer à utiliser ces nouvelles pièces passionnantes avec Arduino. Les conseils d'attiny1624 sont actuellement disponibles, mais les pièces de 20 et 24 broches ne seront pas vendues en tant que carte assemblée jusqu'à ce qu'une conception de PCB nouvellement révisée ne soit pas de retour de la maison de la carte pour permettre l'autoréglage sur la broche alt-réinitialisation. Il y a aussi une révision du conseil d'administration à 14 broches - pensant que c'était largement cosmétique. Le masque de soudure jaune doit aller, car la lisibilité semblait empirer dans les derniers lots. Les nouvelles panneaux standardisent également un espacement de 0,6 "entre les rangées d'épingles, au lieu de l'espacement actuel de 0,7", vous pourrez donc, par exemple, de mettre en tête de broche usin Utilisez-les avec notre carte de prototypage optimisée pour cet espacement des lignes. Les tableaux de la série 0 assemblés sont interrompus et ne seront pas réapprovisionnés une fois qu'ils se vendent. La même chose se produira pour les pièces de la série 16k 2 une fois les 32k disponibles.
L'ADC sur la série 2 et la série EA est le meilleur ADC qui a été publié sur un AVR dans l'ère AVR moderne. Outre ces deux-là. Les comparaisons les plus proches sont les AVR classiques qui ont obtenu des ADC différentielles avec des fonctionnalités de premier ordre (les T841, MEGA2560 et (étonnamment), le T861 étant les concurrents les plus forts). Bien qu'il ne soit pas capable du gain de 100x et 200x fou dont certaines pièces se sont vantées dans les jours AVR classiques, il ne m'a jamais été clair à quel point ce qui était amplifié était simplement du bruit (compte tenu de mon expérience certes limitée à jouer avec des ADC différentiels Je vais dire "probablement la plupart, et certainement la plupart si vous me permettez de concevoir le matériel, je ne connais pas analogique!"). Ce nouvel ADC est certainement très capable, avec une véritable capacité différentielle (contrairement à la série DA et DB), et qui augmente la tête et les épaules au-dessus de tout ce qui est disponible sur tout autre AVR moderne à ce jour. L'amplificateur de gain programmable est une nouvelle capacité, et il reste à voir quel type d'exploitations de mesures analogiques que les gens sont capables d'en sortir; Il semble certainement prometteur. Il sera particulièrement intéressant de comprendre les différences entre l'utilisation du PGA à 1x gain, vs non utiliser le PGA, et les avantages et les inconvénients de le faire. (Microchip serait bien servi par un document qui a expliqué comment choisir la bonne configuration ADC pour une tâche dans le cas général; j'ai soulevé cette préoccupation avec Microchip et la personne à qui j'ai parlé indiqué que c'était une priorité élevée; pendant que La situation a été considérablement améliorée, il semble toujours que le groupe DOC ait été spécifiquement invité à ne pas faire de recommandations concrètes de toute sorte.
L'ajout d'accumulation de 1024 échantillons à des fins de suréchantillonnage et de décimation est un ajout bienvenu, bien que celle qui risque également sous-estimant l'ampleur et la pertinence de l'erreur de décalage. (Prendre 1024 échantillons (qui ont tous une erreur de décalage donnée), puis décimer la somme pour donner une mesure ADC 17 bits permet d'imaginer facilement que toute erreur serait limitée aux deux bits les plus bas. Mais si l'erreur Était, disons 5 LSB sur une seule mesure, lorsque vous accumulez 1024 échantillons et décime, vous avez une erreur de décalage de 160, il est extrêmement facile de voir cela et de penser qu'il n'est pas du bruit.
La première puce pleine grandeur (non-minuscule) avec le nouvel ADC est disponible dans des packages de 28-48 broches avec jusqu'à 64k flash. Il y avait la spéculation habituelle sur ce qui allait si quelque chose passait de la série 2 à la série EA: il semble que la réponse soit, l'un des boutons confus a été supprimé et le hachage automatique des signes pour les mesures accumulées (
La minuterie de type D est uniquement utilisée pour PWM sur les pièces de la série 1 Pin 124 sur les paramètres PWM par défaut. Sur les pièces plus petites, cela ne nous laisserait pas augmenter le nombre total de broches PWM. Seules les broches WOC et WOD (sur PC0 et PC1 respectivement) n'ont pas déjà de PWM dirigée par TCA. En tant que tel, puisque AnalogWrite () ne prend en charge aucune fonctionnalité qui serait activée en désactivant le mode Split (comme PWM 16 bits) ou amélioré en utilisant la minuterie de type D (comme l'ajustement de la fréquence), ce serait juste pire, car Il faudrait un espace supplémentaire pour stocker la routine pour activer et éteindre PWM à partir de deux types de minuterie, au lieu d'un. Ce n'est pas négligeable sur les plus petites pièces flash; Il est de l'ordre de 600 octets. 150 pour DigitalWrite () et 450 pour analogwrite () Si ceux-ci sont appelés sur une broche PWM TCD. L'optimiseur devrait être en mesure d'optimiser cette partie de ces fonctions dans ce cas, tant que les broches utilisées avec ces fonctions n'incluent aucune broche PWM TCD. Remarque L'optimiseur les considérera indépendamment, c'est-à-dire que DigitalWrite () inclura le code pour désactiver TCD PWM s'il est utilisé avec une broche qui utilise TCD pour PWM, que vous appeliez ou non AnalogWrite () sur cette broche.
Contrairement à presque tous les autres AVR (je peux penser à peut-être 3 exemples, et un seul d'entre eux est un "bonus" pas un "non de channeau"), il existe des fonctionnalités "bonus" supplémentaires basées sur la taille de la taille d'une famille au sein d'une famille . Les versions 16K et 32K (uniquement) ont quelques fonctionnalités supplémentaires (qui ne semblent pas non plus avoir été considérées pour les prix) - ils ont tous 2k de RAM, qu'ils soient 16k ou 32k, ils ont 3 comparateurs analogiques (y compris un mode de fenêtre Option), une seconde - désespérément nécessaire - Tipe de type B - et le plus étrange de tout ce dont ils ont un deuxième ADC, ne différant que dans lesquels les épingles correspondent aux canaux!
Contrairement aux AVR classiques, sur ces parties, le flash est mappé au même espace d'adressage que le reste de la mémoire . Cela signifie que pgm_read_*_near() n'est pas nécessaire pour lire directement à partir de Flash. Pour cette raison, le compilateur met automatiquement toute variable déclarée const dans le progmem et y accéde de manière appropriée - vous n'avez plus besoin de les déclarer explicitement en tant que progmem. Cela inclut les littéraux de cordes cités, de sorte que la macro f () n'est plus nécessaire non plus, mais pour maintenir la compatibilité avec certaines bibliothèques tierces, F () déclare toujours son argument progmem.
Cependant, notez que si vous déclarez explicitement un progmem variable, vous devez toujours utiliser les fonctions pgm_read pour la lire, tout comme sur les AVR classiques. Lorsqu'une variable est déclarée progmem sur des pièces avec un flash mappé de mémoire, le pointeur est décalé (l'adresse est relative au démarrage du flash, pas au début de l'espace d'adressage); Ce même décalage est appliqué lors de l'utilisation des macros pgm_read_*_near() . Notez que déclarer les choses progressives et accéder à pgm_read_*_near des fonctions, bien qu'elle fonctionne bien, est plus lente et gaspille une petite quantité de flash (par rapport à la déclaration simplement des variables const); Il en va de même pour la macro f () avec des chaînes constantes en 2.1.0 et plus tard (pendant une période avant 2.1.0, F() n'a rien fait - mais cela a causé des problèmes pour les bibliothèques tierces). Les auteurs ont soutenu que le problème était avec le noyau, pas la bibliothèque, et mon choix était d'accepter moins d'efficacité ou de refuser à mes utilisateurs l'accès aux bibliothèques populaires). L'utilisation de la macro F() peut être nécessaire pour la compatibilité avec certaines bibliothèques tierces (les cas spécifiques qui ont forcé le retour de F() sur nous n'étaient pas de ce genre - nous avons réellement pu faire de ceux que je connaissais avec le travail avec le F () - Code en ce qui concerne le NOOP, et ils ont pris quelques octets en moins Flash en conséquence).
Les versions automobiles devraient également fonctionner. Vous devez toujours sélectionner les vitesses d'horloge dérivées de 16 MHz sur ces pièces. Ils ne prennent pas en charge le fonctionnement de 20 MHz et les options d'horloge réglées ne doivent pas être utilisées.
Passons maintenant à la bonne partie, où nous pouvons parler de la façon dont tout cela est exposé par le mégatinycore. Nous allons commencer par la façon dont vous devez vous référer aux broches pour de meilleurs résultats, puis passer aux fonctionnalités principales, options de menu, avant de se terminer par une série de liens vers des documents avec plus de détails sur divers sous-systèmes.
La simple question de savoir comment se référer à une broche pour analograread () et digitalread (), en particulier sur le matériel non standard, a été une source persistante de confusion chez les utilisateurs d'Arduino. Je suis à mon avis qu'une grande partie du blâme repose sur les décisions prises par l'équipe Arduino (et auteur de Wiring avant eux) concernant la façon dont les épingles devaient être mentionnées; La désignation de certaines broches en tant que «broches analogiques» amène les gens à penser que ces broches ne peuvent pas être utilisées pour les opérations numériques (elles sont mieux considérées comme des «broches avec entrée analogique» - comme la façon dont il y a des «broches qui peuvent sortir PWM»). Le fait que les épingles aient été traditionnellement renumérotées a encore brouillé l'eau. Pour les pièces AVR classiques non standard, les choses sont souvent encore aggravées par de multiples "mappages de broches" incompatibles créés par divers auteurs au fil des ans pour que la pièce agisse "plus comme une uno" ou à d'autres fins (Atttinyccore est un particulier Match de cette manière, avec certaines pièces ayant trois mappages de broches entièrement différents, dans au moins un cas, l'une des mappages alternatifs est une œuvre d'inspiration diable de Pure Evil, ne nécessitant rien de moins qu'une table de recherche supplémentaire pour convertir les broches analogiques en numérique broches).
Ce noyau utilise un schéma simple pour attribuer les numéros de broches Arduino: les broches sont numérotées à partir de la broche d'E / S la plus proche de VCC en tant que broche 0 et procédant dans le sens antihoraire, en sautant la broche Updi (principalement) non utilisable. La broche UPDI est ensuite attribuée au dernier numéro de broche (comme indiqué ci-dessus, il est possible de lire la broche UPDI (les lectures analogiques et numériques fonctionnent) même si elle n'est pas définie comme GPIO). Nous recommandons cela en dernier recours: la broche UPDI a toujours son pullup activé lorsqu'il n'est pas défini comme une broche GPIO, et un signal qui ressemble trop à la séquence d'activation Updi provoquera un fonctionnement indésirable.
Afin d'éviter toute confusion sur les identités de broches et d'éliminer l'ambiguïté, nous vous recommandons d'utiliser la notation PIN_PXN pour se référer aux épingles, sauf si vous utilisez une carte de développement avec différents nombres ou noms pour les épingles imprimées dessus. Cela maximisera la portabilité de votre code à un autre matériel similaire et facilitera la recherche d'informations sur les épingles que vous utilisez dans les fiches techniques pertinentes, si cela est nécessaire.
Il s'agit du moyen recommandé de se référer aux broches #defines sont également fournies par le formulaire PIN_Pxn , où x est A, B ou C, et n est un nombre 0-7 - (à ne pas confondre avec le Pin_an définit ci-dessous). Ceux-ci se résolvent simplement au numéro de broche numérique de la broche en question - ils ne passent pas par un chemin de code différent ou quoi que ce soit. Cependant, ils ont une utilité particulière dans l'écriture de code qui fonctionne à travers la gamme de produits avec des périphériques liés à certaines épingles (par port), comme la plupart des périphériques. Plusieurs éléments de code de démonstration dans la documentation en profitent. La manipulation directe du port est également possible - et en fait, plusieurs options supplémentaires puissantes sont disponibles pour elle - voir la manipulation directe du port .
PIN_Pxn - pas Pxn , et non PIN_xn - ceux-ci signifient différentes choses!
Lorsqu'un seul numéro est utilisé pour se référer à une broche - dans la documentation ou dans votre code - c'est toujours le "numéro de broche Arduino". Ce sont les nombres de broches indiqués en orange (pour les broches capables d'Analogread ()) et du bleu (pour les broches qui ne le sont pas) sur les graphiques d'épingle. Toutes les autres façons de se référer aux broches sont #définies au numéro de broche Arduino correspondant.
Le noyau fournit également An constantes et PIN_An (où n est un nombre de 0 à 11). Comme pour le noyau officiel, PIN_An est défini comme le numéro de broche numérique de la broche partagée avec le canal analogique n celles-ci se réfèrent aux numéros de canal ADC0. Ce système de dénomination est similaire à ce qui a été utilisé sur de nombreux noyaux AVR classiques , mais ici, ils sont simplement défini comme le numéro de broche Arduino correspondant . Si vous avez besoin d'obtenir le numéro de canal analogique sur une broche numérique, utilisez la macro digitalPinToAnalogInput(pin) - mais vous n'en avez besoin que si vous écrivez une bibliothèque ADC avancée.
Ces pièces (enfin, la série 1/2 au moins - la série 0 était conçue comme une option de budget, sauf qu'elles n'ont pas réussi à réduire le budget, et ce sont seulement quelques cents moins chers) fournissent une excellente boîte à outils de polyvalence et des périphériques puissants; Les haut-parleurs sont à égalité avec ou mieux que les pièces MEGAAVR classiques - à un prix minuscule. L'un des principes directeurs de la conception du mégatinyccore, comme avec mes autres noyaux, est de permettre aux pièces prises en charge d'atteindre leur plein potentiel - ou aussi près que possible dans les limites d'Arduino. Cette section (très grande) couvre les caractéristiques de ces pièces et comment elles sont exposées par le mégatinyccore, ainsi que les caractéristiques du noyau lui-même. Cette (très grande) section tente de couvrir chacune des zones de caractéristiques. Essayez de trouver la fonctionnalité avec laquelle vous travaillez si vous essayez d'utiliser une fonctionnalité de puce et d'avoir des problèmes!
20 MHz interne (4,5 V-5,5 V - typique pour les systèmes 5V)
16 MHz interne (4,5 V-5,5 V - typique pour les systèmes 5V)
10 MHz interne (2,7 V-5,5 V - typique pour les systèmes 3,3 V)
8 MHz interne (2,7 V-5,5 V - typique pour les systèmes 3,3 V)
5 MHz interne (1,8 V-5,5 V)
4 MHz interne (1,8 V-5,5 V)
2 MHz interne (1,8 V-5,5 V, mal testé)
1 MHz interne (1,8 V-5,5 V, mal testé)
Horloge externe de 20 MHz (4,5 V-5,5 V, mal testée)
Horloge externe 16 MHz (4,5 V-5,5 V, mal testée)
Horloge externe de 12 MHz (2,7 V-5,5 V, mal testée)
Horloge externe de 10 MHz (2,7 V-5,5 V, mal testée)
Horloge externe de 8 MHz (2,7 V-5,5 V, mal testée)
6 MHz interne (réglé, non testé)
5 MHz interne (réglé, mal testé)
4 MHz interne (réglé, mal testé)
2 MHz interne (réglé, mal testé)
1 MHz interne (réglé, mal testé))
7 MHz interne (à l'écoute, pour les masochistes, non testés)
8 MHz interne (réglé, mal testé)
10 MHz interne (réglé, mal testé)
12 MHz interne (réglé, non testé)
14 MHz interne (à l'écoute, pour les masochistes, non testés)
16 MHz interne (à l'écoute)
20 MHz interne (à l'écoute)
24 MHz interne (réglé, overclocké, mal testé)
25 MHz interne (réglé, overclocké, mal testé)
30 MHz interne (réglé, overclocké, mal testé) - 0/1 série nécessitent un réglage de fusible OSCCFG "20 MHz"; Les pièces de la série 2 peuvent ou non atteindre 30 avec "16 MHz" sélectionnés.
32 MHz interne (réglé, overclocké, mal testé) - 2-la série uniquement, un overclocking très optimiste, peut être instable.
Horloge externe de 24 MHz (overclocké, mal testé)
Horloge externe de 25 MHz (overclocké, mal testé)
Horloge externe de 30 MHz (overclocké, mal testé)
Horloge externe de 32 MHz (overclocké, mal testé)
Nous ne faisons aucune affirmation sur les gammes de tension ou de température pour les pièces overclockées - tout ce que nous prétendons, c'est qu'au moins un des puces que nous avons travaillé à cette vitesse à température ambiante, exécutant un croquis spécifique, à 5V. Votre kilométrage devrait varier, mais être généralement meilleur avec une pièce F Spec par rapport à une partie N ou U Spec.
IMPORTANT - En savoir sur le réglage avant de sélectionner une option réglée!
Plus d'informations sur ces vitesses d'horloge peuvent être trouvées dans la référence de l'horloge
Les tensions indiquées sont celles garanties pour fonctionner par les spécifications du fabricant ( / La série 1 fonctionnera également généralement à 32 MHz avec une horloge externe à condition que l'alimentation soit un 5,0 à 5,5 V) stable.
Aucune action n'est requise pour définir le fusible OSCCFG lorsque l'esquisse est téléchargée via Updi. Lorsqu'il est téléchargé via Optiboot, le fusible ne peut pas être modifié, donc tout ce qui a été choisi lorsque le chargeur de démarrage a été brûlé est ce qui est utilisé, et seul "Burn Bootloader" ou le téléchargement d'un croquis via Updi changera cela.
Toutes les options de vitesse d'horloge de l'oscillateur interne utilisent l'étalonnage par défaut d'usine, sauf si une option "réglée" est sélectionnée, auquel cas l'étalonnage est ajusté comme documenté dans la référence de réglage . Cela peut être utilisé pour obtenir une opération de 16 MHz sur une puce Optiboot fusionnée pour 20 MHz et vice versa.
Voir la référence de grade de vitesse pour plus d'informations sur les notes de vitesse du fabricant. Notez que ce sont les tensions et les vitesses d'horloge auxquelles il est garanti de fonctionner. Ces pièces sont destinées à être utilisées pour une utilisation dans des applications où un problème inattendu d'une description pourrait poser un danger pour les personnes ou les biens (réflexion, équipement industriel, avions, réacteurs nucléaires - endroits où les gens pourraient mourir si la pièce a mal fonctionné) et I Croyez également pour les applications militaires, qui ont des exigences de fiabilité similaires, juste pour la raison inverse. Les utilisateurs de passe-temps typiques seront beaucoup plus détendus quant au potentiel de problèmes de stabilité, les accidents étant un peu plus qu'une nuisance, et les extrêmes des pièces de la plage de température prolongées dépassant ce dont nous aurions besoin. En supposant que la planche avait un revêtement imperméable, thermiquement, une partie N de grade N devrait pouvoir fonctionner selon le grade de vitesse dans un pot d'eau bouillante. Et c'est juste le n-spécial. Le F-Spec devrait être bon à 125!
Il a été établi que les pièces de température étendues overclockent mieux, ce qui a du sens. Une partie qui est spécifique pour fonctionner à 20 MHz à 125C devrait avoir une meilleure chance de fonctionner à 32 MHz à température ambiante qu'un spécifique pour fonctionner à 20 MHz uniquement à 105C
À partir de la version 2.4.0, nous fournissons désormais une option de "carte microchip officielle". Cela ne fait rien de spécial autre que la définition LED_BUILTIN comme la broche qui a la LED sur cette carte, au lieu de A7, et de définir une macro PIN_BUTTON_BUILTIN définie comme la broche avec le bouton utilisateur dessus et en faisant "télécharger" avec le non -prrogrammer / débogueur à bord utilisez toujours le programmeur / débogueur embarqué; Outils -> Le programmeur sera utilisé uniquement pour "Burn Bootloader" et "Télécharger à l'aide du programmeur". Dans le cas du nano ATtiny416 Xplagé, il sélectionne également la version du chargeur de démarrage qui utilise les broches alternatives pour le port série - il n'utilise pas automatiquement les épingles alternatives pour USART0 comme si vous aviez fait Serial.Swap (1) pourtant pourtant encore - La fonctionnalité pour prendre en charge l'échange par défaut des broches en série sera disponible dans une future mise à jour, parallèlement à d'autres modifications dans la machine sous-jacente au mécanisme PINSWAP qui, espérons-le, réduira également l'utilisation du flash.
Comme indiqué ci-dessus, ceux-ci peuvent ne pas fonctionner correctement sur les plates-formes Linux 32 bits. Ceci est hors de ma volonté; Je ne construit pas de binaires Avrdude AMD Je n'assume pas non plus cette tâche. J'en ai déjà trop.
blink() prend-il plus de flash sur le Mini Xplagé VS le XPlated Pro?Les deux ont le même atttiny817! Comment peuvent-ils être différents?
Pour la même raison que Blink prendra plus de flash si vous le modifiez pour utiliser PIN_PC0 par opposition à PIN_PB4 : PC0, utilisé sur le Mini Xplagé est une broche PWM, tandis que PB4, utilisé par le XPlated Pro ne l'est pas. Puisque c'est la seule broche sur laquelle DigitalWrite () est utilisée, le compilateur est libre d'optimiser tout ce qui n'est pas nécessaire pour DigitalWrite () sur cette broche, y compris la fonctionnalité pour désactiver la sortie PWM sur une broche qui prend en charge PWM . La différence disparaît si DigitalWrite () est également utilisée sur une broche qui prend en charge PWM sur les deux appareils (résultant en le résultat d'utilisation du flash plus élevé) ou si DigitalWrite () est remplacé par DigitalWriteFast (), qui utilisera moins de flash (mais suppose que vous avez gagné 't appelle-t-on sur une broche en sortie PWM).
Chaque fois qu'un programmeur Updi est utilisé pour télécharger du code, toutes les fusibles qui peuvent être définies "en toute sécurité" (comme dans, sans risque de briquement de la carte, ou de briquement si l'on n'a pas accès à un programmeur HV), et qui ont des Les options de configuration intégrées seront définies. Ainsi, sauf lorsqu'il est noté, le comportement correspondra toujours au menu des outils sélectionnés. En résumé, ceux-ci sont gérés comme suit:
WDTCFG will not be changed - it is not configured by megaTinyCore except to reset it to the factory default when doing "burn bootloader".
BODCFG will not be changed - not safe, you could set the BOD level to 4.3 on a 3.3v system, and then it would need to get > 4.3v applied to reprogram it. If it is on the same circuit board as parts that would be damaged, this is a difficult situation to recover from.
OSCCFG will be set
TCD0CFG will not be changed - it is not configured by megaTinyCore except to reset it to the factory default when doing "burn bootloader".
SYSCFG0 will not be changed - not safe
SYSCFG1 will be set
APPEND will not be changed - it is not configured by megaTinyCore. There is insufficient demand to justify the development effort.to make use of this as DxCore does
BOOTEND will be set
LOCKBIT will not be changed - it is not configured by megaTinyCore; supporting the lockbits presents several additional complications, and commercial users with need of this facility are unlikely to be using the Arduino IDE to program production units. BODCFG n'est pas sûr, car le régler sur une tension plus élevée que la carte fonctionne et l'activera "brique" la carte jusqu'à ce qu'une tension de fonctionnement plus élevée puisse être fournie; Cela pourrait être particulièrement gênant s'il est soudé aux mêmes PCB que les appareils qui ne toléreront pas ces tensions.
SYSCFG0 n'est pas sûr car c'est là que la vie RSTPINCFG ; Changer cela peut laisser la carte non programmable, sauf via la programmation HV UPDI, et tout le monde n'a pas de programmeur HV Updi. Dans le futur si / quand un programmeur qui garantit la capacité HV UPDI qui peut être sélectionnée comme programmeur (c'est-à-dire, il devient possible de créer une option d'outils -> programme ce programmeur.
En conséquence en 2.2.0 et ultérieurement, vous n'avez plus besoin de «brûler le chargeur de démarrage» pour basculer entre les vitesses dérivées de 16 MHz et des vitesses dérivées de 20 MHz lors du téléchargement à l'aide de UPDI
Ce noyau utilise toujours l'optimisation du temps de liaison pour réduire l'utilisation du flash - toutes les versions du compilateur qui prennent en charge les pièces TinyAVR 0/1/2 de la série prennent également en charge le LTO, il n'est donc pas nécessaire de le rendre facultatif, comme cela a été fait avec Attinyccore. Ce fut une énorme amélioration de la codédimension lors de l'introduction, généralement de l'ordre de 5 à 20%!
Ces pièces ont toutes un grand nombre d'entrées analogiques - les séries DA et DB ont jusqu'à 22 entrées analogiques, tandis que la série DD a une entrée analogique sur chaque broche qui n'est pas utilisée pour conduire le cristal HF (bien que les broches sur Portc soient Seule pris en charge lorsque MVIO est éteint). Ils peuvent être lus avec analogRead() comme sur un AVR normal, et nous avons par défaut une résolution 10 bits; Vous pouvez passer au 12 bits complet avec analogReadResolution() , et utiliser les fonctions analogiques améliorées pour prendre automatiquement des lectures décimées et décimées pour une résolution plus élevée et pour prendre des mesures différentielles. Il y a 4 références de tension interne dans 1.024, 2.048, 4.096 et 2,5 V, plus la prise en charge de la tension de référence externe (et du VDD bien sûr). Les lectures ADC sont prises 3 fois plus rapidement qu'un AVR classique, et cette vitesse peut être doublée à nouveau si ce que vous mesurez est une faible impédance ou prolongez le temps d'échantillonnage d'un facteur considérablement pour lire des sources d'impédance très élevées. Ceci est détaillé dans la référence analogique.
Les pièces de la série DX ont un DAC 10 bits qui peut générer une véritable tension analogique (notez que cela fournit un courant faible et ne peut être utilisé que comme une tension de référence de tension ou une tension de commande, elle ne peut pas être
