Go Down

Topic: MiniCore - An Arduino core for the ATmega8/ 48/ 88/ 168/ 328 (Read 5250 times) previous topic - next topic

hansibull

Quote
Any reason you decided to not include the 85P?
85P? Haven't heard of that one before!  ;)  Are you thinking about the ATmega8?
MightyCore -  ATmega1284, mega644, mega324, mega164, mega32, mega16, mega8535
Github.com/MCUdude/MightyCore

MiniCore - ATmega8, mega48, mega88, mega168, mega328
Github.com/MCUdude/MiniCore

mrburnette

85P? Haven't heard of that one before!  ;)  Are you thinking about the ATmega8?
I'm an idiot until after my second cup of coffee...
Meant ATTINY85-20PU




Ray

DrAzzy

Why would you expect a core meant for the 32/28 pin ATmega x8 series to support an ATtiny chip?

There are many other cores available that support the tiny x5 series. I suggest you try mine - it supports pretty much all chips in the ATtiny line that are interesting to Arduino users except the ATtiny13 (which is covered by a different core) https://github.com/SpenceKonde/ATTinyCore

Unlike most cores for the 85, it gives proper tone support and PWM output on 3 pins (many ATTiny cores for the 85 don't support the amazing timer Atmel gave us) and I'm working on a number of features to further improve support for these parts.
ATtiny core for 841+1634+828 and x313/x4/x5/x61/x7/x8 series Board Manager:
http://drazzy.com/package_drazzy.com_index.json
ATtiny breakouts (some assembled), mosfets and awesome prototyping board in my store http://tindie.com/stores/DrAzzy

mrburnette

Why would you expect a core meant for the 32/28 pin ATmega x8 series to support an ATtiny chip? <...>
The question, is not why, it is why not?

The solution being offered by hansibull is flexible enough to offer a uniform "non-Arduino" core-set ... for 8-bit Atmel uC's... regardless of pinout.  IMO, there are simply too many cores... the time is ripe for someone to publish a uniform approach to all of the Atmel castoffs that never became officially supported.

If not hansibull, someone else will... will not be me 'cause I'm too lazy and have been off in 32-bit land for a couple of years.  Any 8-bit stuff I'm prone to do can be done with IDE 1.0.6. 


Ray

pert

I just used the core for the first time with an ATmega328P @8MHz internal, worked great thanks!

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.

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: https://github.com/majekw/optiboot/commit/6262a28c994034c9303185ce7d46a31ded0c8a00.

hansibull

Quote
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, https://github.com/MCUdude/MicroCore and https://github.com/SpenceKonde/ATTinyCore you should have plenty of microcontrollers to work with.


Quote
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.


Quote
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: https://github.com/majekw/optiboot/commit/6262a28c994034c9303185ce7d46a31ded0c8a00.
Thanks! I'll definitely do that on all my cores :)
MightyCore -  ATmega1284, mega644, mega324, mega164, mega32, mega16, mega8535
Github.com/MCUdude/MightyCore

MiniCore - ATmega8, mega48, mega88, mega168, mega328
Github.com/MCUdude/MiniCore

mcc01

Hi,

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

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! :)

Best regards,
mcc

hansibull

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 ;)

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
MightyCore -  ATmega1284, mega644, mega324, mega164, mega32, mega16, mega8535
Github.com/MCUdude/MightyCore

MiniCore - ATmega8, mega48, mega88, mega168, mega328
Github.com/MCUdude/MiniCore

mcc01

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...)

hansibull

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?

MightyCore -  ATmega1284, mega644, mega324, mega164, mega32, mega16, mega8535
Github.com/MCUdude/MightyCore

MiniCore - ATmega8, mega48, mega88, mega168, mega328
Github.com/MCUdude/MiniCore

mcc01

Hi,

LED flashes:
1.) Arduino is not connected to the FTDI-cable or anything else: No LED flashes ;)
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! :)

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: http://www.martyncurrey.com/arduino-atmega-328p-fuse-settings/
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? :)

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


hansibull

Great to hear! :D And thanks for providing such rich information; it makes it much easier to provide support when all necessary data is available ;)
MightyCore -  ATmega1284, mega644, mega324, mega164, mega32, mega16, mega8535
Github.com/MCUdude/MightyCore

MiniCore - ATmega8, mega48, mega88, mega168, mega328
Github.com/MCUdude/MiniCore

mcc01

WIN<->WIN!
:)

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...

hansibull

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.
MightyCore -  ATmega1284, mega644, mega324, mega164, mega32, mega16, mega8535
Github.com/MCUdude/MightyCore

MiniCore - ATmega8, mega48, mega88, mega168, mega328
Github.com/MCUdude/MiniCore

binduni

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

Go Up