Hi!
For the few last months I've been maintaining the MightyCore. It's an Arduino core for the ATmega8535, ATmega16, ATmega32, ATmega164, ATmega324, ATmega644 and ATmega1284 (and all their P, PA, A, L variants). They come in DIP and TQFP packages.
I'm able to squash a few bugs here and there, but I sure need your help in order to make this a bug free core.
These are great chips if you:
Need more IOs than the Arduino UNO can offer
Like breadboard friendly DIP packages
Need more than one hardware serial port (ATmega164/324/644p/1284)
Need lots of flash memory and RAM (ATmega1284)
Want to buy really cheap chips (ATmega32 at Ebay or AliExpress)
Core features:
All microcontrollers are using a modified version of Optiboot where the flash memory can be written to while the program is running (huge thanks to @majekw)
Libraries like EEPROM, Ethernet, SD, SPI, Servo, SoftSerial and Wire are working
Support for the older Arduino 1.5.x and 1.0.x versions (Arduino IDE 1.6.x or later required)
MightyCore development board
I've designed and built a development board for this particular core. It has all the bells and whistles a hobbyist needs, including:
A voltage select jumper to run the microcontroller at 5V or 3.3V
LOTS of 5V, 3.3V, and GND points broken out, both male and female
Double IO row, all located on the same side of the board
A Reset enable header to enable/disable auto-reset when uploading new code or opening the serial monitor
IO peripherals written on the underside of the board
ISP and JTAG programming header
PWM pins clearly marked, and a lookup table can be found on the underside of the board (three '~'s - all microcontrollers, two '~'s - 164; 324; 644; 1284, one '~' - 1284)
For more information about the board and how to buy; please visit my Tindie listing! And don't hesitate to send me a PM if you have any unanswered questions
Yeah, I love unified cores! When there all ready is support for the mega644 and 1284, why not go through the effort and support the rest of the family and their predecessors?
I've been experimenting with a unified pins_arduino file that contains both the standard and the Bobuino pinout. I was thinking about dropping the tools menu option (the list is already quite long) and instead "enable" the Bobuino pinout by writing #define BOBUINO_PINOUT at the top of the sketch and sort out the rest in the pins_arduino file, using #if defined(BOBUINO_PINOUT) and #else.
Too bad I still get a multiple definition error (seems like the pinout gets defined for Bobuino and standard at the same time.
DrAzzy:
I haven't had success getting defines from the sketch to be picked up in the core files :-/
I was able to get defines work from the sketch.
The following code in the pins_arduino.h file didn't work:
#if defined(BOBUINO_PINOUT)
//Bobuino pinout goes here
#else
//Standard pinout goes here
I was still able to get it working if I used #define STANDARD_PINOUT:
//This works!
#if defined(BOBUINO_PINOUT)
//Bobuino pinout goes here
#elif defined(STANDARD_PINOUT)
//Standard pinout goes here
This means that if the standard or the Bobuino pinout is defined in the top of the sketch, the code won't compile.
Still, this isn't a very intuitive option when it comes to copy/paste coding from the internet..
Or just use the menu, which I think is better, because otherwise, the #define is an "incantation" - a define that you'd never think of using unless someone told you, which has spooky effects on the compile process. People would see it and assume that the core didn't support the other pin mapping.
Yep, you got a point! I guess I'll add the Bobuino layout later. Personally, I think the 'standard' layout is the best when you're breadboarding (or doing anything else except using shields). It's just much more logical and straight forward
I just finished building a simple board around the Atmega1284 (non-P), with a 20Mhz crystal.
I have optiboot working perfectly (compiled from source downloaded from github), and it talks to the IDE at 115200 bauds. Neverthless I'll give your core a try!
I don't see how you could ever get a define in sketch to pick the variant.
While it may allow the sketch to see the appropriate macro definitions, the sketch is not the only entity that needs to have the correct information.
There are libraries that need the pin information and pin macros and since those are compiled separately, neither the library nor the headers that a library includes will see the "magic" define that was in the sketch.
Any type of unified pins file included by the library will not be selecting the macros based on the define in the sketch so the library will see the incorrect macros and pin mappings.
Thanks Hansibull. I'm using your's already with a 1284p. Well, just started. Though having issues getting my serials working. Able to burn bootloader with an UNO, and upload sketches that way but can't seem to upload with a CP2102 w/DTR over either the UARTs. Hopefully get it sorted out soon.
Did try uploading the Multiwii flight controller sketch to it but had compiling issues though I suspect it due to pin layout issues.
Great news! A Bobuino pinout option is added! You'll find it in the Tools menu. I'm planning to edit the readme file (add pinout pics) and update the boards manager URL tomorrow
Dunno if this counts as a crosspost but I'm having a problem where it seems the timing processes are running twice as fast on my 1284P with 16MHz external osc.
All my delay() happen twice as quick, for example delay(1000) completes in 500ms, and also I have to read the serial port twice as fast - if I set Serial.begin(9600) I have to set my serial monitor to run at 19200.
Any ideas? I notice there's two entries in the menu for 16MHz, but the second one doesn't seem to work at all.
I squeezed out a bug in the boards.txt file last week. There was an issue that the burnt bootloader was the 8MHz version, but the fuse settings and everything else had the 16MHz option. It should be OK now. Download the latest version from Github, og use the boards manager Then try burning the 16MHz bootloader again
I am using a board I made with an Atmega1284 (non-P), clocked at 20Mhz. I defined my pins using the standard pin mappings.
Checked the output of delay() and delayMicroseconds() at several values, using a Keysight DSO1072B scope, and everything works perfectly. Actually, delayMicroseconds() is a lot more precise than delay().
PWM also works. On pins D3 and D4 (standard mapping) the PWM frequency is 1.22kHz. On the other pins it is 610Hz.
