megaTinyCore
2.6.10 - Critical Bugfix
Temos uma seção de discussões no Github agora. Quando um problema é definitivamente um defeito central, você reduzirá o tempo necessário para corrigi-lo se criar um problema, já que priorizo os problemas em vez de acompanhar as discussões.
Isso corrige muitos dos bugs presentes no 2.6.x
2.6.x apresenta uma pegada flash serial significativamente aprimorada ao adicionar recursos, o fio pode despertar o escravo do modo de suspensão sem corromper os dados e muito, muito mais, consulte o Changelog.
Somente versões do Arduino IDE baixadas de arduino.cc devem ser usadas, NUNCA de um gerenciador de pacotes Linux. Os gerenciadores de pacotes geralmente possuem o IDE do Arduino – mas o modificaram . Isso ocorre apesar de eles não saberem nada sobre Arduino ou desenvolvimento embarcado em geral, muito menos o que precisariam saber para modificá-lo com sucesso. Essas versões são notórias por problemas sutis, mas sérios, causados por essas modificações imprudentes. Não se deve esperar que este núcleo funcione em tais versões, e nenhuma modificação será feita para corrigir versões do IDE que vêm de gerenciadores de pacotes por esse motivo.
Este é um bug no cliente Arduino.
As versões IDE entre 1.8.13 e 2.x desenvolveram novos defeitos significativos. As versões IDE 1.8.2 e anteriores, no entanto, possuem defeitos incapacitantes não corrigidos. Acredito que eles finalmente tenham uma versão funcional do IDE, e acredito que o mais recente seja capaz de instalar meu núcleo corretamente.
Antes do megaTinyCore 2.6.0, a instalação manual do megaTinyCore causava o travamento da V1.8.14 do IDE devido a esse bug quando você instalava o núcleo manualmente na pasta Arduino. Os usuários da versão 1.8.14 e posterior devem usar a versão 2.6.0 do megaTinyCore.
Compro muita coisa eletrônica no AliExpress. É um ótimo mercado para coisas feitas por empresas chinesas e que são em sua maioria genéricas, incluindo muitos componentes indisponíveis para indivíduos no Ocidente global de qualquer outra forma (por exemplo, o pedido mínimo é um carretel ou algo parecido - se você conseguir encontrar um fornecedor de componentes que trabalha com o fabricante chinês de chips sem nome). Não é um bom lugar para as mais recentes linhas de produtos semicondutores dos principais fabricantes ocidentais, especialmente no meio de uma escassez histórica desses chips. Os dispositivos AVR modernos, quando estão disponíveis através desses canais, são frequentemente relatados como falsos ou defeituosos (como ATtiny412s que pensam que são 416s e podem não executar corretamente a reinicialização ao ligar). Por falar nisso, você provavelmente não vai querer comprar nenhum microcontrolador AVR no AliExpress ... Placas montadas, como os clones do Arduino Nano, geralmente funcionam se você evitar aquelas com chips LGT8 de terceiros e tomar cuidado com aquelas com ATmega168p em vez do '328p - mas há muitos relatos de microcontroladores falsos quando eles são vendidos como chips simples (ouvi falar de ATtiny85s falsos que foram realmente comentados ATtiny13s; não são apenas os AVRs modernos que são falsificados). Existem muitas teorias interessantes sobre a origem desses chips falsos, e a Microchip permaneceu totalmente silenciosa sobre o assunto.
Este documento é melhor visualizado on-line (em vez de abrir o arquivo markdown em seu editor de texto favorito), para que os links sejam clicáveis e as imagens embutidas sejam mostradas e, provavelmente o mais importante, para fazer com que as tabelas sejam renderizadas corretamente às vezes. Novamente, este [documento pode ser encontrado no github](https://github.com/SpenceKonde/megaTinyCore](https://github.com/SpenceKonde/megaTinyCore)
Versões mais antigas não lidam adequadamente com os programadores no menu ferramentas -> programadores, o que degrada a UX rapidamente à medida que o número de núcleos instalados aumenta. Eles não são adequados. As versões mais recentes começando com 1.8.14 (incluindo 1.8.17, 1.8.18 e 1.8.19) podem gerar um erro "pânico: nenhuma versão principal encontrada" porque não conseguem analisar adequadamente o platform.txt. Desde a versão 2.6.0, modificamos manualmente o platform.txt diretamente antes do lançamento, então isso é um problema menor
Quando o megaTinyCore é instalado por meio do gerenciador de placa, a versão necessária do conjunto de ferramentas é instalada automaticamente. Todas as peças da série 0/1/2 são suportadas sem etapas extras. Até 2.2.7, usávamos a versão Arduino7 do avr-gcc (gcc 7.3.0 e avrlibc 3.6.1) com os ATpacks mais recentes em junho de 2020. A partir de 2.2.7, começamos a usar minha versão Azduino do conjunto de ferramentas, que atualizou ATpacks para todas as peças recentemente suportadas. 2.2.7 usou Azduino3, 2.3.0+ usou Azduino4 e, começando com 2.6.0, usamos Azduino5 (embora não ofereça nenhum benefício para nós, além de economizar um quarto de GB de espaço em disco rígido e 40 MB de largura de banda de download se você instalar ambos megaTinyCore e DxCore através do gerenciador de placa.
A instalação manual é mais complicada - principalmente se você deseja suporte para a Série 2; consulte o guia de instalação para obter mais informações.
Um núcleo Arduino para o tinyAVR Série 0, Série 1 e agora Série 2. Essas peças têm uma arquitetura aprimorada em comparação com as peças "clássicas" do tinyAVR (que são suportadas pelo ATTinyCore), com periféricos aprimorados e tempo de execução aprimorado para certas instruções (estes são semelhantes em ambos os aspectos do AVR Dx-Series avançado, bem como chips megaAVR série 0, como o ATmega4809 usado no Nano Every e Uno Wifi Rev. 2 oficial - embora a equipe do Arduino tenha feito o possível para dominá-los) em pacotes pequenos e de baixo custo típicos da linha ATtiny. Todas essas peças apresentam pelo menos um UART de hardware e uma interface SPI e TWI (nada daquele lixo USI como, por exemplo, o ATtiny85 possui), um sistema de eventos poderoso, lógica personalizada configurável, pelo menos um comparador analógico no chip , um oscilador interno surpreendentemente preciso e, no caso da Série 1, um canal de saída DAC real e, no caso da Série 2, um ADC diferencial sofisticado.
Além disso, as peças da série tinyAVR 0/1/2 são baratas - as peças de ponta, o 3226 e o 3227, com 32k de flash e 3k de SRAM (contra os 2k SRAM como o ATmega328p usado em Uno/Nano/ProMini) rodam pouco mais de US $ 1 em quantidade - menos do que muitas peças AVR ATtiny clássicas de 8k ("conjunto de instruções AVR, a um preço PIC"). Todas essas peças são classificadas para funcionar a 16 MHz ou 20 MHz (em 4,5-5,5 V) sem um cristal externo, e o oscilador interno é preciso o suficiente para comunicação UART.
Eles usam programação UPDI, não ISP tradicional como as peças clássicas do ATtiny faziam. Veja abaixo para mais informações. Obter um programador UPDI é simples - você pode usar um Arduino clássico baseado em 328p como programador usando jtag2updi - ou para melhores resultados com hardware mais barato, você pode usar qualquer adaptador serial USB e um resistor (e de preferência um diodo) usando o SerialUPDI incluído ferramenta, ou você pode usar AVRdude com um dos programadores Microchip (os programadores baseados em mEDBG/nEDBG/EDBG em sua placa de desenvolvimento, Atmel-ICE ou SNAP) ou qualquer ferramenta de programação UPDI que emule um desses (o que, até onde sei, todos eles fazem - se houver algum que o avrdude suporte e meu núcleo não, por favor, abra um problema para me avisar!).
Um bootloader serial, Optiboot_x (baseado na mesma base de código do bootloader Arduino Uno clássico, embora bastante alterado) é suportado nessas partes (o suporte à série 0/1 está atualmente ativo, a série 2 é esperada para a primeira semana de maio ; os ajustes para as novas peças são triviais), permitindo que sejam programadas através de uma porta serial tradicional. Consulte a seção Optiboot abaixo para obter mais informações sobre isso e as opções relevantes. A instalação do bootloader requer um programador UPDI. As placas de breakout montadas que vendo no Tindie estão disponíveis pré-inicializadas (elas são inicializadas sob demanda). Dito isto, a experiência do usuário com o Optiboot é um pouco decepcionante nas peças da série 0/1, bem como nas peças da série 2 de 14 pinos, devido à falta de um pino de redefinição de hardware que possa ser usado com o circuito de reinicialização automática usual. para redefinir automaticamente no bootloader quando a porta serial for aberta. Você precisa desabilitar totalmente a programação UPDI (exigindo um programador HV se as configurações do fusível ou o bootloader precisarem ser alterados após o bootload inicial) ou deixar o UPDI habilitado, mas iniciar qualquer upload dentro de 8 segundos após ligar a energia. As peças da série 2 de 20 e 24 pinos suportam um "pino de reinicialização alternativo", permitindo que funcionem mais como um Arduino tradicional.
A interface de programação UPDI é uma interface de fio único para programação (e depuração - Interface U niversal de Programação e Depuração ), que é usada no tinyAVR Série 0/1/2, bem como em todos os outros microcontroladores AVR modernos. . Embora sempre seja possível comprar um programador UPDI feito sob medida da Microchip, isso não é recomendado quando você estiver usando o IDE do Arduino em vez do IDE (terrivelmente complicado) da Microchip. Existem relatos generalizados de problemas no Linux para os programadores oficiais da Microchip. Existem duas abordagens alternativas de custo muito baixo para a criação de um programador UPDI, ambas com as quais a comunidade Arduino tem mais experiência do que os programadores oficiais.
Antes da existência do megaTinyCore, havia uma ferramenta chamada pyupdi - um programa Python simples para fazer upload para microcontroladores equipados com UPDI usando um adaptador serial modificado pela adição de um único resistor. Mas o pyupdi não era facilmente utilizável no IDE do Arduino e, portanto, essa não era uma opção. A partir da versão 2.2.0, megaTinyCore traz uma implementação Python portátil, que abre muitas portas; Originalmente estávamos planejando adaptar o pyupdi, mas a pedido de seu autor e de vários funcionários da Microchip, baseamos essa funcionalidade no pymcuprog, uma ferramenta "mais robusta" desenvolvida e "mantida pela Microchip" que inclui a mesma porta serial de upload recurso, apenas sem as otimizações de desempenho. Se estiver instalando manualmente, você deve adicionar o pacote Python apropriado ao seu sistema operacional para usar este método de upload (uma instalação do sistema Python não é suficiente, nem é necessária).
Leia a documentação do SerialUPDI para obter informações sobre a fiação.
A partir da versão 2.3.2, com as melhorias drásticas no desempenho e a confiabilidade comprovada do esquema de fiação usando um diodo em vez de um resistor, e à luz da instabilidade do firmware jtag2updi, este é agora o método de programação recomendado. A partir desta versão, a velocidade de programação foi aumentada em até um fator de 20 e agora excede em muito o que era possível com jtag2updi (a programação via jtag2updi é aproximadamente comparável em velocidade à programação via SerialUPDI na opção de velocidade "SLOW", 57600 baud; a versão normal de 230400 baud programa cerca de três vezes mais rápido que a versão SLOW ou jtag2updi, enquanto a opção "TURBO" (funciona em 460800 baud e aumenta a velocidade de upload em aproximadamente 50% em relação ao normal. A versão de velocidade TURBO só deve ser usada com dispositivos rodando a 4,5v ou mais, pois temos que rodar o clock UPDI mais rápido para acompanhar (também não é esperado). para ser compatível com todos os adaptadores seriais - esta é uma compensação intencional para melhorar o desempenho), mas permite o upload e a verificação de um esboço de 32kB em 4 segundos.
Três projetos estão sendo iterados: um adaptador serial de porta dupla onde ambas são portas seriais, um adaptador serial de porta dupla onde uma porta é sempre UPDI e uma porta única com um switch para selecionar o modo e uma placa adicional opcional para fornecer leds indicando status das linhas de controle do modem.
Eles permitirão o uso de um conector SMT JST-XH ou dupont - de qualquer forma com 6 pinos para serial (pinagem FTDI conforme marcado) e 3 pinos (para UPDI).
Todos os três serão capazes de fornecer 3,3 ou Vusb (nom. 5V), ou desconectar Vusb e 3V3 da energia, e esperar que o dispositivo alvo seja alimentado com 5,5V > Vdd > 1,8V. Os níveis lógicos utilizados neste caso serão a tensão de tudo o que for aplicado. Esteja avisado que em dispositivos seriais duplos, o barramento de alimentação VccIO é compartilhado! Ambos devem estar funcionando na mesma tensão, ser o mesmo dispositivo ou o adaptador deve estar configurado para alimentá-los e sua alimentação desconectada.
Dependendo do modelo do adaptador e do sistema operacional, descobriu-se que são necessárias diferentes configurações de tempo; no entanto, as configurações necessárias para evitar que até 230.400 baud falhem no Linux/Mac com a maioria dos adaptadores impõem uma penalidade de tempo muito maior no Windows, onde o manuseio serial do sistema operacional é lento o suficiente para que nada precise desse atraso...
O "atraso de gravação" mencionado aqui é para permitir que o comando apagar-gravar página termine de ser executado; isso leva um tempo diferente de zero. Dependendo do adaptador, a latência USB e o buffer implícito de 2 ou 3 bytes (é como um USART, e provavelmente implementado como um internamente. O terceiro byte que chega não tem para onde ir, porque o buffer de hardware tem apenas 2 bytes de profundidade) pode ser suficiente para permitir que funcione sem atraso explícito. Ou pode falhar no meio e relatar um "Erro com st". Quanto mais rápido for o tempo limite de latência do adaptador e mais rápido for o manuseio serial do SO, maior será a chance de isso ser um problema. Isso é controlado pelo parâmetro de linha de comando -wd se o prog.py for executado manualmente. A partir da versão 2.5.6 esse atraso de gravação está mais próximo do tempo real solicitado (em ms), anteriormente tinha uma granularidade de vários ms, quando 1 é tudo o que você precisava, e como resultado, a penalidade imposta foi brutal , principalmente em Windows.
Guia de seleção:
460800+ baud requer que o alvo esteja funcionando a 4,5V+ para permanecer dentro das especificações (na prática, provavelmente não precisa ser tão alto - mas deve ser uma tensão alta o suficiente para ser estável em 16 MHz. Definimos o clock da interface ao máximo para todas as velocidades acima de 230.400 baud - enquanto alguns adaptadores às vezes funcionam a 460.800 sem essa etapa (o que por si só é estranho - 460800 baud é 460800 baud, certo?), a maioria não e o SerialUPDI não tem como determinar qual é o adaptador.
Os adaptadores baseados em CH340 têm latência alta o suficiente na maioria das plataformas e quase sempre funcionam em qualquer velocidade sem recorrer a atraso de gravação. Todas as opções funcionam sem usar o atraso de gravação.
Quase todos os adaptadores funcionam no Windows a 230,4k sem usar o atraso de gravação. Alguns raros não o fazem, incluindo alguns microcontroladores USB nativos programados para atuar como adaptadores seriais (ex: SAMD11C).
Quase nada, exceto os adaptadores baseados em CH340, funcionará a 460,8k ou mais sem atraso de gravação, independentemente da plataforma.
No Windows, muitos adaptadores (mesmo aqueles que realmente deveriam suportá-lo) não conseguirão mudar para 921600 baud. Eu não sei porque. O sintoma é uma pausa no início de alguns segundos enquanto ele tenta, seguida de upload a 115.200 bauds. O único com o qual tive sucesso até agora foi o CH340, por incrível que pareça.
460.800 bauds no Windows com atraso de gravação geralmente é mais lento que 230.400 bauds sem ele. O mesmo não acontece no Linux/Mac, e quanto menor o tamanho da página, maior será o impacto no desempenho causado pelo atraso na gravação.
Deve-se utilizar 57600 baud se outras opções não estiverem funcionando, ou quando programar em Vcc = < 2,7V.
460800 baud funciona sem atraso de gravação em alguns adaptadores com um resistor de 10k colocado no diodo Schottky entre TX e RX, quando não funciona sem isso, a menos que o atraso de gravação esteja habilitado. Não, também não entendo como isso pode ser!
Como você pode ver acima, esta informação é em grande parte empírica; ainda não se sabe como prever o comportamento.
Adaptadores FTDI (FT232, FT2232 e FT4232 etc.), incluindo os falsos que estão disponíveis no eBay/AliExpress por cerca de US$ 2, no Windows o padrão é um período de latência terrivelmente longo de 16 ms. Mesmo com todos os esforços para limitar o número de períodos de atraso de latência que devemos esperar, isso prolongará um upload de 2,2 segundos para mais de 15 segundos. Você deve alterar isso para obter velocidades de upload toleráveis:
Abra o painel de controle, gerenciador de dispositivos.
Expandir portas (COM e LPT)
Clique com o botão direito na porta e escolha propriedades
Clique na guia Configurações de porta
Clique em "Avançado..." para abrir a janela de configurações avançadas.
Na seção "Opções de BM", encontre o menu "Temporizador de latência", que provavelmente será definido como 16. Altere para 1.
Clique em OK para sair da janela de opções avançadas e novamente para sair das propriedades. Você verá o gerenciador de dispositivos atualizar a lista de hardware.
Os uploads devem ser muito mais rápidos agora.
Um pode ser feito a partir de um clássico AVR Uno/Nano/Pro Mini; Nano clones baratos são a escolha usual, sendo baratos o suficiente para serem conectados e deixados assim. Não fornecemos mais documentação detalhada para esses processos; jtag2updi está obsoleto. Se você ainda estiver usando, você deve selecionar jtag2updi no menu ferramentas->programador. Esta era anteriormente nossa opção recomendada. Devido aos bugs persistentes do jtag2updi e à sua dependência da ferramenta 'avrdude', em grande parte não mantida (que, entre outras coisas, insere uma mensagem de erro espúria em todos os uploads UPDI feitos com ela), isso não é mais recomendado.
Aparentemente, o Arduino não está empacotando versões de 32 bits do avrdude mais recente. Eu defini uma nova definição de ferramenta que é uma cópia do arduino18 (o mais recente), exceto que ele usa a versão 17 no Linux de 32 bits, já que é o melhor disponível para essa plataforma. A versão arduino17 não suporta corretamente o upload com algumas das ferramentas de programação da Microchip.
Atualmente, isso é usado apenas nas últimas versões e deve corrigir o erro avrdude não disponível para esta plataforma.
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
Qualquer coisa chamada "AVR##XX##" onde X é uma letra e # é um número - você quer meu DxCore para aqueles
Todas as peças clássicas (pré-2016) do tinyAVR - quase todas são suportadas por um dos meus outros núcleos ATTinyCore
ATtiny 25/45/85, 24/44/84, 261/461/861, 48/88, os dois pequenos e uns (estranho 43 e 4313/2313), e em 2.0.0, o 26, bem como o final -quatro (que mostram indícios de experimentação na direção dos AVRs modernos), o ATtiny 441/841, 1634 e 828 mais o ainda mais estranho 26.
Qualquer outra coisa Consulte este documento para obter uma lista de famílias de peças AVR e com quais núcleos do Arduino elas funcionam - quase tudo tem um núcleo que oferece suporte, geralmente sozinho ou no MCUdude.
Veja este documento cobrindo todos os AVRs modernos
| Recurso | série 0 | Série 1 | 1+série | 2 séries |
|---|---|---|---|---|
| Clarão | 2k-16k | 2k-8k | 16k/32k | 4k-32k |
| Número de pinos | 8-24 | 8-24 | 14-24 | 14-24 |
| SRAM | 128b-1k | 128b-512b | 2k | 512b-3k |
| CDT | Não | Sim | Sim | Não |
| TCB | 1 | 1 | 2 | 2 |
| ADC | 1x10 bits | 1x10 bits | 2x10 bits | 1x12 bits com PGA |
| Pino VREF | Não | Não | Sim | Sim |
| AC | 1 | 1 | 3 | 1 |
| Evento * | 3 canais | 6 canais | 6 canais | 6 canais |
| CCL** | doisLUTA | doisLUTA | doisLUTA | 4LUTA |
* Os canais de eventos, exceto nos tinyAVRs da série 2 (e em todos os AVRs modernos não minúsculos), são subdivididos em dois tipos - síncronos (para o relógio do sistema) e assíncronos. Nem todos os geradores podem ser usados com um canal síncrono, e alguns usuários de eventos só podem usar canais síncronos, e as listas de canais são menos consistentes e mais . Essa loucura foi abandonada na primeira oportunidade – até o mega0 acabou com essa distinção.
** apenas séries 2 e peças não pequenas podem disparar uma interrupção com base no estado CCL.
Todas as partes possuem entrada analógica disponível na maioria dos pinos (todos os pinos em PORTA e PORTB 0-1 e 4-5). O segundo ADC na série 1+ também pode usar os pinos do PORTC como entradas (consulte a referência analógica para obter informações sobre como usá-los).
Estas são as opções de orçamento. Embora sejam suportados, eles não são recomendados. Eles nunca recebem o "impulso" que o tinyAVR série 1 obtém em 16k, não têm segundo TCB em qualquer configuração, não têm TCD, apenas 3 canais de eventos, nenhum dos quais pode transportar saída de eventos RTC. Essas peças possuem 2 LUTs CCL como a série 1 e estão disponíveis com até 16k de flash em configurações de 14, 20 e 24 pinos (apenas 4k para peças de 8 pinos) e até 1k SRAM.
Eles têm 2k, 4k ou 8k de flash e 128, 256 ou 512b de memória RAM, assim como a série 0. Eles não possuem o segundo ADC, a configuração AC tripla ou o segundo TCB, embora possuam o TCD.
De repente, aos 16k, as peças da série 1 tornam-se muito mais interessantes. Acompanhando o flash maior está um arsenal de periféricos que parecem adequados para um chip muito maior, e sejam 16k ou 32k, todos eles recebem 2k de SRAM. Todo o segundo ADC é único entre os AVRs. Parece ter sido o campo de testes para muitos recursos que apareceram de forma refinada na série AVR Dx. O preço não parece levar em conta os periféricos muito superiores da série 16k 1,
Como você pode ver na tabela acima, a série 2 é quase mais um sidegrade do que uma atualização. Eles têm um ADC muito melhor, o sistema de eventos e CCLs são "normais", e têm mais RAM, a parte de 14 pinos está disponível com 32k de flash (um 3214 aparentemente foi planejado, mas depois cancelado; foi longe o suficiente para estar no ATPACK por um tempo antes de ser removido)
Escrevi um breve resumo de quando você gostaria de usar quais séries, se a escolha certa ainda não for óbvia.
Na definição oficial da placa Arduino para seu pacote de hardware "megaavr", eles implicam que a nova arquitetura nas peças da série 0 do megaAVR (que é quase a mesma usada no tinyAVR série 0 e série 1) é chamada de "megaavr " - esse não é um termo oficial. A Microchip usa o termo “megaAVR” para se referir a qualquer peça “ATmega”, seja ela de estilo antigo ou periféricos modernos. Não existem termos oficiais para se referir a todas as partes do AVR de uma família ou de outra, e um funcionário da Microchip até negou que existisse tal termo internamente. Não tenho certeza de como você pode fabricar dois conjuntos de peças, com as peças de cada conjunto tendo tanto em comum entre si e tão pouco em comum com o outro conjunto, sem que ninguém invente uma frase para se referir a qualquer um deles.
Neste documento, antes da versão 2.0.2, usamos a convenção do Arduino e, apesar de ter passado mais de um ano desde então, ainda continuo encontrando lugares onde os chamo de megaAVR. Por favor, relate isso usando um problema do github, se encontrar algum. Observe que os termos avr e megaavr ainda são usados internamente (por exemplo, em bibliotecas, para marcar com quais partes uma determinada biblioteca é compatível ou separar versões diferentes de um arquivo com base no que elas serão executadas). Isso continuará - temos que seguir isso para obter compatibilidade com o que a equipe do Arduino iniciou com o núcleo do Uno WiFi Rev. 2 e do Nano Every.
De qualquer forma, é necessária alguma palavra para se referir aos dois grupos e a Microchip não forneceu nenhuma. Na ausência de um termo oficial, tenho me referido aos dispositivos AVR anteriores a 2016 (com registros PORTx, DDRx, etc. para pinos) como " AVR clássico " e aqueles que o Arduino chama de megaavr como " AVR moderno ". Também existem algumas peças cujos módulos de E/S são muito mais parecidos com AVRs clássicos, mas que também possuem uma versão significativamente pior do conjunto de instruções e tamanhos de flash típicos de 1k ou menos. Eles usam a variante AVRrc (para núcleo reduzido) do AVR, enquanto a maioria dos AVRs clássicos usam AVRe ou AVRe+, e os AVRs modernos usam AVRxt. As partes AVRrc não são suportadas por este núcleo, e na infeliz ocasião em que eu precisar discutir essas partes profundamente decepcionantes, irei me referir a elas como partes " Reduced Core AVR ", já que esse é seu nome oficial, embora eu tenha muitos frases mais coloridas para eles. É recomendado que nenhum projeto use um AVR de núcleo reduzido , ponto final. Não que sejam obsoletos, são simplesmente péssimos. Recomenda-se que " AVRs modernos " (aqueles com os novos periféricos e conjunto de instruções AVRxt ) - série Ex, série Dx, tinyAVR 0/1/2 ou mega0 sejam usados para todos os novos designs
Folha de dados para o novo tinyAVR série 2 - Embora a folha de dados "cobre" apenas as peças de 16k, elas afirmam claramente que não há diferenças nos recursos entre as peças com a mesma contagem de pinos (ou seja, não há peças "douradas" como o 16k/32k série 1), apenas entre peças com contagens de pinos diferentes e somente conforme ditado pela contagem de pinos (ou seja, um recurso na peça de 24 pinos estará na peça de 14 pinos, a menos que o de 14 pinos não tenha os pinos necessários e seja algo que não pode ser usado sem pinos). As peças de 14, 20 e 24 pinos estão todas listadas com flash de 4k, 8k, 16k e 32k; essas opções de tamanho de flash, respectivamente, vêm com 512, 1024, 2048 e 3072 bytes de SRAM (ou seja, as partes 4k e 8k têm o dobro da SRAM), as partes 4/8k recebem 128 bytes de EEPROM, as maiores recebem 256 Peças de 14 pinos vêm em SOIC e TSSOP, 20 pinos em SOIC (largo), SSOP e outros. QFN pequenino como o 1616 (desta vez eles nos deram a parte de 32k naquele pacote também, mas boa sorte em conseguir um, está em espera em todos os lugares - não consegui marcar nenhum) e 24 pinos no mesmo VQFN que o 3217.
TWI, SPI, USART0, AC0 permanecem inalterados, assim como NVMCTRL (as alterações necessárias no bootloader foram exclusivamente em relação ao suporte ao segundo USART). Opções de relógio inalteradas. TCB0 e TCB1 foram atualizados para a versão da série Dx: opção de evento de clock off, cascata e bits INTCTRL separados para OVF e CAPT - boas adições, mas nada relevante para o núcleo em si), e todas as partes possuem ambos TCBs. Agora temos 4 LUTs CCL e 2 sequenciadores, em vez de 2 e 1 - e eles podem disparar interrupções como outras partes do CCL (e ao contrário do tinyAVR série 0/1). Uma das características mais interessantes é que, como esperado, eles têm um segundo USART (aquele barulho que você ouve é o ATtiny841 e o ATtiny1634 soluçando no canto). Os registros PORTMUX agora são nomeados como o restante dos AVRs modernos - mas não perdemos o controle individual sobre os pinos de cada canal TCA WO. EVSYS agora funciona como em peças não-tinyAVR-0/1-Series (o que é uma mudança bem-vinda - a série 0/1 era estranha, e algumas das maneiras pelas quais seu EVSYS era diferente eram uma droga ). Os recursos da Série 1 do TCD0, AC1/2, DAC0 e ADC1 desapareceram . Em seu lugar, o ADC0 é muito mais sofisticado e quase irreconhecível, o primeiro novo AVR lançado desde a aquisição que apresentava um verdadeiro diferencial ADC. (enfileirar outro lamento agonizante do pobre '841, que também tem um ADC incrivelmente sofisticado com ótimas opções de diferenciais, mas que parece completamente desatualizado perto dos novos)... a julgar pelo volume de postagens sobre diferentes tópicos que tenho parece, tenho a sensação de que o ADC diferencial não estava no topo da maioria de suas listas de desejos - mas estava no topo das listas dos principais clientes de chips, e é isso que estamos obtendo. E já era hora de conseguirmos um ADC diferencial adequado em vez daquele da série Dx. E é realmente muito chique. Veja abaixo.
megaTinyCore fornece uma implementação analogRead() e funções mais poderosas para usar oversampling e PGA (veja a seção de recursos analógicos abaixo).
Ah, e mais uma coisa... a configuração dos pinos UPDI tem as opções antigas - UPDI, I/O ou Reset... e uma nova: UPDI no PA0, com pino RESET de hardware no PB4! O Optiboot finalmente será uma opção viável e confortável pelo menos nas peças que possuem PB4, ou seja, não nas peças de 14 pinos. Que também é (se as vendas da minha loja Tindie servirem de indicação) o tipo mais popular.
Você acha que haverá 3 séries? Eu não. DD e os EA estão claramente perseguindo-os e assumindo posições estratégicas em torno do território tinyAVR. Acho que é apenas uma questão de tempo até que a marca seja eliminada, como fizeram com o megaAVR após o megaAVR série 0. Isso não é necessariamente uma coisa ruim: todas as peças das séries Dx e EA são muito semelhantes em mapeamentos de pinos e comportamento, o que é muito bom. Os minúsculos são menos sistemáticos, embora distribuam pinos para mais periféricos. O princípio orientador parece ter sido “nenhum periférico deixado para trás”. Compare com os mapeamentos de pinos das séries Dx e EA, onde tudo segue um plano mestre fixo. As peças têm ou não um determinado pino e, se não tiverem, não têm essa função disponível. Em ambos os grupos amplos, acho que há um gerente de produto cujo trabalho é chicotear os engenheiros que pensam em fazer uma "exceção" à Pinagem Sagrada (uma vez que essas exceções inevitavelmente proliferam e são como terminamos com as atribuições de pinos do alvo de dardos com os olhos vendados no tinyAVR clássico)
A numeração dos pinos é estranha nos tinyAVRs, e a culpa é da Microchip - eles numeraram os pinos dentro das portas de maneira estranha: ele começa em ordem, exceto que PA0 é UPDI e geralmente não pode ser usado, então os pinos do PORTB são numerados na ordem inversa, então PORTC volta para a mesma numeração anti-horária de PORTA. Dá um tempo! Já que a tradição é usar o pino 0 para o primeiro pino, e fazer com que o último número seja o pino que você não pode usar sem colocar um fusível que dificulta a programação do chip. Eu preferiria poder numerá-los no sentido anti-horário, começando com A0, sem quebrar as convenções não escritas do código do Arduino. Pode-se argumentar que tomei uma decisão errada sobre os mapeamentos de pinos - talvez eles devessem ter começado com PA0 (inutilizável a menos que o fusível estivesse definido, caso em que o chip é difícil de programar) como pino 0 e depois numerado os pinos no sentido anti-horário. Mas você ainda não poderia fazer o tipo de truque que faria se todas as portas estivessem em ordem, a menos que numerasse os pinos PORTB ao contrário. Se você conseguisse se livrar da expectativa de que todos os pinos fossem numerados em ordem (e usasse apenas a notação PIN_Pxn), economias significativas poderiam ser obtidas
Eu prevejo que dentro de 2 a 4 anos haverá um AVR DA, DB, DD. Peças das séries DU (USB), EA e D/E/F com número de pinos de 8 (ou pelo menos 14) e peças de 64 pinos com flash de 128k e o novo ADC. E nada mais com a marca ATtiny. Possivelmente a maior questão que resta é se algum dia eles substituirão o ATmega2560 por um AVR moderno com 100 pinos no total (provavelmente 80-88 dos quais são E/S) e opções de flash de até 256k; Isso apresentaria três problemas - primeiro, após 56 pinos de E/S, não há mais registros VPORT - o espaço baixo de E/S está cheio com 28 VPORT e 4 GPIORs. Como eles lidarão com as 4 portas extras? (no 2560, elas eram apenas portas de segunda classe que eram acessadas mais lentamente e não tinham acesso de ciclo único. Tenho algumas reflexões sobre isso e a viabilidade de quão poucos opcodes estão disponíveis no apêndice A aqui. e segundo, para violar A barreira de 128K no Flash, você precisa ir a um balcão do programa de 17 bits. "D X parte em 256k de flash teria 32k de carneiro. Agora lembre -se de como o Progmem funciona no DX - eles não podiam ir até 32. 24K RAM é definitivamente possível, talvez até 28, mas a 32k, mais 32k para Flash mapeado, não deixa espaço para os SFRs, que estão no mesmo espaço de endereço.
Eu vendo placas de breakout com regulador, cabeçalho de atualização e cabeçalho em série na minha loja Tindie, bem como nas tábuas nuas. A compra da minha loja ajuda a apoiar um desenvolvimento adicional no núcleo e é uma ótima maneira de começar a usar essas novas peças emocionantes com o Arduino. Atualmente, as placas ATTINY1624 estão disponíveis, mas as peças de 20 e 24 pinos não serão vendidas como uma placa montada até que um design de PCB recém-revisado esteja de volta da casa do quadro para ativar o Autoreset no pino de retenção alt. Há também uma revisão da placa de 14 pinos - achada que é amplamente cosmética. A máscara de solda amarela precisa ir, pois a legibilidade parecia piorar nos últimos lotes. As novas placas também padronizam um espaçamento de 0,6 "entre as fileiras de pinos, em vez do espaçamento atual de 0,7", para que você poderá, por exemplo, colocar o cabeçalho do pino usinado neles e conectá-los a um soquete de amplo mergulho, ou Use -os com nossa placa de prototipagem otimizada para esse espaçamento de linha. Os quadros da série 0 montados estão sendo descontinuados e não serão reabastecidos quando eles se esgotarem. O mesmo acontecerá para as peças de 16k 2-Series assim que as 32k estiverem disponíveis.
O ADC na série 2 e EA-Series são os melhores ADCs que foram lançados em um AVR na era moderna do AVR. Além daqueles dois. As comparações mais próximas são os AVRs clássicos que obtiveram ADCs diferenciais com recursos de alto nível (o T841, Mega2560 e (surpreendentemente) o T861 sendo os concorrentes mais fortes). Embora não seja capaz do ganho insano de 100x e 200x que algumas partes se gabaram nos dias clássicos da AVR, nunca ficou claro para mim quanto do que estava sendo amplificado foi simplesmente ruído (considerando minha experiência reconhecidamente limitada tocar com ADCs diferenciais Vou dizer "provavelmente a maior parte, e definitivamente a maior parte, se você me deixar projetar o hardware, não conheço analógico!"). Esse novo ADC é certamente altamente capaz, com a verdadeira capacidade diferencial (ao contrário da série DA e DB), e uma que sobe de cabeça e ombros acima de qualquer coisa disponível em quaisquer outros AVRs modernos até o momento. O amplificador de ganho programável é uma nova capacidade, e resta ver que tipo de feitos de medição analógica as pessoas são capazes de sair dela; certamente parece promissor. Será especialmente interessante entender as diferenças entre usar o PGA com 1x ganho, vs não usando o PGA e os benefícios e desvantagens de fazê -lo. (O microchip seria bem servido por um documento que discutia como escolher a configuração correta do ADC para uma tarefa no caso geral; levantei essa preocupação com o microchip e a pessoa com quem falei indicou que era uma alta prioridade; enquanto A situação foi bastante aprimorada, ainda parece que o grupo DOC foi especificamente instruído a não fazer qualquer tipo de recomendação concreta real .
A adição de acumulação de 1024 amostras para fins de superamostragem e dizimação é uma adição bem-vinda, embora uma que também corra o risco de subestimar a magnitude e a relevância do erro de deslocamento. (Chegando 1024 amostras (todas com um determinado erro de deslocamento), depois dizimando a soma para produzir uma medição de ADC de 17 bits, facilita a imaginação de que qualquer erro seria confinado aos dois bits mais baixos. Mas se o erro Digamos que 5 LSB em uma única medição, quando você acumula 1024 amostras e dizime, você tem um erro de deslocamento de 160, é extremamente fácil ver isso e pensar que não é o sinal.
O primeiro chip em tamanho real (não pequeno) com o novo ADC está disponível em pacotes de 28 a 48 pinos com até 64k Flash. Havia a especulação usual sobre o que se algo mudaria de 2-Series para EA-Series: parece que a resposta é que um dos botões confusos foi removido e o corte automático de sinal para medições acumuladas (
O temporizador do tipo D é usado apenas para PWM nas peças da série 1 20/24 pinos 1 nas configurações de pino PWM padrão. Nas partes menores, não nos deixaria aumentar o número total de pinos PWM. Somente os pinos WOC e WOD (no PC0 e PC1, respectivamente), já não possuem PWM acionado por TCA. Como tal, como o analogwrite () não suporta nenhum recurso que seja ativado desligando o modo dividido (como PWM de 16 bits) ou aprimorado usando o timer tipo D (como ajustar a frequência), seria apenas pior, porque Seria necessário espaço adicional para armazenar a rotina para ligar e desligar o PWM de dois tipos de timer, em vez de um. Isso não é insignificante nas peças flash menores; É da ordem de 600 bytes. 150 para digitalWrite () e 450 para analogwrite () se forem chamados em um pino TCD PWM. O otimizador deve ser capaz de otimizar a parte dessas funções nesse caso, já que os pinos usados com essas funções não incluem pinos PWM TCD. Nota O otimizador os considerará independentemente, ou seja, o digitalWrite () incluirá o código para desativar o TCD PWM se for usado com um pino que usa TCD para PWM, se você chama ou não o analogWrite () nesse pino.
Ao contrário de quase todos os outros AVRs de todos os tempos (eu consigo pensar em talvez 3 exemplos, e apenas um deles é um "bônus" e não um "inaconado"), existem recursos adicionais de "bônus" baseados no tamanho do flash de peças dentro de uma família . As versões de 16k e 32k (somente) têm alguns recursos extras (que também não parecem ter sido considerados para preços) - todos eles têm 2k de RAM, sejam 16k ou 32k, eles têm 3 comparadores analógicos (incluindo um modo de janela opção), um segundo timer do tipo B do tipo B segundo - e o mais estranho de tudo o que eles têm um segundo ADC, diferindo apenas nos quais os canais correspondem!
Ao contrário dos AVRs clássicos, nessas partes, o flash é mapeado para o mesmo espaço de endereço do restante da memória . Isso significa que pgm_read_*_near() não é necessário para ler diretamente do flash. Por esse motivo, o compilador coloca automaticamente qualquer variável declarada const em progmem e acessá -la adequadamente - você não precisa mais declará -los explicitamente como progmem. Isso inclui literais de cordas citadas; portanto, a macro f () também não é mais necessária, embora para manter a compatibilidade com algumas bibliotecas de terceiros, f () ainda declara seu argumento progmem.
No entanto, observe que, se você declarar explicitamente uma variável progmem, ainda deverá usar as funções pgm_read para lê -la, assim como nos AVRs clássicos. Quando uma variável é declarada progmem em peças com flash mapeado de memória, o ponteiro é deslocado (o endereço é relativo ao início do flash, e não no espaço de endereço); Esse mesmo deslocamento é aplicado ao usar as macros pgm_read_*_near() . Observe que declarar as coisas progmem e acessar com pgm_read_*_near , embora funcione bem, é mais lento e desperdiça uma pequena quantidade de flash (em comparação com simplesmente declarar as variáveis const); O mesmo vale para a macro f () com cordas constantes em 2.1.0 e posterior (por um período de tempo antes de 2.1.0, F() não fez nada - mas isso causou problemas para bibliotecas de terceiros). Os autores sustentaram que o problema estava com o núcleo, não a biblioteca, e minha escolha era aceitar menos eficiência ou negar aos usuários acesso às bibliotecas populares). Usando a macro F() pode ser necessária para a compatibilidade com algumas bibliotecas de terceiros (os casos específicos que forçaram o retorno de F() sobre nós não eram desse tipo - realmente fomos capazes de fazer os que eu conhecia sobre o trabalho com o F ()-Código como Noo e eles ocuparam alguns bytes a menos flash como resultado).
As versões automotivas também devem funcionar. Você deve sempre selecionar as velocidades de relógio derivadas de 16 MHz nessas peças. Eles não suportam operação de 20 MHz e as opções de relógio sintonizadas não devem ser usadas.
Agora, na parte boa, onde conversamos sobre como tudo isso é exposto por Megatinycore. Começaremos com a questão de como você deve nos referir aos pinos para obter melhores resultados e, em seguida, avançar para os principais recursos, opções de menu, antes de terminar com uma série de links para documentos com mais detalhes em vários subsistemas.
A questão simples de como se referir a um pino para analogread () e DigitalRead (), particularmente em hardware não padrão, tem sido uma fonte persistente de confusão entre os usuários do Arduino. É minha opinião que grande parte da culpa repousa com as decisões tomadas pela equipe do Arduino (e autor de fiação diante deles) sobre como os pinos deveriam ser referidos; A designação de alguns pinos como "pinos analógicos" leva as pessoas a pensar que esses pinos não podem ser usados para operações digitais (elas são melhor pensadas como "pinos com entrada analógica" - como como existem "pinos que podem gerar PWM"). O fato de os pinos serem tradicionalmente renumerados confundiu ainda mais a água. Para peças clássicas de AVR clássicas não padrão, as questões são frequentemente pioradas por múltiplos e incompatíveis "mapeamentos de pinos" criados por vários autores ao longo dos anos para tornar a parte agir "mais como um UNO" ou para algum outro propósito (Attinycore é um particular Mess dessa maneira, com algumas partes com três mapeamentos de pinos totalmente diferentes, em pelo menos um caso, um dos mapeamentos alternativos é um trabalho de inspiração de diabo de puro mal, exigindo nada menos que uma tabela de pesquisa adicional para converter pinos analógicos em digital pinos).
Esse núcleo usa um esquema simples para atribuir os números de pinos Arduino: os pinos são numerados a partir do pino de E/S mais próximo do VCC como o pino 0 e prosseguindo no sentido anti-horário, pulando o pino Updi (principalmente) não utilizável. O pino Updi é então atribuído ao último número de pinos (como observado acima, é possível ler o pino Updi (trabalho analógico e digital), mesmo que não seja definido como GPIO). Recomendamos isso como último recurso: o pino Updi sempre possui seu pullup ativado quando não está definido como um pino GPIO e um sinal que se parece muito com a sequência de ativação da UPDI causará operação indesejada.
Para evitar toda a confusão sobre identidades de pinos e eliminar a ambiguidade, recomendamos o uso da notação pin_PXN para se referir a pinos, a menos que você esteja usando uma placa de desenvolvimento com números ou nomes diferentes para os pinos impressos. Isso maximizará a portabilidade do seu código para outro hardware semelhante e facilitará a consulta de informações sobre os pinos que você está usando nas folhas de dados relevantes, caso sejam necessárias.
Essa é a maneira recomendada de se referir aos pinos #defines também é fornecida do formulário PIN_Pxn , onde x é a, b ou c e n é um número 0-7 - (não deve ser confundido com o pin_an define descrito abaixo). Eles apenas resolvem o número de pinos digitais do pino em questão - eles não passam por um caminho de código diferente ou qualquer coisa. No entanto, eles têm utilidade específica ao escrever um código que funciona em toda a linha de produtos com periféricos vinculados a certos pinos (por porta), como a maioria dos periféricos. Várias partes do código de demonstração na documentação aproveitam isso. A manipulação direta da porta também é possível - e, de fato, várias opções adicionais poderosas estão disponíveis para ela - consulte a manipulação direta da porta .
PIN_Pxn - não Pxn , e não PIN_xn - essas coisas significam coisas diferentes!
Quando um único número é usado para se referir a um pino - na documentação ou no seu código - é sempre o "número do pino Arduino". Estes são os números de pinos mostrados em laranja (para pinos capazes de analogread ()) e azul (para pinos que não estão) nos gráficos de pinagem. Todas as outras maneiras de se referir aos pinos são #decididas para o número de pinos Arduino correspondente.
O núcleo também fornece An e PIN_An (onde n é um número de 0 a 11). Assim como no núcleo oficial, PIN_An é definido como o número de pinos digitais do pino compartilhado com o canal analógico n, eles se referem aos números do canal ADC0. Esse sistema de nomenclatura é semelhante ao usado em muitos núcleos clássicos de AVR , mas aqui, eles são apenas #definidos como o número de pino Arduino correspondente . Se você precisar obter o número do canal analógico em um pino digital, use a macro digitalPinToAnalogInput(pin) - mas você só precisará disso se estiver escrevendo uma biblioteca ADC avançada.
Essas peças (bem, pelo menos as séries 1/2-a série 0 foi para uma opção de orçamento, exceto que não diminuíram o orçamento e são apenas alguns centavos mais baratos) fornecem uma excelente caixa de ferramentas de versátil e periféricos poderosos; Os de ponta estão em pé de igualdade com ou melhor que as peças megaavr clássicas - por um preço do TinyAVR. Um dos princípios orientadores do design do Megatinycore, como nos meus outros núcleos, é permitir que as partes suportadas atinjam todo o seu potencial - ou o mais próximo possível das limitações do Arduino. Esta seção (muito grande) abrange os recursos dessas peças e como elas são expostas pelo Megatinycore, bem como as características do próprio núcleo. Esta seção (muito grande) tenta cobrir cada uma das áreas de características. Tente encontrar o recurso com o qual você está trabalhando se estiver tentando usar algum recurso de chip e ter problemas!
20 MHz interno (4,5V -5.5V - Típico para sistemas 5V)
16 MHz interno (4,5V -5.5V - Típico para sistemas 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 testado)
1 MHz interno (1,8V-5.5V, mal testado)
Relógio externo de 20 MHz (4,5V-5.5V, mal testado)
Relógio externo de 16 MHz (4,5V-5.5V, mal testado)
Relógio externo de 12 MHz (2.7V-5.5V, mal testado)
Relógio externo de 10 MHz (2.7V-5.5V, mal testado)
Relógio externo de 8 MHz (2.7V-5.5V, mal testado)
6 MHz interno (sintonizado, não testado)
5 MHz interno (sintonizado, mal testado)
4 MHz interno (sintonizado, mal testado)
2 MHz interno (sintonizado, mal testado)
1 MHz interno (sintonizado, mal testado)))
7 MHz interno (sintonizado, para masoquistas, não testados)
8 MHz interno (sintonizado, mal testado)
10 MHz interno (sintonizado, mal testado)
12 MHz interno (sintonizado, não testado)
14 MHz interno (sintonizado, para masoquistas, não testados)
16 MHz interno (sintonizado)
20 MHz interno (sintonizado)
24 MHz interno (sintonizado, overclocked, mal testado)
25 MHz interno (sintonizado, overclocked, mal testado)
30 MHz interno (sintonizado, com overclock, mal testado) - 0/1 -série requerem a configuração de fusível OSCCFG "20MHz"; As peças da Série 2 podem ou não ser capazes de atingir 30 com "16 MHz" selecionados.
32 MHz interno (sintonizado, com overclock, mal testado) - apenas 2 -Series, overclocking muito otimista, pode ser instável.
Relógio externo de 24 MHz (overclocked, mal testado)
Relógio externo de 25 MHz (overclocked, mal testado)
Relógio externo de 30 MHz (overclocked, mal testado)
Relógio externo de 32 MHz (overclocked, mal testado)
Não fazemos reivindicações sobre faixas de tensão ou temperatura para peças com overclock - tudo o que afirmamos é que pelo menos um dos chips que trabalhamos a essa velocidade à temperatura ambiente, executando um esboço específico, a 5V. Espera -se que sua milhagem varie, mas geralmente é melhor com uma especificação F versus uma peça de N ou U Spec.
IMPORTANTE - Leia sobre o ajuste antes de selecionar qualquer opção sintonizada!
Mais informações sobre essas velocidades de relógio podem ser encontradas na referência do relógio
As tensões mostradas são que são garantidas para funcionar pelas especificações do fabricante (a menos que empurre os limites da faixa de temperatura operacional, essas peças normalmente se saem muito melhor (as 2-Series geralmente funcionam a 32 MHz e 5V @ temperatura ambiente, mesmo a partir do oscilador interno; o 0 A série 1 também geralmente funcionará a 32 MHz com relógio externo, desde que a fonte de alimentação seja um estábulo 5.0-5.5V).
Nenhuma ação é necessária para definir o fusível OSCCFG quando o esboço é carregado via UPDI. Quando carregado através do OptiBoot, o fusível não pode ser alterado; portanto, o que foi escolhido quando o carregador de inicialização foi queimado é o que é usado, e apenas "Burn Bootloader" ou o upload de um esboço via UPDI mudará isso.
Todas as opções de velocidade do relógio do oscilador interno usam a calibração padrão de fábrica, a menos que uma opção "sintonizada" seja selecionada; nesse caso, a calibração é ajustada conforme documentado na referência de ajuste . Isso pode ser usado para obter operação de 16 MHz em um chip OptiBoot fundido por 20 MHz e vice -versa.
Consulte Referência de Grade de Velocidade para obter mais informações sobre as notas de velocidade do fabricante. Observe que essas são as tensões e as velocidades do relógio nas quais é garantido que funcione. Essas peças devem ser adequadas para uso em aplicações, onde uma falha inesperada de alguma descrição pode representar um risco para pessoas ou propriedades (pense em carros, equipamentos industriais, aviões, reatores nucleares - lugares onde as pessoas poderiam morrer se a parte funcionasse) e eu Acredite também para aplicações militares, que têm requisitos de confiabilidade semelhantes, apenas pelo motivo oposto. Os usuários típicos de hobby ficarão muito mais relaxados com o potencial de problemas de estabilidade, com falhas sendo pouco mais que um incômodo e os extremos das partes estendidas da faixa de temperatura sendo muito além do que jamais precisaríamos. Supondo que a placa tivesse um revestimento à prova d'água, termicamente, uma parte n grau deve ser capaz de funcionar de acordo com o grau de velocidade em uma panela de água fervente. E isso é apenas o N-Spec. A especificação F deve ser boa para 125!
Foi estabelecido que as peças de temperatura estendida overclock melhor o que faz sentido. Espera -se que uma parte que seja especificada a 20 MHz a 125C tenha uma chance melhor de correr a 32 MHz à temperatura ambiente do que uma especificada apenas para correr a 20 MHz apenas a 105c
A partir da versão 2.4.0, agora fornecemos uma opção "placa de microchip oficial". Isso não faz nada de especial além de definir LED_BUILTIN como o alfinete que tem o LED nessa placa, em vez de A7, e definindo um macro PIN_BUTTON_BUILTIN definido como o pino com o botão do usuário e "fazer upload" com o não A versão -OptiBoot sempre usa o programador/depurador a bordo; Ferramentas -> Programador será usado apenas para "Burn Bootloader" e "Upload usando o programador". No caso do Nano de plataforma XPlained, ele também seleciona a versão do carregador de inicialização que usa os pinos alternativos para a porta serial - ele não usa automaticamente os pinos alternativos para o USART0 como se você tivesse feito serial.swap (1) ainda - A funcionalidade para suportar a troca padrão de pinos seriais virá em uma atualização futura, juntamente com outras alterações na maquinaria subjacente ao mecanismo PINSWAP, que esperançosamente reduzirá o uso do flash.
Como observado acima, eles podem não funcionar corretamente em plataformas Linux de 32 bits. Isso está além do meu controle; Não construo binários avrdude e também não estou assumindo essa tarefa. Eu já tenho muitos.
blink() pega mais flash no xplained mini vs o xplained Pro?Ambos têm o mesmo Attiny817! Como eles podem ser diferentes?
Pelo mesmo motivo em que o piscar levará mais flash se você alterá -lo para usar PIN_PC0 em vez de PIN_PB4 : pc0, usado no mini xplained é um pino PWM, enquanto o PB4, usado pelo XPLER PRO não é. Como esse é o único alfinete em que o digitalWrite () está sendo usado, o compilador é livre para otimizar qualquer coisa que não seja necessária para o DigitalWrite () nesse pino, incluindo a funcionalidade para desativar a saída do PWM em um pino que suporta PWM . A diferença desaparece se o DigitalWrite () também é usado em um pino que suporta PWM nos dois dispositivos (resultando no resultado mais alto de uso do flash) ou se o digitalWrite () for substituído pelo DigitalWritefast (), o que usará menos flash (mas assume que você ganhou T chamá -lo em um pino que saindo PWM).
Sempre que um programador updi é usado para fazer upload de código, todos os fusíveis que podem ser definidos "com segurança" (como em, sem risco de bloquear a placa ou bloquear a placa se não tiver acesso a um programador de HV) e que tenha algum As opções de configuração internas serão definidas. Assim, exceto onde observado, o comportamento sempre corresponderá ao menu Ferramentas selecionadas. Em resumo, eles são tratados da seguinte maneira:
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ão é seguro, porque definir isso como uma tensão mais alta do que a placa está em execução e ativando -a "tijolo" a placa até que uma tensão operacional mais alta possa ser fornecida; Isso pode ser particularmente estranho se for soldado no mesmo PCB que os dispositivos que não tolerarão essas tensões.
SYSCFG0 não é seguro, porque é aí que vive RSTPINCFG ; Alterar isso pode deixar a placa não agrícola, exceto por meio da programação de atualização de HV, e nem todos têm um programador de atualização de HV. No futuro, se/quando um programador que garante a capacidade de atualização do HV que pode ser selecionada como um programador (ou seja, torna -se possível fazer uma opção de ferramentas -> programador que funcionará apenas com programadores de HV), esse fusível será definido automaticamente ao usar aquele programador.
Como resultado em 2.2.0 e mais tarde, você não precisa mais 'queimar o carregador de inicialização' para alternar entre velocidades derivadas de 16 MHz e 20 MHz ao fazer o upload usando updi
Esse núcleo sempre usa a otimização do tempo de link para reduzir o uso do flash - todas as versões do compilador que suportam as peças Tinyavr 0/1/2 -Series também suportam LTO, portanto, não há necessidade de torná -lo opcional, como foi feito com Attinycore. Foi uma grande melhoria no código quando introduzida, normalmente da ordem de 5 a 20%!
Todas essas partes têm um grande número de entradas analógicas-DA e DB-Série têm até 22 entradas analógicas, enquanto a série DD tem entrada analógica em cada pino que não é usado para acionar o cristal de HF (embora os pinos no PORTC estejam Somente suportado quando o MVIO é desligado). Eles podem ser lidos com analogRead() como em um AVR normal, e padrão para a resolução de 10 bits; Você pode alterar para os 12 bits completos com analogReadResolution() e usar as funções analogread aprimoradas para fazer leituras automaticamente de amostragem e dizimada para obter uma resolução mais alta e fazer medições diferenciais. Existem 4 referências de tensão interna em 1.024, 2.048, 4.096 e 2.5V, mais suporte para tensão de referência externa (e VDD, é claro). As leituras do ADC são feitas 3 vezes mais rápidas que um AVR clássico, e essa velocidade pode ser dobrada novamente se o que você está medindo for baixa impedância ou estender o tempo de amostragem por um fator muito para ler fontes de impedância muito alta. Isso é detalhado na referência analógica.
As peças da série DX têm um DAC de 10 bits que pode gerar uma tensão analógica real (observe que isso fornece baixa corrente e só pode ser usado como referência de tensão ou tensão de controle, não pode ser
