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.

What I saw wasn't any sort of recasting but rather some use of macros that use concatenationto derive other macro names similar to what is done in the Teensy core.Changing the pin & bit macros and naming, obviously breaks any code that uses them since I'm proposing eliminatingthe old/existing 1284 variant BIT* and PIN* macros for Teensy style "CORE" macros.The DPM() macro used in those libraries when using the mighty 1284 would break.However, the DPM macro could easily be changed to use the CORE macros instead since thefunctionality is the same.By changing the macro the actual tables in utility/Sd2PinMap.h and utility/DigitalPin.h wouldn't change,but the DPM() macro is inside the header too, so the headers would have to be modified.The macro would change from this:

I'm not sure what other code out there is already using these BIT* and PORT* macros,but I think Paul's way is a bit more useful with additional capabilities.All this said it is a pretty large change and a good bit of work.I'm not sure if folks are on board with the changes.However, if this change is to be made, it is better to make it sooner rather than later.

BTW,In looking at the low level code, it looks like there might be a small performance bump andcode size reduction if the tables stored the bitmask rather than the bit number.i.e. let the compiler do the bit shift vs doing it at runtime in the data path.

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.

What I saw wasn't any sort of recasting but rather some use of macros that use concatenationto derive other macro names similar to what is done in the Teensy core.Changing the pin & bit macros and naming, obviously breaks any code that uses them since I'm proposing eliminatingthe old/existing 1284 variant BIT* and PIN* macros for Teensy style "CORE" macros.The DPM() macro used in those libraries when using the mighty 1284 would break.However, the DPM macro could easily be changed to use the CORE macros instead since thefunctionality is the same.

As long as the DPM macro can be rewritten to use the CORE macros, there no issue then.

By changing the macro the actual tables in utility/Sd2PinMap.h and utility/DigitalPin.h wouldn't change,but the DPM() macro is inside the header too, so the headers would have to be modified.The macro would change from this:

All this said it is a pretty large change and a good bit of work.I'm not sure if folks are on board with the changes.However, if this change is to be made, it is better to make it sooner rather than later.

I have to disagree. This looks a very minor change, and not much work at all.

But I will agree that if we are going to do it, let's do it now. Just so we agree on something.

BTW,In looking at the low level code, it looks like there might be a small performance bump andcode size reduction if the tables stored the bitmask rather than the bit number.i.e. let the compiler do the bit shift vs doing it at runtime in the data path.

--- bill

As long as the macros give you the access to the bit shift values as integers as well as masks, I'm happy. Writing a macro or function to convert a pin no. to a mask is trivial, but going the other way is annoyingly messy. One thing I didn't like about the original casting of the pin/port info is that it didn't have the pin no. info explicitly accessible, only indirectly in mask format, and that made things relatively awkward and inflexible.

(BTW, by "casting" I don't mean "cast" as in type casting, rather "cast" as in "represent in a particular way", the more general/non-technical sense. Just to avoid any misunderstanding or confusion.)

Can anyone help. I've been using Manicbug's 1284p Optiboot code on 1.05 and I've now tried twice to get it to work with 1.52 and now 1.57 - I've moved the core files from my sketches hardware folder - and updated the boards.txt file --- and.... Although I can select the 1284p - I get this error even on an empty sketch.

sketch_jul07a.ino:1:21: fatal error: Arduino.h: No such file or directorycompilation terminated.

Can anyone help. I've been using Manicbug's 1284p Optiboot code on 1.05 and I've now tried twice to get it to work with 1.52 and now 1.57 - I've moved the core files from my sketches hardware folder - and updated the boards.txt file --- and.... Although I can select the 1284p - I get this error even on an empty sketch.

sketch_jul07a.ino:1:21: fatal error: Arduino.h: No such file or directorycompilation terminated.

I'm not sure what all you have done,but it isn't as simple as just moving around a few core files and updating a boards.txt file.You have to create a separate 1.5x compatible 3rd party h/w core directory tree for the1284 core files under the users sketchbook/hardware directory as 1.5x 3rd party cores work differently.

You will also have to create a platform.txt with all the compile/link rules for the buildsand then you have to copy some libraries (Wire, SPI, EEPROM, & SoftSerial) that used to be in main libraries area that are nowdown under each core. You will also have to copy over any of the patched libaries into the proper location in the new 1.5x h/w core tree.

And then...... after all that.......I just found out it what I had working on 1.5.6-r2 no longer works under 1.5.7They changed where avrdude lives in the directory tree which affects how it is used by boards.txtavrdude has been moved from {installdir}/hardware/tools/ to {installdir}/hardware/tools/avr/bin

The net result is that avrdude will not be found with the existing 1284 boards.txt entries.With the existing entries, the IDE ends up only looking in {installdir}/hardware/toolsand bombs out because it can't find an avrdude executable there.

To me this new location and execution method has some issues as it doesn't fall back to an avrdude on the users path(which it will be for linux users that have avr tools installed separately from the Arduino tools)

Second, while moving the avrdude executable down into a core related directory is a good thing, I don't think it shouldn't be placed down with the gcc tools. It should be somewhere else.Moving it down with the gcc tools makes it much harder to swap out gcc tools suppliedwith the IDE for a different locally installed versions since you can no longer just move/renamethe IDE's gcc tool directory since it now contains avrdude.The gcc tools and avrdude are now somewhat bound together.

There is a work around for this in boards.txtIf you prefix the upload.tool with the name of the core then it will find it.so in a 1.5x boards.txt file you must change this:

Guys, this is the kind of stuff that I believe shows why this core should be rapidly moved to 1.5xas 1.5x is still having all kinds of changes and updates and you have to keep your eye on itto make sure that things are working and that the Arduino teams doesn't accidentallybreak the 3rd party libraries/cores.

1.5x IDE also has some nice features that are not in 1.x The biggest being that dropdown are now scrollable.This is critical if you have lots of boards or libraries installed.Without this capability you may not be able to select the desired board or be ableto pick an example sketch because the entry is below what is on the screen and thereis no way to scroll down to it.Having this scrolling capability is a MUST HAVE for me as I have close to 100 librariesand nearly the same number of board selections.There is a work around in 1.x that I'm using for that, and that is if you install Paulsteensyduino he modifies the IDE to add in the scrolling menus.So you can get the scrolling menus on 1.x by simply installing Pauls Teensyduino add on.

Another thing that is better with 1.5x is that all the patched libraries could be put into place inthe core directory structure so that once the user installs the core all the patched libraries are thereand ready to go with nothing else to do.

1.5x IDE also has some nice features that are not in 1.x The biggest being that dropdown are now scrollable.This is critical if you have lots of boards or libraries installed.Without this capability you may not be able to select the desired board or be ableto pick an example sketch because the entry is below what is on the screen and thereis no way to scroll down to it.Having this scrolling capability is a MUST HAVE for me as I have close to 100 librariesand nearly the same number of board selections.There is a work around in 1.x that I'm using for that, and that is if you install Paulsteensyduino he modifies the IDE to add in the scrolling menus.So you can get the scrolling menus on 1.x by simply installing Pauls Teensyduino add on.

There's also the eried enhanced 1.0.5 IDE that supports scrolling menus (I believe this is the code that Paul based some of his Teensyduino enhancements upon.)

http://forum.arduino.cc/index.php?topic=118440.0

Personally, I'd never recommend someone use 1.5.x just for something like scrolling menus. 1.5.x is, after all, still a beta platform, with an unstable code base and feature set. If you want to program a Due, then I guess you don't have much choice. But for anything else, unless you are particularly yearning for adventure, well -- fuggetaboutit!

If someone asks "how do you program a 1284p using Arduino?", the current correct answer is "we have a 1.0.5 compatible core and set of libs".

Well, at least that's the answer *I* give!

But for the adventurous, I'd suggest a new thread would be appropriate for discussion of any 1.5.x related work on the 1284p core.

But for the adventurous, I'd suggest a new thread would be appropriate for discussion of any 1.5.x related work on the 1284p core.

Yeah, 1.5x is definitely a moving target.

I guess I fall in to the "adventurous" category.I got the 1284 core up and working on 1.5x including the 1.5.7 just released.I think there are some features in 1.5x that are very useful.The biggest feature for this core being that it makes installing the coreand the updated/patched libraries MUCH easier than installing the core on 1.0.5since with 1.5x you can include the patched libraries in the core so that they areinstalled with the 1284 core and they will automatically get used over the distribution librariesbut will only get used with the 1284 coreso the risk of breaking some other core or processor is eliminated.