GyverCore - fast and light Arduino core for ATmega328

Hello, everyone! I want to introduce you the GyverCore - fast and light core for Arduino IDE with advanced configuration and a bunch of interesting stuff. Here is GitHub page with full information.

Use this url for Additional Boards Manager URLs:


  • All functions are replaced by lighter and faster versions
  • Wide syntax coloring map
  • Fast and light uart class (instead of Serial)
  • Advanced ADC control functions
  • Advanced board menu
  • Few bootloaders
  • New compiler version
  • Some useful fuse presets

Execution time comparsion

Flash comparsion

Board settings

  • Bootloader selection (old and new optiBoot with correct fuses, w/o bootloader)
  • Clock source and frequency selection (includes external and internal clock source)
  • Save EEPROM after flashing with programmer (y/n)
  • Clock Out (on pin D8)
  • System timer initialization (you can take control on timer 0 OVF vector)
  • Replace all calls of Serial to uart
  • B.O.D. disable or configure
  • Initialization (enable/disable default hardware initialization)
  • Compiler version (default and new version of avr-gcc - faster compiling and lighter code!)
    I hope you like it =)

Hmm. Explain how you do analogRead() in 5.41us when the minimum conversion time in the datasheet is 13us?

What's your support plan for the next decade or two? :frowning:
(I watched the "Wiring" folks show up a few years back, promising a faster, better, product with more chips supported. And then I watched not much at all happen. Very depressing.)

Datasheet is lying a little. ADC needs 13 tacts for conversion:

A normal conversion takes 13 ADC clock cycles. The first conversion after the ADC is switched on (ADEN in ADCSRA is set) takes 25 ADC clock cycles in order to initialize the analog circuitry.

adcClock = f_cpu/ adcPrescaler (2-128)
Max freq on 16 MHz = 8 MHz
8 MHz/13 tacts = 600 kHz = 1.6 uS
So it can be faster =)

The smaller prescalers are for slower cpu clocks. You can’t actually do an accurate conversion that quickly; the analog parts don’t go fast enough.
(Supposedly, you can get less accurate results, quicker...)

It is really stable, otherwise we wouldn’t do that as default

I don't understand why these improvements are not simply being proposed for inclusion in the standard Arduino code base.


(several pointless posts regarding a now-fixed spelling error have been deleted)

How long until the core supports the '1284P? I use that in a lot of my designs for the extra IO (32 vs 20, with four 8-bit ports), the large SRAM (16kbytes, twice that of the 2560), and sometimes the large flash (128K). It's not often that I need the all the IO and flash that the 2560 provides.

I don't think that we will make support for another MC's :frowning: maybe, just maybe, it will be ATtiny85 or 167. I've never heard of 1284 before :slight_smile: I am using Arduino Nano/Mini clones for my projects, so there was an idea to make it faster and more convenient to use with different fuses/bootloaders/clocks/etc.

That's too bad. If you look at their datasheets, Atmega1284P looks very similar to Atmega328P.
Four eight bit ports, ABCD, vs 3 ports BCD without all 8-pins brought out, and only 8 pins on port D
Two hardware serial ports vs just one.
Same SPI interface.
Same I2C interface.
16K SRAM vs 2K SRAM.
128K flash vs 32K flash.
Same interrupts, same lots of other stuff.

And the '1284P is supported in the IDE too

I don’t understand why these improvements are not simply being proposed for inclusion in the standard Arduino code base.

Well, first of all, Arduino (the company) has historically been reluctant or unwilling to accept “core” code that improves performance (look at how many times faster digitalWrite() implementations have been proposed.)
Secondly, a lot of the performance improvements in this particular set of code come from hard-wiring the functions for the ATmega328, rather than using the portability mechanism built into the normal Arduino core…