Pages: 1 ... 27 28 [29]   Go Down
Author Topic: Updating the mighty-1284p core  (Read 19794 times)
0 Members and 1 Guest are viewing this topic.
Dallas, TX USA
Offline Offline
Faraday Member
**
Karma: 67
Posts: 2702
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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 concatenation
to 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 eliminating
the 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 the
functionality 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:
Code:
#define DPM(x) { PORT_TO_MODE(PORT_D##x), PORT_TO_INPUT(PORT_D##x), PORT_TO_OUTPUT(PORT_D##x), BIT_D##x }
to this:
Code:
#define DPM(x) { CORE_DDRREG(x), CORE_PINREG(x), CORE_PORTREG(x), CORE_BIT(x) }


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 and
code 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
Logged

Global Moderator
Boston area, metrowest
Offline Offline
Brattain Member
*****
Karma: 538
Posts: 27089
Author of "Arduino for Teens". Available for Design & Build services. Now with Unlimited Eagle board sizes!
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Man, you guys are good! I don't think I'd ever been able to dig in & understand all the layers and subtleties from IDE version to IDE version and then all the library implications.
Logged

Designing & building electrical circuits for over 25 years. Check out the ATMega1284P based Bobuino and other '328P & '1284P creations & offerings at  www.crossroadsfencing.com/BobuinoRev17.
Arduino for Teens available at Amazon.com.

Grand Blanc, MI, USA
Offline Offline
Faraday Member
**
Karma: 95
Posts: 4084
CODE is a mass noun and should not be used in the plural or with an indefinite article.
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Man, you guys are good! I don't think I'd ever been able to dig in & understand all the layers and subtleties from IDE version to IDE version and then all the library implications.

My eyes are fairly glazed over too. I haven't really even looked at 1.5 yet.
Logged

MCP79411/12 RTC ... "One Million Ohms" ATtiny kit ... available at http://www.tindie.com/stores/JChristensen/

Offline Offline
God Member
*****
Karma: 32
Posts: 830
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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 concatenation
to 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 eliminating
the 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 the
functionality 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:
Code:
#define DPM(x) { PORT_TO_MODE(PORT_D##x), PORT_TO_INPUT(PORT_D##x), PORT_TO_OUTPUT(PORT_D##x), BIT_D##x }
to this:
Code:
#define DPM(x) { CORE_DDRREG(x), CORE_PINREG(x), CORE_PORTREG(x), CORE_BIT(x) }

Try it out and see if it works as expected. Post what you propose the CORE macros will be that will be included in the pins_aruduino.h files, and I'll test as well.

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.

Nothing else I can think of off-hand, although I'm sure the compiler will quickly remind me if a macro it was expecting somewhere goes missing.

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.  smiley-mr-green

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 and
code 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.)

« Last Edit: June 25, 2014, 11:19:39 pm by pico » Logged

WiFi shields/Yun too expensive? Embeddedcoolness.com is now selling the RFXduino nRF24L01+ <-> TCP/IP Linux gateway: Simpler, more affordable, and even more powerful wireless Internet connectivity for *all* your Arduino projects! (nRF24L01+ shield and dev board kits available too.)

SF Bay Area (USA)
Offline Offline
Tesla Member
***
Karma: 133
Posts: 6755
Strongly opinionated, but not official!
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
That seems to have worked.  Icky, though.  Can't ask normal Arduino users to go through that.

Logged

Wark
Offline Offline
Newbie
*
Karma: 0
Posts: 40
Interested in all things electronic
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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 directory
compilation terminated.
Logged

Regards

Peter Scargill
www.scargill.net

Dallas, TX USA
Offline Offline
Faraday Member
**
Karma: 67
Posts: 2702
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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 directory
compilation 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 the
1284 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 builds
and then you have to copy some libraries (Wire, SPI, EEPROM, & SoftSerial) that used to be in main libraries area that are now
down 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.7
They changed where avrdude lives in the directory tree which affects how it is used by boards.txt
avrdude 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/tools
and 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 supplied
with the IDE for a different locally installed versions since you can no longer just move/rename
the 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.txt
If 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:
Code:
mighty_sleepingbeauty.upload.tool=avrdude
to this
Code:
mighty_sleepingbeauty.upload.tool=arduino:avrdude

And then it will work on both 1.5.7 and pre 1.5.7

Guys, this is the kind of stuff that I believe shows why this core should be rapidly moved to 1.5x
as 1.5x is still having all kinds of changes and updates and you have to keep your eye on it
to make sure that things are working and that the Arduino teams doesn't accidentally
break 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 able
to pick an example sketch because the entry is below what is on the screen and there
is no way to scroll down to it.
Having this scrolling capability is a MUST HAVE for me as I have close to 100 libraries
and 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 Pauls
teensyduino 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 in
the core directory structure so that once the user installs the core all the patched libraries are there
and ready to go with nothing else to do.


--- bill


Logged

Offline Offline
God Member
*****
Karma: 32
Posts: 830
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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 able
to pick an example sketch because the entry is below what is on the screen and there
is no way to scroll down to it.
Having this scrolling capability is a MUST HAVE for me as I have close to 100 libraries
and 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 Pauls
teensyduino 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.

Logged

WiFi shields/Yun too expensive? Embeddedcoolness.com is now selling the RFXduino nRF24L01+ <-> TCP/IP Linux gateway: Simpler, more affordable, and even more powerful wireless Internet connectivity for *all* your Arduino projects! (nRF24L01+ shield and dev board kits available too.)

Dallas, TX USA
Offline Offline
Faraday Member
**
Karma: 67
Posts: 2702
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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 core
and the updated/patched libraries MUCH easier than installing the core on 1.0.5
since with 1.5x you can include the patched libraries in the core so that they are
installed with the 1284 core and they will automatically get used over the distribution libraries
but will only get used with the 1284 core
so the risk of breaking some other core or processor is eliminated.

That said 1.5x is moving target and updates can break things.

--- bill
Logged

Pages: 1 ... 27 28 [29]   Go Up
Jump to: