MiniCore is an Arduino core for the small ATmegas
Arduino hardware package for ATmega8, ATmega48, ATmega88, ATmega168, ATmega328 and ATmega328PB
At a glance
- What is it?
- MiniCore is an Arduino hardware package for the ATmega8, 48, 88, 168 and 328, with Urboot in place of Optiboot, a long list of selectable clock frequencies, an optional bootloader, and hardware debugging in Arduino IDE 2. It is a replacement core for people who want a specific chip and clock, not a general purpose Arduino distribution.
- Who is it for?
- MiniCore is worth adopting if you are building on one of the small ATmegas and you need a specific clock frequency, a particular chip variant, or the smaller Urboot bootloader, because the stock Arduino core gives you none of those choices. It is the wrong choice for a beginner project, because the install is a manual board selection and a bootloader burn rather than a click, and it is the wrong choice if you need a chip outside the ATmega8 to ATmega328PB family.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 75 days ago.
- What is it written in?
- Mainly C++, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
A core for chips the stock Arduino does not cover
MiniCore is an Arduino core for the ATmega328, ATmega168, ATmega88, ATmega48 and ATmega8, and the project description calls it an Arduino hardware package for those parts. The supported list also covers all the variants, the A, P, PA and PB versions, and the topics list adds the ATmega328PB explicitly.
The distinction between a core and a board is worth making, because it explains what this project is for. The Arduino IDE ships with a board definition that maps a menu selection to a chip, a clock, a programmer and a set of fuses. MiniCore replaces that definition for the small ATmega family and gives you far more choices inside it: which chip, which clock, which upload port, whether there is a bootloader at all, and how the brown out and EEPROM retention fuses are set.
The memory table shows what you are choosing between. The ATmega328 has 32kB of flash, 2kB of RAM and 1kB of EEPROM with 6 PWM pins, or 9 on the PB variant. The ATmega168 drops to 16kB, 1kB and 512B. The ATmega88 has 8kB, 1kB and 512B, the ATmega48 has 4kB, 512B and 256B with 320 bytes of bootloader savings, and the ATmega8 has 8kB, 1kB and 512B with only 3 PWM pins.
That last column is why the bootloader's size matters on these parts, because on a chip with 4kB of flash the 320 bytes the bootloader takes is not a rounding error.
The audience is a maker who has decided on a specific ATmega, often because it is in stock, cheap, or already in a product they are building, and who needs the Arduino workflow with that chip rather than the UNO's default ATmega328P at 16MHz.
Urboot replaces Optiboot, and the size difference is the point
From MiniCore version 3 and onwards, the Optiboot bootloader has been replaced by the superior Urboot bootloader, and the documentation gives three reasons: it is smaller, it is faster, and it has automatic baud rate detection, and it can read and write to EEPROM.
The size difference is the one that matters on these chips, and the documentation quantifies it. Disabling the bootloader entirely frees 384 bytes of flash memory on the ATmega8, 88, 168 and 328, and 320 bytes on the ATmega48. So on an ATmega48 with 4kB of flash, the bootloader is roughly eight percent of the program space, which is the difference between a sketch that fits and one that does not.
The other Urboot features are named but explicitly not used by MiniCore. User program metadata stored in flash, which can easily be viewed with avrdude -xshowall, and chip erase functionality. So the bootloader is capable of more than MiniCore asks of it, and if you need those features you would flash Urboot yourself rather than expect the board manager to do it.
The migration story is handled calmly. If you already have Optiboot installed and do not want to replace it with Urboot, you can still upload programs without any compatibility issues. However, if you are burning a bootloader to a new chip, Urboot is the way to go.
That is a fair position for a hardware package. The bootloader choice is the one part of an Arduino core that touches a chip's fuses and its first bytes of flash, and the project is explicit that changing it is a decision, not an automatic upgrade.
The clock list is really a list of UART friendly frequencies
The supported clock frequency table is long, and reading it closely explains why.
There are nineteen entries, and the pattern is that the frequencies which are described as a great clock for UART communication with no error are the non round ones: 18.4320 MHz, 14.7456 MHz, 11.0592 MHz, 9.216 MHz, 7.3728 MHz, 3.6864 MHz and 1.8432 MHz. The round ones, 16 MHz, 20 MHz, 12 MHz, 6 MHz, 4 MHz, 2 MHz and 1 MHz, are listed without that comment, because the divider does not come out as a whole number for the usual serial rates.
The baud rate section states the rule directly. A rule of thumb is that non round baud rates like 230400 work best with non round clock speeds like 18.4320 MHz, while round ones like 16 MHz work best with round baud rates like 25000.
This is the real reason to install a custom core. Serial communication is where a wrong clock immediately shows up, as garbled characters, and the standard 16MHz crystal does not divide cleanly into 115200 baud. Choosing 18.4320 MHz and a matching baud rate is the difference between a working serial link and a flaky one, and a core that only offers you 16MHz forces you to solve that with a different baud rate or a different crystal.
Two more entries are worth noting. 8 MHz with an external crystal is described as the common clock when working with 3.3V, which matters because the ATmega is a 5V part and 3.3V peripherals need the timing to be right. And there are internal oscillator options at 8, 4, 2 and 1 MHz, the smaller ones derived from the 8 MHz internal oscillator, which lets you run without a crystal at all, at the cost of timing accuracy.
And Urboot's automatic baud rate detection is what makes the choice forgiving, since UART uploads should work fine even though the oscillator is a little too fast or too slow.
Burning the bootloader is a fuse operation, not an optional step
There is one instruction in the documentation that decides whether your first session with MiniCore works, and it is repeated in more than one place.
You will have to hit Burn bootloader in order to set the correct fuses and upload the correct bootloader. This also has to be done if you want to change any of the fuse settings, the BOD and EEPROM settings, regardless of whether a bootloader is installed or not.
That is a stronger requirement than a normal Arduino board, where the fuses are set once when the board is manufactured and you never touch them. Here the clock frequency is a fuse setting, and the brown out detector and the EEPROM retention behaviour are fuse settings, so choosing a different clock or flipping a retention option means a programmer and a reflash of the fuse bytes.
The documentation also says to make sure you connect an ISP programmer and select the correct one in the Programmers menu, and that for time critical operations an external crystal or oscillator is recommended.
The bootloader's own settings are a separate axis. MiniCore lets you select which serial port you want to use for uploading, with UART0 as the default port for all targets, while the ATmega328PB can also use UART1. And you need to connect a programmer and hit Burn bootloader if you want to change any of the bootloader settings.
So there are two distinct reasons to reach for the ISP programmer: setting the fuses, and changing what the bootloader does. Neither of them is a one time setup for a board you buy, because MiniCore is a definition for a chip you configure yourself, often a bare chip on your own board.
No bootloader at all is a supported choice
If your application does not need or require a bootloader for uploading, you can also choose to disable it by selecting No bootloader. And the documentation quantifies exactly what that buys: 384 bytes of flash memory on the ATmega8, 88, 168 and 328, and 320 bytes on the ATmega48.
This is a genuinely useful option that most Arduino users never consider, because the stock boards ship with a bootloader already burned. On a chip where you are writing the fuses yourself, the decision is yours, and on the smaller parts the saving is real.
The cost of that choice is that you can no longer upload over serial. You will be programming the chip with the ISP programmer every time. For a one off firmware in a product, that is usually the right trade. For a development board where you are iterating, it is not.
The README's table of contents lists the other options a user is expected to make, and they are all in the same family: the BOD option for the brown out detector, the EEPROM retain option, link time optimization, printf support, pin macros, a write to own flash feature, and a programmers section. The write to own flash entry is the one with its own heading in the table of contents, which suggests it is unusual enough to need explaining: it lets the sketch write to its own program flash, which is how a device can store configuration or a new firmware image in the field.
The documentation also points at a wiring reference and a pinout in the repository, under Wiring_reference.md and the avr directory, which is the practical part for anyone building a board rather than using a ready made one.
Four install routes, and one of them is not a package manager
The installation section of the README has four routes, and they differ in how much they assume about your setup.
The Boards Manager installation is the one for the Arduino IDE, which is where the board selection, the clock menu and the Burn bootloader button live. The Manual Installation is the fallback for a board manager that does not carry the package. The Arduino CLI Installation is for people who drive the toolchain from the command line, where the board selection, the FQBN and the burn bootloader step are expressed as commands rather than as menu choices. PlatformIO has its own document in the repository, PlatformIO.md, because PlatformIO has its own concept of a board manifest and its own notion of where a core lives.
The reason there are four is that MiniCore is not just a board definition, it is a package with tools: a bootloader to flash, fuses to set, and a clock to choose. An IDE integration has to expose all three, and each of the four routes does it differently.
There is also a support thread on the Arduino forum, linked from the badge at the top of the README. The forum thread is the better place for the specific questions that come up during a first install, because the people who answer there are the people who built the package.
For a first time user, the order that makes sense is the Boards Manager route, then Burn bootloader with the right programmer, then a trivial sketch over serial at a baud rate that matches the clock you chose. The last step is the one that catches people, because a clock and a baud rate have to agree.
Maintenance, licence, and when the stock core is enough
The repository is not archived, and the last push was on 2026-08-09, the same day as the v3.1.3 release. Before that came v3.1.2 on 2026-02-10 and v3.1.1 on 2025-05-03, so the project ships when there is something to ship rather than on a calendar, which is the right rhythm for something tied to a specific chip family and a specific bootloader.
The licence is a custom one that GitHub cannot classify, with the terms in the LICENSE file at the root of the repository. For a hardware package, that is worth a closer look than usual, because a core is copied into the Arduino IDE's hardware folder on the developer's machine, and in a product it is compiled into firmware. The file is the source of the terms, not the badge.
The primary language is C++, and the repository is small in the way a hardware package should be: an avr directory for the core, the wiring reference, the PlatformIO document, the readme and the licence.
The case against MiniCore is the case for the stock core. If you are building with an Arduino Uno or a Nano clone, the default core already works, the bootloader is already burned, the clock is already right, and every tutorial on the internet assumes it. The cost of MiniCore is that every one of those assumptions becomes a decision you make and can get wrong, and the documentation is candid that changing the clock means reaching for a programmer.
The case for it is just as concrete. A specific chip variant, a specific clock, a UART that does not garble, the largest possible program space on a small part, and, since version 3.1.0, hardware debugging in the Arduino IDE 2 with a Microchip EDBG debugger or a DIY dw-link unit. That is a list of constraints the stock core does not let you satisfy.
Editorial conclusion
MiniCore is worth adopting if you are building on one of the small ATmegas and you need a specific clock frequency, a particular chip variant, or the smaller Urboot bootloader, because the stock Arduino core gives you none of those choices. It is the wrong choice for a beginner project, because the install is a manual board selection and a bootloader burn rather than a click, and it is the wrong choice if you need a chip outside the ATmega8 to ATmega328PB family. Before you install it, pick the clock frequency you actually need and read the BOD and EEPROM retain options in the documentation, and note that the current release is v3.1.3 from 2026-08-09 with the repository pushed to on the same day.
Frequently asked questions
What is MiniCore and which microcontrollers does it support?
It is an Arduino core, an Arduino hardware package, for the ATmega8, ATmega48, ATmega88, ATmega168 and ATmega328, including the A, P, PA and PB variants. The repository topics list the ATmega328PB explicitly, and Arduino IDE v1.8 and v2.x are both supported.
Why did MiniCore replace Optiboot with Urboot?
The README says Urboot is superior because it is smaller, it is faster, and it has automatic baud rate detection, and it can read and write to EEPROM. If you already have Optiboot installed you can still upload programs without compatibility issues, but for a new chip the documentation recommends Urboot.
Do I need an ISP programmer to install MiniCore?
For the fuse settings, yes. The documentation says you will have to hit Burn bootloader to set the correct fuses and upload the correct bootloader, and that this also has to be done if you want to change the BOD or EEPROM settings, regardless of whether a bootloader is installed. You connect an ISP programmer and select the right one in the Programmers menu.
What clock frequencies does MiniCore support and why do some matter more for serial?
There are nineteen entries, from 16 MHz down to 1 MHz, including external crystals and internal oscillator options. The non round frequencies such as 18.4320 MHz, 14.7456 MHz and 11.0592 MHz are described as great for UART communication with no error, and the rule of thumb is that non round baud rates work best with non round clock speeds, while round ones like 16 MHz work best with round baud rates like 25000.
How much flash does disabling the MiniCore bootloader save?
The documentation says selecting No bootloader frees 384 bytes of flash memory on the ATmega8, 88, 168 and 328, and 320 bytes on the ATmega48. The trade is that the chip can then no longer be programmed over serial and needs the programmer each time.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/mcudude-minicore)Was this useful?