Go Down

Topic: Updating the mighty-1284p core (Read 77748 times) previous topic - next topic

bperrybap


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: [Select]
#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: [Select]
#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

CrossRoads

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.
Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.

Jack Christensen


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.

pico

#423
Jun 26, 2014, 04:54 am Last Edit: Jun 26, 2014, 06:19 am by pico Reason: 1


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: [Select]
#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: [Select]
#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.)

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

westfw

Quote
[aliasing baud rates to get 1Mbps] http://spin.atomicobject.com/2013/06/23/baud-rates-ftdi-driver-mac/

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


scargill

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.
Regards

Peter Scargill
http://tech.scargill.net

bperrybap


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: [Select]
mighty_sleepingbeauty.upload.tool=avrdude
to this
Code: [Select]
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



pico


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.

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

bperrybap


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

AlfaOmega



I've had exactly the same problem as scargill - fatal error: Arduino.h: No such file or directory

Solved it by changing:

Code: [Select]

#mighty_opt.build.core=arduino:arduino
mighty_opt.build.core=standard


Code: [Select]

mighty_opt.build.core=arduino:arduino
#mighty_opt.build.core=standard


Dear bperrybap/Bill,

It is really encouraging to read on a forum messages like "Hurray! Got it working!"  XD

If it is not too much trouble please explain how you made it)

bvernham

Has any work been done for 20 MHz bootloader?  I have previously run the Bobuino boards at 20 MHz with no issue using the 20 MHz bootloader.

Thanks

Bruce Vernham

OldMicroGuy

Back in July bperrybap posted about the work he had done with porting the mighty-1284p core to Arduino 1.5.7.  The current version is now 1.5.8 and if you install 1.5.8, it will uninstall your 1.0.5

Is there some other thread about this discussion ?

Any Github site like Jack's where we could download the files for 1.5.x ?


Roger


pert

#432
Apr 28, 2015, 02:30 pm Last Edit: May 02, 2015, 01:08 am by pert
I have updated Mighty 1284P to work with Arduino IDE 1.5+ https://github.com/per1234/mighty-1284p/tree/IDE-1.5.x-compatibility. I had to update the patched GSM library because the previous patched version doesn't work with 1.5+ but I don't have the GSM hardware to test it. Does anyone have an ATmega1284/644 and the GSM hardware that can try it out and let me know if it works: https://github.com/per1234/mighty-1284p/tree/IDE-1.5.x-compatibility/patched-libs/official/IDE1.5.x-Compatible/GSM
Thanks, Per

Go Up