Mighty-1284p repo updated for IDE 1.6.x

Just added a new v1.6.3 branch to the JChristensen github repo for the mighty-1284p:

https://github.com/JChristensen/mighty-1284p/tree/v1.6.3

There are three branches for this repo now, each with a different target set of IDE versions.

  • The original v1.0.5 branch is for IDE 1.0.1 - 1.0.5.
  • The v1.0.6 branch is for 1.0.6 only.
  • The latest v.1.6.3 branch should work with 1.6.0-1.6.4 (tested only briefly on 1.6.4, but seems to be fine so far.)

Make sure you are on the correct branch when downloading the zip file.

The installation instructions are slightly different for 1.6.x (simpler, actually) so do read the installation steps.

The patched libs have been updated for 1.6.x. Thanks to Per (pert) for updating these!

Also thanks to Bill (bperrybap) for help with new the set-up for the 1.6.x files.

Any suggestions, questions, or problems, drop a note in this thread.


These are the manual installation steps on the github page from the link above:

Installation

  1. Go to https://github.com/JChristensen/mighty-1284p/tree/v1.6.3, click the Download ZIP button and save the ZIP file to a convenient location on your computer.

  2. Ensure that the Arduino IDE is not running.

  3. Go to your Arduino "hardware" folder.

  4. Unzip the downloaded file into the hardware folder.

  5. The download from GitHub will have a dash and branch name appended, so the folder will be named, e.g. mighty-1284p-v1.6.3. Rename the folder to just mighty-1284p.

  6. The following folders and files should now exist:

◦ hardware\mighty-1284p\avr\bootloaders ◦ hardware\mighty-1284p\avr\libraries ◦ hardware\mighty-1284p\avr\patched-3rd-party-libs ◦ hardware\mighty-1284p\avr\variants ◦ hardware\mighty-1284p\avr\boards.txt ◦ hardware\mighty-1284p\avr\boards.txt.alt ◦ hardware\mighty-1284p.gitignore ◦ hardware\mighty-1284p\README.md

  1. Move any mighty-1284p compatible 3rd party patched libs under [sketchfolder]\libraries as required. (Note: the mighty-1284p compatible "official" patched libs are already set-up to be used as default when using mighty-1284p by being in avr\libraries. If the wrong libs are being used, check to see that there aren't old versions of the patched libs still under [sketchfolder]\libraries, as those would take precedence.)

  2. Restart the Arduino IDE.

  3. Select the desired board from the Tools > Board menu and enjoy those extra pins and all that extra memory!

Thank you Pico !!! This was exactly what I was looking for today :)

mcnobby: Thank you Pico !!! This was exactly what I was looking for today :)

No probs -- glad you found it useful. You get karma points for actually bothering to say thank you. :)

Recently we've added an alternative boards.txt file named board.txt.alt.

To explain, this note has been added under the installation instructions:

Note: There is an alternative version of the boards.txt file supplied named boards.txt.alt. It provides more combinations of boards and clock speeds than the standard boards.txt selection menu. It uses a two-step selection of board type and then clock-speed via a submenu. As this differs from the standard boards.txt format, it is provided as an option for those users with more specialized needs, while the default boards.txt retains the more familiar style of interface, to minimise any potential for confusion. To enable the alternate version, rename boards.txt to boards.txt.org, and then rename boards.txt.alt to boards.txt. Restart IDE, and the new selection options will appear.

If you decide to try it out, and have any comments or questions, please post here.

Ok thanks for that, I already made an adapted entry for my 32MHz version, but I will have a look at that .alt :)

Very cool. I picked up a Mighty-1284p compatible board off ebay a couple of weeks ago and have been keen to try it out. I really appreciate the work you guys put into it.

Would you know if the atmega1284 (not P) 44pin tqfp has been tested with this bootloader?

dThirteen: Very cool. I picked up a Mighty-1284p compatible board off ebay a couple of weeks ago and have been keen to try it out. I really appreciate the work you guys put into it.

No probs. Let us know how you go.

THLL: Would you know if the atmega1284 (not P) 44pin tqfp has been tested with this bootloader?

I've tested the boot loader with a atmega1284 40 pin DIP, and it's fine -- I wouldn't expect any problems with the TQFP package.

Updated Mighty-1284p v1.6.3 repo today:

• added support for variant “Sleeping Beauty”
• updated boards.txt.alt to include menu options for enabling/disabling JTAG, as well as A4/A5 functionality for Sleeping Beauty
• updated boards.txt.alt clock speed options to disallow bootloader options that flash LED on PB7 for boards that do not have the board LED connected to PB7
• added platform.local.txt to restore Mighty-1284p separator heading in Tools|Board list

Thanks to Bill (bperrybap) for providing the variant file pins_arduino.h for “Sleeping Beauty” board.

boards.txt.alt has been extended, with more menu options added - JTAG enable/disable (all boards), A4/A5 pin function select (Sleeping Beauty only).

Clock speed for boards that do not have a board LED attached to PB7 have had bootloader options that flash the LED using that pin have been removed from the boards.txt.alt menu. This affects avr_developers and the original “maniacbug” Mighty-1284p layouts.

The issue is that “optiboot_atmega1284p.hex” is currently the only bootloader file in the “bootloaders” directory that has the LED flash on bootloader startup disabled. For compatibility across the different board types, all bootloaders should have the LED flashing disabled, otherwise some boards may be getting unexpected toggling of the PB7 pin, which may be appear as a bug.

After some discussion last year, it was decided the preferred approach would be to simply disable the LED flash on all bootloaders for Mighty-1284p, but unfortunately it is now evident this was only actually done for one version of the bootloader, not all.

To fix this would require rebuilding the bootloaders, possibly renaming them with an appended “_NO_LED” for additional clarity. It may also be an opportunity to update optiboot.c to the latest version – the current optiboot.c Makefile is out of date for the current avr-gcc tools. (Thanks to Bill for uncovering these issues and bringing them to my attention.)

Volunteers for the “clean up the Mighty-1284p bootloaders/optiboot directory” project welcome. :slight_smile:

I tried to make a 32MHz (TTL clock gen) entry into boards.txt with the correct clock gen unit. No matter how hard I tried I just couldnt get it to work, it was like it was dead, or wouldnt start up I lowered the frequency to 24MHz and changed the clock gen for a standard crystal (using the xtal1 & 2 pins) and everything was fine

I havent had any trouble getting '328, or Tiny's to work at 32MHz, just the '1284

Its probably well over the limit of overclocking :)

Mark, Seriously? You didn't add the B7 bootloader for sleeping beauty? And no renaming for all the other bootloaders for clarity. Why?

So SleepingBeauty users loose the LED functionality that they originally had when they re-burn their bootloader with this core. That is unacceptable to me.

OK. I've had enough of the bootloader mess. As long as I can get it into the tree, I'll go fix all this optibootloader crap that exists today since everyone seems to just keep avoiding it. For me, it is way less work to just go fix it, than to point out the issues in what is there now since doing it is pretty trivial and I'm sick of this bootloader disaster that is being allowed to persist.

I'll use the latest optiboot and create a wrapper script that creates all the needed 15 bootloaders with descriptive names that includes the cpu clock rate, baud rate, and led support. And then update the boards.txt files to match.

If I do this, can I get this checked into the tree?


BTW as a FYI to others. To unsugar coat the state of the bootloader stuff:. In my view, the bootloader stuff is a total mess right now. This is a sample of what is there now: - The code in the optiboot directory does not match what is in the pre-built bootloaders - the optiboot code and build tools included are very old and won't build with the latest tools that ship with the IDE that this core is for - boards in boards.txt.alt are using bootloaders that toggle the wrong the LED pin

---- bill

bperrybap: Mark, Seriously? You didn't add the B7 bootloader for sleeping beauty?

And no renaming for all the other bootloaders for clarity. Why?

So SleepingBeauty users loose the LED functionality that they originally had when they re-burn their bootloader with this core. That is unacceptable to me.

OK. I've had enough of the bootloader mess. As long as I can get it into the tree, I'll go fix all this optibootloader crap that exists today since everyone seems to just keep avoiding it. For me, it is way less work to just go fix it, than to point out the issues in what is there now since doing it is pretty trivial and I'm sick of this bootloader disaster that is being allowed to persist.

I'll use the latest optiboot and create a wrapper script that creates all the needed 15 bootloaders with descriptive names that includes the cpu clock rate, baud rate, and led support. And then update the boards.txt files to match.

If I do this, can I get this checked into the tree?

---- bill

Sounds like we have a volunteer. :)

As we discussed offline, the consensus way back when was that no bootloader for the Mighty-1284p project should flash the LED. I know you strongly dissent from that decision, but in the absence of a new consensus reversing the original decision, I think it should stand. And personally, I also think it was the correct decision, FWIW. Bootloaders should not flash LEDs, period, IMHO.

But if you want to undertake the bootloader overhaul project, and nobody else voices an opinion at this stage one way or the other, I will submit your updates... even though I think personally think maintaining the additional bootloaders required for "LED flashing" and "non-LED non-flashing" versions of the bootloaders, depending on target board, is just messy, unnecessary and actually, undesirable.

But I don't feel as strongly about all of this as you obviously do!

pico: Sounds like we have a volunteer. :)

As we discussed offline, the consensus way back when was that no bootloader for the Mighty-1284p project should flash the LED. I know you strongly dissent from that decision, but in the absence of a new consensus reversing g the original decision, I think it should stand. And personally, I also think it was the correct decision, FWIW. Bootloaders should not flash LEDs, period, IMHO.

But if you want to undertake the bootloader overhaul project, and nobody else voices an opinion at this stage one way or the other, I will submit your updates... even though I think personally think the additional bootloader required for flashing and non-flashing versions of the bootloaders, depending on target board, is just messy, unnecessary and actually, undesirable.

But I don't feel as strongly about all of this as you obviously do!

The view of a non flashing led bootloader does not seemed to be shared by the wider arduino population (or at least team arduino.cc ) as all AVR based Arduino boards that are now shipping appear to have a blinking bootloader.

In general I don't believe in forcing personal/group opinions on people and instead believe in giving people the flexibility to "have it their way".

In the case of SB users, I think that by default, SB users should get the same bootloader that they had when then received their board when they use the IDE and this core to re-burn a SB bootlaoder. If they don't want the blinking led, then then can go in an modify their boards.txt entry to point to a non blinking LED bootloader.

In the larger picture, can I get an updated optiboot directory that uses the newer optiboot and creates all the combinations of bootlaoders with more descriptive names in to the tree? (if there is concern, perhaps rename the current optiboot directory to something else when this is added)

--- bill

bperrybap: In general I don't believe in forcing personal/group opinions on people and instead believe in giving people the flexibility to "have it their way".

Sounds good to me.

bperrybap: In the larger picture, can I get an updated optiboot directory that uses the newer optiboot and creates all the combinations of bootlaoders with more descriptive names in to the tree? (if there is concern, perhaps rename the current optiboot directory to something else when this is added)

Yes, as I said, unless anyone else comes forward with a strong opinion about it one way or the other, if you are willing to do the tidy up, I will upload your updates to the repo. As you say, if anyone has strong religious convictions about the issue one way or the other, they can manually adjust which bootloader they want. (It's not like they will be wanting for choice...)

bperrybap:

  • boards in boards.txt.alt are using bootloaders that toggle the wrong the LED pin

No, this isn’t true – I fixed that. All the available bootloaders for each board match up to the board. (I think you were confused because you didn’t realize Jack’s Mini actually has a LED connected to PB7, unlike the original “maniacbug” Mighty layout. )

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

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.

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.

bperrybap: 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.

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

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

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.