Go Down

Topic: Mighty_1284p and IDE 1.6.x (Read 2283 times) previous topic - next topic

pico

Mar 03, 2015, 02:25 am Last Edit: Mar 03, 2015, 02:26 am by pico
Bill (bperrybap) and I have been experimenting with getting the Mighty_1284p repo working with IDE 1.6.0.

I've been testing using my 1284p "Skinny Bob" board, which uses the Bobuino layout.

There are a few ways of getting thing going, but this is the setup I will recommend at this time:

arduino-1.6.0/hardware/mighty_1284p/avr/

as the base directory.

Holds repo files

arduino-1.6.0/hardware/mighty_1284p/avr/boards.txt
arduino-1.6.0/hardware/mighty_1284p/avr/platform.txt
arduino-1.6.0/hardware/mighty_1284p/avr/programmers.txt

and subdirs

arduino-1.6.0/hardware/mighty_1284p/avr/bootloaders
arduino-1.6.0/hardware/mighty_1284p/avr/libraries
arduino-1.6.0/hardware/mighty_1284p/avr/variants

The files platform.txt and programmers.txt are copied from

arduino-1.6.0/hardware/arduino/avr/

board.txt is from the repo, but has to be slightly modified (I will describe later).

The repo files in patched-libs/official should be located to
 
arduino-1.6.0/hardware/mighty_1284p/avr/libraries

The repo files in bootloaders and variants are located in

arduino-1.6.0/hardware/mighty_1284p/avr/bootloaders

and

arduino-1.6.0/hardware/mighty_1284p/avr/variants

respectively.

The last thing to do is to modify boards.txt

For each variant, and additional configuration line

bobuino.upload.tool=avrdude

needs to be added.

So for example, instead of

Code: [Select]

bobuino.name=Bobuino
bobuino.upload.protocol=arduino
 :
 :


change to

Code: [Select]

bobuino.name=Bobuino
bobuino.upload.tool=avrdude
bobuino.upload.protocol=arduino
 :
 :


Optionally, you can also modify platform.txt to read

Code: [Select]

name=Mighty 1284p Boards
version=1.6.0
 :
 :


to get a more accurate subtitle in the tools|board list in the IDE.

That should be enough info to get things working. Try this, and if there any problems, post here and we will sort through it.
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.)

pico

#1
Mar 03, 2015, 02:56 am Last Edit: Mar 03, 2015, 12:47 pm by pico
BTW, the version of SdFat lib I patched for last revision of mighty_1284p and is in the

patched-libs/unofficial

directory of the repo, and can be placed in

<sketch folder>/libraries

if you want to use this.

I've recently been in contact with Bill Greiman (fat16lib), and the required changes for Mighty_1284p are now in the latest beta

https://github.com/greiman/SdFat-beta

and so this can be used instead of the patched version (which is the most recent stable version) in the Mighty_1284p repo, if you prefer to use the beta.

The good news is that the changes in the latest SdFat beta (as of Feb 23) will work with all existing Mighty 1284p variant files, as well as any new ones, without having to modify the SdFat lib. So if a new variant file for layout (eg, Goldilocks, Sleeping Beauty, or something new) is added, it should "just work" by dint of the pin abstraction macros in the variant files.

BTW, Bill (bperrybap) has identified I need to better document the pin abstraction macros I introduced in the last round of development of Mighty_1284p repo, and so I will do this as part of the next revision of the Mighty_1284p files.

I think the installation documentation for the repo would aslo benefit from a bit of attention. I think we should look at this in conjunction with deciding on the final packaging for the 1.6.0 version of the repo files.
 
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

#2
Mar 03, 2015, 06:14 pm Last Edit: Mar 03, 2015, 06:16 pm by bperrybap
BTW, Bill (bperrybap) has identified I need to better document the pin abstraction macros I introduced in the last round of development of Mighty_1284p repo, and so I will do this as part of the next revision of the Mighty_1284p files.

I think the installation documentation for the repo would aslo benefit from a bit of attention. I think we should look at this in conjunction with deciding on the final packaging for the 1.6.0 version of the repo files.
 

I was thinking about this a bit.
I was wondering which would be better:
- comments in the variant file
- a readme.txt in the variant directory, or perhaps somewhere else.

I'm almost thinking it might be better to have "documenation" or release information
in a readme file that is included with the release rather than bury it down in a variant file.

A readme in the variant file might be a good place for information about the variants
but perhaps there is other information and it could all be combined into a higher level readme?

Although my preference would be to have a readme in the variant directory even if there is another
readme somewhere else. Not any real reason other than for some reason it seems to "feel" better.
But I have no strong feelings as long as there is something somewhere providing some information
on how all this is glued together and how to use the new defines from cpp.
(how to use pasting macros)

The only reason I ended up preferring a readme over comments in the variant file
is that it keeps the information in one place vs duplicated so it will be easier to keep
up to date.

--- bill

pico

#3
Mar 05, 2015, 02:52 am Last Edit: Mar 05, 2015, 02:54 am by pico
I was thinking about this a bit.
I was wondering which would be better:
- comments in the variant file
- a readme.txt in the variant directory, or perhaps somewhere else.
Good ideas. I think perhaps the idea of just having a comment in the variant files pointing to the variants/readme.txt file for more complete documentation might be the best compromise. That way the pins_arduino.h file doesn't get overwhelmed with a large comment block, and as you say, also simplifies maintenance.
 
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

I think perhaps the idea of just having a comment in the variant files pointing to the variants/readme.txt file for more complete documentation might be the best compromise. 
That sounds even better. I really like that.

--- bill

mgoes

Also missing from boards.txt is the maximum data size (so it can tell you how much ram was used)

add to boards.txt:

mighty_opt.upload.maximum_data_size=16384


I wish you didn't have to copy the entire library directory to get it to compile, why don't they define paths to the library?


mrburnette

#6
Apr 27, 2015, 03:21 pm Last Edit: Apr 27, 2015, 03:21 pm by mrburnette
<...>
I wish you didn't have to copy the entire library directory to get it to compile, why don't they define paths to the library?
I have not tried it, but you should be able to use your OS tools to create a symbolic link to the Arduino library.

The old GUI architecture assumed AVR compliant libraries.  Then the ARM stuff was added for the Due which included a new set of compiler tools, too.  Then the GUI gods got creative and decided they needed to handle many different uC designs and architectures.  The hardware is coming quicker than the software GUI versions and libraries were looking like Swiss cheese with all of the #ifdef's that were required for different uC designs.  So, for now, the 1.6.x GUI needs to have a separate set of core files and library files.


Ray

blocos27

Hi,

Many thanks for this solution !

Compiling is ok.

but there is a little modification for writing bootloader in "platforms.txt"

in section :

Code: [Select]
tools.avrdude.bootloader.params.verbose=-v
tools.avrdude.bootloader.params.quiet=-q -q
tools.avrdude.bootloader.pattern="{cmd.path}" "-C{config.path}" {bootloader.verbose} -p{build.mcu} -c{protocol} {program.extra_params} "-Uflash:w:{runtime.platform.path}\bootloaders\{bootloader.file}:i" -Ulock:w:{bootloader.lock_bits}:m


add "bootloader.path" to "tools.avrdude.bootloader.pattern" :

Code: [Select]
tools.avrdude.bootloader.params.verbose=-v
tools.avrdude.bootloader.params.quiet=-q -q
tools.avrdude.bootloader.pattern="{cmd.path}" "-C{config.path}" {bootloader.verbose} -p{build.mcu} -c{protocol} {program.extra_params} "-Uflash:w:{runtime.platform.path}\bootloaders\{bootloader.path}\{bootloader.file}:i" -Ulock:w:{bootloader.lock_bits}:m


and burning bootloader is ok  :D

Blocos27

Go Up