MiniCore - An Arduino core for the ATmega8/ 48/ 88/ 168/ 328

Other Hardware 3rd Party Boards
21

Meant ATTINY85-20PU
...
IMO, there are simply too many cores

Yes, there are too many cores out there, and that's why I've created a core for a whole family instead of single microcontrollers. IMO it's better to install ~3 or 4 cores and get support for most AVRs rather than installing one gigantic core where the author just push the code and never updates or supports it. The best ATtiny core out there is definitely Dr Azzy's core. If you for instance install MightyCore, MegaCore, MiniCore, GitHub - MCUdude/MicroCore: A light-weight Arduino hardware package for ATtiny13 and GitHub - SpenceKonde/ATTinyCore: Arduino core for ATtiny 1634, 828, x313, x4, x41, x5, x61, x7 and x8 you should have plenty of microcontrollers to work with.

I frequently recommend that people put the Uno bootloader on their ATmega328P 16MHz boards like Nano and Pro Mini. If a bit-more-advanced-than-beginner user has no need of majek's flash write modification, are there any other improvements in the version of Optiboot used in MiniCore vs the old one used for the stock Uno bootloader that warrant the extra complication of installing MiniCore? I did look at the comparison of majekw/optiboot/supermaster vs Optiboot/optiboot/v4.4 but I'm not sure how significant those commits are to this application.

No. If the user is using an ATmega328P go ATmega328PA and running them at 16 MHz them my core doesn't bring any advantage over the standard "Arduino UNO" option in the boards menu. The new bootloader is still equal or less than 512B, so I don't see why someone would prefer the "original" version. The Optiboot version that ships with Arduino IDE haven't had a significant update since late 2011. I'll regularly update my bootloader files and build new hex files when Majek pushes some significant changes.

It might be a good idea to add a link to the majekw/optiboot repository branch and commit that you got your bootloader source from to https://github.com/MCUdude/MiniCore/blob/master/avr/bootloaders/optiboot_flash/README.TXT(and your other cores) so that users can easily see if there have been any significant changes to majekw's fork or Optiboot/optiboot since that time. For example, I can see that your version is at least one commit behind majekw/optiboot/supermaster: Workaround for gcc 4.7/4.8 bug #50925 making unnecessary stack frame. · majekw/optiboot@6262a28 · GitHub.

Thanks! I'll definitely do that on all my cores :slight_smile:

22

Hi,

I WANT that MiniCore on my Arduino Pro Mini! :slight_smile:

But I got some problems...

The setup:
Two Arduino Pro Mini (identical), each with an ATmega328P, 8MHz (crystal clocked -
NO ceramic resonator), 3.3 V.

One prepared as Arduino as ISP and "OLD FASHION WIRED" (D10,D11,D12,D13...).
The other one on the way being MiniCored.

I did it.

It worked fine. No errors while flashing the new bootloader.

I disconnected the MiniCored Pro Mini and attached it directly to my FTDI cable
and tried to upload a simple sketch.

No chance.

The output of the IDE:
Sketch uses 2,208 bytes (6%) of program storage space. Maximum is 32,256 bytes.
Global variables use 216 bytes (10%) of dynamic memory, leaving 1,832 bytes for local variables. Maximum is 2,048 bytes.
/usr/local/arduino-1.6.9/hardware/tools/avr/bin/avrdude -C/home/mccramer/.arduino15/packages/watterott/hardware/avr/1.0.5/tools/avrdude.conf -v -patmega328p -carduino -P/dev/ttyUSB0 -b57600 -D -Uflash:w:/tmp/build85532bc1833fbf246595d6ba5d447797.tmp/CheckMCU.ino.hex:i

avrdude: Version 6.0.1, compiled on Apr 14 2015 at 19:04:16
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2009 Joerg Wunsch

System wide configuration file is "/home/mccramer/.arduino15/packages/watterott/hardware/avr/1.0.5/tools/avrdude.conf"
User configuration file is "/home/mccramer/.avrduderc"
User configuration file does not exist or is not a regular file, skipping

Using Port : /dev/ttyUSB0
Using Programmer : arduino
Overriding Baud Rate : 57600
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x00

avrdude done. Thank you.

Problem uploading to board. See http://www.arduino.cc/en/Guide/Troubleshooting#upload for suggestions.

Then I tried the same thing but choosing the original bootloader.
Everything works including uploading a sketch.

Now I am sitting here, scratching the top of my head and asking myself,
what I did so badly wrong...
(WARNING! I am relatively new to Arduino...)

Thank you very much for any help in advance! :slight_smile:

Best regards,
mcc

23

Open Arduino IDE preferences and turn on verbose output for uploading. Then post the output of the bootloader burning and the code upload. The upload error you're experiencing means that there is something wrong with the serial connection. May be the bootloader, the baud rate or the physical connection :wink:

Please post a picture of your physical setup as well. My Pro minis have mirrored programming headers, so the programmer needs to be connected the opposite direction to make it work

24

Hi hansibull,

I put the posting into a file attached.

...the posting became too long...

Best regards,
mcc

Post EDIT:
A photo of the pysical setup may come tommorrow ... the light is too bad (and my tablets
cam also...).
On the other hand: Same setup with the original bootloader works nice...it cant be
THAT wrong (famous last words...)

Menu_027.png

log.txt (14.5 KB)

25

Quick question; does the little LED on the Pro mini flash twice every second or so, after you're burnt the bootloader?

EDIT:
If the LED is flashing, that means that the bootloader is loaded and working. My best guess is the baud rate. Open the boards.txt file located at /home/mccramer/.arduino15/packages/MiniCore/hardware/avr/1.0.1/boards.txt and replace the baud rate at line 72. Insert 19200, 57600 or 115200 instead. Try all if the first one isn't working. You'll have to restart the IDE to load the changes.

You should probably also try the 8 MHz and the 1 MHz internal oscillator options. Does these works?

26

Hi,

LED flashes:
1.) Arduino is not connected to the FTDI-cable or anything else: No LED flashes :wink:
2.) Connecting the Arduino to the FTDI-cable: Power LED lights up. No further LEDs do anything.
3.) Pressing the RESET button of the Arduino: D13-LED starts flashing. Rythm:
X.X.........X.X.........X.X.........X.X.........X.X.........X.X.........
Each period is about 2+ but less then 3 seconds long.
4.) This flashing only stops, when I disconnect the Arduino from the power.
The "no sync"-messages of the IDE while trying to flash a sketch come in sync with the flashes.

I tried the different baudrates via changeing the board.txt: No success.
BUT 8MHz internal clock WORKS.

Therefore I have mis-set the settings while I was uploading the bootloader.
I will now flash the bootloader again with corrected settings...wait a second...
(or two...) ....

TADA! FIXED! Christmas day! :slight_smile:

Thank you so much for your help!

A small sketch, which reads the fuse bits and
signature off the chip gave me:

Signature 1E 95 F
Fuses F7 D6 FD CF

I put the Fuses into here:
http://www.engbedded.com/fusecalc/

which show me, that neither BOOTSZ0 nor BOOTSZ1 are set.
From here: Arduino / ATmega 328P fuse settings | Martyn Currey
I learned that a BOOTSZ=512byte are set when both BOOTZS*=1 which
seems not to be the case if MiniCore is flashed.
So it seems that BOOTSZ=2048 bytes is set with MiniCore?
Or am I again the only one, who needs some external additional informations needs to
be uploaded in the brain flash? :slight_smile:

Thanks a lot for your help to get this running so quickly, hansibull!
Best regards,
mcc

27

Great to hear! :smiley: And thanks for providing such rich information; it makes it much easier to provide support when all necessary data is available :wink:

28

WIN<->WIN!
:slight_smile:

Additionally I won a great tiny bootloader!

Best regards
mcc

PS: The fuse settings con-fuse-d me a little (see previous posting)...
may I ask you to take a closer look...it looks like there are set to
a bootsize of 2048...at least to my naked eyes...

29

Have a look at line 73 and 74 in the boards.txt file. The low fuse us set to 0xf7, and the high fuse is set to 0xd6. According to Engbeddeds fuse calc the boot flash section size is set to 256 words, which is 512 bytes.

30

Hansibull, thank you for your hard work with MiniCore!

My question is this - I've successfully burned bootloader with the bod set to 4.3v, but it seems to have messed with the clock rate. My code uses an interrupt to poll a gps chip, here's the snippet:

//Interrupt is called once a millisecond, looks for any new GPS data, and stores it
SIGNAL(TIMER0_COMPA_vect) {
char c = GPS.read();
}

void useInterrupt(boolean v) {
if (v) {
OCR0A = 0xAF;
TIMSK0 |= _BV(OCIE0A);
usingInterrupt = true;
}
else {
TIMSK0 &= ~_BV(OCIE0A);
usingInterrupt = false;
}
}

What I'm experiencing now is a very slow update, maybe once every 10 seconds instead of every second that the program loops.

Any thought on why this would be?

Thanks!

Briann

31

If the timing isn't correct, it means that you've set the wrong fuses. Select the correct click frequency, and hit "Burn bootloader". You can test this by uploading the blink sketch, and verify that delay(1000) is actually a second

32

Thanks for the MiniCore, I had big problems trying on my own, MiniCore made my day! :slight_smile:

33

jim_beam:
Thanks for the MiniCore, I had big problems trying on my own, MiniCore made my day! :slight_smile:

Thanks from me also. I am using Mega and Mini core now and hope to try out MightyCore in the near future.
Your work is appreciated!

34

I'm using mini-core but i'm a bit unclear on how it works. To increase the serial buffer size i believe i have to copy the core, adjust a #define, and point to the new core in boards.txt - how do i do that with minicore?

It's great by the way, thanks!

35

Hi everybody! Great to hear you guys use and enjoy MiniCore, that's the stuff that's keep me going :slight_smile:

I'm using mini-core but i'm a bit unclear on how it works. To increase the serial buffer size i believe i have to copy the core, adjust a #define, and point to the new core in boards.txt - how do i do that with minicore?

MiniCore doesn't have it's own copy of the Arduino source files, like MightyCore and MegaCore. If you want to increase the serial buffer size, you'll actually have to do changes to the original source files. I've tried to redefine the serial buffer size in the sketch, but the source files are compiled before the sketch, and is not picked up..

36

hansibull:
Hi everybody! Great to hear you guys use and enjoy MiniCore, that's the stuff that's keep me going :slight_smile:

MiniCore doesn't have it's own copy of the Arduino source files, like MightyCore and MegaCore. If you want to increase the serial buffer size, you'll actually have to do changes to the original source files. I've tried to redefine the serial buffer size in the sketch, but the source files are compiled before the sketch, and is not picked up..

so there's no way to point to a modified version of the core files?

37

so there's no way to point to a modified version of the core files?

If course you can copy the Arduino source files and add them to the MiniCore directory.
Do a manual install of the core and paste the core files in the "/MiniCore/avr/cores/minicore" directory. You'll probably need to create the cores/minicore folders.

In the boards.txt file you'll need to replace arduino:arduino with minicore (all lowercase letters).

38

Hi hansibull and congratulations for this great effort!!

I'm a newbie in Arduino and I'm giving MiniCore a try. Unfortunately, I've been having some problems uploading a bootloader into ATmega8. I'm using USBtiny programmer and IDE 1.8.3 (though I had same results with 1.6.13) and getting intermittent results...sometimes it uploads and some time it doesn't.

I've tried modifying the board with an upload.speed =19200 with similar results.

I get the following: "Error while burning bootloader"..... though bootloader has been uploaded correctly! and at other times...it will just fail.

Please let me know if you have any thoughts for these uncertain behavior.

Attach you will find a log of the error. Thanks!

Error log.txt (9.83 KB)

39

That's quite strange. I've never used an ATmega8 before. I do always have problems with the USBtinyISP (though maybe not that specific problem). Do you have an extra Arduino or microcontroller you can use for Arduino as ISP to see if that works better?

40

I think I found it:

avrdude: verifying ...
avrdude: 1 bytes of lock verified
avrdude: reading input file "{bootloader.extended_fuses}"
avrdude: writing efuse (0 bytes):

Writing | ################################################## | 100% -0.00s

avrdude: 0 bytes of efuse written
avrdude: verifying efuse memory against {bootloader.extended_fuses}:
avrdude: load data efuse data from input file {bootloader.extended_fuses}:
avrdude: input file {bootloader.extended_fuses} contains 0 bytes
avrdude: reading on-chip efuse data:

ATmega8 doesn't have an efuse, so there's no value specified for it in the boards.txt file. So this shows up in the command line: -Uefuse:w:{bootloader.extended_fuses}:m avrdude can't write a fuse that the microcontroller doesn't have, and it's got a nonsense value on the command line on top of that. The lfuse, hfuse, bootloader and lock bits all write properly, but because of these efuse issues it shows an error.