Mighty-1284P core updated for Arduino 1.0.6

With the release of Arduino 1.0.6, changes to the core files are no longer needed to support the ATmega1284P. This allows the cores directory to be deleted, which simplifies the mighty-1284p core considerably. I've changed all the entries in boards.txt to point to the regular Arduino core.

These changes are in a new branch named v1.0.6. The v1.0.5 branch will remain the default for the time being, until the v1.0.6 branch can be tested further. Please report test results here; also please raise an issue on GitHub if issues are found with v1.0.6.

I've tested basic analog and digital pin mapping for the standard variant with no issues.

Prefect timing, thank you. I should be receiving my Mouser order tomorrow with the pats for 3 mighty 1284p's, purple boards were received last week. Looking forward to building them this weekend as I need one for a current project.

avr_fred:
Prefect timing, thank you. I should be receiving my Mouser order tomorrow with the pats for 3 mighty 1284p's, purple boards were received last week. Looking forward to building them this weekend as I need one for a current project.

You're welcome. I'll be interested to hear how it all works!

Thanks for the update, Jack. Now, I'm confused though. People have been talking v1.5.x for months, and now suddenly v1.0.6. Is the IDE splitting in 2 different directions? Do the v1.5.x versions have 1284 support?

oric_dan:
Thanks for the update, Jack. Now, I'm confused though. People have been talking v1.5.x for months, and now suddenly v1.0.6. Is the IDE splitting in 2 different directions? Do the v1.5.x versions have 1284 support?

I haven't actually been using 1.5.x so I may not have the best answer. But I think 1.5.6-r2 (if not earlier 1.5.x as well) already had the needed support. Note that only a single change (to wiring_analog.c) was needed to make the 1.0.5 core files 1284p-compatible. I was aware that there was a patch made after 1.0.5 was released to implement a similar change. When I checked 1.0.6, I found that indeed it was there, which is what I expected.

Not sure on the grand strategy with 1.0.x vs. 1.5.x but I think they may be trying to move them back together. In the 1.0.6 release notes I see several changes back-ported from 1.5.x.

Hope I've got all that right; if not, someone please correct me.

I figured to tack this on here, rather than go way back to the old thread.

Jack, I looked at your github page on the 1284, and the SD library in particular. I notice you use some complex syntax [that I don't understand at all] for the MIGHTY_1284P_VARIANT pin selections in the Sd2PinMap.h file, but my question is that I do not see a section for the Bobuino board under here:

#elif defined(__AVR_ATmega1284__) || defined(__AVR_ATmega1284P__) \
  || defined(__AVR_ATmega644__)  || defined(__AVR_ATmega644A__) \
  || defined(__AVR_ATmega644P__)  || defined(__AVR_ATmega644PA__)

I can probably figure out how to patch the Sanquino section, but ?? ??

EDIT:
Similarly, I looked in your patched library file, and don't see the Bobuino listed.

Also, I just downloaded IDE v1.0.6, and the only section I see in the SD library Sd2PinMap.h file is for the Sanguino, not anything for 1284. So, I'm pretty darn confused here.

Bobuino is only used for pins_arduino.h to define the mapping from physical pins to the software names.
Think of it as the end of the chain - the last step that makes the connection from PortB bit 7 (SCK) to D13 for example.
The processor type is still Atmega1284P.

Yes, I understand that's the way it's supposed to work in the best of possible worlds, but the 1284 has always out in left-field somewheres. Most of the "libraries" have special definitions for the different processors, and only had the Sanguino defined, not the 1284. Up until recently the .... defined(AVR_ATmega1284P) .... bit wasn't even found in most libraries, and they defaulted to the UNO port/pin scheme.

I can't speak to "most libraries" as I don't use them. I haven't had issue with the basic ones - SPI, I2C, Serial. Don't think I use much else than that, just write the code I need.
Here's how the 2010 version of Sd2pinmap.h was modified for use with the original Bobuino.
I think the only change since was to swap the analog pins end for end.

//------------------------------------------------------------------------------
#elif defined(__AVR_ATmega1284P__)
// add this if use these other chips
// ||defined(__AVR_ATmega644P__) || defined(__AVR_ATmega324P__)

// ATMEL ATMEGA1284P / BOBUINO
//
// Make it agree with the as-built hardware & pins_arduino.c
//
//                    +---\/---+
//  INT0 (D 4)  PB0  1|        |40  PA0 (AI 0 / D14)
//  INT1 (D 5)  PB1  2|        |39  PA1 (AI 1 / D15)
//  INT2 (D 6)  PB2  3|        |38  PA2 (AI 2 / D16)
//   PWM (D 7)  PB3  4|        |37  PA3 (AI 3 / D17)
//   PWM (D 10) PB4  5|        |36  PA4 (AI 4 / D18)
//  MOSI (D 11) PB5  6|        |35  PA5 (AI 5 / D19)
//  MISO (D 12) PB6  7|        |34  PA6 (AI 6 / D21)
//   SCK (D 13) PB7  8|        |33  PA7 (AI 7 / D22)
//              RST  9|        |32  AREF
//              VCC 10|        |31  GND 
//              GND 11|        |30  AVCC
//            XTAL2 12|        |29  PC7 (D 29)
//            XTAL1 13|        |28  PC6 (D 28)
//  RX0 (D 0)   PD0 14|        |27  PC5 (D 27) TDI
//  TX0 (D 1)   PD1 15|        |26  PC4 (D 26) TDO
//  RX1 (D 2)   PD2 16|        |25  PC3 (D 25) TMS
//  TX1 (D 3)   PD3 17|        |24  PC2 (D 24) TCK
//  PWM (D 30)  PD4 18|        |23  PC1 (D 23) SDA
//  PWM (D 8 )  PD5 19|        |22  PC0 (D 22) SCL
//  PWM (D 9)   PD6 20|        |21  PD7 (D 31) PWM
//                    +--------+
//
//	NOT_ON_TIMER,	/* 0  - PD0 */  
//	NOT_ON_TIMER, 	/* 1  - PD1 */
//	NOT_ON_TIMER, 	/* 2  - PD2 */
//	NOT_ON_TIMER,   /* 3  - PD3 */  
//	NOT_ON_TIMER,	/* 4  - PB0 */ 
//	NOT_ON_TIMER, 	/* 5  - PB1 */
//	NOT_ON_TIMER, 	/* 6  - PB2 */
//	TIMER0A,	/* 7  - PB3, PWM */
//	TIMER1A,	/* 8  - PD5, PWM */
//	TIMER2B, 	/* 9  - PD6, PWM */
//	TIMER0B,	/* 10 - PB4, PWM */
//	NOT_ON_TIMER, 	/* 11 - PB5 */
//	NOT_ON_TIMER,   /* 12 - PB6 */ 
//	NOT_ON_TIMER,   /* 13 - PB7 */ 
//	NOT_ON_TIMER,   /* 14 - PA0 */ 
//	NOT_ON_TIMER,   /* 15 - PA1 */ 
//	NOT_ON_TIMER, 	/* 16 - PA2 */
//	NOT_ON_TIMER,	/* 17 - PA3 */
//	NOT_ON_TIMER,	/* 18 - PA4 */
//	NOT_ON_TIMER,	/* 19 - PA5 */
//	NOT_ON_TIMER,	/* 20 - PA6 */
//	NOT_ON_TIMER,	/* 21 - PA7 */
//	NOT_ON_TIMER,	/* 22 - PC0 */
//	NOT_ON_TIMER,	/* 23 - PC1 */
//	NOT_ON_TIMER,	/* 24 - PC2 */
//	NOT_ON_TIMER,	/* 25 - PC3 */
//	NOT_ON_TIMER,	/* 26 - PC4 */
//	NOT_ON_TIMER,	/* 27 - PC5 */
//	NOT_ON_TIMER,	/* 28 - PC6 */
//	NOT_ON_TIMER,	/* 29 - PC7 */
//	TIMER1B,	/* 30 - PD4, PWM */
//	TIMER2A		/* 31 - PD7, PWM */


// Two Wire (aka I2C) ports
uint8_t const SDA_PIN = 23;  // C1 23
uint8_t const SCL_PIN = 22;  // C0 22

// SPI port
   uint8_t const SS_PIN =   10;  // physical 5, D 10  SS
   uint8_t const MOSI_PIN = 11;  // physical 6, D 11  MOSI
   uint8_t const MISO_PIN = 12;  // physical 7, D 12  MISO
   uint8_t const SCK_PIN =  13;  // physical 8, D 13  SCK

static const pin_map_t digitalPinMap[] = {
  {&DDRD, &PIND, &PORTD, 0},  // D0  0
  {&DDRD, &PIND, &PORTD, 1},  // D1  1
  {&DDRD, &PIND, &PORTD, 2},  // D2  2
  {&DDRD, &PIND, &PORTD, 3},  // D3  3
  {&DDRB, &PINB, &PORTB, 0},  // B0  4
  {&DDRB, &PINB, &PORTB, 1},  // B1  5
  {&DDRB, &PINB, &PORTB, 2},  // B2  6
  {&DDRB, &PINB, &PORTB, 3},  // B3  7
  {&DDRD, &PIND, &PORTD, 5},  // D5  8
  {&DDRD, &PIND, &PORTD, 6},  // D6  9
  {&DDRB, &PINB, &PORTB, 4},  // B4 10
  {&DDRB, &PINB, &PORTB, 5},  // B5 11
  {&DDRB, &PINB, &PORTB, 6},  // B6 12
  {&DDRB, &PINB, &PORTB, 7},  // B7 13
  {&DDRA, &PINA, &PORTA, 0},  // A0 14
  {&DDRA, &PINA, &PORTA, 1},  // A1 15
  {&DDRA, &PINA, &PORTA, 2},  // A2 16
  {&DDRA, &PINA, &PORTA, 3},  // A3 17
  {&DDRA, &PINA, &PORTA, 4},  // A4 18
  {&DDRA, &PINA, &PORTA, 5},  // A5 19
  {&DDRA, &PINA, &PORTA, 6},  // A6 20
  {&DDRA, &PINA, &PORTA, 7},  // A7 21
  {&DDRC, &PINC, &PORTC, 0},  // C0 22
  {&DDRC, &PINC, &PORTC, 1},  // C1 23
  {&DDRC, &PINC, &PORTC, 2},  // C2 24
  {&DDRC, &PINC, &PORTC, 3},  // C3 25
  {&DDRC, &PINC, &PORTC, 4},  // C4 26
  {&DDRC, &PINC, &PORTC, 5},  // C5 27
  {&DDRC, &PINC, &PORTC, 6},  // C6 28
  {&DDRC, &PINC, &PORTC, 7},  // C7 29
  {&DDRD, &PIND, &PORTD, 4},  // D4 30
  {&DDRD, &PIND, &PORTD, 7}   // D7 31

};

Thanks, we seem to be cross-posting on this thing. I'll try it all again tomorrow. I was hoping Jack had this all fixed for the different variants.

oric_dan:
Thanks, we seem to be cross-posting on this thing. I'll try it all again tomorrow. I was hoping Jack had this all fixed for the different variants.

Sorry about that. I've only had time to work on the core, not the libraries. I didn't do the original work on the libraries; to get up to speed and dive into that would probably be more time than I'm going to have here for a while. If someone wanted to take that on (or partly, even a single library), that'd be great :grin:

@oric_dan

I have been using the original bobuino that CrossRoads sold preassembled. On it, chip select for the SD card is pin 30. The pin only goes to the (SD card buffer) and NOT the header AFAIK.

Other than that, I use the SdFat library that user Fat16lib has made. Everything from his library that I have tested has worked great.

I have a few 1284 project updates coming soon, so I will gladly test, athough I was hoping to do a full upgrade to 1.5.x for all my projects..

cyclegadget:
@oric_dan

I have been using the original bobuino that CrossRoads sold preassembled. On it, chip select for the SD card is pin 30. The pin only goes to the (SD card buffer) and NOT the header AFAIK.

Other than that, I use the SdFat library that user Fat16lib has made. Everything from his library that I have tested has worked great.

This is one of the problems with those darn libraries. It's not "just" pin 30. First, the SD card CS appears all over the place on different boards [D4, D8, D10, and apparently D30 on Bob's boards], and sometimes the various libraries reference by Arduino Dx pin, and sometimes they reference via mega chip port-pin .... and they're always poorly labelled to boot. It always takes a while to figure out what they actually meant.

I'm also not sure why yours even works, as there are no BOBUINO variant sections in the SD libraries that I can see, so ?? ??

Ah so, since you had included the libraries in your distribution, I had figured you and the other 1284-Revisioniste Group guys had fixed them. If you will recall back then, I had previously checked and "fixed" about 18 libraries for 1284 use, but not gotten to SD.

Maybe things will go better today.

CrossRoads:
I can't speak to "most libraries" as I don't use them. I haven't had issue with the basic ones - SPI, I2C, Serial. Don't think I use much else than that, just write the code I need.
Here's how the 2010 version of Sd2pinmap.h was modified for use with the original Bobuino.
I think the only change since was to swap the analog pins end for end.
............

Thanks for the data, Bob, I can already see one thing I had confused. Also, SPI, I2C, and Serial are 3 of the libraries that rely on pins_arduino.h for the variant, so they have no problem working, whereas SD and many others need patching for the 1284, and some also for different variants.

EDIT:
Well, I just solved part of the SD library ala 1284 mess. You mentioned the 2010 version of Sd2pinmap.h as having the Bobuino variant. Well, as it turns out, not only is the IDE SD library deficient in this regard [as expected], but so is Bill Greiman's LATEST version of the SDFat library, which is what I was using. So, he must have removed the Bobuino variant since 2010, Du-uh!

https://github.com/greiman/SdFat/blob/master/SdFat/utility/DigitalPin.h

However, he magically included it again in the new Beta version, which I wasn't using, Double Du-uh!

https://github.com/greiman/SdFat-beta/blob/master/SdFat/utility/DigitalPin.h

From what I can tell, a lot of library writers decided the Arduino pin control functions weren't fast enough, so they optimized to direct use of port/pin instead. Therein lies the problem with the 1284 variants.

Using the library called SdFat.h, I made all my changes in the sketch. I think if you look it over you will understand. Feel free to ask question.

By the way, I have very little knowledge on how to change libraries for boards.

#include <SdFat.h>
// file system
// file system object
SdFat sd;


// buffer to format data - makes it eaiser to echo to Serial
char SDbuf[512];

// text file for logging
ofstream logfile;
// store error strings in flash to save RAM
#define error(s) sd.errorHalt_P(PSTR(s))#include <SdFat.h>
// file system
// file system object
SdFat sd;

// text file for logging
ofstream logfile;
// store error strings in flash to save RAM
#define error(s) sd.errorHalt_P(PSTR(s))

 pinMode(CHIP_SELECT,OUTPUT);  //SD CARD CHIPSELECT 30 on bobuino

  //SETUP SD CARD AND SET FILE NAME//
  if (!sd.begin(CHIP_SELECT, SPI_FULL_SPEED)) sd.initErrorHalt();

  // create a new file in root, the current working directory
  char name[] = "LOGGER00.CSV";

  for (uint8_t i = 0; i < 100; i++) {
    name[6] = i/10 + '0';
    name[7] = i%10 + '0';
    if (sd.exists(name)) continue;
    logfile.open(name);
    break;
  }
  if (!logfile.is_open())error("file.open");

@cyclegadget, so the question now comes ... Which version of the SDFat library are you using?

There seem to be at least 3 different ones in play, in regards the Bobuino variant. At least, I'm beginning the see what's been happening around here. Jeez Louise!

Oops, 4 versions including Jack's, and they're all different and handle the 1284 variants differently.

GitHub - greiman/SdFat: Arduino FAT16/FAT32 exFAT Library It has been a while since I downloaded my version of Sdfat but, I think it is on this page.

If you go down into that repository, you'll see it's one of the 4 or 5 SD library versions I mentioned that does NOT have the Bobuino variant in it,
https://github.com/greiman/SdFat/blob/master/SdFat/utility/DigitalPin.h

Well, at least as a result of Bob's post in reply #8, I've got things figured out enough now that I do actually have the SD card working with my 1284 board. At last.
[of course, it's incompatible with the RFM12 library that also uses SPI, but that's another story not yet finished].