LarryD:
Fingers too fast brain too slow.Should have asked also, for the 1M bootloader do I make the following change in boards.txt?
From
bobuino.bootloader.file=optiboot_atmega1284p.hex
to
bobuino.bootloader.file=optiboot_mighty1284p_1M.hex
Here, that is usually caused by too much caffeine or not enough caffeine. 
Yes, that should do it for the bootloader, let us know how it works!
Jack - I just wanted to follow up with you that I've since started using the new bootloader with old code from the previous version and it all works fine (I had only added the INPUT_PULLUP to the previous loader). From what I can tell, they appear to be compatible.
Pico - I am interested to see the changes required for the SDfat library as that is what I use. I don't recall any issues with the previous Mighty-1284 version.
Personally, I think we should make a new repo for the altered 1284 stuff since there is a group of people working on it. That way, we can collaborate on the wiki as well instead of keeping track of the different issues on the forum. As official libraries get updated to include compatibility to 1284, we can just include a link to the library to keep the amount of redundant data down.
At any rate, do you have a link where I could download the fixed version of SDfat for 1284?
Cheers!
@pekasus, thanks for the feedback. The patched libraries are part of the same repo: GitHub - JChristensen/mighty-1284p: Mighty 1284P Platform for Arduino
Tried this on the 1284WEENY see picture (Crossroads may be offering them at some point).
Good Idea when re-burning the bootloader is to first put a blank sketch on it.
//This cleans the current program from the controller
void setup()
{
}
void loop()
{
}
Just wanted to also say thanks to @Pico for his work on the libraries. Awesome!
Great timimg, as I've just put one of his (Pico's) "Skinny Bob" kits together today. It all went together very fast (less 1 hour, and I don't think I'm a fast solderer). Loaded some example sketches after installing mighty-1284p-1.0.5.zip and -- success!
Very satifying to start with a bag of parts in the afternoon and end up with a fully functioning board running programs just a few hours later! 
Thanks again to everyone who made this possible.
(One thing I would suggest is updating the Installation instructions on the GitHub page to include installing the libraries.)
pekasus:
Pico - I am interested to see the changes required for the SDfat library as that is what I use. I don't recall any issues with the previous Mighty-1284 version.
You wouldn't have seen issues unless you were enabling USE_SOFTWARE_SPI in SdFatConfig.h, as all the required changes were in DigitalPin.h.
pekasus:
At any rate, do you have a link where I could download the fixed version of SDfat for 1284?
For want of a better idea of where to park it, I've uploaded it to patched-libs/unofficial so as to make accessible until such time Bill G. incorporates the changes into his next release.
bluesmoke328:
Just wanted to also say thanks to @Pico for his work on the libraries. Awesome!Great timimg, as I've just put one of his (Pico's) "Skinny Bob" kits together today. It all went together very fast (less 1 hour, and I don't think I'm a fast solderer). Loaded some example sketches after installing mighty-1284p-1.0.5.zip and -- success!
Very satifying to start with a bag of parts in the afternoon and end up with a fully functioning board running programs just a few hours later!
Excellent to hear.
bluesmoke328:
(One thing I would suggest is updating the Installation instructions on the GitHub page to include installing the libraries.)
Oops, good point, forgot about this... I'm not sure I can edit that page though. Perhaps you could update when you have time, Jack?
pico:
Oops, good point, forgot about this... I'm not sure I can edit that page though. Perhaps you could update when you have time, Jack?
Actually you can, it's just part of the repo. It's a Markdown file, README.md. I use Markdown Pad, seems pretty good. But I'd be glad to do it if you wouldn't mind sending me what you want to say. It should go in the Revision History section, but I wonder if we should have a Libraries section in the README as well.
In looking back at the commits, I see a pretty big change to the pins_arduino.h header file that
was put in as part of a commit related to adding patched versions of Ethernet, Servo, & SD.
It added defines for the bit and port for each pin.
I'm assuming that these changes weren't needed for those libraries, but were tossed in for clarity?
If adding all these new port and bit defines for each pin is desired,
I'd suggest moving down a path of what what Paul did in the Teensy core in his core_pins.h header file.
(It was rejected by the Arduino team but I believe it is quite useful and makes a lot of sense)
In his implementation, there are defines per pin for port, bit, and bitmask but I think it is better than
what is currently in the 1284 variant pins_arduino.h header files.
You never use the port, bit, and bitmask defines directly but rather through macros and as and added bonus
you have the added ability to specify AVR port/bit pins directly. i.e.
digitalWrite(PIN_B0, HIGH);
to set PB0 high.
To make this happen, you create a define for each pin, whose name is PIN_Pb where P is the port and b is the bit
and the value is the Arduino pin number.
Then you have the port bit, and bitmask defines that are never used directly but
rather through some concatenation macros.
This allows you to access things like bit, bitmask or port: (examples for B7)
CORE_BIT(PIN_B7)
CORE_BITMASK(PIN_B7)
CORE_PORTREG(PIN_B7)
It is very clear and easy to visualize for things like the progmem tables.
If there is interest in moving twards Paul's "core" defines (which goes a bit further than just these bits/masks/port defines),
I'll be happy to do the mods, but I before doing it,
I want to make sure people are ok with this.
To see the defines and macros, look down in the teensy core at the file core_pins.h
--- bill
One other note:
Making these changes and adding these defines, should have no impact on existing code.
It merely adds defines that new code could take advantage of.
Guys,
I'm seeing this:
extern const uint8_t digital_pin_to_pcint[]; // this extern needed for mighty-1284p core support
show up in code. Like SoftwareSerial and the GSM libraries.
To me this is wrong. This is an extern to support some macros like
digitalPinToPCICRbit(p)
digitalPinToPCMSK(p)
digitalPinToPCMSKbit(p)
The code that uses those macros should have no knowledge about their internal implementation
and shouldn't have to do special things to make them work.
So in my view the extern declaration should be in pins_arduino.h where the macro definition is.
i.e. the pins_arduino.h should do whatever it takes to make the macros/functions it uses & defines
work and that should also include declaring extern references when needed.
Was it just an "oops" or is there some reason why this wasn't done in pins_arduino.h?
Given that this extern declaration is the only change to SoftwareSerial, if the extern is moved to pins_arduino.h
then a patched version of SoftwareSerial wouldn't be needed.
Another issue I'm seeing is that these patched libraries are interfering with other patched libraries.
For example, the Teensy install modifies some libraries. SoftwareSerial is one of the libraries that Teensy modifies.
So if you have Teensy installed and then try to copy/install the patched 1284 patched SoftwareSerial,
you overwrite/replaced the SoftSerial with Teensy support.
I think at least for SoftSerial, that if pins_arduino.h could be updated to include the extern for digital_pin_to_pcint[]
that this specific issue will go away.
But this is hinting at the issue I was concerned about: supporting patched libraries.
It is a very large task with almost no boundaries.
--- bill
bperrybap:
In looking back at the commits, I see a pretty big change to the pins_arduino.h header file that
was put in as part of a commit related to adding patched versions of Ethernet, Servo, & SD.
It added defines for the bit and port for each pin.
I'm assuming that these changes weren't needed for those libraries, but were tossed in for clarity?
Actually, no, the port/pin info needed to be recast so as to be able to support Bill G.'s fast pin mapping code in Sd2PinMap.h SD lib (also used in his SdFat lib, in DigitalPin.h).
bperrybap:
If adding all these new port and bit defines for each pin is desired,
I'd suggest moving down a path of what what Paul did in the Teensy core in his core_pins.h header file.
(It was rejected by the Arduino team but I believe it is quite useful and makes a lot of sense)
In his implementation, there are defines per pin for port, bit, and bitmask but I think it is better than
what is currently in the 1284 variant pins_arduino.h header files.
You never use the port, bit, and bitmask defines directly but rather through macros and as and added bonus
you have the added ability to specify AVR port/bit pins directly. i.e.
digitalWrite(PIN_B0, HIGH);
to set PB0 high.To make this happen, you create a define for each pin, whose name is PIN_Pb where P is the port and b is the bit
and the value is the Arduino pin number.
Then you have the port bit, and bitmask defines that are never used directly but
rather through some concatenation macros.This allows you to access things like bit, bitmask or port: (examples for B7)
CORE_BIT(PIN_B7)
CORE_BITMASK(PIN_B7)
CORE_PORTREG(PIN_B7)It is very clear and easy to visualize for things like the progmem tables.
If there is interest in moving twards Paul's "core" defines (which goes a bit further than just these bits/masks/port defines),
I'll be happy to do the mods, but I before doing it,
I want to make sure people are ok with this.To see the defines and macros, look down in the teensy core at the file core_pins.h
--- bill
One other note:
Making these changes and adding these defines, should have no impact on existing code.
It merely adds defines that new code could take advantage of.
I'm completely OK with this, particularly if it ties into a scheme like Paul is already using -- why have fragmented approaches if they can be avoided? Before you do too much work, please double check that the recasting is still going to work for the SD and SdFat libs.
bperrybap:
Guys,
I'm seeing this:extern const uint8_t digital_pin_to_pcint[]; // this extern needed for mighty-1284p core supportshow up in code. Like SoftwareSerial and the GSM libraries.
To me this is wrong. This is an extern to support some macros like
digitalPinToPCICRbit(p)
digitalPinToPCMSK(p)
digitalPinToPCMSKbit(p)The code that uses those macros should have no knowledge about their internal implementation
and shouldn't have to do special things to make them work.
So in my view the extern declaration should be in pins_arduino.h where the macro definition is.
i.e. the pins_arduino.h should do whatever it takes to make the macros/functions it uses & defines
work and that should also include declaring extern references when needed.
Was it just an "oops" or is there some reason why this wasn't done in pins_arduino.h?
The digital_pin_to_pcint[] array is defined in pins_arduino.h, but for only the "bobuino" variant. Because it's an array, and pins_arduino.h is potentitally pulled into multiple libs, the declaration is guarded by a #ifdef ARDUINO_MAIN, so the linker doesn't complain about multiple declarations..
Changing this so that
#ifndef ARDUINO_MAIN
extern const uint8_t digital_pin_to_pcint[];
#else
const uint8_t digital_pin_to_pcint[NUM_DIGITAL_PINS] =
:
#endif
will work just as well, and has the advantage of not needing a patched version of SoftwareSerial, so I will make that change, and then we can remove the patched SoftwareSerial lib from the repo.
bperrybap:
Given that this extern declaration is the only change to SoftwareSerial, if the extern is moved to pins_arduino.h
then a patched version of SoftwareSerial wouldn't be needed.
Another issue I'm seeing is that these patched libraries are interfering with other patched libraries.
For example, the Teensy install modifies some libraries. SoftwareSerial is one of the libraries that Teensy modifies.
So if you have Teensy installed and then try to copy/install the patched 1284 patched SoftwareSerial,
you overwrite/replaced the SoftSerial with Teensy support.
I think at least for SoftSerial, that if pins_arduino.h could be updated to include the extern for digital_pin_to_pcint[]
that this specific issue will go away.
But this is hinting at the issue I was concerned about: supporting patched libraries.
It is a very large task with almost no boundaries.--- bill
The boundaries are just where you set them. In this case, I was seeking to make a set of libs that patch support for the mighty-1284p core with the official Arduino 1.0.5 IDE. If anyone wants to mix and match patched libs from other non-official distros of the IDE, fine, but that's beyond the well-defined scope of the undertaking here.
Having said that, if we can easily make things compatible with what Paul has done, why not?
But sorry, Bill, your hand-wringing and finger-wagging here leaves me as unmoved now as it ever has. 
pico:
The digital_pin_to_pcint[] array is defined in pins_arduino.h, but for only the "bobuino" variant. Because it's an array, and pins_arduino.h is potentitally pulled into multiple libs, the declaration is guarded by a #ifdef ARDUINO_MAIN, so the linker doesn't complain about multiple declarations..Changing this so that
#ifndef ARDUINO_MAIN
extern const uint8_t digital_pin_to_pcint[];
#else
const uint8_t digital_pin_to_pcint[NUM_DIGITAL_PINS] =
:
#endifwill work just as well, and has the advantage of not needing a patched version of SoftwareSerial, so I will make that change, and then we can remove the patched SoftwareSerial lib from the repo.
Very nice. Somehow I missed that conditional.
That will remove that collision with the Teensy SoftSerial patches.
But sorry, Bill, your hand-wringing and finger-wagging here leaves me as unmoved now as it ever has.
I might be wringing my hands but definitely not wagging my fingers...
I think many of the library issues can go away on 1.5x as each core can have its own libraries.
I need to verify that a core library trumps a common library the same way that a user sketchbook library
trumps a common library.
Assuming it does, that will make things really nice as the core can ship with
all the core specific/patched libraries already in place ready to go so it becomes a nice simple install.
And if it doesn't, that is something that we need to work with the Arduino team to
get changed/fixed in the 1.5x IDE before it finalizes.
--- bill
Optiboot 6.0 "alpha": optiboot-6.zip - Google Drive
The important change WRT 1284 is EEPROM support! Also, I think I fixed "Bobuino", and put the 1284/644 in there own sub-makefike, so that adding platforms can be more easily "logically separate" from actual logic changes.
/* 6.0 WestfW: modularize memory read/write functions */
/* Remove serial/flash overlap */
/* (and all references to NRWWSTART/etc) */
/* Correctly handle pagesize > 255bytes */
/* Add EEPROM support in BIGBOOT (1284) */
/* EEPROM write on small chips now causes err */
/* Split Makefile into smaller pieces */
/* Add Wicked devices Wildfire */
/* Remove LUDICOUS_SPEED option */
We had a "ludicrous" speed option before? Was that like overclocking?
"ludicrous speed" was 230400bps at 3.5% error. I like the idea of having 1Mbps at 0% error better!
(except that I can't convince my Mac Host-side to support 1Mbps...)
westfw:
"ludicrous speed" was 230400bps at 3.5% error. I like the idea of having 1Mbps at 0% error better!
(except that I can't convince my Mac Host-side to support 1Mbps...)
Does it like 500kbps?
Does it like 500kbps?
Nope. Apparently only "standard" bitrates. I can't tell whether it's a MacOS thing or an FTDI driver thing 
(FTDI claims to support non-standard speeds, but when I look for details, all the info is about the windows driver(s))
avrdude -carduino -p atmega1284p -P /dev/tty.usbserial-AM01QQUY -b 500000 -t
avrdude: ser_setspeed(): tcsetattr() failed
avrdude: ser_open(): can't set attributes for device "/dev/tty.usbserial-AM01QQUY": Invalid argument
ioctl("TIOCMGET"): Bad file descriptor
avrdude: ser_close(): can't reset attributes for device: Bad file descriptor
avrdude done. Thank you.
westfw:
Does it like 500kbps?
Nope. Apparently only "standard" bitrates. I can't tell whether it's a MacOS thing or an FTDI driver thing
(FTDI claims to support non-standard speeds, but when I look for details, all the info is about the windows driver(s))
I'm guessing it is a MacOS thing.
From what I remember from decades ago, and a brief google,
the unix ioctls only support standard bit rates,
but in more recent times there is "kludge" that has been done,
where a different field is overloaded with the desired bitrate if it is non standard.
Apple may not support this.
UGLY, but maybe this will help:
--- bill
So on a different note,
I decided to get the existing 1284 core working on 1.5x
I've got it up and working. Didn't take very long - maybe 30 minutes.
The tree is different, and there are some mods and added files, and libraries
that have to be delt with but not very difficult.
Things like the boards.txt files are slightly different, there is a platform.txt for all the compile/build rules
and then some local core libraries that must now exist in the core directory tree but that's about it.
I also verified that libraries supplied with the 1.5x core override libraries in the distribution.
That is good, since the patched libraries can now be put into the core directory tree so that that
they can automatically override the distribution versions when the 1284 core is being used.
So here is the current precedence of libraries
Which seems like the order it should be in.
I haven't beat on it to see where the issues are - I'm sure there are issues
as essentially, what I did is get a 1284 1.x core working on 1.5x
What needs to happen is the core files from 1.5x need to be moved over and then
the tweaks made for the 1284 as there are a few new features in the 1.5x core that
won't exist until that is done.
I did notice that there are some big differences in HardwareSerial and wiring_analog.c
so those need very close scrutiny.
To me the 1.5x solution looks interesting as it can create a package that once installed
"just works" and has all the needed patched libraries already in place and ready to go.
Long term, maintaining a 1284 core that is so close to the Arduino team distribution AVR core is
a maintenance PITA.
I think the ideal solution would be to get the 1284 mods pushed into the Arduino team AVR core
as they are pretty minor.
That way there is only a single AVR core vs having to maintain a parallel AVR core.
--- bill