Go Down

Topic: Mighty-1284p repo updated for IDE 1.6.x (Read 15796 times) previous topic - next topic

bperrybap

I see the modifications.
However, I wouldn't call it "fixed", but rather temporarily patched it to hide/remove/disable the offending entries by commenting them out.
This is a loss of boards entries from the previous release.

I also did see what looks like another issue.
The 20mhz clock entries are using the same bootloader and baud rate as the 16MHz bootloader.
Wont' the the baud rate when using a 20Mhz clock be double vs 16Mhz since they are both using the same bootloader?

--- bill

pico

#16
Jun 16, 2015, 05:54 am Last Edit: Jun 16, 2015, 07:00 am by pico
I see the modifications.
However, I wouldn't call it "fixed", but rather temporarily patched it to hide/remove/disable the offending entries by commenting them out.
This is a loss of boards entries from the previous release.
This is permanently patched until someone puts the time in to provide the "no led" versions of the bootloader suitable for avr_developers and "maniacbug" Mighty layouts.

The last release introduced the boards.txt.alt file as an alternative boards.txt that extended the clock options for different boards. As it turns out, not all of those new options were valid for some boards. That was a bug. That's been fixed. The latest boards.txt.alt file only allows valid combinations of boards and bootloaders.

I also did see what looks like another issue.
The 20mhz clock entries are using the same bootloader and baud rate as the 16MHz bootloader.
Wont' the the baud rate when using a 20Mhz clock be double vs 16Mhz since they are both using the same bootloader?
That was reported as working by another user -- I don't have a 20MHz xtal on hand to test myself, unfortunately.

If you (or anyone else interested) have a 20MHz xtal, please test and advise if there are any problems.

A bootloader expecting 115200 @ 16MHz would presumably be looking for 144000 @ 20MHz, so changing upload.speed to 144000 might work. Else, a new bootloader compiled for 20MHz would be needed. In the meantime, only ICSP programming would be supported.
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

#17
Jun 16, 2015, 09:01 am Last Edit: Jun 16, 2015, 09:02 am by bperrybap
The issue/bug with using the incorrect LED bootloaders in boards.alt.txt was not fixed. You can't call that a  fix.
It is like a person having an issue on channel 4 on their TV and taking it to the repair shop and the guy returns it saying it is fixed.
But the "fix" was to disable the TV from being able to select channel 4.
As far as the customer is concerned it was not fixed and he would not be happy since he knows there is a channel 4 but now he can't get to it at all.

On the 20Mhz clock. Clearly nobody tested (or even thought about) the effects of using a 16Mhz bootloader with a 20Mhz clock at 115.2k baud. There is no way that is going to work since the baud rate is directly driven off the CPU clock. Alter the CPU clock and the resulting baud rate changes.

While my comment about it being double was wrong, (It is actually 20/16 of the baud rate or 144000) it still won't work.
You can not use the same bootloader image that was built for 16Mhz and 115200 baud and have 115200 baud work with both a 16Mhz and 20 Mhz clock since at 20Mhz the baud rate will be 144000.

BTW, I let my self get sucked into the 1284p optiboot mess vortex again and did hook it up to see what would happen.
First, avrdude doesn't like 144000 baud, it complains but goes ahead and tries it.
Then linux appears to silently ignore the non standard 144000 requested baud rate and drops back down to 9600 on the FTDI chip.
I verified this using a logic analyzer.

I did quick build of a B7 bootloader at 20Mhz for 115.2k and it works as expected.
Since I used the 1284p optiboot stuff vs the latest optiboot stuff, I also had to correct the makefile to allow it to be built
with the latest avr-gcc tools.
Not a big deal, it took like 5 minutes to correct the makefile, build the image and test it on my SB board.

This latest issue is just another example of how using better more descriptive file names would have helped prevent using incorrect pre-built bootloaders.

Like I said before, this optiboot bootloader stuff is a real mess.

--- bill


bperrybap

#18
Jun 16, 2015, 09:18 am Last Edit: Jun 16, 2015, 09:21 am by bperrybap
Some additional FYI on the never ending optiboot bootloader issues:
The latest official optiboot has used some conditional features in make to allow external scripts to control some of the parameters such as CPU frequency, LED, baud rate, etc...
Unfortunately, there is a bug in older versions of make that causes it to not work correctly.
This bug was fixed in gnu make version 4.0 so any 4.x version works.
However while version 4.0 is several years old most *nix OS distributions (including Ubuntu and Linux mint) are still shipping with make version 3.81 which is whopping 9 years old!
Most of the minw/msys tool sets for Windows and the make that used to ship with the Windows Arduino IDE are also using make 3.81

While this issue is a bug in make it is very unfortunate that the new optiboot depends on having a newer version of make to be able to build bootloaders and at this point in time it appears to me that most users will not have this newer version of make.

During my testing with the new optiboot, i just went and grabbed make 4.2 and built it.
While building a new version of make is trivial on *nix machines, it is not so easy on Windows since Windows doesn't come with real s/w build tools that come standard in *nix operating systems.

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.

Just another part of the overall messy state of optiboot bootloaders.

--- bill

john1993

afaik the idea of eliminating the silly flashing was brought up by me first a couple years ago in that other mega-thread. imo a blinky is great for a demo but serves little purpose in a bootloader.  actually potential for big problems. much worse when nobody seems to agree on what pin to use. relays clicking and displays showing mysterious garbage on startup are real annoyances.

i do agree there is a big mess in many of these arduino packages. too many cooks spoil the broth. TMI seems to be a bigger issue for beginners than not enough info. sometimes less is more. kiss.

pico

#20
Jun 16, 2015, 06:41 pm Last Edit: Jun 16, 2015, 06:42 pm by pico
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.
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

#21
Jun 16, 2015, 07:21 pm Last Edit: Jun 16, 2015, 08:00 pm by bperrybap
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.

john1993

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.

john1993

#23
Jun 16, 2015, 11:32 pm Last Edit: Jun 16, 2015, 11:33 pm by john1993
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:


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

bperrybap

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

john1993

#25
Jun 17, 2015, 04:40 pm Last Edit: Jun 17, 2015, 05:18 pm by john1993
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:

Quote
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:

Quote
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?

bperrybap

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:

Quote
3. 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

john1993

#27
Jun 17, 2015, 08:30 pm Last Edit: Jun 17, 2015, 08:31 pm by john1993
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?

bperrybap

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:
Quote
copied contents into /hardware of the arduino i just installed and tested with uno. nothing else.
But this comment from post #23 concerns me:
Quote
... 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

john1993

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.

Go Up