Mighty-1284p repo updated for IDE 1.6.x

bperrybap: Oh and then after I finally got a 20Mhz 115.2k bootloader built with the new optiboot, it didn't work on the SB board. It wasn't dead but it didn't work. I didn't spend any time trying to figure out why.

I've just built a fresh 20MHz optiboot named

optiboot_1284p_20MHz_noled.hex

and added it to the bootloaders dir in the repo. I've also updated boards.txt.alt to use it for the 20MHz clock option.

I don't have a 20MHz xtal to hand to test directly, but I tested the version using the same build parameters for 16MHz, and that worked OK on one of my "Skinny Bob" boards. This is built from the latest optiboot v6.2.

If anyone has a 20MHz xtal to test with a 1284p, please test and report here.

Why use that name that doesn't include the baud like the others? It seems be yet another inconsistent ambiguous file name for a pre-built bootloader.

And since the .lst file is not there, it is particularly difficult to tell what is in that .hex image.

Why can't we use better more descriptive file names that are all consistent with each other? I'd like to use my previous recommendation for all the bootloader names so people know how they were built and what the heck is in them. i.e here are the names I suggested for the existing bootloaders in the repo at this point in time:

optiboot_1284p_20MHZ_115.2k_NOled.hex
optiboot_1284p_20MHZ_115.2k_NOled.lst
optiboot_1284p_16MHZ_115.2k_NOled.hex
optiboot_1284p_16MHZ_115.2k_NOled.lst
optiboot_1284p_16MHZ_1M_B7led.hex
optiboot_1284p_16MHZ_1M_B7led.lst

optiboot_1284p_8MHZ_28.8k_B7led.hex
optiboot_1284p_8MHZ_28.8k_B7led.lst
optiboot_1284p_8MHZ_57.6k_B7led.hex
optiboot_1284p_8MHZ_57.6k_B7led.lst
optiboot_1284p_8MHZ_500k_B7led.hex
optiboot_1284p_8MHZ_500k_B7led.lst

It would also be good to add the other B7 bootloader that I gave you:

optiboot_1284p_16MHZ_115.2k_B7led.hex
optiboot_1284p_16MHZ_115.2k_B7led.hex

So SB users could re-burn their blinking led bootloader that came with the board. And bobuino uses could also have a blinking bootloader if they wanted it.

Given all the issues and confusion over the bootloaders and their contents, I'm not understanding the reluctance to use better and more consistent names for the pre-built bootloaders so people can look at the file and tell what they are going to get.

Also, what I've noticed is that when building optiboot with the newer compiler tools, the .lst file is not very useful as the code is optimized differently and the objdump tool no longer inserts the C code for main() which is pretty much all the code. So unless you weed through the actual machine code you can't tell how the code was built. So when using the newer tools, using the more descriptive names becomes even more important.

--- bill


further note: Once things are properly renamed you could avoid needing some pre-built bootloaders to save on files. You could get away with just doing 8Mhz and 20Mhz prebuilt bootloaders. For example. The 8Mhz 57.6k B7 led bootloader is the same as the 16Mhz 115.2k B7 led bootloader so the boards.txt could use that instead of having to supply both.

In other words you don't need both the 16Mhz and 8Mhz versions of prebuilt bootloaders since they can be shared for the two clock rates since the 8Mhz baud rates can be used to get 16Mhz 57.6, 115.2 and 1M or they could all be called 16Mhz bootloaders which also get 28.8, 57.6 and 500k at 8Mhz

But I still strongly believe that the key to removing so much of the confusion and issues is to name the files consistently with better names that include build parameters. And if addtional NOled bootloaders are wanted/needed just add them.

i have a 20mhz 1284 and will try that when if i get a chance. periodic links to the files is helpful to avoid searching big threads.

a list file would also be very helpful as i do almost all development in asm. it was essential for my implementation of m256 opti with >128k capabilty. i would like to enhance 1284 too but lack of lst hinders. if somebody could compile one with the old tools that would be great because the c comments are useful.

well i downloaded a new 1.6.4 and tested ok with m328 then copied "avr-developers.com" section into boards.txt and set fuses. e=fd h=de l=f7. copied contents of zip file into ardunio/hardware. next flashed 20mhz opti and selected "avr-deveopers.c..." (in addition to baud in hex filename might be a good idea to mention m1284 in the boards entry). Got this:

Arduino: 1.6.4 (Windows XP), Board: "avr-developers.com pinout, JTAG disabled, 20Mhz Full Swing"

In file included from Blink.ino:18:0: G:\arduino-1.6.4\hardware\arduino\avr\cores\arduino/Arduino.h:247:26: fatal error: pins_arduino.h: No such file or directory

include "pins_arduino.h"

^ compilation terminated. Error compiling.

evidently some files are in the wrong place. I use this chip almost daily but couple years since trying with arduino so maybe could use a hint where to put them.

The latest 1284p code in Jack's 1.6.3 repo branch that mark updated is all working with IDE 1.6.4 for me on linux. Not sure how/what you installed as you should not need to modify any files.

All you have to do is get the latest 1.6.3 1284p core from jack's repo (make sure to get the 1.6.3 branch and not the 1.0.6 default zip) and you will get everything you need including all the the needed bootloaders and boards entries. You don't edit anything. Just install/extract it under the {user_sketchbookdir}/hardware directory so it works with whatever 1.6x IDE release you use. I added a menu label to the boards manager menu so that all the 1284 boards are all grouped together away from the official Arduino boards with a title separator "Mighty-1284p Boards" when selecting a board. And yeah I agree that the 1284p avr-developers board name is a bit dopey.

--- bill

bperrybap: You don't edit anything. Just install/extract it under the {user_sketchbookdir}/hardware directory

this conflicts with instructions from first post here which require editing the folder name to "mighty-1284p" instead of "mighty-1284p-v1.6.3". in any case i tried both approaches with same results. files are exactly where pico says. strangely the path in that error does not seem to mention any 1284 so i dunno.

btw i did select "avr-developers.c","jtag disabled", and "20mhz full swing", and correct com port.

personal experience and observing several semesters of students it looks like roughly 95% of problems deal with issues like this and little with actual programming. most likely ive made some stupid mistake or possibly those who put these packages together. no wonder a few are driven in desperation to assembly instead of "portable" and "productive" hll.

here's the error again not abbreviated this time:

Arduino: 1.6.4 (Windows XP), Board: "avr-developers.com pinout, JTAG disabled, 20Mhz Full Swing"

Build options changed, rebuilding all

G:\arduino-1.6.4\hardware\tools\avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -mmcu=atmega1284p -DF_CPU=20000000L -DARDUINO=10604 -DARDUINO_1284P_AVR_DEVELOPERS -DARDUINO_ARCH_AVR -IG:\arduino-1.6.4\hardware\arduino\avr\cores\arduino -IG:\arduino-1.6.4\hardware\arduino\avr\variants\avr_developers C:\DOCUME~1\r\LOCALS~1\Temp\build4488457291395959552.tmp\Blink.cpp -o C:\DOCUME~1\r\LOCALS~1\Temp\build4488457291395959552.tmp\Blink.cpp.o

In file included from Blink.ino:18:0: G:\arduino-1.6.4\hardware\arduino\avr\cores\arduino/Arduino.h:247:26: fatal error: pins_arduino.h: No such file or directory

include "pins_arduino.h"

^ compilation terminated. Error compiling.

same for empty sketch:

Arduino: 1.6.4 (Windows XP), Board: "avr-developers.com pinout, JTAG disabled, 20Mhz Full Swing"

G:\arduino-1.6.4\hardware\tools\avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -mmcu=atmega1284p -DF_CPU=20000000L -DARDUINO=10604 -DARDUINO_1284P_AVR_DEVELOPERS -DARDUINO_ARCH_AVR -IG:\arduino-1.6.4\hardware\arduino\avr\cores\arduino -IG:\arduino-1.6.4\hardware\arduino\avr\variants\avr_developers C:\DOCUME~1\r\LOCALS~1\Temp\build4488457291395959552.tmp\sketch_jun17a.cpp -o C:\DOCUME~1\r\LOCALS~1\Temp\build4488457291395959552.tmp\sketch_jun17a.cpp.o

In file included from sketch_jun17a.ino:1:0: G:\arduino-1.6.4\hardware\arduino\avr\cores\arduino/Arduino.h:247:26: fatal error: pins_arduino.h: No such file or directory

include "pins_arduino.h"

^ compilation terminated. Error compiling.

why isnt arduino even looking in the new 1284 folders?

I agree that there are many issues like this that show in in forum threads. In nearly all the cases I've seen, it is due to incorrectly installing things which comes from either not following the installation instructions or misinterpreting them OR from attempting a trial and error guessing process of editing and patching things which corrupts the installation.

Your include paths look messed up. The second -I option to the compiler should point to the variant directory for the board selected which is down under where the core is installed. In your case, it looks like the second include directory is pointing down under the IDE directories avr core directory rather than to the variant directory under the 1284p core. That shouldn't happen as the variant directory that the IDE "calculates" is relative to where the boards.txt file is and the 1284p core boards.txt will be in a different directory than the IDE supplied avr core.

While it could be a problem with the Windows version of the 1.6.4 IDE, I'm guessing this is because the 1284p core was either installed incorrectly or there were some manual edits to some files in the tree that altered things and it has now confused the IDE.

While you can install the core under the IDE area, I think it is better to install it under your personal hardware directory so that it works with more than just the single IDE installation and will work with future IDE installations. I believe that was the intent of #3 of instructions in the first post of this thread:

  1. Go to your Arduino "hardware" folder.

How and where did you install it? It really is as simple as just unziping 1284p core image under your {sketcthbookdire}/hardware directory. You don't even have to rename the mighty-1284p-1.6.3 directory created by the unzipping.

Looking forward, one thing that would help, would be to update the 1284p core package and git tree to support the new library/core manager so that the IDE could install the core and allow the user to update it from the IDE when updates are available. It's a pretty nice feature of the latest IDEs.

--- bill

bperrybap: How and where did you install it?

I downloaded 1.6.4 and unzipped it into a large partition. then downloaded the package from post #1 and copied contents into /hardware of the arduino i just installed and tested with uno. nothing else.

the difference between "my" hardware folder and "theirs" is not clear. i do have a few dozen other versions of arduino from 0013 up to latest. maybe this is trouble. the irony is a rather large group of individuals consider me the ardu-guru in spite of all denials so you can imagine what they go through on their own. some people have "good luck"... others... not so fortunate.

what exactly did i do wrong? next step?

I've also installed into the IDE hardware directory with 1.6.4. and that works as well. Although I still recommend putting the 1284p core under your hardware directory and not the IDE hardware directory so it can work with more than just that one IDE.

You are leaving out details and details matter. The steps you described in post #27 disagree with your steps in post #23 post #27 said:

copied contents into /hardware of the arduino i just installed and tested with uno. nothing else.

But this comment from post #23 concerns me:

... then copied "avr-developers.com" section into boards.txt ...

Which boards.txt did you edit and why? as you shouldn't have to do any editing of any of the board.txt files that come with the 1284p core as all the board entries are included. For sure you don't want to be editing the IDE's boards.txt file to add 1284p boards as that won't work since the include paths will be wrong just like what we are seeing as the variant directory is based on where the boards.txt file is and the 1284p core is not in the same location as the IDEs avr core and variant files.

Sounds like you may have confused your installation by doing some editing of files. Perhaps you also have an older version of the 1284 core installed down in your hardware directory?

I would install the 1284p core in your hardware directory vs the IDE hardware directory as that way it will work with all the IDEs that support the new 1.5x add on cores.

All you have to do is unzip the file in your hardware directory. And if you need the 20Mhz support, rename the boards.txt.alt to boards.txt in the 1284 core so you get it. It really is just that easy.

--- bill

bperrybap: Which boards.txt did you edit and why?

at first i just downloaded and unzipped files. when that didnt work i copied boards.txt from 1284 folder to the avr folder. at least the 1284 options showed up then but still that error. then as a last resort i put the original boards.txt back and added the 20mhz no-led entry to it. then got serious about editing and changing and of course things got worse. initially though no luck before any changes or editing.

i will delete all this and start over from scratch. as always your help and patience is appreciated.

john1993: at first i just downloaded and unzipped files. when that didnt work i copied boards.txt from 1284 folder to the avr folder. at least the 1284 options showed up then but still that error. then as a last resort i put the original boards.txt back and added the 20mhz no-led entry to it. then got serious about editing and changing and of course things got worse. initially though no luck before any changes or editing.

i will delete all this and start over from scratch. as always your help and patience is appreciated.

What would you suggest to the instructions to make it clearer how to install the package?

almost impossible to improve upon the instructions in post #1, except of course it didnt work for me this time. im sure i did something silly.

anyway lets find out why it failed before i make any real suggestions. only improvement at this time is adding the name of the board so it is easier to find in the menu and maybe the baud naming thing you mentioned. But these are trivial cosmetic items not worth mentioning.

i started right at the beginning of arduino and things were not working too well which is understandable for anything new. around 0018-0023 everything was great. chances a sketch worked was almost certain and all this folder stuff was manageable. then things started downhill and issues with compatibility and file locations cropped up. it wouldnt be the first time in computers that "progress" and "improvements" caused downhill slide.

this is not just myself but observations from many other beginners. my only general comment would be to make things easier for noobs and simplify instead of complicate. ive had many general suggestions over the years here for things like clock, pin naming, baud, pc interface, loaders, etc but dont want to get too far off topic. mostly i just want to see where i went wrong with this particular install. i will wipe this pc and start from scratch. stay tuned.

so i reformatted the hd, reinstalled windows and followed instructions again. this time it worked. as confirmation the original crowded image was restored and the same procedure duplicated. this time it failed again. so something on the drive, maybe registry or other arduino droppings interfere.

anyway while things were working i tested a few benchmark programs. there is definite improvement since last time i played with arduino for this chip couple years back. thanks to all those who put effort into making it better. particularly the opti.

speaking of which it would be nice to get a lst file with comments so i can crunch it down and squeeze in some favorite enhancements.

john1993: so i reformatted the hd, reinstalled windows and followed instructions again. this time it worked. as confirmation the original crowded image was restored and the same procedure duplicated. this time it failed again. so something on the drive, maybe registry or other arduino droppings interfere.

When you mentioned that you first saw the boards.txt entries when you copied the file up one level from mighty-1284p/avr to mighty-1284p, that gave me pause.

It suggests that the IDE you are running is 1.0x rather than 1.6.x.

The Arduino IDE developers changed the position of the files starting with the 1.5.x IDEs.

IDEs 1.5.x and later (including 1.6.x) expects boards.txt to appear under mighty-1284p/avr, while IDEs 1.0.x and earlier expects to find them in mighty-1284p.

Are you installing the Windows IDE using the windows installer version, or the zip file install version? If the former, try installing with the zip file version instead -- much less chance of interference between new and previous installed versions of the IDE. In fact, pretty much the only way to do it if you want to run multiple installed versions of the IDE (which is often required for a variety of reasons.)

always zip file because i agree installers in general are evil. as mentioned i downloaded another copy of 1.6.4 and know exactly which version is being used because i always click on the exe flle. no task bar, desktop icons. or win start menu here. in the "crowded" partition i have every version of arduino from 0013 up and something there conflicts. maybe some rainy day i will take time to find exactly what.

for now if the need arises to use arduino with this chip i can always restore that virgin windows partition which works fine. atm the only reason to do that would be enhancing the bootloader and i wouldnt even start on that w/o a lst file.

john1993: always zip file because i agree installers in general are evil. as mentioned i downloaded another copy of 1.6.4 and know exactly which version is being used because i always click on the exe flle. no task bar, desktop icons. or win start menu here. in the "crowded" partition i have every version of arduino from 0013 up and something there conflicts. maybe some rainy day i will take time to find exactly what.

for now if the need arises to use arduino with this chip i can always restore that virgin windows partition which works fine. atm the only reason to do that would be enhancing the bootloader and i wouldnt even start on that w/o a lst file.

Well, then it deepens the mystery because the zip file installs are supposed to be mostly limited to working within their own trees (but that's never been 100% true, and is even less so now with all the burgeoning BM stuff.)

BTW, the bootloaders all have .lst files -- I have uploaded a .lst file for the 20MHz optiboot bootloader for reference.

Thanks to Per (pert) for testing and confirming the operation of the new 20MHz optiboot bootloader!

Per also found and corrected a typo in the new 'sleeping beauty" entry in boards.txt.alt. Pull request has been merged, and v1.6.3 of repo updated.

If you want to manually correct the typo, rather than downloading again, just change

slwwpingbeauty.upload.maximum_data_size=16384

to

sleepingbeauty.upload.maximum_data_size=16384

it was a surprise to see the noled version so much bigger than the led one. not 2x but almost half again. so much for my theory that pretty flashing lights take up valuable memory space.

i must say the first post here is an example of how things should really be done. excellent attention to instructions and links, if only more developers followed suit. thanks for doing such a great job. maybe arduino is becoming a practical tool for me to use on one of my favorite avrs.

john1993: it was a surprise to see the noled version so much bigger than the led one. not 2x but almost half again. so much for my theory that pretty flashing lights take up valuable memory space.

Go look at the .lst file and you can see why. The 20Mhz image has code that is not in the optiboot.c code that is in the tree. The 20Mhz image is not only built with a different version of the optiboot code (which is not what is checked into this 1284 core tree) but appears to have been built with the BIGBOOT option which adds extra features like EEPROM support. All the other images were built with an older version of optiboot.

While I think it is great to have a pre-built image with the newer optiboot code and with BIGBOOT support, I think it is bad to have this 20 Mhz image using code that came from some other place than what is checked into the tree.

In looking at the location in the image where the optiboot version is stored, it looks like the 20Mhz image was built with optiboot version 6.2 while all the other images were built with optiboot version 5.0

The optiboot.c image that is in the tree is version 4.5 so it appears that none of the pre-built images were built with the optiboot.c source code that is in the tree.

I think it is bad to ship pre-built bootloaders that were not built with the accompanying source code.

--- bill

i would have to agree that its better to have correct source with the binary. in my case the list file is the source so no biggy. since im trying to cram a lot of non-standard function into minimum boot block the smaller older images are more useful. it only took me a couple minutes to change baud in the old/small opti to 20mhz. im just glad to have some working m1284 code as a starting point. and very happy libraries are improved so more programs work compared to last time i tried.