megaTinyCore
2.6.10 - Critical Bugfix
Ahora tenemos una sección de Discusiones de Github. Cuando un problema es definitivamente un defecto en el núcleo, reducirá el tiempo necesario para solucionarlo si crea un problema, ya que priorizo los problemas antes que ponerse al día con las discusiones.
Esto corrige muchos de los errores presentes en 2.6.x.
2.6.x introduce una huella flash mejorada significativamente en serie al mismo tiempo que agrega funciones, el cable puede despertar al esclavo del modo de suspensión sin dañar los datos y mucho, mucho más, consulte el Registro de cambios.
Sólo se deben utilizar versiones del IDE de Arduino descargadas desde arduino.cc, NUNCA desde un administrador de paquetes de Linux. Los administradores de paquetes a menudo tienen el IDE de Arduino, pero lo han modificado . Esto es a pesar de que no saben nada sobre Arduino o el desarrollo integrado en general, y mucho menos lo que necesitarían saber para modificarlo con éxito. Esas versiones son conocidas por los problemas sutiles pero graves causados por estas modificaciones imprudentes. No se debe esperar que este núcleo funcione en dichas versiones, y no se realizarán modificaciones para corregir las versiones del IDE que provienen de los administradores de paquetes por este motivo.
Este es un error en el cliente Arduino.
Las versiones de IDE entre 1.8.13 y 2.x desarrollaron defectos novedosos importantes. Sin embargo, las versiones 1.8.2 y anteriores del IDE poseen defectos devastadores no solucionados. Creo que finalmente tienen una versión funcional del IDE y creo que la última versión puede instalar mi núcleo correctamente.
Antes de megaTinyCore 2.6.0, la instalación manual de megaTinyCore causaba que la V1.8.14 del IDE fallara debido a este error cuando instala el núcleo manualmente en su carpeta arduino. Los usuarios de 1.8.14 y posteriores deben usar la versión 2.6.0 de megaTinyCore.
Compro muchos productos electrónicos en AliExpress. Es un gran mercado para cosas fabricadas por empresas chinas y en su mayoría genéricas, incluidos muchos componentes que no están disponibles para las personas en el Occidente global de ninguna otra manera (por ejemplo, el pedido mínimo es un carrete o algo así, si es que puedes encontrar un proveedor de componentes que trabaja con el fabricante chino de chips sin nombre). No es un buen lugar para las últimas líneas de productos semiconductores de los principales fabricantes occidentales, especialmente en medio de una escasez histórica de dichos chips. Con frecuencia se informa que los dispositivos AVR modernos, cuando están disponibles a través de esos canales, son falsos o defectuosos (como los ATtiny412 que piensan que son 416 y es posible que no ejecuten correctamente el encendido al reiniciar). De hecho, probablemente no quieras comprar ningún microcontrolador AVR en AliExpress ... Las placas ensambladas, como los clones de Arduino Nano, generalmente funcionan si evitas las que tienen chips LGT8 de terceros y ten cuidado con las que tienen ATmega168p. en lugar del '328p, pero hay muchos informes de microcontroladores falsos cuando se venden como chips básicos (he oído hablar de ATtiny85 falsos que en realidad fueron comentados ATtiny13s; no son sólo los AVR modernos los que se falsifican). Hay muchas teorías interesantes sobre el origen de esos chips falsos, y Microchip ha guardado silencio total sobre el tema.
Este documento se ve mejor en línea (en lugar de abrir el archivo de rebajas en su editor de texto favorito), para que se pueda hacer clic en los enlaces y se muestren las imágenes en línea, y probablemente lo más importante, para que a veces las tablas se representen correctamente. Nuevamente, este [documento se puede encontrar en github](https://github.com/SpenceKonde/megaTinyCore](https://github.com/SpenceKonde/megaTinyCore)
Las versiones anteriores no manejan adecuadamente a los programadores en el menú herramientas -> programadores, lo que degrada la UX rápidamente a medida que aumenta la cantidad de núcleos instalados. No son adecuados. Las versiones más recientes que comienzan con 1.8.14 (incluidas 1.8.17, 1.8.18 y 1.8.19) pueden generar un error de "pánico: no se encontró una versión principal" porque no analizan correctamente el archivo platform.txt. Desde 2.6.0 hemos estado modificando manualmente el archivo platform.txt directamente antes del lanzamiento, por lo que esto es un problema menor.
Cuando megaTinyCore se instala a través del administrador de placa, la versión requerida de la cadena de herramientas se instala automáticamente. Todas las piezas de la serie 0/1/2 son compatibles sin pasos adicionales. Hasta 2.2.7, usamos la versión Arduino7 de avr-gcc (gcc 7.3.0 y avrlibc 3.6.1) con los últimos ATpacks a partir de junio de 2020. A partir de 2.2.7, comenzamos a usar mi compilación Azduino de la cadena de herramientas, que ha actualizado ATpacks para todas las piezas recientemente compatibles. 2.2.7 usó Azduino3, 2.3.0+ usó Azduino4 y, a partir de 2.6.0, usamos Azduino5 (aunque no nos ofrece ningún beneficio, aparte de ahorrar un cuarto de GB de espacio en el disco duro y 40 MB de ancho de banda de descarga si instala ambos). megaTinyCore y DxCore a través del administrador de la junta.
La instalación manual es más complicada, especialmente si desea compatibilidad con la Serie 2; consulte la guía de instalación para obtener más información.
Un núcleo Arduino para tinyAVR Serie 0, Serie 1 y ahora Serie 2. Estas partes tienen una arquitectura mejorada en comparación con las partes "clásicas" de tinyAVR (que son compatibles con ATTinyCore), con periféricos mejorados y tiempo de ejecución mejorado para ciertas instrucciones (éstas son similares en ambos aspectos a la avanzada AVR Dx-Series, así como Chips megaAVR 0-Series como el ATmega4809 tal como se usa en el Nano Every y Uno Wifi Rev. 2 oficial (aunque el equipo de Arduino ha hecho todo lo posible para derrotarlos) en los paquetes pequeños y de bajo costo típicos. de la línea ATtiny. Todas estas piezas cuentan con al menos un UART de hardware y una interfaz SPI y TWI (nada de esa basura USI como, por ejemplo, el ATtiny85), un potente sistema de eventos, lógica personalizada configurable, al menos un comparador analógico en chip. , un oscilador interno sorprendentemente preciso y, en el caso de la Serie 1, un canal de salida DAC real y, en el caso de la Serie 2, un elegante ADC diferencial.
Además, las piezas de la serie tinyAVR 0/1/2 son baratas : las piezas de gama alta, el 3226 y el 3227, con 32k de flash y 3k de SRAM (frente a los 2k SRAM del ATmega328p utilizado en Uno/Nano/ProMini). poco más de $1 USD en cantidad, menos que muchas piezas AVR ATtiny clásicas de 8k ("conjunto de instrucciones AVR, a precio PIC"). Todas estas piezas están clasificadas para funcionar a 16 MHz o 20 MHz (a 4,5-5,5 V) sin un cristal externo, y el oscilador interno es lo suficientemente preciso para la comunicación UART.
Estos utilizan programación UPDI, no ISP tradicional como lo hacían las piezas clásicas de ATtiny. Consulte a continuación para obtener más información. Obtener un programador UPDI es simple: puede usar un Arduino clásico basado en 328p como programador usando jtag2updi, o para obtener mejores resultados con hardware más económico, puede usar cualquier adaptador serie USB y una resistencia (y preferiblemente un diodo) usando el SerialUPDI incluido. herramienta, o puede usar AVRdude con uno de los programadores de Microchip (los programadores basados en mEDBG/nEDBG/EDBG en su placa de desarrollo, Atmel-ICE o SNAP) o cualquier herramienta de programación UPDI que emule una de esas (que, que yo sepa, todas lo hacen; si hay una que avrdude admite y que mi núcleo no, ¡abra un problema para hacérmelo saber!).
Un gestor de arranque en serie, Optiboot_x (basado en el mismo código base que el gestor de arranque Arduino Uno clásico, aunque muy modificado) es compatible con estas partes (el soporte de la Serie 0/1 está actualmente activo, se espera la Serie 2 para la primera semana de mayo). ; los ajustes para las piezas nuevas son triviales), lo que permite programarlas a través de un puerto serie tradicional. Consulte la sección Optiboot a continuación para obtener más información sobre esto y las opciones relevantes. La instalación del gestor de arranque requiere un programador UPDI. Las placas de conexión ensambladas que vendo en Tindie están disponibles precargadas (se cargan bajo demanda). Dicho esto, la experiencia del usuario con Optiboot es un poco decepcionante en las piezas de la serie 0/1, así como en las piezas de la serie 2 de 14 pines, debido a la falta de un pin de reinicio de hardware que pueda usarse con el circuito de reinicio automático habitual. para restablecerse automáticamente en el gestor de arranque cuando se abre el puerto serie. Debe deshabilitar completamente la programación UPDI (se requiere un programador HV si es necesario cambiar la configuración de los fusibles o el cargador de arranque después del arranque inicial) o dejar UPDI habilitado, pero iniciar cualquier carga dentro de los 8 segundos de aplicar energía. Las piezas de la Serie 2 de 20 y 24 pines admiten un "pin de reinicio alternativo" que les permite actuar más como un Arduino tradicional.
La interfaz de programación UPDI es una interfaz de un solo cable para programación (y depuración - Interfaz universal de programación y depuración ), que se utiliza en la serie tinyAVR 0/1/2, así como en todos los demás microcontroladores AVR modernos. . Si bien siempre se puede comprar un programador UPDI específico de Microchip, esto no se recomienda cuando se va a utilizar el IDE de Arduino en lugar del IDE (terriblemente complicado) de Microchip. Hay numerosos informes de problemas en Linux para los programadores oficiales de Microchip. Hay dos enfoques alternativos de muy bajo costo para crear un programador UPDI, y en ambos la comunidad Arduino tiene más experiencia que los programadores oficiales.
Antes de que existiera megaTinyCore, existía una herramienta llamada pyupdi, un programa Python simple para cargar microcontroladores equipados con UPDI utilizando un adaptador en serie modificado mediante la adición de una sola resistencia. Pero pyupdi no se podía utilizar fácilmente desde el IDE de Arduino, por lo que esta no era una opción. A partir de la versión 2.2.0, megaTinyCore incorpora una implementación portátil de Python, que abre muchas puertas; Originalmente estábamos planeando adaptar pyupdi, pero a instancias de su autor y varios empleados de Microchip, hemos basado esta funcionalidad en pymcuprog, una herramienta "más robusta" desarrollada y "mantenida por Microchip" que incluye la misma carga de puerto serie. característica, solo que sin las optimizaciones de rendimiento. Si realiza la instalación manualmente, debe agregar el paquete Python apropiado para su sistema operativo para poder utilizar este método de carga (una instalación del sistema Python no es suficiente ni necesaria).
Lea la documentación de SerialUPDI para obtener información sobre el cableado.
A partir de 2.3.2, con las espectaculares mejoras en el rendimiento y la confiabilidad comprobada del esquema de cableado que utiliza un diodo en lugar de una resistencia, y en vista de la debilidad del firmware jtag2updi, este es ahora el método de programación recomendado. A partir de esta versión, la velocidad de programación se ha incrementado hasta en un factor de 20 y ahora supera con creces lo que era posible con jtag2updi (la programación a través de jtag2updi es aproximadamente comparable en velocidad a la programación a través de SerialUPDI en la opción de velocidad "LENTA", 57600 baudios; la versión normal de 230400 baudios se programa aproximadamente tres veces más rápido que la versión LENTA o jtag2updi, mientras que la opción "TURBO" (se ejecuta a 460800 baudios y aumenta la velocidad de carga en aproximadamente un 50% con respecto a la normal. La versión de velocidad TURBO solo debe usarse con dispositivos que funcionen a 4.5v o más, ya que tenemos que ejecutar el reloj UPDI más rápido para mantener el ritmo (tampoco es lo esperado). para ser compatible con todos los adaptadores serie (ésta es una compensación intencional para mejorar el rendimiento), pero permite cargar y verificar un boceto de 32 kB en 4 segundos.
Se están iterando tres diseños: un adaptador serial de doble puerto donde ambos son puertos seriales, un adaptador serial de doble puerto donde un puerto es siempre UPDI y un puerto único con un interruptor para seleccionar el modo y una placa adicional opcional para proporcionar Leds indicadores del estado de las líneas de control del módem.
Estos permitirán el uso de un conector SMT JST-XH o un conector Dupont, de cualquier manera con 6 pines para serie (distribución de pines FTDI como está marcado) y 3 pines (para UPDI).
Los tres podrán suministrar 3.3 o Vusb (nom. 5V), o desconectar tanto Vusb como 3V3 de la alimentación, y esperar que el dispositivo de destino reciba alimentación con 5.5V > Vdd > 1.8V. Los niveles lógicos utilizados en este caso serán el voltaje de lo que se aplique. ¡Tenga en cuenta que en dispositivos seriales duales, el riel de alimentación VccIO se comparte! Ambos deben estar funcionando al mismo voltaje, ser el mismo dispositivo o el adaptador debe estar configurado para alimentarlos y desconectar su alimentación.
Según el modelo del adaptador y el sistema operativo, se ha descubierto que se requieren diferentes configuraciones de sincronización; sin embargo, las configuraciones necesarias para evitar que incluso 230400 baudios fallen en Linux/Mac con la mayoría de los adaptadores imponen una penalización de tiempo mucho mayor en Windows, donde el manejo en serie del sistema operativo es lo suficientemente lento como para que nada necesite ese retraso...
El "retraso de escritura" mencionado aquí es para permitir que el comando de borrado y escritura de página termine de ejecutarse; esto lleva un tiempo distinto de cero. Dependiendo del adaptador, la latencia USB y el buffer implícito de 2 o 3 bytes (es como un USART, y probablemente implementado como tal internamente. El tercer byte que llega no tiene adónde ir, porque el buffer de hardware tiene solo 2 bytes de profundidad) puede ser suficiente para permitirle funcionar sin un retraso explícito. O puede fallar a la mitad e informar un "Error con st". Cuanto más rápido sea el tiempo de espera de latencia del adaptador y cuanto más rápido sea el manejo de serie del sistema operativo, mayores serán las posibilidades de que esto sea un problema. Esto está controlado por el parámetro de línea de comando -wd si se ejecuta prog.py manualmente. A partir de 2.5.6, este retraso de escritura está más cerca del tiempo real solicitado (en ms), anteriormente tenía una granularidad de varios ms, cuando 1 es todo lo que necesitaba y, como resultado, la penalización que impuso fue brutal , particularmente en Ventanas.
Guía de selección:
460800+ baudios requiere que el objetivo esté funcionando a 4,5 V+ para permanecer dentro de las especificaciones (en la práctica, probablemente no necesite ser tan alto, pero debe tener un voltaje lo suficientemente alto como para ser estable a 16 MHz. Configuramos el reloj de interfaz al máximo para todas las velocidades superiores a 230400 baudios, mientras que algunos adaptadores a veces funcionan a 460800 sin este paso (lo cual en sí mismo es extraño: 460800 baudios es 460800 baudios, ¿verdad?), la mayoría no lo hace y SerialUPDI no tiene una forma de determinar cuál es el adaptador.
Los adaptadores basados en CH340 tienen una latencia suficientemente alta en la mayoría de las plataformas y casi siempre funcionan a cualquier velocidad sin recurrir al retraso de escritura. Todas las opciones funcionan sin utilizar el retraso de escritura.
Casi todos los adaptadores funcionan en Windows a 230,4k sin utilizar el retraso de escritura. Unos pocos no lo hacen, incluidos algunos microcontroladores USB nativos programados para actuar como adaptadores en serie (por ejemplo, SAMD11C).
Casi nada, excepto los adaptadores basados en CH340, funcionará a 460,8 k o más sin retraso de escritura, independientemente de la plataforma.
En Windows, muchos adaptadores (incluso aquellos que realmente deberían admitirlo) no tendrán éxito al cambiar a 921600 baudios. Yo no sé por qué. El síntoma es una pausa al comienzo de unos segundos mientras lo intenta, seguida de una carga a 115200 baudios. El único con el que he tenido éxito hasta ahora es el CH340, por extraño que parezca.
460800 baudios en Windows con retraso de escritura suelen ser más lentos que 230400 baudios sin él. No ocurre lo mismo en Linux/Mac, y cuanto menor sea el tamaño de la página, mayor será el rendimiento afectado por el retraso de escritura.
Se deben usar 57600 baudios si otras opciones no funcionan o cuando se programa en Vcc = < 2,7 V.
460800 baudios funciona sin retraso de escritura en algunos adaptadores con una resistencia de 10 k colocada en el diodo Schottky entre TX y RX, cuando no funciona sin eso a menos que el retraso de escritura esté habilitado. ¡No, yo tampoco entiendo cómo puede ser esto!
Como puede verse en lo anterior, esta información es en gran medida empírica; aún no se sabe cómo predecir el comportamiento.
Los adaptadores FTDI (FT232, FT2232 y FT4232, etc.), incluidos los falsos que están disponibles en eBay/AliExpress por alrededor de $2, en Windows tienen por defecto un período de latencia insoportablemente largo de 16 ms. Incluso con los esfuerzos que hacemos para limitar la cantidad de períodos de retraso de latencia que debemos esperar, esto prolongará una carga de 2,2 segundos a más de 15 segundos. Debes cambiar esto para obtener velocidades de carga tolerables:
Abra el panel de control, administrador de dispositivos.
Ampliar puertos (COM y LPT)
Haga clic derecho en el puerto y elija propiedades
Haga clic en la pestaña Configuración de puerto
Haga clic en "Avanzado..." para abrir la ventana de configuración avanzada.
En la sección "Opciones de BM", busque el menú "Temporizador de latencia", que probablemente estará configurado en 16. Cámbielo a 1.
Haga clic en Aceptar para salir de la ventana de opciones avanzadas y nuevamente para salir de propiedades. Verá que el administrador de dispositivos actualiza la lista de hardware.
Las cargas deberían ser mucho más rápidas ahora.
Se puede fabricar uno a partir de un AVR Uno/Nano/Pro Mini clásico; Los nanoclones económicos son la opción habitual, ya que son lo suficientemente baratos como para conectarlos y dejarlos así. Ya no proporcionamos documentación detallada para estos procesos; jtag2updi está en desuso. Si todavía lo está usando, debe seleccionar jtag2updi en el menú herramientas->programador. Esta era anteriormente nuestra opción recomendada. Debido a los persistentes errores de jtag2updi y su dependencia de la herramienta 'avrdude', que en gran medida no se mantiene (que, entre otras cosas, inserta un mensaje de error falso en todas las cargas de UPDI realizadas con ella), esto ya no se recomienda.
Aparentemente Arduino no incluye versiones de 32 bits del último avrdude. Definí una nueva definición de herramienta que es una copia de arduino18 (la última), excepto que incorpora la versión 17 en Linux de 32 bits, ya que es la mejor disponible para esa plataforma. La versión arduino17 no admite correctamente la carga con algunas de las herramientas de programación de Microchip.
Actualmente, esto se usa solo para las últimas versiones y debería corregir el error avrdude no disponible para esta plataforma.
TinyAVR Serie 2
ATtiny3227,1627,827,427
ATtiny3226,1626,826,426
ATtiny3224,1624,824,424
TinyAVR Serie 1
ATtiny3217,1617,817,417
ATtiny3216,1616,816,416
ATtiny1614,814,414,214
ATtiny412,212
TinyAVR Serie 0
ATtiny1607,807
ATtiny1606.806.406
ATtiny1604,804,404,204
ATtiny402,202
Cualquier cosa llamada "AVR##XX##" donde X es una letra y # es un número; quieres mi DxCore para eso.
Todas las partes clásicas (anteriores a 2016) de tinyAVR; casi todas son compatibles con uno de mis otros núcleos, ATTinyCore.
ATtiny 25/45/85, 24/44/84, 261/461/861, 48/88, los dos pequeños y unos (extraños 43 y 4313/2313), y en 2.0.0, el 26 así como el final -cuatro (que muestran indicios de experimentación en la dirección de los AVR modernos), el ATtiny 441/841, 1634 y 828 más el aún más extraño 26.
Cualquier otra cosa Consulte este documento para obtener una lista de familias de piezas AVR y con qué núcleos arduino funcionan ; casi todo tiene un núcleo que ofrece soporte, generalmente por mí o por MCUdude.
Consulte este documento que cubre todos los AVR modernos.
| Característica | serie 0 | 1-serie | 1+serie | 2 series |
|---|---|---|---|---|
| Destello | 2k-16k | 2k-8k | 16k/32k | 4k-32k |
| cuenta | 8-24 | 8-24 | 14-24 | 14-24 |
| SRAM | 128b-1k | 128b-512b | 2k | 512b-3k |
| DCT | No | Sí | Sí | No |
| TCB | 1 | 1 | 2 | 2 |
| CAD | 1x10 bits | 1x10 bits | 2x10 bits | 1x12 bits con PGA |
| pasador VREF | No | No | Sí | Sí |
| C.A. | 1 | 1 | 3 | 1 |
| Evento * | 3 canales | 6 canales | 6 canales | 6 canales |
| CCCL ** | 2 LUT | 2 LUT | 2 LUT | 4 LUT |
* Los canales de eventos, excepto en los tinyAVR de la serie 2 (y todos los AVR modernos que no son minúsculos), se subdividen en dos tipos: sincrónicos (con el reloj del sistema) y asíncronos. No todos los generadores se pueden usar con un canal sincrónico y algunos usuarios de eventos solo pueden usar los canales sincrónicos, y las listas de canales son menos consistentes y más. Esta locura fue abandonada a la primera oportunidad; incluso el mega0 había eliminado esa distinción.
** Solo las piezas de 2 series y que no sean pequeñas pueden activar una interrupción según el estado de CCL.
Todas las piezas tienen entrada analógica disponible en la mayoría de los pines (todos los pines en PORTA y PORTB 0-1 y 4-5). El segundo ADC en la serie 1+ también puede usar los pines de PORTC como entradas (consulte la referencia analógica para obtener información sobre su uso).
Estas son las opciones de presupuesto. Aunque son compatibles, no se recomiendan. Estos nunca obtienen el "impulso" que obtiene la serie tinyAVR 1 a 16k, no tienen un segundo TCB en ninguna configuración, ni TCD, solo 3 canales de eventos, ninguno de los cuales puede transportar salida de eventos RTC. Estas piezas tienen 2 CCL LUT como la serie 1 y están disponibles con hasta 16k de flash en configuraciones de 14, 20 y 24 pines (solo 4k para piezas de 8 pines) y hasta 1k SRAM.
Estos tienen 2k, 4k u 8k de flash y 128, 256 o 512b de ram, al igual que la serie 0. No tienen el segundo ADC, la configuración triple AC ni el segundo TCB, aunque sí tienen el TCD.
De repente, a 16k, las partes de la serie 1 se vuelven mucho más interesantes. Acompañando al flash más grande hay un arsenal de periféricos que parecen adecuados para un chip mucho más grande, y ya sean 16k o 32k, todos obtienen 2k de SRAM. Todo el segundo ADC es único entre los AVR. Parece haber sido el campo de pruebas para muchas funciones que aparecieron de forma refinada en la serie AVR Dx. El precio no parece tener en cuenta los periféricos muy superiores de la serie 1 de 16k,
Como puede ver en la tabla anterior, la Serie 2 es casi más una versión secundaria que una actualización. Tienen un ADC mucho mejor, el sistema de eventos y los CCL son "normales" y tienen más RAM, la parte de 14 pines está disponible con 32k de flash (aparentemente se planeó un 3214, pero luego se canceló; llegó lo suficientemente lejos como para estar en el ATPACK por un tiempo antes de ser eliminado)
He escrito un breve resumen de cuándo le gustaría usar qué serie, si la elección correcta no es obvia a estas alturas.
En la definición oficial de la placa Arduino para su paquete de hardware "megaavr", implican que la nueva arquitectura en las piezas megaAVR 0-Series (que es casi la misma que se usa en tinyAVR 0-Series y 1-Series) se llama "megaavr". " - ese no es un término oficial. Microchip utiliza el término "megaAVR" para referirse a cualquier pieza "ATmega", ya sea que tenga periféricos de estilo antiguo o modernos. No existen términos oficiales para referirse a todas las partes de AVR de una familia u otra, y un empleado de Microchip incluso negó que existiera tal término internamente. No estoy seguro de cómo se pueden fabricar dos conjuntos de piezas, teniendo las piezas de cada conjunto tanto en común entre sí y tan poco en común con el otro conjunto, sin que nadie acuñe una frase para referirse a cualquiera de ellas.
En este documento, antes de la versión 2.0.2, utilizamos la convención Arduino y, a pesar de que ha pasado más de un año desde entonces, sigo encontrando lugares donde los llamo megaAVR. Informe esto usando un problema de github si ve alguno. Tenga en cuenta que los términos avr y megaavr todavía se usan internamente (por ejemplo, en bibliotecas, para marcar con qué partes es compatible una biblioteca determinada, o para separar diferentes versiones de un archivo según en qué se ejecutarán). Esto continuará; tenemos que seguir con esto por compatibilidad con lo que el equipo Arduino comenzó con el núcleo de Uno WiFi Rev. 2 y Nano Every.
En cualquier caso, se necesita alguna palabra para referirse a los dos grupos y Microchip no la ha proporcionado. En ausencia de un término oficial, me he estado refiriendo a los dispositivos AVR anteriores a 2016 (con registros PORTx, DDRx, etc. para pines) como " AVR clásico " y a los que Arduino llama megaavr como " AVR moderno ". También existen algunas partes cuyos módulos de E/S se parecen más a los AVR clásicos, pero que también tienen una versión significativamente peor del conjunto de instrucciones y tamaños de flash típicos de 1k o menos. Estos usan la variante AVRrc (para núcleo reducido) de AVR, mientras que la mayoría de los AVR clásicos usan AVRe o AVRe+, y los AVR modernos usan AVRxt. Las partes de AVRrc no son compatibles con este núcleo, y en la desafortunada ocasión en que necesite discutir estas partes profundamente decepcionantes, me referiré a ellas como partes de " Núcleo reducido AVR ", ya que ese es su nombre oficial, aunque tengo mucho frases más coloridas para ellos. Se recomienda que ningún diseño utilice un AVR de núcleo reducido , punto. No es que estén obsoletos, simplemente son pésimos. Se recomienda que los " AVR modernos " (aquellos con los nuevos periféricos y el conjunto de instrucciones AVRxt ), ya sea la serie Ex, la serie Dx, tinyAVR 0/1/2 o mega0, se utilicen para todos los diseños nuevos.
Hoja de datos para la nueva serie tinyAVR 2: si bien la hoja de datos solo "cubre" las 16k piezas, establece claramente que no hay diferencias en las características entre piezas con el mismo número de pines (es decir, no hay piezas "doradas" como la 16k/32k Serie 1), solo entre piezas con diferentes números de pines, y solo según lo dicte el número de pines (es decir, una característica en la parte de 24 pines estará en la de 14 pines, a menos que el Uno de 14 pines no tiene los pines que necesita y es algo que no se puede usar sin pines). Las piezas de 14, 20 y 24 pines se enumeran con flash de 4k, 8k, 16k y 32k; Estas opciones de tamaño de flash, respectivamente, vienen con 512, 1024, 2048 y 3072 bytes de SRAM (es decir, las partes de 4k y 8k tienen el doble de SRAM), las partes de 4/8k obtienen 128 bytes de EEPROM, las más grandes obtienen 256 Las piezas de 14 pines vienen en SOIC y TSSOP, las de 20 pines en SOIC (ancho), SSOP y eso. QFN diminuto como el 1616 (esta vez también nos dieron la parte de 32k en ese paquete, pero buena suerte para conseguir uno, está pendiente de entrega en todas partes; no pude conseguir ni uno solo) y 24 pines en el mismo VQFN que el 3217.
TWI, SPI, USART0, AC0 no han cambiado, al igual que NVMCTRL (los cambios requeridos en el gestor de arranque estaban únicamente en relación con la compatibilidad con el segundo USART). Opciones de reloj sin cambios. TCB0 y TCB1 se actualizaron a la versión de la serie Dx: opción de evento de desconexión, cascada y bits INTCTRL separados para OVF y CAPT (buenas adiciones, pero nada relevante para el núcleo en sí), y todas las piezas tienen ambos TCB. Ahora tenemos 4 LUT CCL y 2 secuenciadores, en lugar de 2 y 1, y pueden disparar interrupciones como otras partes con CCL (y a diferencia de la serie tinyAVR 0/1). Una de las características más interesantes es que, como era de esperar, tienen un segundo USART (ese ruido que escuchas es el del ATtiny841 y el ATtiny1634 sollozando en la esquina). Los registros PORTUX ahora tienen el mismo nombre que el resto de los AVR modernos, pero no perdimos el control individual sobre los pines de cada canal TCA WO. EVSYS ahora funciona como lo hace en piezas que no son de la serie tinyAVR-0/1 (lo cual es un cambio bienvenido: la serie 0/1 era la extraña, y algunas de las formas en que su EVSYS era diferente apestaron ). Las funciones de la Serie 1 de TCD0, AC1/2, DAC0 y ADC1 desaparecieron . En su lugar, ADC0 es mucho más elegante y casi irreconocible, el primer AVR nuevo lanzado desde la compra que presentaba un ADC diferencial real. (otro gemido agonizante del pobre '841, que también tiene un ADC increíblemente elegante con excelentes opciones diferenciales, pero que parece completamente anticuado al lado de los nuevos)... a juzgar por el volumen de publicaciones sobre diferentes temas que he Parece que tengo la sensación de que el ADC diferencial no estaba en la parte superior de la mayoría de sus listas de deseos, pero sí en la parte superior de las listas de los principales clientes de chips, y eso es lo que estamos obteniendo. Y ya era hora de que tuviéramos un ADC diferencial adecuado en lugar del de la serie Dx. Y es realmente muy elegante. Vea abajo.
megaTinyCore proporciona una implementación analogRead() y funciones más potentes para usar el sobremuestreo y PGA (consulte la sección de funciones analógicas a continuación).
Ah, y una cosa más... la configuración del pin UPDI tiene las opciones antiguas: UPDI, E/S o Reset... y una nueva: UPDI en PA0, con pin RESET de hardware en PB4. Optiboot finalmente será una opción viable y cómoda al menos en las piezas que tienen PB4, es decir, no las de 14 pines. Que también resulta ser (si las ventas de mi tienda Tindie son una indicación) el tipo más popular.
¿Crees que habrá 3 series? Yo no. DD y EA claramente los están persiguiendo y tomando posiciones estratégicas en todo el territorio de tinyAVR. Creo que es sólo cuestión de tiempo antes de que la marca sea eliminada como lo hicieron con megaAVR después de la serie megaAVR 0. Esto no es necesariamente algo malo: todas las piezas de las series Dx y EA son muy similares en cuanto a asignación de pines y comportamiento, lo cual es muy bueno. Los diminutos son menos sistemáticos, aunque distribuyen pines a más periféricos. El principio rector parece haber sido "ningún periférico se quedará atrás". En contraste con las asignaciones de pines de las series Dx y EA, donde todo sigue un plan maestro fijo. Las piezas tienen o no un pin determinado, y si no lo tienen, no tienen esa función disponible. En ambos grupos amplios, creo que hay un gerente de producto cuyo trabajo es golpear a los ingenieros que piensan en hacer una "excepción" al Holy Pinout (ya que esas excepciones inevitablemente proliferan y es como terminamos con las asignaciones de pines de la diana con los ojos vendados). en el clásico tinyAVR)
La numeración de pines es extraña en los tinyAVR, y es culpa de Microchip: numeraron los pines dentro de los puertos de manera extraña: comienza en orden, excepto que PA0 es UPDI y generalmente no se puede utilizar, luego los pines de PORTB se numeran en orden inverso. luego PORTC vuelve a la misma numeración en sentido antihorario que PORTA. ¡Dame un respiro! Dado que la tradición es usar el pin 0 para el primer pin y que el último número sea el pin que no puede usar sin configurar un fusible que dificulte la programación del chip. Hubiera preferido poder numerarlos en sentido antihorario comenzando con A0 sin romper las convenciones no escritas del código Arduino. Se puede argumentar que tomé una mala decisión en las asignaciones de pines; tal vez deberían haber comenzado con PA0 (inutilizable a menos que se establezca un fusible, en cuyo caso el chip es difícil de programar) como pin 0, luego numerar los pines en sentido antihorario. Pero aún así no podrías hacer el tipo de trucos que harías si todos los puertos estuvieran en orden, a menos que numeraras los pines PORTB al revés. Si pudiera deshacerse de la expectativa de que todos los pines estén numerados en orden (y solo usen la notación PIN_Pxn), se podrían obtener ahorros significativos.
Predigo que dentro de 2 a 4 años habrá un AVR DA, DB, DD. Piezas de las series DU (el USB), EA y D/E/F reducidas a 8 (o al menos 14) y piezas de 64 pines con flash de 128k y el nuevo ADC. Y nada más con la marca ATtiny. Posiblemente la pregunta más importante que queda es si alguna vez reemplazarán el ATmega2560 con un AVR moderno con 100 pines en total (probablemente 80-88 de los cuales son E/S) y opciones de flash de hasta 256k; Eso presentaría tres problemas: primero, después de 56 pines de E/S no quedan más registros VPORT; el espacio de E/S bajo está lleno con 28 VPORT y 4 GPIOR. ¿Cómo manejarán los 4 puertos adicionales? (en el 2560, eran solo puertos de segunda clase a los que se accedía más lentamente y no tenían acceso de ciclo único. Tengo algunas reflexiones al respecto y la viabilidad con los pocos códigos de operación disponibles en el apéndice A aquí. Y en segundo lugar, violar La barrera de 128k en Flash, debe ir a un mostrador de 17 bits. "D x parte a 256k de flash tendría 32k de RAM. Ahora recuerde cómo Progmem funciona en DX: no podrían llegar hasta 32. 24k Ram es definitivamente posible, tal vez incluso 28, pero a 32k, más 32k para Flash Mapped, no deja espacio para los SFR, que están en el mismo espacio de direcciones.
Vendo tableros de ruptura con regulador, encabezado Updi y encabezado en serie en mi tienda Tindie, así como en las tablas desnudas. Comprar en mi tienda ayuda a apoyar un mayor desarrollo en el núcleo, y es una excelente manera de comenzar a usar estas nuevas piezas emocionantes con Arduino. Actualmente están disponibles tableros Attiny1624, pero las piezas de 20 y 24 pines no se venderán como una placa ensamblada hasta que un diseño de PCB recientemente revisado regrese de la casa de la junta para habilitar el autoreset en el pasador de reembolso alternativo. También hay una revisión de la junta de 14 pines, pensó que es en gran medida cosmético. La máscara de soldadura amarilla tiene que irse, ya que la legibilidad parecía empeorar en los últimos lotes. Las nuevas placas también estandarizan un espacio de 0.6 "entre las filas de los pines, en lugar del espacio de 0.7" actual, por lo que podrá, por ejemplo, colocar el encabezado del pasador mecanizado sobre ellos y enchufarlos a un enchufe de inmersión ancha, o Úselos con nuestro tablero de creación de prototipos optimizado para ese espacio de fila. Los tableros de la Serie 0 ensamblados están siendo descontinuados y no se reabastecerán una vez que se agoten. Lo mismo sucederá para las piezas de la serie de 16k 2 una vez que las 32k estén disponibles.
El ADC en la serie 2 y la serie EA son los mejores ADC que se han lanzado en un AVR en la era moderna de AVR. Además de esos dos. Las comparaciones más cercanas son los AVR clásicos que obtuvieron ADC diferenciales con características de primer nivel (T841, Mega2560 y (sorprendentemente) el T861 es los competidores más fuertes). Si bien no es capaz de obtener una ganancia loca de 100x y 200x de la que algunas partes se jactaron en los clásicos días de AVR, nunca me quedó claro cuánto de lo que se estaba amplificando era simplemente ruido (considerando que mi experiencia admitida jugando con ADC diferenciales Voy a decir "probablemente la mayor parte, y definitivamente la mayor parte si me dejas diseñar el hardware, ¡no sé analógico!"). Este nuevo ADC es ciertamente altamente capaz, con una verdadera capacidad diferencial (a diferencia de la serie DA y DB), y uno que se eleva de cabeza y hombros por encima de cualquier cosa disponible en cualquier otra AVR moderna hasta la fecha. El amplificador de ganancia programable es una nueva capacidad, y queda por ver qué tipo de hazañas de medición analógica pueden obtener de ella; Ciertamente parece prometedor. Será especialmente interesante comprender las diferencias entre usar el PGA con ganancia 1x, frente a no usar el PGA y los beneficios y desventajas de hacerlo. (Microchip estaría bien servido por un documento que discutía cómo elegir la configuración ADC correcta para una tarea en el caso general; he planteado esta preocupación con Microchip y la persona con la que hablé indicaba que era una alta prioridad; La situación se ha mejorado enormemente, todavía parece que el grupo DOC recibió instrucciones específicas de no hacer ninguna recomendación concreta de ningún tipo.
La adición de la acumulación de 1024 muestras para los fines de sobremuestreo y decimación es una adición bienvenida, aunque también corre el riesgo de subestimar la magnitud y la relevancia del error de desplazamiento. (Tomar 1024 muestras, (todas las cuales tienen un error de desplazamiento dado), luego diezmar la suma para producir una medición ADC de 17 bits hace que sea fácil imaginar que cualquier error se limitaría a la pareja más baja de bits. Pero si el error fue, digamos 5 LSB en una sola medición, cuando acumula 1024 muestras y diezpas, tiene un error de compensación de 160, es extremadamente fácil ver eso y pensar que es una señal no ruido.
El primer chip de tamaño completo (no pequeño) con el nuevo ADC está disponible en paquetes de 28-48 pines con flash de hasta 64k. Hubo la especulación habitual sobre qué si algo cambiaría de 2 series a la serie EA: parece que la respuesta es, se eliminó una de las perillas confusas, y se cortó el letrero automático para las mediciones acumuladas ((
El temporizador Tipo D solo se usa para PWM en las piezas de la serie 1 de Pin 1 de 20/24 en la configuración predeterminada del PIN PWM. En las partes más pequeñas, no nos permitiría aumentar el número total de pines PWM. Solo los pines WOC y WOD (en PC0 y PC1 respectivamente) ya no tienen PWM dirigido por TCA. Como tal, dado que AnalogWrite () no admite ninguna característica que se habilite desactivando el modo dividido (como PWM de 16 bits) o mejorado mediante el uso del temporizador Tipo D (como ajustar la frecuencia), sería peor, porque sería peor, porque Requeriría espacio adicional para almacenar la rutina para encender y apagar PWM de dos tipos de temporizador, en lugar de uno. Esto no es insignificante en las partes flash más pequeñas; Está del orden de 600 bytes. 150 para DigitalWrite () y 450 para AnalogWrite () si alguna vez se llaman en un pin TCD PWM. El optimizador debería poder optimizar esa parte de esas funciones en este caso, siempre que los pines utilizados con esas funciones no incluyan ningún pines TCD PWM. Tenga en cuenta que el optimizador los considerará de forma independiente, es decir, DigitalWrite () incluirá el código para apagar TCD PWM si se usa con un PIN que usa TCD para PWM, ya sea que alguna vez llame o no AnalogWrite () en ese pin.
A diferencia de casi todos los demás AVR (puedo pensar en quizás 3 ejemplos, y solo uno de ellos es un "bono" no un "unbonus"), hay características adicionales de "bonificación" basadas en el tamaño flash de una familia . Las versiones de 16k y 32k (solo) tienen algunas características adicionales (que tampoco parecen haber sido consideradas para el precio): todas tienen 2K de RAM, ya sea 16k o 32k, tienen 3 comparadores analógicos (incluido un modo de ventana Opción), un segundo, necesarios desesperadamente, un temporizador Tipo B, y más extraño de todo, tienen un segundo ADC, ¡que difiere solo en el que corresponden los canales!
A diferencia de los AVR clásicos, en estas partes, el flash se asigna al mismo espacio de direcciones que el resto de la memoria . Esto significa que pgm_read_*_near() no es necesario para leer directamente desde Flash. Debido a esto, el compilador coloca automáticamente cualquier variable declarada const en progmem, y lo accede de manera apropiada; ya no necesita declararlos explícitamente como progmem. Esto incluye literales de cadena citados, por lo que la macro f () ya no es necesaria, aunque para mantener la compatibilidad con algunas bibliotecas de terceros, f () todavía declara su argumento progmem.
Sin embargo, tenga en cuenta que si declara explícitamente un progmem variable, aún debe usar las funciones pgm_read para leerlo, al igual que en los AVR clásicos. Cuando se declara una variable progmem en piezas con flash mapeado de memoria, el puntero se compensa (la dirección es relativa al inicio de flash, no el inicio del espacio de direcciones); Este mismo desplazamiento se aplica cuando se usa pgm_read_*_near() macros. Tenga en cuenta que declarar las cosas progmem y acceder con pgm_read_*_near las funciones, aunque funciona bien, es más lento y desperdicia una pequeña cantidad de flash (en comparación con simplemente declarar las variables const); Lo mismo ocurre con la macro f () con cadenas constantes en 2.1.0 y más tarde (durante un período de tiempo antes de 2.1.0, F() no hizo nada, pero eso causó problemas para las bibliotecas de terceros). Los autores sostuvieron que el problema era con el núcleo, no con la biblioteca, y mi elección era aceptar menos eficiencia o negar el acceso a mis usuarios a bibliotecas populares). El uso de la macro F() puede ser necesaria para la compatibilidad con algunas bibliotecas de terceros (los casos específicos que forzaron el retorno de F() sobre nosotros no eran de ese tipo; en realidad pudimos hacer que los que conocía trabajara con el F ()-Código AS-Noop, y tomaron algunos bytes menos flash como resultado).
Las versiones automotrices también deberían funcionar. Siempre debe seleccionar las velocidades de reloj derivadas de 16 MHz en estas partes. No admiten una operación de 20 MHz, y las opciones de reloj sintonizadas no deben usarse.
Ahora, a la buena parte, donde podemos hablar sobre cómo todo esto está expuesto por Megatinycore. Comenzaremos con la cuestión de cómo debe consultar los pines para obtener los mejores resultados, y luego pasar a las características centrales, las opciones de menú, antes de terminar con una serie de enlaces a documentos con más detalles en varios subsistemas.
La simple cuestión de cómo referirse a un PIN para Analogread () y DigitalRead (), particularmente en hardware no estándar, ha sido una fuente persistente de confusión entre los usuarios de Arduino. Es mi opinión que gran parte de la culpa recae en las decisiones tomadas por el equipo de Arduino (y el autor de Cableado ante ellos) con respecto a cómo se refería los pines; La designación de algunos pines como "pines analógicos" lleva a las personas a pensar que esos pines no se pueden usar para las operaciones digitales (se consideran mejor como "pines con entrada analógica", como cómo hay "pines que pueden emitir PWM"). El hecho de que los alfileres se hayan renumerado tradicionalmente ha enturbiado aún más el agua. Para las piezas AVR clásicas no estándar, las asuntos a menudo empeoran aún más por múltiples "mapeaciones de pines" incompatibles creadas por varios autores a lo largo de los años para hacer que la parte actúe "más como una Uno" o para algún otro propósito (Attinycore es un particular Mess de esta manera, con algunas partes que tienen tres asignaciones de pines completamente diferentes, en al menos un caso, una de las asignaciones alternativas es un trabajo inspirado en el diablo de puro mal, que requiere nada menos que una tabla de búsqueda adicional para convertir pines analógicos en digital digital alfileres).
Este núcleo utiliza un esquema simple para asignar los números de pin de Arduino: los pines están numerados a partir del pin de E/S más cercano a VCC como PIN 0 y procediendo en sentido antihorario, omitiendo el PIN (en su mayoría) no utilizado. El PIN UPDI se asigna al último número de PIN (como se señaló anteriormente, es posible leer el PIN UPDI (las lecturas analógicas y digitales funcionan) incluso si no se establece como GPIO). Recomendamos esto como último recurso: el pin updi siempre tiene su pullup habilitada cuando no está configurado como un pin GPIO, y una señal que se parece demasiado a la secuencia de habilitación de actualización causará una operación no deseada.
Para evitar toda confusión sobre las identidades de PIN y eliminar la ambigüedad, recomendamos usar la notación PIN_PXN para referirse a PIN a menos que esté utilizando un tablero de desarrollo con diferentes números o nombres para los pines impresos en él. Esto maximizará la portabilidad de su código a otro hardware similar y facilitará la búsqueda de información sobre los pines que está utilizando en las hojas de datos relevantes, si eso es necesario.
Esta es la forma recomendada de referirse a los pines #defines también se proporciona de la forma PIN_Pxn , donde x es A, B o C, y n es un número 0-7 - (no debe confundirse con el PIN_AN define a continuación). Estos simplemente se resuelven al número de PIN digital del PIN en cuestión: no pasan por una ruta de código diferente ni nada. Sin embargo, tienen una utilidad particular en el código de escritura que funciona en la línea de productos con periféricos que están vinculados a ciertos pines (por puerto), como lo son la mayoría de los periféricos. Varias piezas de código de demostración en la documentación aprovechan esto. También es posible la manipulación de puertos directos, y de hecho, hay varias opciones adicionales poderosas disponibles para ello, consulte la manipulación de puertos directos .
PIN_Pxn - no Pxn , y no PIN_xn - ¡Esas significan cosas diferentes!
Cuando se usa un solo número para referirse a un PIN, en la documentación o en su código, siempre es el "número de pin Arduino". Estos son los números de PIN que se muestran en naranja (para pines capaces de anicogroad ()) y azul (para pines que no lo están) en los gráficos de pinout. Todas las otras formas de referencia a pines están #definidas al número de pin Arduino correspondiente.
El núcleo también proporciona An y PIN_An (donde n es un número de 0 a 11). Al igual que con el núcleo oficial, PIN_An se define como el número de PIN digital del PIN compartido con el canal analógico N, se refieren a los números del canal ADC0. Este sistema de nombres es similar a lo que se usó en muchos núcleos AVR clásicos , pero aquí, solo están #definidos como el número de pin Arduino correspondiente . Si necesita obtener el número de canal analógico en un PIN digital, use digitalPinToAnalogInput(pin) Macro, pero solo necesita eso si está escribiendo una biblioteca ADC avanzada.
Estas partes (bueno, al menos la serie 1/2, la serie 0 se entendía como una opción de presupuesto, excepto que no pudieron reducir el presupuesto, y solo son un par de centavos más baratos) proporcionan una excelente caja de herramientas de versátil y poderosos periféricos; Los mejores están a la par o mejor que las piezas megaavr clásicas, por un precio TinyAVR. Uno de los principios rectores del diseño de Megatinycore, como con mis otros núcleos, es permitir que las piezas compatibles alcancen su máximo potencial, o lo más cerca posible de las limitaciones de Arduino. Esta sección (muy grande) cubre las características de estas piezas y cómo están expuestas por MegatinyCore, así como características del núcleo en sí. Esta sección (muy grande) intenta cubrir cada una de las áreas de características. ¡Trate de encontrar la función con la que está trabajando si está intentando usar alguna función de chip y tener problemas!
20 MHz interno (4.5V -5.5V - típico para sistemas de 5V)
16 MHz interno (4.5V -5.5V - típico para sistemas de 5V)
10 MHz interno (2.7V -5.5V - típico para sistemas de 3.3V)
8 MHz interno (2.7V -5.5V - típico para sistemas de 3.3V)
5 MHz interno (1.8V-5.5V)
4 MHz interno (1.8V-5.5V)
2 MHz interno (1.8V-5.5V, mal probado)
1 MHz interno (1.8V-5.5V, mal probado)
Reloj externo de 20 MHz (4.5V-5.5V, mal probado)
Reloj externo de 16 MHz (4.5V-5.5V, mal probado)
Reloj externo de 12 MHz (2.7V-5.5V, mal probado)
Reloj externo de 10 MHz (2.7V-5.5V, mal probado)
Reloj externo de 8 MHz (2.7V-5.5V, mal probado)
6 MHz interno (sintonizado, no probado)
5 MHz interno (sintonizado, mal probado)
4 MHz interno (sintonizado, mal probado)
2 MHz interno (sintonizado, mal probado)
1 MHz interno (sintonizado, mal probado))
7 MHz interno (sintonizado, para masoquistas, no probado)
8 MHz interno (sintonizado, mal probado)
10 MHz interno (sintonizado, mal probado)
12 MHz interno (sintonizado, no probado)
14 MHz interno (sintonizado, para masoquistas, no probado)
16 MHz interno (sintonizado)
20 MHz interno (sintonizado)
24 MHz interno (sintonizado, overclockeado, mal probado)
25 MHz interno (sintonizado, overclockeado, mal probado)
30 MHz interno (sintonizado, overclockeado, mal probado) - La serie 0/1 requiere configuración de fusible OSCCFG "20MHz"; Las piezas de la serie 2 pueden o no poder alcanzar las 30 con "16 MHz" seleccionadas.
32 MHz interno (sintonizado, overclocable, mal probado): solo 2 -series, overclocking muy optimista, puede ser inestable.
Reloj externo de 24 MHz (overclociado, mal probado)
Reloj externo de 25 MHz (overclociado, mal probado)
Reloj externo de 30 MHz (overclociado, mal probado)
Reloj externo de 32 MHz (overclociado, mal probado)
No hacemos afirmaciones sobre los rangos de voltaje o temperatura para las piezas overclocadas; todo lo que reclamamos es que al menos una de las chips que hemos trabajado a esa velocidad a temperatura ambiente, ejecutando un boceto específico, a 5V. Se espera que su kilometraje varíe, pero generalmente será mejor con una especificación F versus una parte de especificación N o U.
IMPORTANTE: ¡lea sobre el ajuste antes de seleccionar cualquier opción sintonizada!
Puede encontrar más información sobre estas velocidades de reloj en la referencia del reloj
Los voltajes que se muestran son aquellos garantizados para funcionar por las especificaciones del fabricante (a menos que empujen los límites del rango de temperatura de funcionamiento, estas piezas generalmente lo harán mucho mejor (la serie 2 generalmente funcionan a 32 MHz y 5V @ temperatura ambiente incluso desde el oscilador interno; el 0 /La serie 1 también generalmente funcionará a 32 MHz con reloj externo siempre que la fuente de alimentación sea un establo de 5.0-5.5V).
No se requiere acción para establecer el fusible OSCCFG cuando el boceto se cargue a través de Updi. Cuando se sube a través de Optiboot, el fusible no se puede cambiar, por lo que lo que se eligió cuando se quemó el cargador de arranque es lo que se usa, y solo "quemar el gestor de arranque" o cargar un boceto a través de Updi cambiará eso.
Todas las opciones de velocidad de reloj del oscilador interno usan la calibración predeterminada de fábrica a menos que se seleccione una opción "sintonizada", en cuyo caso la calibración se ajusta como se documenta en la referencia de sintonización . Esto se puede usar para obtener una operación de 16 MHz en un chip Optiboot fusionado por 20 MHz y viceversa.
Consulte la referencia de calificación de velocidad para obtener más información sobre las calificaciones de velocidad del fabricante. Tenga en cuenta que esos son los voltajes y las velocidades del reloj a las que se garantiza que funcione. Estas piezas están destinadas a ser adecuadas para su uso en aplicaciones donde una falla inesperada de alguna descripción podría representar un peligro para personas o propiedades (piense en automóviles, equipos industriales, aviones, reactores nucleares, lugares donde las personas podían morir si la parte no funcionaba) y yo Cree también para aplicaciones militares, que tienen requisitos de confiabilidad similares, solo por la razón opuesta. Los usuarios típicos de pasatiempos estarán mucho más relajados sobre el potencial de problemas de estabilidad, y los accidentes son poco más que una molestia, y los extremos de las piezas de rango de temperatura extendido están mucho más allá de lo que necesitaríamos. Suponiendo que el tablero tenía un recubrimiento impermeable, térmicamente, una parte de grado N debería poder funcionar según el grado de velocidad en una olla de agua hirviendo. Y eso es solo el N-Spec. ¡El F-Spec debería ser bueno para 125!
Se ha establecido que las piezas de temperatura extendidas se overcloce mejor, lo que tiene sentido. Se espera que una parte que se especifica para que se ejecute a 20 MHz a 125 ° C tenga una mejor oportunidad de correr a 32 MHz a temperatura ambiente que una especificada solo para correr a 20 MHz a 105 ° C
A partir de la versión 2.4.0, ahora proporcionamos una opción "Junta de microchip oficial". Esto no hace nada especial que no sea definir LED_BUILTIN para que sea el pin que tiene el LED en esa placa, en lugar de A7, y definir una macro PIN_BUTTON_BUILTIN definida como el pin con el botón de usuario y hacer "cargar" con el no no -optiboot versión siempre use el programador/depurador integrado; Herramientas -> El programador se utilizará solo para "Burn Bootloader" y "Cargar usando programador". En el caso del Attiny416 XPlained Nano, también selecciona la versión del gestor de arranque que usa los pines alternativos para el puerto serie: no usa automáticamente los pines alternativos para USART0 como si hubiera hecho Serial.swap (1) todavía - La funcionalidad para admitir el intercambio predeterminado de los pines en serie vendrá en una actualización futura, junto con algunos otros cambios en la maquinaria subyacente al mecanismo de fielps que, con suerte, también reducirá el uso de flash.
Como se señaló anteriormente, pueden no funcionar correctamente en plataformas Linux de 32 bits. Esto está más allá de mi control; No construyo binarios de avrdude y no estoy asumiendo esa tarea tampoco. Ya tengo demasiados.
blink() toma más flash en el XPlained Mini frente al XPlained Pro?¡Ambos tienen el mismo Attiny817! ¿Cómo pueden ser diferentes?
Por la misma razón que Blink tomará más flash si lo cambia para usar PIN_PC0 en lugar de PIN_PB4 : PC0, utilizado en el mini XPlained es un pin PWM, mientras que PB4, utilizado por el Pro Pro no lo es. Dado que ese es el único PIN en el que se está utilizando DigitalWrite (), el compilador es libre de optimizar cualquier cosa que no sea necesaria para DigitalWrite () en ese pin, incluida la funcionalidad para desactivar la salida de PWM en un PIN que admite PWM . La diferencia se desvanece si DigitalWrite () también se usa en un pin que admite PWM en ambos dispositivos (lo que resulta en el resultado de uso de flash más alto) o si DigitalWrite () se reemplaza con DigitalWriteFast (), que usará menos flash (pero supone que ganó que ganó 'T Llámalo en un pin de salida PWM).
Cada vez que se usa un programador UPDI para cargar código, todos los fusibles que se pueden establecer "de forma segura" (como, sin riesgo de bloquear la placa, o bloquear el tablero si uno no tiene acceso a un programador de HV), y que tienen alguno Se establecerán opciones de configuración incorporadas. Por lo tanto, excepto cuando se indique, el comportamiento siempre coincidirá con el menú de herramientas seleccionadas. En resumen, estos se manejan de la siguiente manera:
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 no es seguro, porque establecer esto en un voltaje más alto que el tablero se ejecuta y habilitarlo "lade" la placa hasta que se pueda suministrar un voltaje de funcionamiento más alto; Esto podría ser particularmente incómodo si se suelde a la misma PCB que los dispositivos que no tolerarán esos voltajes.
SYSCFG0 no es seguro porque aquí es donde vive RSTPINCFG ; Cambiar esto puede dejar la placa improvisable, excepto a través de la programación HV Updi, y no todos tienen un programador HV Updi. En el futuro si/cuando un programador que garantiza la capacidad de HV Updi que se puede seleccionar como programador (es decir, es posible hacer una opción de herramientas -> programador que solo funcionará con programadores de HV) Este fusible se establecerá automáticamente cuando se use ese programador.
Como resultado , en 2.2.0 y posterior, ya no necesita 'quemar el cargador de arranque' para cambiar entre velocidades derivadas de 16 MHz y 20 MHz derivadas al cargar usando Updi
Este núcleo siempre utiliza la optimización del tiempo de enlace para reducir el uso de flash: todas las versiones del compilador que admiten las piezas de la serie TinyAVR 0/1/2 también admiten LTO, por lo que no hay necesidad de hacerlo opcional, como se hizo con AttinyCore. Esta fue una gran mejora en Codesize cuando se introduce, ¡generalmente en el orden del 5-20%!
Todas estas piezas tienen una gran cantidad de entradas analógicas: la serie DA y DB tienen hasta 22 entradas analógicas, mientras que la serie DD tiene entrada analógica en cada pin que no se usa para conducir el cristal HF (aunque los pines en PORTC son Solo admitido cuando MVIO está apagado). Se pueden leer con analogRead() como en un AVR normal, y nos quedamos de forma predeterminada a una resolución de 10 bits; Puede cambiar a los 12 bits completos con analogReadResolution() , y usar las funciones de Analogread mejoradas para tomar lecturas diecimadas y de muestra automáticamente para una mayor resolución y tomar mediciones diferenciales. Hay 4 referencias de voltaje interno en 1.024, 2.048, 4.096 y 2.5V, más soporte para el voltaje de referencia externo (y VDD, por supuesto). Las lecturas de ADC se toman 3 veces más rápido que un AVR clásico, y esa velocidad se puede duplicar nuevamente si lo que está midiendo es de baja impedancia o extender el tiempo de muestreo por un factor enormemente para leer fuentes de impedancia muy alta. Esto se detalla en la referencia analógica.
Las piezas de la serie DX tienen un DAC de 10 bits que puede generar un voltaje analógico real (tenga en cuenta que esto proporciona baja corriente y solo puede usarse como una referencia de voltaje o voltaje de control, no puede ser
