megaTinyCore
2.6.10 - Critical Bugfix
我們現在有一個 Github 討論部分。當一個問題肯定是核心缺陷時，如果你創建了一個問題，那麼你會減少修復它所需的時間，因為我優先考慮問題而不是趕上討論。
這修正了 2.6.x 中存在的許多錯誤
2.6.x 顯著改進了串行閃存佔用空間，同時添加了功能，線路可以將從設備從睡眠狀態喚醒而不會損壞數據，等等，請參閱變更日誌。
只能使用從 arduino.cc 下載的 Arduino IDE 版本，切勿使用從 Linux 套件管理器下載的版本。套件管理器通常有 Arduino IDE，但對其進行了修改。儘管他們總體上對 Arduino 或嵌入式開發一無所知，更不用說他們成功修改它所需的知識了。不應期望該核心在此類版本上工作，並且不會為了修復來自套件管理器的 IDE 版本而進行任何修改。
這是 Arduino 用戶端中的一個錯誤。
1.8.13 和 2.x 之間的 IDE 版本出現了重大的新缺陷。然而，IDE 版本 1.8.2 及更早版本具有未修復的嚴重缺陷。我相信他們終於推出了 IDE 的工作版本，我相信最新版本能夠正確安裝我的核心。
在 megaTinyCore 2.6.0 之前，當您在 arduino 資料夾中手動安裝 core 時，手動安裝 megaTinyCore 會導致 IDE V1.8.14 由於此錯誤而崩潰。 1.8.14及更高版本的使用者必須使用megaTinyCore 2.6.0版本。
我在速賣通買了很多電子產品。對於中國公司製造的產品來說，這是一個很好的市場，而且大部分都是通用的，包括大量西方國家的個人無法以任何其他方式獲得的組件（例如，最小訂單是捲軸或類似的東西- 如果你甚至可以找到一個）與無名中國晶片製造商合作的組件供應商）。對於西方主要製造商的最新半導體產品線來說，這並不是一個好地方，特別是在上述晶片歷史性短缺的情況下。現代 AVR 設備在透過這些管道可用時，經常被報告為假冒或有缺陷（例如 ATtiny412 認為自己是 416，可能無法正確執行開機重設）。就這一點而言，您可能不想在速賣通上購買任何 AVR 微控制器……如果您避免使用第三方LGT8 晶片並留意使用ATmega168p 的主機板，那麼組裝板（如Arduino Nano 克隆版）通常可以工作。關於這些假晶片的來源有很多有趣的理論，而 Microchip 在這個問題上完全保持沉默。
本文檔最好在線查看（而不是在您喜歡的文本編輯器中打開 Markdown 文件），以便可以單擊鏈接並顯示內聯圖像，並且可能最重要的是，有時可以使表格正確呈現。同樣，這個[文件可以在 github 上找到](https://github.com/SpenceKonde/megaTinyCore)(https://github.com/SpenceKonde/megaTinyCore)
舊版本無法在工具 -> 程式設計師選單中正確處理程式設計師，這會隨著安裝的核心數量的增加而迅速降低使用者體驗。他們不合適。從 1.8.14 開始的最新版本（包括 1.8.17、1.8.18 和 1.8.19）可能會產生「恐慌：未找到主要版本」錯誤，因為它們無法正確解析 platform.txt。從 2.6.0 開始，我們在發布之前直接手動修改 platform.txt，所以這不是一個問題
當透過板管理器安裝megaTinyCore時，會自動安裝所需版本的工具鏈。所有 0/1/2 系列部件均受支援，無需額外步驟。在2.2.7 之前，我們使用Arduino7 版本的avr-gcc（gcc 7.3.0 和avrlibc 3.6.1）以及截至2020 年6 月的最新ATpack。鏈，其中已更新所有新支援部件的 ATpack。 2.2.7 使用Azduino3，2.3.0+ 使用Azduino4，從2.6.0 開始，我們使用Azduino5（儘管它對我們沒有任何好處，除了節省四分之一GB 的HDD 空間和40mb 的下載頻寬（如果同時安裝） megaTinyCore 和 DxCore 透過董事會經理。
手動安裝更加複雜 - 特別是如果您想要支援 2 系列；有關詳細信息，請參閱安裝指南。
適用於 tinyAVR 0 系列、1 系列和現在的 2 系列的 Arduino 核心。與「經典」tinyAVR 部件（由 ATTinyCore 支援）相比，這些部件具有改進的架構，具有改進的周邊和改進的某些指令的執行時間（這些部件在兩個方面與高級 AVR Dx 系列相似，以及megaAVR 0 系列晶片（如官方Nano Every 和Uno Wifi Rev. 2 上使用的ATmega4809（儘管Arduino 團隊已盡最大努力限制它們））採用ATtiny 系列典型的低成本小型封裝。所有這些零件都具有至少一個硬體 UART、一個 SPI 和 TWI 介面（沒有像 ATtiny85 那樣的 USI 垃圾）、一個強大的事件系統、可配置的自訂邏輯、至少一個片上模擬比較器，一個令人驚訝的精確內部振盪器，對於1 系列來說，是一個實際的DAC 輸出通道，對於2 系列來說，是一個奇特的差分ADC。
此外，tinyAVR 0/1/2 系列零件價格便宜- 最高端零件 3226 和 3227，具有 32k 快閃記憶體和 3k SRAM（相對於 Uno/Nano/ProMini 中使用的 ATmega328p 的 2k SRAM）運行數量略高於1 美元-少於許多8k 經典AVR ATtiny 零件（“AVR 指令集，PIC 價格”）。所有這些部件的額定運行頻率為 16 MHz 或 20 MHz（4.5-5.5v），無需外部晶體，並且內部振盪器對於 UART 通訊來說足夠準確。
這些使用 UPDI 編程，而不是像經典 ATtiny 元件那樣的傳統 ISP。請參閱下文以了解更多資訊。獲得 UPDI 編程器很簡單 - 您可以使用基於 328p 的經典 Arduino 作為使用 jtag2updi 的編程器 - 或者為了使用更便宜的硬體獲得更好的結果，您可以使用任何 USB 串行適配器和電阻器（最好是二極體），使用隨附的SerialUPDI工具，或者您可以將AVRdude 與Microchip 編程器之一（開發板上基於mEDBG/nEDBG/EDBG 的編程器、Atmel-ICE 或SNAP）或任何模擬其中之一的UPDI 編程工具（據我所知）結合使用，所有這些都支持 - 如果有一個 avrdude 支持而我的核心不支持，請打開一個問題讓我知道！ ）。
這些元件支援串行引導程式Optiboot_x（基於與經典Arduino Uno 引導程式相同的程式碼庫，但經過了很大改動）（0/1 系列支援目前已上線，2 系列預計在5 月第一周提供） ；對新部件的調整是微不足道的），允許它們透過傳統的串行端口進行編程。有關此內容以及相關選項的更多信息，請參閱下面的 Optiboot 部分。安裝引導程式確實需要 UPDI 編程器。我在 Tindie 上銷售的組裝分線板可以預先引導加載（它們是根據需要引導加載的）。話雖這麼說， 0/1 系列部件以及 14 引腳 2 系列部件的 Optiboot 用戶體驗有點令人失望，因為它們缺少可與通常的自動重置電路一起使用的硬體重置引腳當串行端口打開時自動重置到引導程式。您需要完全停用 UPDI 編程（如果在初始引導加載後需要更改保險絲設定或引導程序，則需要 HV 編程器）或保持 UPDI 啟用，但在通電後 8 秒內開始任何上傳。 20 引腳和 24 引腳 2 系列零件支援“備用重置引腳”，使它們的行為更像傳統的 Arduino。
UPDI 編程接口是用於編程（和調試 -通用編程和調試接口）的單線接口，用於 tinyAVR 0/1/2 系列以及所有其他現代 AVR 微控制器。雖然人們總是可以從 Microchip 購買專用的 UPDI 編程器，但當您使用 Arduino IDE 而不是 Microchip 的（極其複雜的）IDE 時，不建議這樣做。關於 Microchip 官方程式設計師在 Linux 上出現問題的廣泛報導。有兩種非常低成本的替代方法來創建 UPDI 編程器，Arduino 社群在這兩種方法上比官方程式設計器擁有更多的經驗。
在 megaTinyCore 出現之前，有一個名為 pyupdi 的工具 - 一個簡單的 Python 程序，用於使用通過添加單個電阻修改的串行適配器上傳到配備 UPDI 的微控制器。但 pyupdi 無法在 Arduino IDE 中輕鬆使用，因此這不是一個選項。從 2.2.0 開始，megaTinyCore 引入了可移植的 Python 實現，這打開了許多大門；最初我們計劃改編 pyupdi，但在其作者和幾位 Microchip 員工的敦促下，我們將此功能基於 pymcuprog，這是一個「更強大」的工具，由 Microchip 開發和維護，其中包括相同的串行端口上傳功能，僅沒有效能優化。如果手動安裝，您必須新增適合您的作業系統的 Python 套件才能使用此上傳方法（系統 Python 安裝是不夠的，也不是必要的）。
有關接線的信息，請閱讀SerialUPDI 文件。
從 2.3.2 開始，隨著性能的顯著改進，以及使用二極管代替電阻器的接線方案的可靠性得到驗證，並且考慮到 jtag2updi 固件的不穩定，現在這是推薦的編程方法。從這個版本開始，編程速度提高了 20 倍，現在遠遠超過了 jtag2updi 的速度（透過 jtag2updi 進行編程的速度大致與透過「SLOW」速度選項上的 SerialUPDI 進行編程相當，57600波特率；正常的230400 波特版本程式大約比SLOW 版本或jtag2updi 快三倍，而「TURBO」選項（以460800 波特率運行，上傳速度比正常版本提高約50%。TURBO 速度版本應僅為與以4.5v 或更高電壓運行的設備一起使用，因為我們必須更快地運行UPDI 時脈才能跟上（它也不期望與所有串行適配器兼容- 這是提高性能的有意權衡），但它允許4 秒內上傳並驗證32kB 草圖。
正在迭代三種設計：雙端口串行適配器，其中兩個端口都是串行端口，雙端口串行適配器，其中一個端口始終為UPDI，以及單端口一個，其中一個開關用於選擇模式，以及一個選購的附加板LED 指示調變解調器控制線路的狀態。
這些將允許使用 SMT JST-XH 連接器或杜邦連接器 - 無論哪種方式都有 6 個引腳用於串列（FTDI 引腳排列如所標記）和 3 個引腳（用於 UPDI）。
這三個都能夠提供 3.3 或 Vusb（額定值 5V），或斷開 Vusb 和 3V3 的電源，並期望目標設備的供電電壓為 5.5V > Vdd > 1.8V。在這種情況下使用的邏輯電平將是所施加的電壓。請注意，在雙串行設備上，VccIO 電源軌是共享的！它們必須運行在相同的電壓下，是同一設備，或者必須將適配器設定為為它們供電並斷開電源。
根據適配器型號和作業系統的不同，需要不同的計時設定；然而，在Linux/Mac 上，即使是230400 波特率也需要進行設定才能避免失敗，大多數適配器在Windows 上會造成更大的時間損失，其中作業系統的串行處理速度足夠慢，不需要任何延遲......
這裡所說的「寫延遲」是為了讓頁擦寫指令執行完成；這需要非零時間。根據適配器、USB 延遲和隱式2 或3 位元組緩衝區（它就像USART，並且可能在內部實現為一個。到達的第三個位元組無處可去，因為硬體緩衝區只有2 位元組深）可能是足以讓它在沒有明顯延遲的情況下工作。或者，它可能會中途失敗並報告“Error with st”。適配器的延遲逾時越快，作業系統的串列處理越快，出現問題的可能性就越大。如果手動執行 prog.py，則由-wd命令列參數控制。從 2.5.6 開始，此寫入延遲更接近請求的實際時間（以毫秒為單位），以前它的粒度為幾毫秒，而 1 就足夠了，因此，它施加的懲罰是殘酷的，特別是在視窗。
選用指南：
FTDI 轉接器（FT232、FT2232 和 FT4232 等），包括在 eBay/AliExpress 上以約 2 美元的價格出售的假冒適配器，在 Windows 上默認有 16 毫秒的長得令人難以忍受的延遲。即使我們為了限制必須等待的延遲時間而設定的長度，這也會將 2.2 秒的上傳時間延長到超過 15 秒。您必須更改此設定才能獲得可接受的上傳速度：
一個可以由經典的 AVR Uno/Nano/Pro Mini 製作；廉價的 Nano 克隆是通常的選擇，因為價格足夠便宜，可以將其連接起來然後就這樣離開。我們不再提供此過程的詳細文件； jtag2updi 已棄用。如果您仍在使用它，您應該從工具->程式設計師選單中選擇 jtag2updi。這是我們之前推薦的選項。由於持續存在 jtag2updi 錯誤，以及它對很大程度上未維護的「avrdude」工具的依賴（該工具會在使用它進行的所有 UPDI 上傳中插入虛假錯誤訊息），因此不再建議這樣做。
顯然 Arduino 沒有打包最新 avrdude 的 32 位元版本。我定義了一個新的工具定義，它是 arduino18（最新）的副本，只不過它在 32 位元 Linux 上引入版本 17，因為這是該平台可用的最佳版本。 arduino17版本無法正確支援使用某些Microchip程式工具進行上傳。
目前，這僅用於最後幾個版本，並且應該修復 avrdude 不適用於此平台錯誤。
請參閱此文檔，涵蓋所有現代 AVR
| 特徵 | 0系列 | 1系列 | 1+系列 | 2系列 |
|---|---|---|---|---|
| 閃光 | 2k-16k | 2k-8k | 16k/32k | 4k-32k |
| 針數 | 8-24 | 8-24 | 14-24日 | 14-24日 |
| 靜態隨機記憶體 | 128b-1k | 128b-512b | 2k | 512b-3k |
| TCD | 不 | 是的 | 是的 | 不 |
| TCB | 1 | 1 | 2 | 2 |
| 類比數位轉換器 | 1x10位 | 1x10 位元 | 2x10 位 | 1x12 位 帶PGA |
| VREF腳 | 不 | 不 | 是的 | 是的 |
| 交流電 | 1 | 1 | 3 | 1 |
| 事件 * | 3 陳 | 6 陳 | 6 陳 | 6 陳 |
| 覆銅板** | 2個查找表 | 2個查找表 | 2個查找表 | 4個查找表 |
*除 2 系列 tinyAVR（以及所有非微型現代 AVR）外，事件通道分為兩種類型 - 同步（針對系統時鐘）和非同步。並非所有產生器都可以使用同步通道，且某些事件使用者只能使用同步通道，且通道清單不太一致且較多。這種瘋狂的做法一有機會就被放棄了——甚至連 mega0 也取消了這種區別。
**只有 2 系列和非小型部件可以根據 CCL 狀態觸發中斷。
所有裝置的大多數引腳上都提供類比輸入（PORTA 和 PORTB 0-1 和 4-5 上的所有引腳）。 1-series+ 上的第二個 ADC 也可以使用 PORTC 上的引腳作為輸入（有關使用這些引腳的信息，請參閱模擬參考）。
這些是預算選項。儘管它們受到支持，但不建議使用。這些永遠不會獲得tinyAVR 1系列在16k時獲得的“提升”，在任何配置中都沒有第二個TCB，沒有TCD，只有3個事件通道，其中沒有一個可以承載RTC事件輸出。這些裝置與 1 系列一樣具有 2 個 CCL LUT，並可在 14、20 和 24 引腳配置中配備高達 16k 的快閃記憶體（8 引腳元件僅為 4k）以及高達 1k SRAM。
這些具有 2k、4k 或 8k 閃存以及 128、256 或 512b 內存，就像 0 系列一樣。他們沒有第二個 ADC、三重 AC 配置或第二個 TCB，儘管他們有 TCD。
突然之間，在 16k 時，1 系列零件變得更加有趣。伴隨更大的閃存的是一系列外圍設備，似乎適合更大的晶片，無論是 16k 還是 32k，它們都具有 2k 的 SRAM。整個第二個 ADC 在 AVR 中是獨一無二的。它似乎是許多功能的測試場，這些功能以精緻的形式出現在 AVR Dx 系列上。定價似乎並未考慮到 16k 1 系列上極其優越的周邊，
從上表可以看出，2 系列幾乎更像是側級產品，而不是升級產品。他們有一個更好的ADC，事件系統和CCL 是“正常的”，並且他們有更多的RAM，14 針部分可使用32k 閃存（3214 顯然是計劃中的，但後來被取消了；它已經足夠遠了在被刪除之前在 ATPACK 中存在一段時間）
如果現在還不清楚正確的選擇，我已經寫了一個簡短的總結，說明您何時想使用哪個系列。
在其“megaavr”硬體包的官方 Arduino 板定義中，他們暗示 megaAVR 0 系列部件上的新架構（與tinyAVR 0 系列和 1 系列上使用的幾乎相同）被稱為“megaavr” “ - 這不是一個官方術語。 Microchip 使用術語「megaAVR」來指任何「ATmega」零件，無論它具有舊式週邊裝置還是現代週邊裝置。沒有官方術語來指稱一個系列或另一個系列的所有 AVR 部件，一位 Microchip 員工甚至否認內部有這樣一個術語。我不知道如何製造兩套零件，每套零件之間有很多共同點，而與另一套零件卻很少有共同點，沒有人創造一個短語來指稱它們中的任何一個。
在本文檔中，在 2.0.2 之前，我們使用 Arduino 約定，儘管從那時起已經過去了一年多，我仍然不斷尋找我稱之為 megaAVR 的地方。如果您發現任何問題，請使用 github 問題回報此問題。請注意，術語avr和megaavr仍在內部使用（例如，在庫中，標記給定庫與哪些部分相容，或根據文件將運行的內容分隔文件的不同版本）。這將繼續下去 - 我們必須堅持這一點，以便與 Arduino 團隊從 Uno WiFi Rev. 2 和 Nano Every 的核心開始的兼容性。
無論如何，需要一些詞彙來指這兩個群體，而 Microchip 沒有提供任何單字。在沒有官方術語的情況下，我將 2016 年之前的 AVR 設備（帶有 PORTx、DDRx 等引腳寄存器）稱為“經典 AVR ”，將 Arduino 稱為 megaavr 的設備稱為“現代 AVR ”。還有一些零件的 I/O 模組在很大程度上更像經典的 AVR，但其指令集版本也明顯較差，典型的快閃記憶體大小為 1k 或更小。它們使用 AVR 的 AVRrc（用於精簡核心）變體，而大多數經典 AVR 使用 AVRe 或 AVRe+，而現代 AVR 使用 AVRxt。該核心不支援 AVRrc 部件，並且在不幸的情況下，我需要討論這些非常令人失望的部件，我將它們稱為“精簡核心 AVR ”部件，因為這是它們的官方名稱，儘管我有很多為他們提供更多豐富多彩的短語。建議任何設計都不要使用精簡核心 AVR 。並不是說它們過時了，而是它們很糟糕。建議所有新設計使用「現代 AVR 」（具有新周邊和AVRxt指令集的 AVR） - Ex 系列、Dx 系列、tinyAVR 0/1/2 或 mega0
新的tinyAVR 2系列的數據表 - 雖然數據表僅「涵蓋」16k部件，但它們明確指出具有相同引腳數的部件之間在功能上沒有差異（也就是說，不存在像16k/32k 1 系列），僅在具有不同引腳數的裝置之間，並且僅由引腳數決定（即24 引腳裝置上的功能將在14 引腳裝置上出現，除非14 引腳裝置不具有沒有它需要的引腳，沒有引腳就無法使用）。 14、20、24針零件均列出4k、8k、16k、32k快閃記憶體；這些快閃記憶體大小選項分別配備 512、1024、2048 和 3072 位元組的 SRAM（即 4k 和 8k 元件具有雙倍的 SRAM），4/8k 元件獲得 128 位元組 EEPROM，較大的元件獲得 256 位元組14 元件獲得 128 位元組 EEPROM，較大的元件獲得 256 位元組14 位元引腳裝置採用SOIC 和TSSOP，20 引腳裝置採用（寬）SOIC、SSOP，以及像1616 一樣的小型QFN（這次他們也在該封裝中為我們提供了32k 器件，但祝您好運。 ，它到處都缺貨- 我無法獲得一個）和24 針，採用與3217 相同的VQFN。
TWI、SPI、USART0、AC0 未更改，NVMCTRL 也未更改（引導程式所需的更改僅與支援第二個 USART 有關）。時鐘選項不變。 TCB0 和 TCB1 已升級到 Dx 系列中的版本：時脈關閉事件選項、級聯以及用於 OVF 和 CAPT 的單獨 INTCTRL 位元（很好的補充，但與核心本身無關），並且所有部件都具有 TCB。我們現在有 4 個 CCL LUT 和 2 個定序器，而不是 2 個和 1 個 - 並且它們可以像其他具有 CCL 的部件一樣觸發中斷（與tinyAVR 0/1 系列不同）。最令人興奮的功能之一是，正如預期的那樣，它們有第二個 USART（您聽到的噪音是 ATtiny841 和 ATtiny1634 在角落裡哭泣）。 PORTMUX 暫存器現在的命名與其他現代 AVR 類似 - 但我們並沒有失去對每個 TCA WO 通道引腳的單獨控制。 EVSYS 現在的工作方式就像在非微型 AVR-0/1 系列部件上一樣（這是一個值得歡迎的變化 - 0/1 系列是奇特的，並且他們的 EVSYS 的一些不同之處被吸收了）。 TCD0、AC1/2、DAC0 和 ADC1 的 1 系列功能已消失。取而代之的是，ADC0 更加精美，幾乎無法辨認，這是自收購以來發布的第一個具有真正差分 ADC 的新 AVR。 （可憐的'841又發出一聲痛苦的哀嚎，它也有一個令人難以置信的奇特ADC，具有出色的差分選項，但與新的ADC相比，它看起來完全過時了）……從我已經發表的不同主題的貼文數量來看看來，我有一種感覺，差分 ADC 並不是您大多數願望清單中的首選 - 但它卻位於主要晶片客戶的首選清單中，所以這就是我們所得到的。我們很快就需要一款合適的差分 ADC，而不是 Dx 系列上的 ADC。它真的非常非常奇特。見下文。
megaTinyCore 提供了analogRead() 實現，以及使用過採樣和PGA 的更強大的功能（請參閱下面的模擬功能部分）。
哦，還有一件事...UPDI 引腳配置有舊選項 - UPDI、I/O 或重設...以及一個新選項：PA0 上的 UPDI，PB4 上的硬體 RESET 引腳！ Optiboot 最終將成為一個可行且舒適的選擇，至少對於具有 PB4 的零件而言，即不是 14 針零件。這也恰好是（如果我的 Tindie 商店銷售額有任何跡象的話）最受歡迎的一種。
你覺得會有3系列嗎？我不知道。 DD 和 EA 顯然正在追隨他們，並在tinyAVR 領域佔據戰略地位。我認為這個品牌被淘汰只是時間問題，就像他們在 megaAVR 0 系列之後對 megaAVR 所做的那樣。這不一定是壞事：所有 Dx 和 EA 系列部件在引腳映射和行為方面都非常相似，這非常好。儘管它們將引腳分配給更多的外圍設備，但它們的系統性較差。指導原則似乎是「不遺漏任何外圍」。與 Dx 和 EA 系列的引腳映射形成對比，其中一切都遵循固定的總體規劃。零件要么有要么沒有給定的引腳，如果沒有，則不具有可用的功能。在這兩個廣泛的群體中，我認為都有一個產品經理，他的工作就是對那些想對神聖引腳分配製定「例外」的工程師進行鞭打（因為這些例外不可避免地會激增，這也是我們最終蒙上眼睛的飛鏢板引腳分配的原因）在經典的tinyAVR上）
tinyAVR 上的引腳編號很奇怪，這是Microchip 的錯- 他們對連接埠內的引腳進行了奇怪的編號：它按順序開始，除了PA0 是UPDI 並且通常不可用，然後PORTB 的引腳以相反的順序編號，然後 PORTC 回到與 PORTA 相同的逆時針編號。讓我休息一下吧！因為傳統上是使用引腳 0 作為第一個引腳，最後一個數字是如果不設定保險絲就無法使用的引腳，這會使晶片難以編程。我更希望能夠從 A0 開始逆時針編號，而不破壞 Arduino 程式碼的不成文約定。有人可能會說我在引腳映射上做出了一個糟糕的決定——也許他們應該從PA0（除非設置保險絲否則不可用，在這種情況下芯片很難編程）作為引腳0 開始，然後按逆時針方向對引腳進行編號。但是，如果所有連接埠都按順序排列，您仍然無法實現這種技巧，除非您將 PORTB 引腳向後編號。如果您能夠擺脫所有引腳按順序編號的期望（並且僅使用 PIN_Pxn 表示法），則可以實現顯著的節省
我預測，在 2-4 年內，將會出現 AVR DA、DB、DD。 DU（USB 之一）、EA 和 D/E/F 系列裝置的引腳數降至 8（或至少 14），以及具有 128k 快閃記憶體和新 ADC 的 64 引腳裝置。沒有其他任何品牌的 ATtiny。剩下的最大問題可能是他們是否會用總引腳數為 100 個（可能其中 80-88 個是 I/O）且閃存選項高達 256k 的現代 AVR 來取代 ATmega2560；這將帶來三個問題 - 首先，過去 56 個 I/O 引腳不再剩下 VPORT 暫存器 - 低 I/O 空間已滿，有 28 個 VPORT 和 4 個 GPIOR。他們將如何處理這 4 個額外的連接埠？ （在 2560 上，它們只是訪問速度較慢且沒有單週期訪問的二類端口。我對此有一些思考，以及附錄 A 中可用操作碼的可行性。第二，違反閃存中的128k 屏障，您必須轉到17位元程式計數器。在Dx 上的工作原理- 它們不可能一直達到32。24k 記憶體絕對是可能的，甚至可能是28，但在32k 時，再加上32k 的映射閃存，就沒有空間了。的SFR，因此了解它們如何處理這一點將會很有趣。
我在我的 Tindie 商店中銷售帶有調節器、UPDI 接頭和串行接頭的分線板以及裸板。從我的商店購買有助於支持核心的進一步開發，並且是開始在 Arduino 中使用這些令人興奮的新部件的好方法。目前 ATtiny1624 板已上市，但 20 和 24 引腳零件不會作為組裝板出售，直到新修改的 PCB 設計從板廠返回以啟用 alt-reset 引腳上的自動重設。還有一個 14 針板版本即將推出 - 雖然它主要是裝飾性的。黃色阻焊層必須去除，因為在過去幾批中可讀性似乎變得更差。新板還標準化了引腳行之間的 0.6 英寸間距，而不是當前的 0.7 英寸間距，因此您可以將機械加工的引腳接頭放在它們上面並將它們插入寬 DIP 插座，或者將它們與我們針對該行間距最佳化的原型板一起使用。組裝好的 0 系列主機板即將停產，售完後將不再補貨。一旦 32k 零件上市，16k 2 系列零件也會發生同樣的情況。
2 系列和 EA 系列上的 ADC 是現代 AVR 時代 AVR 上發布的最好的 ADC。除了那兩個。最接近的比較是具有一流功能的差分 ADC 的經典 AVR（t841、mega2560 和（令人驚訝的）t861 是最強大的競爭對手）。雖然它無法實現某些部件在經典 AVR 時代所吹噓的瘋狂 100 倍和 200 倍增益，但我一直不清楚被放大的有多少只是噪音（考慮到我使用差分 ADC 的經驗有限）我會說「可能是大部分，如果你讓我設計硬體的話，肯定是大部分，我不懂模擬！這款新的 ADC 無疑功能強大，具有真正的差分功能（與 DA 和 DB 系列不同），並且遠遠超過迄今為止任何其他現代 AVR 上的任何產品。可程式增益放大器是一項新功能，人們能夠從中獲得什麼樣的類比測量壯舉還有待觀察。它看起來確實很有前途。了解在 1 倍增益下使用 PGA 與不使用 PGA 之間的差異以及這樣做的優點和缺點將特別有趣。 （討論如何在一般情況下為任務選擇正確的 ADC 配置的文檔對 Microchip 來說是非常有用的；我已向 Microchip 提出了這個問題，與我交談的人表示這是一個高度優先的事項；而情況已經有了很大的改善，但似乎文檔組仍然被特別指示不要提出任何類型的實際具體建議，這是不幸的，因為我認為這是我們大多數人希望看到的！ ）。
為了過採樣和抽取而添加 1024 個樣本累積是一項值得歡迎的補充，儘管這也有低估偏移誤差的幅度和相關性的風險。 （採用 1024 個樣本（所有樣本都有給定的偏移誤差），然後對總和進行抽取以產生 17 位 ADC 測量結果，很容易想像任何誤差都會被限制在最低的幾位中。但是如果誤差例如說，單次測量為5 lsb，當您累積1024 個樣本並進行抽取時，您的偏移誤差為160，很容易看出這一點並認為這是訊號而不是雜訊。
第一款帶有新 ADC 的全尺寸（非微型）晶片採用 28-48 引腳封裝，快閃記憶體容量高達 64k。人們通常猜測如果從 2 系列到 EA 系列會發生什麼變化：看起來答案是，移除了其中一個令人困惑的旋鈕，並自動對累積測量值進行符號斬波（
D 型定時器僅用於預設 PWM 接腳設定的 20/24 接腳 1 系列裝置上的 PWM。在較小的部件上，它不會讓我們增加 PWM 引腳的總數。只有 WOC 和 WOD 腳位（分別在 PC0 和 PC1 上）還沒有 TCA 驅動的 PWM。因此，由於 AnalogWrite() 不支援透過關閉分割模式（如 16 位元 PWM）來啟用或透過使用 D 型定時器（如調整頻率）來增強的任何功能，因此情況會更糟，因為它需要額外的空間來儲存從兩種類型（而不是一種）定時器開啟和關閉PWM 的例程。這對於較小的閃光燈部件來說是不可忽略的；它大約為 600 位元組。 digitalWrite() 為 150，analogWrite() 為 450（如果在 TCD PWM 引腳上呼叫過這些函數）。在這種情況下，只要與這些功能一起使用的引腳不包括任何 TCD PWM 引腳，優化器就應該能夠優化掉這些功能的該部分。請注意，優化器將獨立考慮它們，也就是說，如果digitalWrite() 與使用TCD 進行PWM 的引腳一起使用，則digitalWrite() 將包含關閉TCD PWM 的程式碼，無論您是否在該引腳上調用了AnalogWrite()。
與幾乎所有其他 AVR 不同（我可以想到大約 3 個範例，其中只有一個是「獎勵」而不是「無獎勵」），根據系列中零件的快閃記憶體大小，還有其他「獎勵」功能。 16k 和 32k 版本（僅）有一些額外的功能（似乎也沒有考慮定價） - 它們都有 2k 的 ram，無論是 16k 還是 32k，它們都有 3 個模擬比較器（包括視窗模式）選項），第二- 迫切需要- B 型定時器- 最奇怪的是他們有第二個ADC，僅通道對應的引腳不同！
與傳統的 AVR 不同，在這些部分上，快閃記憶體被映射到與記憶體其餘部分相同的位址空間。這意味著不需要pgm_read_*_near()直接從快閃記憶體讀取。因此，編譯器會自動將任何宣告為const變數放入 PROGMEM 中，並適當地存取它 - 您不再需要將它們明確聲明為 PROGMEM。這包括帶有引號的字串文字，因此也不再需要 F() 宏，但為了保持與某些第三方程式庫的兼容性，f() 仍然聲明其參數 PROGMEM。
但是，請注意，如果您明確聲明變數 PROGMEM，則仍然必須使用pgm_read函數來讀取它，就像在經典 AVR 上一樣。當在具有記憶體對映快閃記憶體的部分上宣告變數 PROGMEM 時，指標會發生偏移（位址相對於快閃記憶體的開頭，而不是位址空間的開頭）；使用pgm_read_*_near()巨集時會套用相同的偏移量。請注意，聲明 PROGMEM 並使用pgm_read_*_near函數進行存取雖然工作正常，但速度較慢並且浪費少量閃存（與簡單聲明變數 const 相比）； 2.1.0 及更高版本中具有常數字串的 F() 巨集也是如此（在 2.1.0 之前的一段時間內， F()沒有執行任何操作 - 但這給第三方函式庫帶來了問題）。作者堅持認為問題在於核心，而不是庫，我的選擇是接受較低的效率，或拒絕我的用戶訪問流行的庫。為了與某些第三方程式庫相容，可能需要使用F()巨集（強制我們返回F()的具體情況不是這樣的 - 我們實際上能夠使我知道的那些與F()-as-noop 程式碼，因此它們佔用的閃存少了幾個位元組）。
汽車版本也應該可以使用。您必須始終在這些零件上選擇源自 16 MHz 的時脈速度。它們不支援 20 MHz 操作，並且不應使用調諧時脈選項。
現在到了好的部分，我們開始討論 megaTinyCore 是如何揭露這一切的。我們將從如何引用引腳以獲得最佳結果的問題開始，然後繼續討論核心功能、選單選項，最後提供一系列指向文檔的鏈接，其中包含有關各個子系統的更多詳細資訊。
如何引用 AnalogRead() 和 digitalRead() 引腳的簡單問題（特別是在非標準硬體上）一直是 Arduino 使用者困惑的根源。我認為，大部分責任歸咎於 Arduino 團隊（以及他們之前的《Wiring》一書的作者）關於如何引用引腳所做的決定；將某些引腳指定為“類比引腳”會導致人們認為這些引腳不能用於數位操作（最好將它們視為“具有類比輸入的引腳” - 就像“可以輸出PWM 的引腳”一樣）。傳統上，圖釘會被重新編號，這一事實進一步攪亂了水。對於非標準的經典AVR 部件，多年來不同作者創建的多個不相容的「引腳映射」常常使情況變得更糟，以使部件「更像Uno」或用於某些其他目的（ATTinyCore 是一個特殊的以這種方式混亂，某些部件具有三種完全不同的引腳映射，至少在一種情況下，其中一種替代映射是一種受魔鬼啟發的純粹邪惡的作品，只需要一個額外的查找表即可將類比引腳轉換為數位引腳針）。
此核心使用簡單的方案來分配Arduino 引腳編號：引腳從最靠近Vcc 的I/O 引腳開始編號為引腳0，並逆時針方向進行編號，跳過（大部分）不可用的UPDI引腳。然後將 UPDI 引腳分配給最後一個引腳編號（如上所述，即使未將其設定為 GPIO，也可以讀取 UPDI 引腳（類比和數位讀取均有效）。我們建議將此作為最後的手段：當未設定為 GPIO 引腳時，UPDI 引腳始終啟用上拉，並且看起來太像 UPDI 啟用序列的訊號將導致意外的操作。
為了防止有關引腳標識的所有混淆並消除歧義，我們建議使用 PIN_Pxn 表示法來引用引腳，除非您使用的開發板上印有不同的引腳編號或名稱。這將最大限度地提高程式碼與其他類似硬體的可攜性，並在必要時更輕鬆地在相關資料表中查找有關您正在使用的引腳的資訊。
這是引用引腳#defines建議方式，也以PIN_Pxn形式提供，其中x是 A、B 或 C， n是數字 0-7 -（不要與下面描述的 PIN_An 定義混淆）。這些只是解析為相關引腳的數字引腳號 - 它們不會通過不同的程式碼路徑或任何東西。然而，它們在編寫跨產品線工作的程式碼時具有特殊的實用性，這些程式碼與連結到某些引腳（透過連接埠）的周邊一起工作，就像大多數週邊一樣。文件中的幾段演示程式碼利用了這一點。直接連接埠操作也是可能的 - 事實上，有幾個強大的附加選項可供使用 - 請參閱直接連接埠操作。
PIN_Pxn - 不是Pxn ，也不是PIN_xn - 這些意味著不同的東西！
當在文件或程式碼中使用單一數字來指稱引腳時，它始終是「Arduino 引腳號」。這些引腳號在引腳排列圖上以橘色（適用於能夠執行analogRead() 功能的引腳）和藍色（適用於不支援analogRead() 的引腳）顯示。所有其他引用引腳的方式均被 #define 為對應的 Arduino 引腳編號。
核心還提供An和PIN_An常數（其中n是 0 到 11 之間的數字）。與官方核心一樣， PIN_An被定義為與類比通道 n 共享的引腳的數位引腳編號，這些指的是 ADC0通道編號。這個命名系統與許多經典 AVR 核心上使用的命名系統類似，但在這裡，它們只是 #define 作為相應的 Arduino 引腳號。如果您需要取得數位引腳上的類比通道號，請使用digitalPinToAnalogInput(pin)巨集 - 但只有在編寫高階 ADC 函式庫時才需要該巨集。
這些零件（嗯，至少是 1/2 系列 - 0 系列本來是作為預算選項，但它們未能縮小預算，而且它們只便宜幾美分）提供了一個出色的多功能工具箱和強大的周邊；高階產品與經典的 megaAVR 零件相當或更好 - 以 tinyAVR 的價格。與我的其他核心一樣，megaTinyCore 設計的指導原則之一是讓支援的部件充分發揮其潛力，或者在 Arduino 的限制內盡可能接近其潛力。這個（非常大的）部分涵蓋了這些部件的功能以及 megaTinyCore 如何公開它們，以及核心本身的功能。這個（非常大的）部分試圖涵蓋每個功能區域。如果您嘗試使用某些晶片功能但遇到問題，請嘗試尋找您正在使用的功能！
我們對超頻部件的電壓或溫度範圍沒有做出任何聲明 - 我們所聲明的是，我們至少有一個晶片在室溫下以該速度工作，在 5v 下運行特定的草圖。您的里程預計會有所不同，但通常 F 規格零件比 N 或 U 規格零件更好。
重要 - 在選擇任何調整選項之前請閱讀有關調整的資訊！
有關這些時脈速度的更多資訊可以在時鐘參考中找到
顯示的電壓是製造商規格保證工作的電壓（。除非超出工作溫度範圍的界限，否則這些部件通常會做得更好（2 系列通常在32 MHz 和5v @ 室溫下工作，即使是內部振盪器； 0 /1 系列通常同樣以 32 MHz 的頻率工作，並帶有外部時脈（前提是電源電壓穩定為 5.0-5.5V）。
透過 UPDI 上傳草圖時，無需執行任何操作來設定OSCCFG熔絲。當透過 Optiboot 上傳時，熔絲無法更改，因此燒錄引導程式時選擇的內容就是所使用的，只有「燒錄引導程式」或透過 UPDI 上傳草圖才會改變這一點。
所有內部振盪器時脈速度選項均使用工廠預設校準，除非選擇「調諧」選項，在這種情況下，將按照調諧參考中的記錄調整校準。這可用於在融合了 20 MHz 的 optiboot 晶片上獲得 16 MHz 操作，反之亦然。
有關製造商速度等級的更多信息，請參閱速度等級參考。請注意，這些是保證其工作的電壓和時脈速度。這些零件適用於某些意外故障可能對人員或財產造成危害的應用（例如汽車、工業設備、飛機、核反應器 - 如果零件發生故障，人們可能會死亡的地方），而我軍事應用也是如此，它們具有類似的可靠性要求，只是出於相反的原因。典型的業餘愛好者對於潛在的穩定性問題會更加放心，崩潰只不過是一個麻煩，而且擴展溫度範圍部件的極端情況遠遠超出了我們的需要。假設電路板具有防水塗層，從熱學角度來說，N 級部件應該能夠在一鍋沸水中按照速度等級運行。這只是 N 規格。 F-spec 應該會好到 125！
已經確定擴展溫度部件超頻效果更好，這是有道理的。預計在 125°C 下以 20 MHz 運行的零件在室溫下以 32 MHz 運行的機會比僅在 105°C 下以 20 MHz 運行的部件要好
從版本 2.4.0 開始，我們現在提供「官方 Microchip 主機板」選項。除了將LED_BUILTIN定義為該板上有 LED 的引腳（而不是 A7），並定義宏PIN_BUTTON_BUILTIN定義為帶有用戶按鈕的引腳並使用非-optiboot版本始終使用板載編程器/調試器；工具 -> 程式設計器僅用於「燒錄引導程式」和「使用程式設計器上傳」。對於 ATtiny416 XPlained Nano，它還會選擇使用串行埠備用引腳的引導程式版本 - 它不會自動使用 USART0 的備用引腳，就像您已完成 Serial.swap(1) 一樣- 支援串列引腳預設交換的功能將在未來的更新中出現，同時引腳交換機制底層機制的一些其他變化也將有望減少快閃記憶體的使用。
如上所述，這些可能無法在 32 位元 Linux 平台上正常運作。這超出了我的控制範圍；我不會建立 avrdude 二進位文件，我也不承擔這項任務。我已經有太多了。
blink()比在 XPlained Pro 上需要更多快閃記憶體？兩者都有相同的 ATtiny817！他們怎麼能不同呢？
基於相同的原因，如果將其變更為使用PIN_PC0而不是PIN_PB4 ，則閃爍將需要更多快閃記憶體：XPlained Mini 上使用的 PC0 是 PWM 引腳，而 XPlained Pro 使用的 PB4 則不是。由於這是使用 digitalWrite() 的唯一引腳，因此編譯器可以自由優化該引腳上 digitalWrite() 不需要的任何內容，包括關閉支援 PWM 的引腳上的 PWM 輸出的功能。如果在兩個裝置上都支援PWM 的引腳上也使用digitalWrite()（導致更高的快閃記憶體使用結果），或者如果將digitalWrite() 替換為digitalWriteFast()，則差異消失，這將使用更少的快閃記憶體（但假設您贏了）不要在輸出 PWM 的引腳上呼叫它）。
每當使用 UPDI 編程器上傳程式碼時，所有可以「安全」設定的保險絲（例如，沒有使板變磚的風險，或者如果無法使用 HV 編程器則不會使板變磚），並且具有任何將設置內建配置選項。因此，除非另有說明，行為將始終與所選工具功能表相符。概括來說，這些處理如下：
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並不安全，因為將其設定為比電路板運行電壓更高的電壓並啟用它會「堵塞」電路板，直到可以提供更高的工作電壓；如果將其與無法承受這些電壓的設備焊接到同一塊 PCB 上，這可能會特別尷尬。
SYSCFG0不安全，因為這是RSTPINCFG所在的地方；更改此設定可能會使電路板無法編程，除非透過 HV UPDI 編程，並非每個人都有 HV UPDI 編程器。將來，如果/當程式設計器保證 HV UPDI 功能可以被選為程式設計器時（即可以製作僅適用於 HV 程式設計器的工具 -> 程式設計器選項），則在使用時該保險絲將自動設定該程式設計師。
因此，在 2.2.0 及更高版本中，使用 UPDI 上傳時，您不再需要「刻錄引導程式」即可在 16 MHz 衍生速度和 20 MHz 衍生速度之間切換
此核心始終使用連結時間最佳化來減少快閃記憶體使用 - 支援tinyAVR 0/1/2系列零件的所有編譯器版本也支援LTO，因此無需像ATTinyCore那樣將其設為可選。引入後，程式碼大小有了巨大的改進，通常約為 5-20%！
這些部件都有大量的類比輸入 - DA 和 DB 系列有多達 22 個類比輸入，而 DD 系列在每個不用於驅動 HF 晶振的引腳上都有類比輸入（儘管 PORTC 上的引腳是僅當MVIO 關閉時支援）。它們可以像在普通 AVR 上一樣使用analogRead()讀取，我們預設為 10 位元解析度；您可以使用analogReadResolution()變更為完整的 12 位，並使用增強的 AnalogRead 函數自動取得過取樣、抽取的讀數以獲得更高分辨率，並進行差分測量。有 4 個內部參考電壓，分別為 1.024、2.048、4.096 和 2.5V，另外也支援外部參考電壓（當然還有 Vdd）。 ADC 讀數的讀取速度比經典 AVR 快 3 倍，如果您測量的是低阻抗，則該速度可以再次加倍，或者將取樣時間大大延長以讀取非常高的阻抗源。模擬參考中對此進行了詳細說明。
Dx系列元件有一個10位DAC，可以產生真實的類比電壓（注意，這提供了低電流，只能用作電壓基準或控制電壓，不能用於為其他設備供電）。這會產生 0 和所選VREF之間的電壓（與tinyAVR 1 系列不同，這可以是 Vcc！）。透過 DACR reference()函數設定 DAC 參考電壓 - 將其傳遞給上面 ADC 部分列出的任何 ADC 參考選項（包括 VDD！）。呼叫DAC引腳（PD6）上的analogWrite()來設定DAC輸出的電壓（這在8位元模式下使用）。若要關閉 DAC 輸出，請在該引腳上呼叫digitalWrite()或turnOffPWM() 。
可能還有其他選項可用於配置 EA 系列上的 DAC。
有關完整詳細信息，請參閱ADC 和 DAC 參考。
不建議使用類比引腳的An常數 - 建議的做法是僅使用數位引腳編號，或者更好的是，在呼叫analogRead()時使用PIN_Pxn表示法。
與經典 AVR 相比，有更多的重置選項，包括程式碼是否以某種方式掛起。看門狗定時器只能重設（使用RTC和PIT進行定時中斷）。
請參閱重設和看門狗 (WDT) 參考和核心輔助庫 megaTinyCore
此核心增加了許多新功能，包括快速數位 I/O（1-14 個時鐘，取決於編譯時已知的內容）和 2-28 位元組閃存（必須在編譯時知道________Fast()函數的引腳號，並使用pinConfigure()配置硬體的所有每個引腳設定。
請參閱改進的數字 I/O 參考。
所有 0/1 系列零件都有一個硬體串列連接埠（UART 或 USART）； 2 系列零件有兩個。它的工作原理與官方Arduino 板上的一模一樣，只是沒有自動重置功能，除非您透過將UPDI 引腳熔斷為重置來將其連接起來（需要HV-UPDI 或Optiboot 引導程式來上傳程式碼），或設定如本文檔其他部分所述，安裝「代用重設引腳」。有關串列引腳的位置，請參閱引腳排列圖。
在將部件置於睡眠模式或以其他方式停用其傳輸能力之前，請確保它已透過呼叫Serial.flush()完成發送緩衝區中的數據，否則序列埠將發出損壞的字元和/或失敗完成訊息的傳輸。
有關選項的完整列表，請參閱串行參考。從 2.5.0 開始，支援串行硬體幾乎所有類型的功能，包括 RS485 模式、半雙工（透過 LBME 和 ODME），甚至同步和主 SPI 模式，2.6.0 將添加自動波特率，儘管它不是很有用。
所有這些部件都有一個硬體 SPI 週邊。它的工作原理與使用 SPI.h 庫的官方 Arduino 板上的類似。有關這些引腳的位置，請參閱引腳排列圖。在 8 引腳裝置上，SS 引腳的唯一選擇是 PA0（UPDI/重設引腳）；不過，這對於該核心的目的來說並不重要，因為與官方庫一樣，它僅作為主機運行，並且僅在可能充當從機時才使用 SS 引腳。
在 14 個引腳裝置之外的所有裝置上，SPI 引腳都可以移動到備用位置（注意：在 8 個引腳裝置上，SCK 引腳無法移動）。這是使用SPI.swap()或SPI.pins()方法配置的。它們都實現了相同的目標，但在指定要使用的引腳集的方式上有所不同。必須在呼叫SPI.begin()之前呼叫此函數。
SPI.swap(1)或SPI.swap(0)將映射設定為備用 ( 1 ) 或預設 ( 0 ) 引腳。如果這是一個有效的選項，它將傳回 true，如果不是，它將傳回 false（您不需要檢查它，但它在開發過程中可能有用）。如果指定了無效選項，則會將其設為預設選項。
SPI.pins(MOSI pin, MISO pin, SCK pin, SS pin); - 這會將對應設定為具有指定引腳的對應。如果這不是有效的映射選項，它將返回 false 並將映射設為預設值。這比SPI.swap()使用更多的閃存，因此該方法是首選。 SS pin參數是可選的，因為在充當 SPI 主設備時不使用該引腳，並且該庫和官方 SPI.h 庫都不支援充當從設備。
當可以確定傳遞給SPI.swap()或SPI.pins()參數在編譯時無效（最常見的是當參數是常數時，它們幾乎總是如此），核心將產生一個編譯錯誤的效果。這旨在幫助防止此類可檢測到的問題需要在硬體上進行調試。
該核心禁用SS 引腳，這意味著“SS”引腳可以用於您想要的任何目的，並且該引腳僅在創建SPI 從機時相關（這需要您自己實現與SPI 週邊設備的交互-儘管它不是火箭科學或任何東西）。在經典的AVR 上，如果SS 是輸入並且啟用了SPI，則它充當SS 引腳，如果它變低，則會將裝置切換到從模式（並且SPI.h 將不會起作用，直到回到主模式）模式，這不是自動完成的）。
所有這些部件都有一個硬體 I2C (TWI) 週邊。它提供了一個與標準 Arduino 實現兼容的 API，但增加了對多個從地址、應答一般調用地址以及 - 最令人興奮的 - 同時主從操作的支援！ （2.5.0 中的新功能）。
有關完整的描述和詳細信息，請參見Wire.H文件。硬體I2C是較複雜的周邊設備之一。最近，Wire有很多熱門新的增強功能檢查了一下。
核心透過標準analogWrite()函數提供硬體PWM。在8針零件（412、212、402、204）上，有4個PWM腳位。在所有其他零件上，除了具有20或24個銷釘的1系列零件外，還有6個PWM引腳可用，全部由計時器A（TCA0）驅動。 20和24腳1系列零件有兩個由TCD0驅動的銷釘。這兩個系列顯然將TCD0交換為第二個序列埠和一個超級美食ADC-這些零件也有6個PWM引腳。 B型（TCBN）計時器不能用於其他PWM引腳 - 它們的輸出引腳與計時器A可用的引腳相同，並且通常太有用了，無法證明使用整個TCB的合理性。但是，如果您需要以不同的頻率產生PWM，則可以將它們接管，儘管預先電腦與計時器類型也限制了此用途的事實。有關引腳支援PWM的列表，請參閱PINOUT圖表。
從2.6.8開始，新增了一個工具子選單以使您從合理的有用的PWM映射中進行選擇，並且（在1系列上）停用TCD PWM以節省快閃記憶體。
請注意，所有零件上的TCA0（A型計時器）均由啟動時的Core配置，以在分割模式下操作，以支援使用analogWrite()可能提供的最多的PWM引腳。從2.2.x版本開始，已經加入了takeOverTCA0()函數，可以呼叫該功能以指示核心不寫入TCA0-Registers，也可以對TCA0進行任何特定模式或行為。 analogWrite()不會產生PWM，除非在20/24針零件上由TCD0驅動的引腳上， digitalWrite()如果要為其他目的重新配置TCA0，請將其關閉，請參閱下面的指南和「硬重置”指南」。
3216、1616、816、416和3217、1617和817具有由計時器D驅動的兩個額外的PWM引腳（X17上的X16、12和13和13）。計時器D是非同步（非同步）計時器，如果不簡短停止計時器，就無法啟用或停用輸出。這會導致另一個PWM引腳（如果當前輸出PWM）的短暫故障，並且需要更長的時間 - 儘管該小故障的持續時間低於1。如果將TCD用作MILLIS計時器 - 這是任何具有D型計時器的部分的預設值（為了保持更容易重新使用的計時器可用-TCD0並不容易使用），這將結果在millis()中，每次在TCD引腳上開啟或關閉PWM時，都會浪費很少的時間（在1歲以下）。
截至2.2.0， TCD驅動的PWM引腳上的0或255的analogWrite()不會與計時器斷開PIN的連接- 相反，它會導致恆定的HIGH或LOW輸出，而無需斷開計時器（使用DigitalWrite（使用digitalWrite() ）。這意味著可以使用analogWrite(PIN_PC0, 0)或analogWrite(PIN_PC1, 0)將計時器連接到PIN，而無需輸出PWM（尚未輸出PWM） - 在設定任何其他稅單週期之前都可以在兩個PIN上進行此操作當第二引腳連接到它時，其他TCD0引腳上沒有任何類型的故障。只有digitalWrite()或turnOffPWM()才能將計時器與PIN斷開連接。以這種方式輸出HIGH時，引腳是「倒」的；這意味著它上的digitalRead()將返回0，而不是1（如果您是digitalRead() 'pin，您將其設置為使用analogWrite()輸出恆定的HIGH ，並且是這兩個引腳之一，但是，如果您設定的digitalRead()您將輸出恆定值讀取，則它可能會讀取LOW （），您通常會做錯了什麼。
因為TCD是異步的，並且可以從未升級的內部振盪器中運行，這意味著您可以降低系統時脈頻率而不會影響PWM的速度。雖然16 MHz衍生和20 MHz派生的時脈之間的PWM頻率差異，但對於TCD控制的引腳而言，不同系統時脈速度的頻率沒有變化（TCA控制的引腳將有兩個因素而變化。 ）例外是當將TCD0用作1 MHz的Millis/micros正時源- 以全速運行，導致在millis() ISR（百分之％）中花費不合理的運行時間。
預設情況下，TCD0用於millis() / micros() 。請注意，這確實具有很小的閃光懲罰，因此您可以透過切換使用TCA或TCB作為計時器來節省閃光燈。這也將使micros()返回速度更快。大多數這些部分都缺乏計時器，我還沒有看到有人在談論或發布重新配置TCD的程式碼。同時，每個人似乎都在重新配置TCA，許多庫都需要TCB。這些因素一直是使TCD0成為millis() / micros()的預設值的動力：最不可能直接幹擾。
在2.2.0之前的某些版本的MegatinyCore上，TCD0引腳上的PWM完全被打破了。
有關可用計時器以及如何使用PWM和其他功能的一般信息，請諮詢指南：這也涵蓋了這些計時器將在各種系統時鐘為您提供的PWM頻率。計時器和MegatinyCore
除非存在TCB1，並且將TCB0設定為millis()來源，否則在所有零件上提供對tone()的支援（）。這就像標準音tone()函數。與某些經典的AVR不同，它不支援使用硬體「輸出比較」來產生音調。由於TCB計時器的PWM功能非常有限且預定器選擇限制，因此這是不切實際的。如果在millis() / micros()設定中使用TCB0或TCB1，請參閱下方的注意事項。有關更多信息，請參見計時器參考
tone()一次只能在一個銷釘上發揮音調。從理論上講，您可以同時播放每種B計時器的音調，而不是添加了管理多個引腳的功能，而沒有任何其他tone()更具異國情調的。我認為那些屬於圖書館，而不是核心。如果您想實施類似的事情，請在tone.cpp中查看評論。
MegatinyCore提供了可以在millis() / micros()計時器上使用任何可用的計時器的選項，該計時器由工具子選單控制。如果需要，可以完全停用它以節省閃存，允許使用所有計時器中斷或消除週期性的背景中斷。預設情況下，TCD0將用於具有一個零件的零件- 否則將使用TCA0（在1.1.9之前的版本中，預設情況下，TCA0在可能在不適合TCA0 PWM上輸出tcd0輸出的PWM上使用TCA0） 。零件上可用的所有計時器均可使用：TCA0，TCD0（在具有零件），TCB0，TCB1（現在）和RTC。其中許多（尤其是非預設選項）涉及權衡。簡而言之，TCA0是一個非常通用的計時器，用戶通常希望重新配置，TCD0在兩個TCD0 PWM引腳上打開或關閉PWM時損失了少量時間24針零件），TCB0與沒有TCB1的零件上的Servo和tone()衝突，當使用RTC時， micros()完全不可用，因為時鐘不夠快。考慮到這些限制，計時器選擇選單提供了一種將millis() / micros()移至最適合您需求的計時器的方法。
有關更多信息，有關受支援部分的硬體計時器以及MegatinyCore內建功能的使用方式，請參見The Timers和MegatinyCore參考。
2.3.0修正了一個長期存在（儘管出乎意料的影響）「時間旅行」錯誤。
millis()的RTC計時器如果選擇RTC作為millis()計時器的計時器，則將無法使用micros() 。此外，該計時器將配置為在待機睡眠模式下運作。這有兩個重要的後果：首先，它將在睡眠中保留時間。其次，每64秒鐘，RTC溢出中斷會發射，喚醒晶片 - 因此，如果您使用rtc for millis()並將零件放入睡眠狀態，則應聲明您在ISR中設定的揮發性全域變數應該喚醒零件，例如volatile boolean ShouldWakeUp=0; ，將其設置為ISR中的1，當您將Attiny放入睡時，請在醒來後立即檢查一下，如果沒有設置，請重新入睡，並在設置設置時清除它，例如：
void GoToSleep () {
do {
sleep_cpu ();
} while (!ShouldWakeUp)
ShouldWakeUp= 0 ;
}當該庫可用時，將使該功能更易於透過ModernSleep使用。
該板軟體包還支援使用外部32.768KHz晶體作為RTC的時脈源（在0系列或8針零件上不支援 - 不是我們的錯，硬體不支援它）。如果使用此方法，請確保晶體在TOSC1和TOSC2引腳之間連接（它們與帶有預設引腳映射的TX和RX引腳相同 - 非常方便嗎？電線或跡線連接到這些銷釘，並且每個水晶製造商數據表連接了適當的裝載電容器（並且它不是滿月- 我發現32k晶體非常不合作。為了減少功率使用，他們試圖驅動晶體驅動晶體他們可以逃脫，這又使其更容易受到干擾。
是的，您可以將外部振盪器用於RTC，至少在1和2系列零件上。當它是振盪器而不是晶體時，可以將其饋送到TOSC0或Extclk；對此的更好的支持將來會發生。請注意，雖然TOSC0不允許您以更快的速度運行RTC。 Extclk Will。
printf()支援「可列印」類與官方董事會方案不同，但像許多第三方板軟體包一樣，MegatinyCore包括可列印類別的printf()方法（用於UART串行端口，以及使用print()方法）；這與sprintf()一樣，除了它輸出到相關設備；例如：
Serial.printf( " Milliseconds since start: %ld n " , millis());請注意，使用此方法將拉出與sprintf()一樣多的膨脹，並且受到與printf相同的限制 - 預設情況下，未列印浮點值。您可以將其與所有序列埠一起使用，如果您想列印浮點號，可以從工具子選單中選擇完整的printf()實現，並以其他額外的閃光為代價。
printf()及其變體有許多陷阱使用printf()有很多方法可以搞砸。最近出現的一些問題：
printf() - printf()錯誤是現實世界中軟體錯誤的常見原因。請注意，雖然您可以在格式字串上使用f（），但在這種情況下沒有警告無效格式字串；保守的程式設計師將首先使該應用程式在格式字串周圍不使用F（）的情況下工作，並且一旦已知格式字串工作，僅切換到F（）。來自cplusplus.com：
長度子指定器修改資料類型的長度。這是一個圖表，顯示用於解釋帶有和不長度指定符的相應參數的類型
（如果使用了不同的類型，則執行適當的類型促銷或轉換，如果允許）：StrikeThrough地雷，因為這裡不起作用（這不是我的錯，也不是在我的控制之下- 它是由Avrlibc提供的，我懷疑這是因為在8位AVR上實施它的開銷太大了）。當給出不正確的長度指定符時（包括在使用時不用）時會發生令人驚訝的事情。在我看來，所有論點都被擊中成一組位元組。然後它讀取格式字串，當它到達n個位元組資料類型的格式指定符時，它會從參數陣列中獲取n個位元組，格式化並將它們列印到您列印的任何內容中，繼續進行直至格式的末端細繩。因此，未能將格式指定器的長度修飾符與參數匹配，將導致列印錯誤的數據，以替換該替換以及該printf()中的所有後續數據。
下表包括該表的相關行 - 在Arduino中，許多標準類型不是一件事情（它們的原始類型更長的時間更長，但包括混亂將使討論變得複雜。
| 長度 | 迪 | UOX X | f f f e g g a a | c | s | p | n |
|---|---|---|---|---|---|---|---|
| （沒有任何） | 整數16 | uint16 | 漂浮 | 整數 | 字元* | 空白* | int* |
| 呵呵 | INT8 | uint8 | 字元* | ||||
| 我 | 整數32 | uint32 | int32_t* |
請注意，上表中沒有64位元類型的行；這些不支援（對64位元類型的支援非常斑點，這並不奇怪。該大小的變數很難在8位元微控制器上使用32個工作暫存器），並且使用UINT64是您應該嘗試的東西。 ，類似於在道路錯誤的一側開車，在雷暴中駕駛風箏或喝漂白劑。雖然所有這些都被建議（歐洲確實對道路的一側持續存在；就我而言，它歸結於物理；鏡像對稱i。這適用於printf()的所有版本 - 功能不是由AVR-LIBC提供。
有關於與printf的記憶腐敗的報道，我懷疑這實際上是對上面的誤解。
printf()實現一個工具子選單可讓您從三個等級的printf() ：完整的printf()中選擇所有功能，預設一個丟棄float支援以節省1k的閃光燈的預設功能，而最小的一個幾乎所有東西都掉落了所有功能，對於另一個450 byts flash節省（在16K和8K的零件上，這將是一個很大的事情。請注意，在此處選擇任何非預設選項都會導致它包含在二進位中，即使它從未被調用- 如果從未被調用，通常不包括在內。因此，空的草圖將使用最小的printf()佔用更多的空間，而使用printf()的草圖將使用最小的printf()與預設值更少的空間。
所以：
| 選單選擇 | printf（）還是類似的使用？ | 開賣 |
|---|---|---|
| 預設 | 不 | 0根據定義 |
| 預設 | 是的 | APX 1500 |
| 最小 | 不 | APX 1000 |
| 最小 | 是的 | APX 1100 |
| 滿的 | 不 | APX 2800 |
| 滿的 | 是的 | APX 3000 |
請注意，當不使用printf或類似功能的情況下，您會更好地將其保留在預設設定上，而不是切換到最小的思考可以節省Flash，因為您會使用更多的閃光燈。
所有引腳均可與attachInterrupt()和detachInterrupt()一起使用，在RISING ， FALLING ， CHANGE或LOW 。所有引腳都可以在CHANGE或LOW睡眠中喚醒晶片。標記為MegatinyCore Pinout圖表上的非同步中斷引腳（每個連接埠中的第2和6號引腳）也可用於從RISING和FALLING邊緣上醒來。這些引腳被稱為資料表中的「完全非同步引腳」。
高級用戶可以手動設定中斷，忽略attachInterrupt() ，操縱相關連接埠暫存器並使用ISR()巨集來定義ISR-這將產生較小的程式碼（使用較少的閃光燈和RAM），ISR將其運行速度更快，並且會更快地運行速度。
有關完整資訊和範例，請參閱中斷參考。
像我的其他核心一樣，草圖 - >匯出編譯的二進位檔案將在草圖資料夾中產生彙編清單。還創建了內存圖。內存圖的格式留下了一些需要的內容，並且我寫了一個粗略的腳本來嘗試改進它，請參閱導出參考以獲取更多資訊。請參閱匯出的文件文檔
可以透過工具 - >儲存EEPROM選單來控制Eesave保險絲。如果將其設為“保留EEPROM”，則在編程過程中刪除董事會時，將不會刪除EEPROM。如果將其設為“未保留”，則上傳新草圖將清除EEPROM記憶體。請注意，這僅在透過UPDI進行編程時適用 - 透過引導程式編程永遠不會觸摸EEPROM。
您必須執行“燃燒啟動加載程序”才能在修改此設定後應用更改，因為Eesave與可用於禁用Updi的eesave是同一保險絲，使其成為“不安全”的保險絲（如果用該保險絲編寫，則錯誤的選項可能會使設備難以重新編程）。我們在上傳草圖時不會寫「不安全」的保險絲，因為永遠不可能透過上傳來磚頭，您可以在不打開工具選單的情況下進行操作，並看到您忘記了將選項更改回到的目前項目的意圖。
這些零件正式支援BOD觸發1.8V，2.6V和4.2V的BOD觸發水平，何時禁用，活動和採樣的操作選項為何時處於活動狀態和睡眠模式時- 殘疾人無需使用額外的功能，主動使用最多，並且使用最多，並且採樣在中間。從2.1.0開始，將主動/睡眠模式合併為單一選單，刪除了荒謬的選項（例如，在睡覺時使用比醒著時使用更具侵略性的BOD），並添加了先前未暴露的選項。取樣模式現在可以使用兩個取樣率（正如您所期望的那樣，一個較快的功率越快）和「啟用hold wake」：在這種模式下，在該模式下，BOD在睡眠中被停用，在不睡覺時啟用，醒來時啟用了向上，直到BOD準備好之前，程式碼執行才開始。有關功耗和這些選項的含義的詳細信息，請參見數據表。
您必須進行刻錄啟動載入程式才能套用此設定。這種保險絲被認為是「不安全」的，因為您可以將BOD水平設置為高於焊接到同一PCB的其他晶片耐受的最高電壓，並與AVR共享電源軌，這將防止重新編程而不會脫落物（因為您要么無法對AVR進行編程，因為它是在BrownOut重置中，要么以足夠高的電壓使BOR供電，因此您會損壞上述低壓零件）。
在初始標頭文件和初步數據表發布之間，以及每個版本的最新版本，從Tinyavr 0/1系列數據表中刪除了幾個BOD設置，而ATPACK發行說明將其描述為“無限制” - （我知道這是這樣的，與工廠測試過程以及這些零件已認證的安全關鍵應用程式的審查過程有關。三個官方的BOD等級是保證晶片的電壓（是的，它們在數據表中使用該單字！）在製造商指定的溫度範圍內工作，並且以系統時脈頻率運行，沒有比該電壓指定的不高。儘管如此，人們認為其他5個BOD等級正如人們所期望的那樣（我已經成功使用了），但是Microchip並不能保證它們會工作，即使滿足了所有其他操作要求，我也不相信它們在生產中進行了測試。這些「不保證」電壓仍由MegatinyCore BOD下拉選單支持，但是（截至2.0.4-首個具有新標頭的版本）在子選單中標記為「（非正式）」。請注意，新標頭不再為這些BOD等級提供*_gc enum條目。
| BOD等級
0/1系列| BOD等級
2系列|保證速度
正常溫度。範圍|保證速度
升高的溫度。範圍）| ------------ | ---------------------------------- ---------------------------------- --| | 1.8V | 1.8V | 5 MHz | 4 MHz | | 2.1V | 2.15V |非官方|非官方| | 2.6V | 2.6V | 10 MHz | 8 MHz | | 2.9V | 2.95V |非官方|非官方| | 3.3V | 3.3V |非官方|非官方| | 3.7V | 3.7V |非官方|非官方| | 4.0V | 4.0V |非官方|非官方| | 4.2V | 4.3V | 20 MHz | 16 MHz |
0/1系列零件上的正常溫度範圍為-40-105c，在2系列零件上為-40-85c。這些零件在零件編號末尾有一個字母n（0/1系列）或u（2系）；這在0/1系列上也標記在實體晶片上，但在2系列上也標記了這一點。
延長溫度範圍為-40-125C，這些部分以F溫度規格表示。當溫度範圍高於正常範圍且在F-Spec零件上，溫度範圍柱將適用。如果正常溫度範圍列在正常溫度範圍內運行，則仍適用於F-Spec零件。
大多數現有的Arduino庫都起作用。有關更完整的列表，請參閱“受支援的庫”列表，並討論哪些圖書館可能存在問題。在少數不起作用的庫中，少數碰巧也非常流行和大量使用，因此，有必要與MegatinyCore一起包含一個相容版本。除此之外，還包括暴露僅現代AVR上的硬體的庫。這些庫在下面列出。
該庫提供了兩個功能來檢查它正在運行的晶片的調整狀態，現在添加了兩個軟體重置功能（透過WDT或透過軟體重置）。它還保存著大量的關鍵字。
MEGATINYCORE HERPER圖書館文檔
通常的Neopixel（WS2812）庫，包括受歡迎的封裝以及Adafruitneopixel，在這些零件上都有問題 - 它們取決於手動調整的組件，但是幾個關鍵指令的執行時間已得到改善。這些改進能夠對驅動這些LED的程式碼進行大量簡化。該核心包括一個相容的TinyNeopixel庫的版本，用於與這些無所不在的可尋址LED介面。有兩個版本，都基於Adafruit_neopixel庫緊密。一個人實現了一個真正相同的API，僅在名稱上有所不同（顯然，它在Tinyavr和Dx系列以及Megaavr 0系列零件上以從8 8 MHz到48 MHz的速度工作的事實，而不是在大多數經典AVR上12和16 MHz）。另一個版本對構造函數進行了略有更改，並放棄了在運行時更改長度的支持，以實現大量的閃光節省（左右）。有關更多信息，請參見TinyNeopixel文檔，其中包括範例。
標準的EEPROM.H可以在此處使用 - 它的工作原理就像在任何AVR上一樣。 USERSIG.h （來自資料表有時稱為USERROW的「使用者簽署」）它具有與EEPROM相同的API，儘管將來可能會增加與DX友善函數進行協調的，以更新多個位元組。 DX系列零件只能刪除整個USERROW，因此每個位元組都可能涉及刪除和重寫所有內容 - 如何處理的問題就是為什麼DXCore還沒有使用者庫）。名稱「使用者」是指USERROW的替代名稱，「使用者簽署」空間 - 無法使用userrow的名稱，因為它是由io標頭定義的（這是userrow_t type USERROW_t的struct ，由USERROW.USERROW0組成通過USERROW.USERROW31 。
注意：在2.1.0之前，我們試圖透過EEPROM庫支援USERROW變得聰明；這不僅是近視的（因為它在邏輯上與超過256b的EEPROM相抵觸），還引入了一些嚴重的錯誤。為此，使用USERSIG.h庫。
來自Library Manager的通常的伺服庫與這些零件不相容（較小的更改可能使其“起作用”，但存在明顯的問題和對TCA0配置的依賴）。核心提供了伺服庫的版本，該版本將選擇適當的計時器（TCB0是大多數零件上唯一的選項，在具有TCB1（2系和3216、3217、3217、1617、1616和1614）的零件上，將使用TCB1相反，只要它不用於millis() ）。除了具有TCB1的零件外，音調不能與伺服庫同時使用。在更高的時脈速度下，伺服輸出更好；使用伺服器時，建議以操作電壓允許的最高頻率運行，以最大程度地減少抖動。
警告如果您已將伺服庫的版本安裝到您的/庫資料夾（包括透過庫管理器），則IDE將使用該版本的庫（與這些零件不相容），而不是MegatinyCore提供的版本（它是）。作為解決方法，包括其他名稱的伺服庫的複製品包括#include 而不是#include - 無需其他程式碼變更。
請注意，伺服庫僅在2.2.0版中固定 - 在此之前，我們有一個伺服庫，但是由於大量的錯誤，它沒有起作用（我發誓我對其進行了測試 - 顯然還不夠好）。
由@mcudude撰寫，這提供了圍繞optiboot.h庫（由著名的@westfw撰寫）的更容易訪問（更容易訪問！）包裝。透過將應用程式程式碼呼叫例程在引導程式中寫入閃存，這支援使用Optiboot將其寫入任何裝置的閃光燈。所有現代AVR都有內建的快閃記憶體保護機制，僅允許從Bootloader部分（ BOOTCODE ，其術語中的Boot Code）執行程式碼，以寫入應用程式部分（ APPCODE ）。雖然硬體確實支援第三個快閃記憶體部分（ APPDATA ），但該部分可以透過APPCODE中的程式碼編寫，僅當也定義了BOOTCODE部分時，這才可用（否則將整個閃光燈視為BOOTCODE而將永遠無法自行編程） ，並且需要單獨的此庫的實作。也可以透過使用DXCORE FLASH.H所使用的技巧的類似物來獲得flash-write-from-app app。由於似乎對這種功能的需求很少，因此目前尚未實現該功能（它們是在DXCore的Flash Writing庫上實施的，因為額外的努力實際上是零的，並且因為有對該功能特別感興趣的用戶）。如果有人想要這個，並且會調整庫，我可以將入口點添加到核心中，並為您提供一些將其稱為的內聯彙編組合。關於術語的注意：在AVR DX系列上，保險絲稱為BOOTSIZE和CODESIZE而在0/1系列Tinyavrs上，它們稱為BOOTEND和APPEND 。我不太確定他們在稱呼「應用程式結尾」時沒有預見的客戶混亂，無論他們做同樣的事情，儘管tinyavrs上的粒度更加細膩，但正如您所期望的那樣。
optiboot_flasher文檔
如上所述，有一個用於DXCORE的庫，該庫也名為Flash.h 。兩者都允許使用Optiboot（如果存在）將應用程式寫入快閃記憶體。那是他們唯一的相似之處。 API，NVM硬件，用於呼叫引導程式的方法，基本上有關這些庫的所有內容都是不同的。確保為與您使用的硬體相符的程式碼編寫程式碼。雖然我（Spence Konde）寫了DXCore，但我對哪種方式「正確」沒有特別強烈的看法。我們將它們獨立做，但不是因為我們每個人都認為對方對應該如何做的想法是錯誤的。它們在很大程度上反映了硬體與閃光燈相互作用的方式。例如，MegatinyCore的一個面向頁面的頁面緩衝區，這些部分以頁面為導向的方式寫入，而DXCore庫僅在擦除時才關心頁面 - 在這些部分上，閃光燈用Word或Word或Word編寫即使是位元組粒度！
所有這些部分至少具有一對可配置的自訂邏輯（CCL）區塊；官方的微晶片術語稱其為“ LUTS”，以參考查找表（又稱真相表）。我們使用術語“邏輯區塊”，以避免與其他類型的查找表混淆（邏輯區塊中的“查找表”與大多數查找表非常不同；包含8個條目，每個條目是0或1個條目，它是一個單一字節，這不是一個表格），並且為了防止錯過本段的使用者被術語混淆。每個區塊可讓您提供任意的3輸入真實表，並配置其他選項，例如同步器，過濾器或邊緣偵測器。 CCL非同步運作（除非您使用同步器） - 這表示事情的發生速度可能比時脈更快。將CCL輸出同步到幾個時脈來源之一（系統時脈可能是您將與之同步的）。輸入可以來自引腳，事件或其他週邊設備。還有一個回饋輸入，它允許許多令人興奮的可能性，而「音序器」可以使用一對邏輯塊作為其輸入的輸出，就像閂鎖或觸發器一樣。這是一個非常強大的外圍設備 - 尤其是在兩個系列零件上，它們具有第二對邏輯塊，並且在一個變化狀態變化時觸發中斷的能力。
Logic（ #include Logic.h ）庫在TinyAVR 0/1/2系列設備中提供了一個簡單的包裝器。該庫還包含在DXCORE和MEGACOREX中，涵蓋了所有具有CCL硬體的AVR。由@mcudude撰寫。
邏輯庫文檔
這些零件具有1個（其他所有）或3（1614、1616、1617、3216和3217）的片上類比比較器，可用於比較兩個類比電壓，並取決於更大的，請做一個或多個以下內容：產生事件輸出，控制輸出接腳或發射中斷。電壓之一可以是內部參考（0系列）或由8位元DAC（其他所有內容）縮放的內部參考。該庫由@mcudude編寫，在模擬比較器周圍提供了一個簡單的包裝器，該包裝器使其配置更容易，並且由此產生的代碼更可讀取（在手腕上也更容易- 比手動配置暫存器的內容較少）在這些部分上揭示模擬比較器的幾乎完整功能集。請注意，不支援具有3個比較器的零件的視窗比較選項；不過，對那個的需求似乎沒有太大需求！
DXCORE和MEGACOREX中還包括了比較庫（ #include Comparator.h ），涵蓋了所有現代AVR，並帶有比較器硬體。由@mcudude撰寫。
比較庫文檔
通常，您應該期望以下關於庫的兼容性：
__AVR_ARCH__ >= 102的移植工作都應很小。architectures=*會表示它可以在任何地方工作 - 所有這些都是沒有單獨的資料夾，其中包含用於不同體系結構的實作。這並不意味著圖書館沒有對架構進行假設，對#ifdef s的特定架構進行測試等等。不幸的是，圖書館的作者知道它與幾個架構一起使用，聳聳肩，並假設它可以在任何地方使用並在該領域放下 *。端口庫所需的努力將根據圖書館而差異很大。對於任何合理熟悉這些部分的人，以及通常期望和接近它的任何人，有些人很簡單。 Any library associated with some peripheral that both classic and modern had, it's probably going to be a straightforward change if you just need to swap out the classic peripheral for the modern one - Yes, every bitfield will be named differently, but only rarely did a modern AVR's peripheral lack a feature the classic version had. The USART on classic AVR has whack stuff like MPCM, and the 9 bit mode - sorry, modes. Even the layout of some of the registers is similar - the parts aren't as different as they appear at first. Another type is the "bitbanger", where they're using direct port writes; the solution to this is cookbook - switch to using the relevant PORT or VPORT registers. Input capture is a little more complicated because you have to set up the event channel, and figure out how to offer that in a library (that is the hard part). But the consistent factor is that generally, none of these things are long slow painful slogs. And as noted above, many libraries will work out of the box, or have already been adapted.
The fact that many libraries can be ported no or little underlines the need for reports from users about incompatible libraries as well as compatible ones not listed on the table linked below. Usually reports of non-working libraries to add to the table result in the library getting fixed , and the fixed library being added to the table; Almost all of the fruit here low hanging. So when you come upon incompatible libraries report it to me! Many libraries that were initially incompatible were fixed up in under 10 minutes. Porting typical libraries from classic AVRs requires a fraction of the effort that the "tar pit" libraries included with this core take to port to new modern AVR families (these are Comparator, Logic, Event: Logic and Event are both, on their own, large, complicated, "system-like" peripherals. The CCL is just complex in general, and has seen relatively modest changest between families, except for the t0/1. Event is simple in theory and much more complicated in practice, in no small part because the implementation on the 0-series, 1-series, mega0, 2-series/DA/DB/DD, EA and the EB are each different. And a single library has to support all of them with a consistent interface and paper over all the differences.
I know lots of people use libraries that aren't on that list, and I fully expect that there is a great number of libraries that work and are not listed, and I'd love to hear about them. Use the "discussions" or email me, or even submit a PR to add a line to the table. I want to hear about working libraries so others will know they work and not hesitate, and I'm even more interested in ones that don't work so they can be fixed - or determined to be unfixable)
For more information on resetting from software, using the Watchdog Timer, the causes of unexpected resets and how to prevent them, and generally all things reset-related, see the Reset Guide.
It is often useful to identify what options are selected on the menus from within the sketch; this is particularly useful for verifying that you have selected the options you wrote the sketch for when opened later by yourself or someone who you shared it with. Or, you can use such in-sketch identification, combined with preprocessor #if macros, to select the appropriate code depending on the part or options at hand.
There are a great number of #define s provided to get information about the hardware in-use, in order to write portable and flexible code in your sketch or, especially, library code.
Note : You cannot distinguish an extended temperature range part from a normal one from software. For 0/1-series, most packages mark the temperature grade. this is no longer true on the 2-series, nor on any part released after the 1-series - So better make sure you mark those parts if you unpack them, because the only alternative is to give the lot number to Microchip support, and they'll tell you if it's an F, a U, or an N (FUN letters - but notice that you can't turn any letter into any other letter without both erasing and adding lines. The same is true of the different set of letters they used on automotive parts - BMZ or something - less FUN, but they had the same "modification resistance" (hey, on at least one occasion, a quantity of t13'd had the markings polished off and were remarked as tiny85's and sold as such on aliexpress and ebay - that was worth doing to some criminal in China! Unethical behavior is of course the norm for companies everywhere, but in the US, criminality of the company (as opposed to rogue employees) is not pervasive. When it rises above that, low end of chinese industry - ex, virtually all PVC wire is 2-8 AWG smaller than what is printed on the wire; same with silicone wire (but FEP insulated wire is always spot on, cause it's not at the low end ya see), one has to assume that (well, if they still marked the parts) someone has taken a bunch of parts marked I (vertical line), added 3 horizontal lines to each one (One imagines, with the same sort of automated chip marking method that would be used for putting any other pattern, except here it would just be the missing parts of an E. The consistency of the location of markings on packages is remarkably consistent specimen to specimen, such that you might be able to target by position and get it close enough to be convincing, and with just 3 small marks and no grinding, and significant price difference between I and E spec parts for certain parts (oddly, not for most tinies). Of course when they adopted the I and E when they stopped marking parts at all, so this is academic. But can you seriously imagine anyone inspecting 200 boards and writing down every lot number he saw, and emailing the list to Microchip and asking for confirmation that they're all E's as he ordered?).
A new version of Optiboot (Optiboot_x) now runs on the tinyAVR 0-Series, 1-Series and 2-Series chips. It's under 512 bytes, and works on all parts supported by this core, allowing for a convenient workflow with the same serial connections used for both uploading code and debugging (like a normal Arduino Pro Mini). Note the exception about not having autoreset unless you disable UPDI (except for the 20 and 24-pin 2-Series parts which can put reset on PB4 instead), which is a bit of a bummer.
To use the serial bootloader, select a board definition with (optiboot) after it. Note - the optiboot suffix might be visually cut off due to the width of the menu; the second / lower set of board definitions in the board menu are the optiboot ones). The 2-Series Optiboot definitions and the 0/1-Series Optiboot definitions are separate entries in the board menu.
See the Optiboot referencefor more information.
These guides cover subsystems of the core in much greater detail (some of it extraneous or excessive).
Covering top-level functions and macros that are non-standard, or are standard but poorly documented, and which aren't covered anywhere else.
The API reference for the analog-related functionality that is included in this core beyond the standard Arduino API.
The API reference for the digital I/O-related functionality that is included in this core, beyond the standard Arduino API, as well as a few digital I/O-related features that exist in the hardware which we provide no wrapper around.
Documents the (largely intended for internal use) dirty inline assembly macros that are used by the core to improve performance or reduce code size.
Includes a list of all interrupt vectors that can be used, how the flags are cleared (not a substitute for the datasheet - just a very quick reminder), which parts each vector exists on, and and what parts of the core, if any, make use of a vector. It also has general guidance and warnings relating to interrupts their handling, including estimates of real-world interrupt response times.
The USARTs (Serial) have some greatly enhanced functionality compared to the stock core.
Serial UPDI is our recommended tool for UPDI programming.
Supported clock sources and considerations for the use thereof.
Manufacturer specs for speed at various voltages, and some discussion of BOD thresholds - this is written largely from a very conservative perspective, in contrast to most of the documentation.
These are provided by the core and can be overridden with code to run in the event of certain conditions, or at certain times in the startup process.
The core feature #define s are used by megaTinyCore and other cores I maintain as well. This also documents what constant values are defined by the core for version identification, testing for features, and dealing with compatibility problems.
Export compiled binary generates both assembly listings and memory maps, in addition to the hex file. The options selected are encoded in the name of the file to help prevent confusion and make it easy to compare two configurations when you are surprised by the differences between them. Also provides links to a script I wrote to reformate memory maps so you can read the damned things.
The sources of reset, and how to handle reset cause flags to ensure clean resets and proper functioning in adverse events. Must read for production systems
The installation and operation of the Optiboot bootloader (for uploading over straight serial (not SerialUPDI)) is described here. Not recommended except on the 20/24-pin 2-Series (since they have the alt reset pin) or for special use cases that demand it.
This contains detailed information on how the timers are used in megaTinyCore, and some background on their capabilities.
These guides are older; some are still relevant.
This has been recently updated and will likely be turned into a Ref_TCA0.
This document describes how (on the 0 and 1 Series only) the ADC can be taken over and reconfigured, with particular attention to free running mode. The 2-Series ADC is different, and it would require changes to reflect those differences.
A delightful, though unfortunately short, document on bare metal programming in C.
The bible of the AVR instruction set. Like any such tome, it is a lengthy document which contains timeless wisdom from the creator(s), written in obtuse and challenging language and a confusing syntax (though you won't go to hell if you don't read it, if you're writing assembly without it, you might not be able to tell the difference).
As promised, a bunch of additional information was released; Unfortunately it leaves some of the key questions unanswered.
printf() implementation - The default option can be swapped for a lighter weight version that omits most functionality to save a tiny amount of flash, or for a full implementation (which allows printing floats with it) at the cost of about 1k extra flash. Note that if non-default options are selected, the implementation is always included in the binary, and will take space even if not called. This applies everywhere that format strings are used, including Serial.printf() .attachPortAEnable() and replace A with the letter of the port) before attaching the interrupt. This allows attachInterrupt() to be used without precluding any use of a manually defined interrupt (which is always much faster to respond). Basically any time you "attach" an interrupt, the performance is much worse.millis() , micros() and pulseInLong() will be available. If set to disable, these will not be available, Serial methods which take a timeout as an argument will not have an accurate timeout (though the actual time will be proportional to the timeout supplied); delay() will still work. Disabling millis() and micros() saves flash, and eliminates the millis() interrupt every 1-2 ms; this is especially useful on the 8-pin parts which are extremely limited in flash. Depending on the part, options to force millis() / micros() onto specific timers are available. A #error will be shown upon compile if a specific timer is chosen but that timer does not exist on the part in question (as the 0-Series parts have fewer timers, but run from the same variant). If RTC is selected, micros() and pulseInLong() will not be available - only millis() will be.There are however a few cautions warranted regarding megaTinyCore - either areas where the core is different from official cores, or where the behavior is the same, but not as well known.
If you are manually manipulating registers controlling a peripheral, except as specifically noted in relevant reference pages, the stated behavior of API functions can no longer be assured. It may work like you hope, it may not, and it is not a bug if it does not, and you should not assume that calling said API functions will not adversely impact the rest of your application. For example, if you "take over" TCA0, you should not expect that using analogWrite() - except on the two pins on the 20/24-pin parts controlled by TCD0 - will work for generating PWM. If you reconfigure TCA0 except as noted in Ref_Timers, without calling takeOverTCA0 , both analogWrite() and digitalWrite() on a PWM pin may disrupt your changed configuration.
While we generally make an effort to emulate the official Arduino core, there are a few cases where the decision was made to have different behavior to avoid compromising the overall functionality; the official core is disappointing on many levels. The following is a (hopefully nearly complete) list of these cases.
Earlier versions of megaTinyCore, and possibly very early versions of DxCore enabled the internal pullup resistors on the I2C pins. This is no longer done automatically - they are not strong enough to meet the I2C specifications, and it is preferable for it to fail consistently without external ones than to work under simple conditions with the internal ones, yet fail under more demanding ones (more devices, longer wires, etc). However, as a testing aid, we supply Wire. usePullups() to turn on the weak internal pullups. If usePullups() ever fixes anything, you should install external pullups straight away. Our position is that whenever external pullups are not present, I2C is not expected to work. Remember that many modules include their own on-board pullups. For more information, including on the appropriate values for pullups, see the Wire library documentation
The official core for the (similar) megaAVR 0-Series parts, which megaTinyCore was based on, fiddles with the interrupt priority (bet you didn't know that!) in methods that are of dubious wisdoom. megaTinyCore does not do this, saving several hundred bytes of flash in the process, and fixing at least one serious bug which could result in the microcontroller hanging if Serial was used in ways that everyone tell stroller hanging if Serial was used in ways that everyone to s catller hanging serial was used in ways that everyone to quent sently 5 筆 筆。 Writing to Serial when its buffer is full, or calling Serial.flush() with interrupts disabled, or during another ISR (which you really shouldn't do ) will behave as it does on classic AVRs and simply block, manually calling the transmit handlers, until there is space in the buffer for all of the data waiting to be written or the buffer is empty (for flush() ). On th stock megaAVR core, this could hang forever.
This is deprecated on the official core and is, and always has been, a dreadful misfeature. Dropped as of 2.3.0.
digitalRead() Does Not Turn Off PWM On official cores, and most third party ones, the digitalRead() function turns off PWM when called on a pin. This behavior is not documented by the Arduino reference. This interferes with certain optimizations, makes digitalRead() take at least twice as long (likely much longer) as it needs to and generally makes little sense. Why should a "read" operation change the thing it's called on? We have a function that alters the pin it's called on: digitalWrite() . There does not seem to be a logically coherent reason for this and, insofar as Arduino is supposed to be an educational platform it makes simple demonstrations of what PWM is non-trivial (imagine setting a pin to output PWM, and then looking at the output by repeatedly reading the pin).
digitalWrite() and INPUT Pins Like the official "megaavr" core, calling digitalWrite() on a pin currently set INPUT will enable or disable the pullups as appropriate. digitalWrite() also supports "CHANGE" as an option; on the official core, this will turn the pullup on, regardless of which state the pin was previously in, instead of toggling the state of it. The state of the pullup is now set to match the value that the port output register was just set to.
This was done because of the huge volume of code that makes use of this behavior. We experimented with making pinMode() do the inverse for INPUT and INPUT_PULLUP, but this was removed by unanimous agreement by everyone in the discussion thread.
analogWrite() and TCD0 Pins Please see the above PWM feature description if using PWM on those pins and also using digitalRead() or direct port writes on the same pins (PIN_PC0, and PIN_PC1).
On the official "megaavr" board package, TCA0 is configured for "single mode" as a three-channel 16-bit timer (used to output 8-bit PWM). megaTinyCore always configures it for "Split mode" to get additional PWM outputs. See the datasheets for more information on the capabilities of TCA0. See Taking over TCA0 for information on reconfiguring it. One downside to this is that the compare channels do not support buffering, so changing the duty cycle can cause a glitch lasting up to one PWM cycle (generally under 1 ms).
0 is a count, so at 255, there are 256 steps, and 255 of those will generate PWM output - but since Arduino defines 0 as always off and 255 as always on, there are only 254 possible values that it will use. The result of this is that (I don't remember which) either analogWrite(pin,254) results in it being LOW 2/256's of the time, or analogWrite(pin,1) results in it being HIGH 2/256 the the時間。 On megaTinyCore, with 255 steps, 254 of which generate PWM, the hardware is configured to match the API, and this does not occur. As it happens, 255 also (mathematically) works out such that integer math gets exact results for millis() timing with both 16-MHz-derived and 20-MHz-derived clock speeds, which millis()定時。 The same thing is done for TCD0, though to 509, giving 510 steps. analogWrite() accounts for this, so that we can get the same output frequency while keeping the fastest synchronization prescaler for fastest synchronization between TCD0 and system clock domains.
On the official "megaavr" board package, as well as DxCore, the Type B timers are used to generate 8-bit PWM (one pin per timer). There are very few circumstances where this could increase the number of usable PWM pins. These timers are just too scarce and valuable on these parts. Being minimally useful for PWM, in short supply, and highly desirable for other purposes, support for using Type B timers for PWM was removed in order to save space that would support for be used initializing these time for analogWrite() 。等人。 If a Type B timer is used for millis() , it is configured in a radically different way than the official core does it.
They return and expect uint8_t (byte) values, not enum s like the official megaavr board package does. Like classic AVR cores, constants like LOW , HIGH , etc are simply #define d to appropriate values. The use of enum s unfortunately broke many common Arduino programming idioms and existing code (granted, these idioms were poor programming practice - they're also incredibly widespread and convenient), increased flash usage, lowered performance and made optimization more challenging. The enum implementation made language design purists comfortable and provided error checking for newbies, because you couldn't pass anything that wasn't a PinState to a digital I/O function and would see that error if you accidentally got careless. Nevertheless, due to all the complaints, a compatibility layer was added to the official core, so all the old tricks would work again, it was just less performant. However, that got rid of what was probably the most compelling benefit by allowing the workarounds: the fact that it did generate an error for new users to train them away from common Arduino practices like passing 1 or 0 to digitalWrite() , if(digitalRead(pin)) and the like. The choice of names of the enum s also had the perverse effect of making PinMode(pin,OUTPUT) (an obvious typo of pinMode(pin,OUTPUT) ) into valid syntax (comma operator turns pin,OUTPUT into OUTPUT , and it returns a new PinMode of value OUTPUT ...) and does nothing with it, instead of a syntax error (It took me over an hour to find the erroneous capitalization. That evening, I converted the digital I/O functions to the old signatures and removed the enum s). Anyway - the enum s are not present here, and they never will be; this is the case with MegaCoreX and DxCore as well.
There are two classes of significant low level architectural differences (aside from the vastly improved peripherals): the improved instruction set and the unified memory address space.
The classic AVR devices all use the venerable AVRe (ATtiny) or AVRe+ (ATmega) instruction set ( AVRe+ differs from AVRe in that it has hardware multiplication and supports devices with more than 64k of flash). Modern AVR devices (with the exception of ones with minuscule flash and memory, such as the ATtiny10, which use the reduced core AVRrc ) all use the latest iteration of the AVR instruction set, AVRxt . AVRxt has much in common with AVRxm (used in XMega parts) in terms of instruction timing - and in the few places where they differ, AVRxt is faster (SBIC, as well as LDD, and LD with pre-decrement, are all 1 clock slower on AVRxm vs AVRxt or AVRe ), however AVRxt doesn't have the single-instruction-two-clock read-and-write instructions for memory access LAT , LAC , LAS , and XCH . The difference between subspecies of the AVR instruction set is unimportant for 99.9% of users - but if you happen to be working with hand-tuned assembly (or are using a library that does so and assembly (or are using a library that does so and assembly why, the areare that that does so ), are'變化是：
As you can see, everything that involves writing to the SRAM is faster now; it would appear that any time it is writing to a location based on one of the pointer registers or the stack pointer, it's a single cycle. All the other improvements except CBI and SBI can be viewed as a consequence of that. Of course, the variants of CALL are faster; they have to put the return address into the stack. I can't say I've ever felt like LAT , LAC , or LAS would be terribly useful as they are described in the instruction set manual - those take a register and the address pointed to by the Z register, load the contents of the specified address and toggle, set or clear in that memory address the bits that were set to begin with in the register. If that worked on special function registers, it would be a very useful instruction, taking PERIPHERAL.REGISTER |= SOME_BIT_bm; from a 5 clock, non-atomic operation to a 2 clock atomic one! But it says they only work on SRAM... so not as much of a loss. XCH is more obviously useful than the others, but all 4 of them come with the need to set up the Z register... which in many cases would take long enough that it wouldn't be a notable improvement.
Note that the improvement to PUSH can make interrupts respond significantly faster (since they have to push the contents of registers onto the stack at the beginning of the ISR), though the corresponding POP s at the end aren't any faster. The change with ST impacted tinyNeoPixel. Prior to my realizing this, the library worked on SK6812 LEDs (which happened to be what I tested with) at 16/20 MHz, but not real WS2812's. However, once I discovered this, I was able to leverage it to use a single tinyNeoPixel library instead of a different one for each port like was needed with ATTinyCore (for 8 MHz, they need to use the single cycle OUT on classic AVRs to meet timing requirements, the two cycle ST was just too slow; hence the port had to be known at compile time, or there must be one copy of the routine for each port, an extravagance that the ATtiny parts cannot afford. But with single cycle ST , that issue vanished).
Oh, and one other instruction it doesn't have that (some) AVRxm parts have: The hardware DES encryption instruction - an instruction which is most effective at marking AVRxm as, ah, back from the time when DES was a big deal.
On all modern AVRs with up to 48k of flash, both the flash and ram reside in the same address space - On tinyAVRs, the program memory starts at 0x8000, while on megaAVR 0-Series, it starts at 0x4000 to leave room for the 48k of flash that they can have, and on the Dx-Series parts with up to 32k of flash, they have the same layout as the tinyAVRs, while Dx-Series parts with 64k or 128k of flash have a 32k section of flash mapped at any given time (how to make sure variables go into this memory mapped flash has been described elsewhere in this document). There is another big and fundamental change to the layout of the address space as well: the registers are organized by peripheral. PORTA is assigned 0x400 to 0x41F. PORTB is the next 32 bytes, and so on - and the address space is far sparser - all the peripherals have multiple "reserved" registers that may or may not get functions added in the future. And each instance of a peripheral on a part that has multiple of them has the same layout. You can, say, pass a pointer to a TCB around without the functions that get it knowing which TCB they'll get, and then access the TCB registers through it. On classic AVRs the names of the registers were consistent, but their locations were all over the place, packed much more tightly, so that sort of trick isn't possible. This also means that the EEPROM (and USERROW) are part of this unified address space (on classic AVRs, reading was accomplished through special function registers, and was far more awkward).
The lowest 64 registers are special - you can read or write them with the IN or OUT instructions (hence, "I/O space") in a single clock cycle, without setting up a pointer to them as you would need to with ST or LD . The 32 "Low I/O registers" additionally have bit-level access instructions CBI and SBI to clear and set bits, and SBIC / SBIS to skip the next instruction if a certain bit is set or cleared. On all AVRxt parts released so far, the low I/O registers are used only for the VPORTs, up to VPORTG or the last port on the part, whichever comes first. This means VPORTG.OUT |= 1 << n , where n is known at compile-time and constant , is a 1 clock cycle atomic operation , while VPORTG.OUT = 1 << n (note the = in lieu of |= ) takes two clock cycles. For the latter, the first cycle is to put the value to be stored into a register, and the second is to write it with an OUT instruction. The GPIOR0-3 registers occupying the last 4 bytes in the low I/O space (those are user-defined registers to use as you choose. We use GPIOR0 internally during startup to record reset cacause, andlicet caus, and war woable causables 片段）。 The reset flag register is always cleared very early in startup to prevent dirty resets, and when using a bootloader, so that it can honor bootloader entry conditions on next reset). No other part of this core touches those registers, and we only set GPIOR0; we never read it. So all can be used freely, as long as you remember that GPIOR0 is not empty when you enter setup, and contains the reset cause flags. Other Low I/O registers are not used by the hardware.
The 32 "high I/O registers" are used even less - they only contain the the stack pointer, RAMPZ on the 128k DA/DB parts, SREG , and CCP (Configuration Change Protection - where _PROTECTED_WRITE() does it's magic to let you write to protected registers. That's all - 5 out of 32 registers are used, the rest are "reserved". On classic AVRs, registers for assorted peripherals that the designers thought would be accessed often were put into the I/O space, so it was a disappointment that they didn't put an alias of any other registers there. I'd vote for the intflags registers to be aliased there
megaTinyCore itself is released under the LGPL 2.1. It may be used, modified, and distributed freely, and it may be used as part of an application which, itself, is not open source (though any modifications to these libraries must be released under the LGPL as well). Unlike LGPLv3, if this is used in a commercial product, you are not required to provide means for users to update it.
The DxCore hardware package (and by extension this repository) contains DxCore as well as libraries, bootloaders, and tools. These are released under the same license, unless specified otherwise . For example, tinyNeoPixel and tinyNeoPixel_Static, being based on Adafruit's library, are released under GPLv3, as described in the LICENSE.md in those subfolders and within the body of the library files themselves.
The pyupdi-style serial uploader in megaavr/tools is a substantially renovated version of pymcuprog from Microchip, which is not open source has now been released under the open source MIT license! 。
Any third party tools or libraries installed on behalf of megaTinyCoreCore when installed via board manager (including but not limited to, for example, avr-gcc and avrdude) are covered by different licenses as described in their respective license files.
