Support for mega1284 - the never-ending saga

I decided to break this out from the related thread, here,
http://forum.arduino.cc/index.php?topic=275718.30

Given all the confusion, I decided to take another look at library support in the various IDEs, etc.
Basically, NONE of the following IDEs have libraries updated for the mega1284 chips:

  • IDE v.1.0.5 - as noted in 2013

  • IDE v.1.5.x - as noted yesterday, on the other thread

  • IDE v.1.0.6 - just checked, same as v.1.0.5 - although wiring_analog.c in the core has
    apparently been fixed to Jack's satisfaction, but not the libraries.
    GitHub - arduino/Arduino at 1.0.6

  • IDE v.1.0.7 [I'm "assuming" this is the v.1.0.7 update] - appears to be no changes from v.1.0.6
    GitHub - arduino/Arduino: Arduino IDE 1.x


Of happy note, most of the relevant libraries in Jack's 1284 distribution have been fixed by pico [yea!!].

The exception is, neither "official" or "unofficial" SD libraries have the Bobuino variant included, and the board variant callouts don't match in the 2 versions, in any case.

So, the goal has almost been reached here, but not hardly in "any" of the IDEs.

I took Jack's core and the associated modified libraries and have it up and running on 1.5x
To me it is much easier than 1.x because of the way the core and libraries work on 1.5x.
You can unzip and install everything all at once down in your sketchbook/hardware directory
rather than piece meal as was required with the 1.x support.

If you buy into the 1.5x way of doing things for 3rd party core support,
it can become easier to maintain and much easier for users to install.
I couldn't seem to get much interest for looking at 1.5x over in the other thread.

--- bill

I couldn't seem to get much interest for looking at 1.5x over in the other thread.

There was interest! Just seemed that the volunteers wanted to work at a non-beta level. I think 1.5.7 and previous releases have been out in the wild long enough not to be hampered as "beta". But we all have opinions and since I was not volunteering to do the effort Jack undertook, I elected not to push any harder than I did...

Of happy note, most of the relevant libraries in Jack's 1284 distribution have been fixed by pico [yea!!].

Thanks for looking this over... Great info to know.

The exception is, neither "official" or "unofficial" SD libraries have the Bobuino variant included, and the board variant callouts don't match in the 2 versions, in any case.
So, the goal has almost been reached here, but not hardly in "any" of the IDEs.

Crap!

Well, at least I now know where the sinkholes are located.

Ray

mrburnette:
Crap!

Well, at least I now know where the sinkholes are located.

Ray, if you have a Bobuino with SD card, it should be a trivial issue to get [most any] SD library working with it. Just go to the following page, and cut out the Bobuino bit, and patch it into whatever library you want to use.
https://github.com/greiman/SdFat-beta/blob/master/SdFat/utility/DigitalPin.h

I included the code here, and you can see how it fits in from the page just cited.

#elif defined(VARIANT_BOBUINO)
// Bobuino Layout
static const pin_map_t pinMap[] = {
  {&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, 7},  // A7 14
  {&DDRA, &PINA, &PORTA, 6},  // A6 15
  {&DDRA, &PINA, &PORTA, 5},  // A5 16
  {&DDRA, &PINA, &PORTA, 4},  // A4 17
  {&DDRA, &PINA, &PORTA, 3},  // A3 18
  {&DDRA, &PINA, &PORTA, 2},  // A2 19
  {&DDRA, &PINA, &PORTA, 1},  // A1 20
  {&DDRA, &PINA, &PORTA, 0},  // A0 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
};

I don't have a Bobuino myself, but I modified the above to match my board's similar header pinout, and patched it into the SD library that's included with IDE v.1.0.5, and it's working fine. You should also be able to do this with either of pico's SD library versions on Jack's github page, or with any of Bill Greiman's several versions of the SD library that are also missing the Bobuino variant.

You will also need to know which Arduino Dx pin on the Bobuino the SD card's CS pin maps to, and use that in the initialize function.

NOTE: if you use IDE v.1.0.x through v.1.5.x SD library, remember they're all 5 years out of date, and do have some problems.

Eg, there are 2 example sketches that display the SD card files, listfiles and CardInfo, plus a couple of examples that show how to write and read files on the SD card. Well, it turns out [at least for me] that, the listfiles scheme is not compatible with the simple read/write operations, but the CardInfo scheme is ok. Specifically, listfiles no longer works once either read or write has been done, and I couldn't figure out how to fix it, so stay with the CardInfo scheme. Bizarre.

bperrybap:
I took Jack's core and the associated modified libraries and have it up and running on 1.5x
To me it is much easier than 1.x because of the way the core and libraries work on 1.5x.
You can unzip and install everything all at once down in your sketchbook/hardware directory
rather than piece meal as was required with the 1.x support.

I'm not very familiar with v.1.5.x. Are you saying you can include a complete extra set of libraries in the sketch folder, with all having the exact same names,etc as the ones in the IDE, and they will be picked up preferentially without any conflicts?

oric_dan:
Ray, if you have a Bobuino with SD card, it should be a trivial issue to get [most any] SD library working with it. <...>

Thanks! I have 3 of the Bobuinos and I love them, but long ago I made the decision to off-load SD to serial-TTL logging on a dedicated SD/328P module. This simply eliminates all SD issues in the main sketch. When I design an Arduino sketch, I build a debug/logging channel on one of the hardware serial ports. I use a byte of EEPROM that is settable at PoR or RESET to control logging OFF/on and the details of logging: LOW/high.

Another relative nice feature of off-loading SD to a separate uC is that you can stop worrying about allocating time slices between the main sketch and the SD routines. Dedicated routines are small and can use the entire memory space of the uC. I also like the idea of varying density of logging data. Often, having the entire microcompter and SD conveniently located in a project is a challenge; making the two physically separate really opens the door to locating the SD in a convenient place. I use standard CAT5 or CAT6 cable for the data signal as this is adequate and cheap.

Of course, this is just my way of doing stuff and I know many people like to have the SD card right on the same board and use an SD library with the single uC on the board. It's a sound approach that works well where the SD is used to host files integral to the program logic.

Cheap External SD Card Data Logger

Oh, thanks for the code snippet.

Ray

You might at least try SD with your Bobuino board, so we can get some additional feedback on the experience, and possible problems. Especially if you're using any of the newer libraries.

oric_dan:
You might at least try SD with your Bobuino board

Yes, I sound like a self-centered ass but I did not mean it quiet as rough as it sounded... I'm messing around with the STM32 Maple Mini clones and have my workbench is quiet a disarray. I do not have the Bobduino with the SD card onboard... rather, I have the older FTDI external header unit.

If I get over this hardware SPI mess with this $5 STM32 board, I'll throw an SD socket on the breadboard and give it a whirl. Most regretful... even retired, I never seem to have enough time to play.

Ray

I figured it was worth an attempt to try and keep the thread about testing and using various libraries with the mega1284.

[and my dissarray is certainly bigger than your disarray. Right now, besides wires everywheres, 3 robots in pieces, 4 RFM12 radio nodes with 328s and 1284s for my home automation system, with the SD card on the Hub 1284-board, plus 3 other RFM69 radio nodes on 1284-boards to go to robots and outside cars, all in development in parallel. And I spend "most" of my time debugging and fixing other people's libraries that should have been fixed years ago, foo]

And I spend "most" of my time debugging and fixing other people's libraries that should have been fixed years ago

Libraries... a two-edged sword. Allow for reuse by the author and abuse by those using it who are not the author. The concept is good and C/C++ has many great examples from the compiler and language view. However, it is when we move up the programming model that things generally become an issue (IMO). Library misuse is common, documentation may be sparse, examples may not fully exercise the library, rarely is there test data and known-good output, and the list goes on.

Ray

oric_dan:
I'm not very familiar with v.1.5.x. Are you saying you can include a complete extra set of libraries in the sketch folder, with all having the exact same names,etc as the ones in the IDE, and they will be picked up preferentially without any conflicts?

Yes. (in the sketchbook folder - down under the hardware core directory)
With 1.5x if you create the proper directory tree under your sketchbook for a 1.5x
hardware core, you can override things from the IDE and its built in cores, when
your core is used.

In this case:

{usersketchbook-dir}/hardware/1284core-name/avr/

Just like 1.x the 1.5x has a search order for libraries.
Under 1.x the "libraries" under the user sketchbook override the "libraries" in the IDE.
Now with 1.5x the "libraries" directory under the core can override the "libraries"
in the IDE.
There is a search order/precedence.
This is the order that each of the "libraries" directories is looked at/used:

  • user sketchbook
  • user hardware core
  • IDE

You can create subdirectories under the the users hardware core directory
to use "libraries" that overrides the IDE "libraries" directory but only when
that core is used.
i.e. The board type selects the core, and the h/w core can have a "libraries" directory
that contains libraries that are used for that core/board which override the IDE libraries.

For 1.5x you also have to create a few other files:
boards.txt, platform.txt

All pretty simple stuff.

I brought this up starting back in June 2014:
http://forum.arduino.cc/index.php?topic=235521.msg1766650#msg1766650

And then went ahead and just did it for myself:
http://forum.arduino.cc/index.php?topic=235521.msg1781012#msg1781012

The value of the 1.5x way of doing things is that you can create a single tar/zip image that
you can extract and everything is installed at once and "just works".
No futzing around with libraries, and the libraries included with the core are only used with that core
and so there is no danger of breaking the other cores.
It is also really easy to remove should you want/need to do that as well since everything
is contained under a single directory.

I brought this up back in june because I thought that this should be being looked because
Team Arduino is not very focused on 3rd party support and doesn't really have a way to test
what they have done since they don't really do any 3rd party stuff.
The reason to start looking at it sooner
rather than later is because it may need some tweaks, and if you wait to long to start using it and finding any potential wrinkles, it may be too late to get Team Arduino to change things before
the next official release.
i.e. you may get stuck with having to live with some sub optimal ways of doing things.

I'm currently using 1.5x to test my openGLCD library with a 1284 based SleepingBeauty board.

--- bill

I brought this up back in june because I thought that this should be being looked because
Team Arduino is not very focused on 3rd party support and doesn't really have a way to test
what they have done since they don't really do any 3rd party stuff.

Thanks for the comprehensive explanation. The problem with that previous thread is, it went for 425 posts, and although I was there in it, I wasn't comprehending all the issues from every direction. But at least, we're slowly getting these things worked out. And good excuse to try IDE v.1.5x.

mrburnette:
Libraries... a two-edged sword. Allow for reuse by the author and abuse by those using it who are not the author. The concept is good and C/C++ has many great examples from the compiler and language view. However, it is when we move up the programming model that things generally become an issue (IMO). Library misuse is common, documentation may be sparse, examples may not fully exercise the library, rarely is there test data and known-good output, and the list goes on.

You can flavor this how you like, but even forgetting about 1284 support, it's still a big PITN when something like the SD library in the IDE hasn't been updated in 5 years, and the example sketches are incompatible with each other [as mentioned previously]. That's a big onus on using the "official" stuff. 3rd party libraries, you have to expect to take with a bushel of salt.

... it's still a big PITN when something like the SD library in the IDE hasn't been updated in 5 years, and the example sketches are incompatible with each other ...

Affirmative! If you are running for office, you have my vote.

I am completely in the dark as to why a library that ships in the Official Install would be so old unless the decision makers thought it was "good enough." You, I, and most senior members that have been around a few years understand that the Arduino 1.0.x distribution is long-in-the-tooth by software standards.

But troubling is that the 1.5.x distribution does not update these older 3rd party libraries. Perhaps (pure speculation on my part) the intent is to maintain backward compatibility with the old hardware while making it easy to transition the base of 1.0.x users to 1.5.x easily. Were the Arduino makers to act as Microsoft (example) then they would just pull the support rug out from 1.0.x and pull it from the web for download and publicly state that 1.0.x was history and the only course for users of that environment was to move forward. I liken this approach to the way my mom taught me to remove a band-aid ... 'pull it off briskly so the pain will peak and subside quickly'. In many ways, Mom knew best.

My preference would be for included libraries to be refreshed with input by the original authors (if they were willing) or by the Arduino team. This however would likely lead to some turmoil or at least a few summit meetings! Cypress with their PSoC line scans every component library with each execution of the compiler and offers to update locally older components with new ones... the final choice being the workstation operator (and hopefully) the software author! I managed Java middleware developers in a Corporate 100 setting for years - can you imagine the nightmare such a self-updating tool would have had on rigid software regression testing?

Maybe the answer is simply the way things are now... an active forum where 3rd party developers have a voice into articulating the merits of their newer product versions and linking us to those installations. In this scenario, at least the programmer (sketcher?) can make an informed decision. But while I am old and feeble in the memory department, I am (almost) certain that Massimo Banzi has not asked for my input... and I doubt he will; perhaps, you will be more fortunate as I can easily defer my opinion to yours as we see things similarly.

Ray

UPDATE:
I noticed that within the past 2 days, Bill Greiman has now updated his "main" SD library to include the Bobuino variant:

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

Ray said:
But troubling is that the 1.5.x distribution does not update these older 3rd party libraries.
...............
My preference would be for included libraries to be refreshed with input by the original authors (if they were willing) or by the Arduino team.

Bill Grieman mentioned he has notified [or notifies] Ardunio-Centrale of his SD library updates.

Thanks oric_dan, thanks Bill Greiman.

AFAIK, both the SD and SdFat libs in the "patched-libs" that are in the Mighty-1284p 1.0.5 github distro work for all the 1284p variants in the distro, including boards with Bobuino pin definitions. That's why they are in there.

For example, in the file Sd2PinMap.h for the SD (official) lib, there are these macro defns:

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

 #if defined(MIGHTY_1284P_VARIANT)
// from pins_arduino.h in mighty-1284p core

// Two Wire (aka I2C) ports
uint8_t const SDA_PIN = SDA;
uint8_t const SCL_PIN = SCL;

// SPI port
uint8_t const SS_PIN = SS;
uint8_t const MOSI_PIN = MOSI;
uint8_t const MISO_PIN = MISO;
uint8_t const SCK_PIN = SCK;

#define DPM(x) { PORT_TO_MODE(PORT_D##x), PORT_TO_INPUT(PORT_D##x), PORT_TO_OUTPUT(PORT_D##x), BIT_D##x }
 
static const pin_map_t digitalPinMap[NUM_DIGITAL_PINS] = {
  DPM(0),
  DPM(1),
  DPM(2),
  DPM(3),
  DPM(4),
  DPM(5),
  DPM(6),
  DPM(7),
  DPM(8),
  DPM(9),
  DPM(10),
  DPM(11),
  DPM(12),
  DPM(13),
  DPM(14),
  DPM(15),
  DPM(16),
  DPM(17),
  DPM(18),
  DPM(19),
  DPM(20),
  DPM(21),
  DPM(22),
  DPM(23),
  DPM(24),
  DPM(25),
  DPM(26),
  DPM(27),
  DPM(28),
  DPM(29),
  DPM(30),
  DPM(31)
};

 #else
// else, assume Sanguino pin assignments
#warning "SANGUINO PIN ASSIGMENT ASSUMED"

// Two Wire (aka I2C) ports
uint8_t const SDA_PIN = 17;
uint8_t const SCL_PIN = 18;

// SPI port
uint8_t const SS_PIN = 4;
uint8_t const MOSI_PIN = 5;
uint8_t const MISO_PIN = 6;
uint8_t const SCK_PIN = 7;

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

BTW, in case it is the cause of any confusion, there are no #ifdef BOBUINO (or similar) directives needed in the library files because the pin defns are already defined in the pins_arduino.h file for the Bobuino variant file. The code was generalized to work with all 1284p variants, not just the Bobuino variant.

Similarly for the patched Sdfat16 lib, this is from DigitalPin.h:

#elif defined(__AVR_ATmega1284P__)\
|| defined(__AVR_ATmega1284__)\
|| defined(__AVR_ATmega644P__)\
|| defined(__AVR_ATmega644__)\
|| defined(__AVR_ATmega64__)\
|| defined(__AVR_ATmega32__)\
|| defined(__AVR_ATmega324__)\
|| defined(__AVR_ATmega16__)

 #if defined(MIGHTY_1284P_VARIANT)
// from pins_arduino.h in mighty-1284p core

#define DPM(x) { PORT_TO_MODE(PORT_D##x), PORT_TO_INPUT(PORT_D##x), PORT_TO_OUTPUT(PORT_D##x), BIT_D##x }

static const pin_map_t pinMap[NUM_DIGITAL_PINS] = {
  DPM(0),
  DPM(1),
  DPM(2),
  DPM(3),
  DPM(4),
  DPM(5),
  DPM(6),
  DPM(7),
  DPM(8),
  DPM(9),
  DPM(10),
  DPM(11),
  DPM(12),
  DPM(13),
  DPM(14),
  DPM(15),
  DPM(16),
  DPM(17),
  DPM(18),
  DPM(19),
  DPM(20),
  DPM(21),
  DPM(22),
  DPM(23),
  DPM(24),
  DPM(25),
  DPM(26),
  DPM(27),
  DPM(28),
  DPM(29),
  DPM(30),
  DPM(31)
};

#undef DPM

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

If anyone is having problems with any of the patched libs with any of the 1284p variants, let me know and we can get to bottom of it. I was going to have a look to see if there were any changes needed to be compatible with 1.0.6 (I suspect not, but I'll be testing over the next few days.)

Thanks pico. I don't know how this affects you, but Bill Greiman is almost continually updating the SdFat library on his github page. Of course, the SD library in even-the-latest IDE versions hasn't changed since 2010 or so, so they're lightyears out of date.

oric_dan:
Thanks pico. I don't know how this affects you, but Bill Greiman is almost continually updating the SdFat library on his github page. Of course, the SD library in even-the-latest IDE versions hasn't changed since 2010 or so, so they're lightyears out of date.

Yes, I appreciate the SD lib is out of date, but it still distributed as an "official" library, and so the goal was to make a version of all the official libraries that will run under the Mighty-1284p distro. That (to me, anyway) seemed like a minimum requirement for a distro that aimed to provide a usable level of Arduino IDE support for the Mighty-1284p variants.

But realizing that many people would prefer running the more advanced SdFat, I also added a patched version of the SdFat library, in the "patched-libs/unofficial" subfolder, as a place-holder until Bill Greiman made an official release of his lib supporting the Mighty-1284p variants.

As I say, I will be contacting Bill to see what level of support for the Mighty-1284p variants is now in the latest SdFat lib. I've just sent him a PM.

I gave up on the IDE SD libraries - actually I just went in and patched the files in the IDE v1.0.5 disto on my HD myself for the 1284.

Early on in this thread, I checked Bill's github page to see what the current state of SdFat is. From what I can tell, the one is his current release, and the other marked "beta" has the changes he is working on for the next update. He seems to be updating it continually, but nothing ever gets back into the IDE itself.