Hi! Great work! Thanks!

Is there any support for firmware update (like over the air) such as there is on xboot ?

How would I go about implementing this ?

Thanks in advance for any pointers,

Best regards

First of all, thanks for your great work!
I would like to request a feature: platformio support.

Kind regards,
Gilles Callebaut

Symptom was that SoftwareSerial was not able to receive input.

At this point I think the majority of Arduino users are using IDE version 1.6.x and enough time has passed for any serious bugs in the branch to have been found.

Well somehow this 'upgrade' has caused the old analog pin assignment problem to reappear where reading from analog pin A0 or 14 only really sees voltage applied to shield pins A1 or 15. This was 'solved' back when by the changes CrossRoads showed in the bobuino variant pins_arduino file that he posted below. Don't understand how changes to the core files would change that but that's what I'm seeing at the moment. So if anyone does this IDE upgrade and is using the Bobuino through hole board, they might want to check out their analog pin addressing.

Lefty
http://forum.arduino.cc/index.php?topic=235521.msg1707500#msg1707500

In the avr_developers variant, the Port A has the enumeration of the pins opposite to the mighty variant. The picture in the comments shows the correct enumeration.

// ATMEL ATMEGA644P / SANGUINO (also works for ATmega1284P)
|40 PA0 (AI 0 / D31)
|39 PA1 (AI 1 / D30)
|38 PA2 (AI 2 / D29)
|37 PA3 (AI 3 / D28)
|36 PA4 (AI 4 / D27)
|35 PA5 (AI 5 / D26)
|34 PA6 (AI 6 / D25)
|33 PA7 (AI 7 / D24)

Subsequently, the analog ports don't work with the avr-developers variant.
Also, if MIGHTY_1284P_VARIANT is defined, the pins are incorrect in the SD library for sanguino as the mighty variant is selected.

I think that 'avr-developers' should be renamed to 'sanguino', as sanguino is popular and has these pin numbers.

My diff:

--- pins_arduino_original.h 2014-10-24 22:09:00.900933382 -0700
+++ pins_arduino.h 2014-10-24 15:02:51.000000000 -0700
@@ -55,13 +55,13 @@
// +--------+
//

-#define MIGHTY_1284P_VARIANT "AVR_DEVELOPERS"
+//#define MIGHTY_1284P_VARIANT "AVR_DEVELOPERS"

#define NUM_DIGITAL_PINS 32
#define NUM_ANALOG_INPUTS 8
#define analogInputToDigitalPin(p) ((p < NUM_ANALOG_INPUTS) ? 31 - (p) : -1)
#define digitalPinHasPWM(p) ((p) == 3 || (p) == 4 || (p) == 6 || (p) == 7 || (p) == 12 || (p) == 13 || (p) == 14 || (p) == 15)
-#define digitalPinToAnalogPin(p) ( (p) >= 24 && (p) <= 31 ? (p) - 24 : -1 )
+#define digitalPinToAnalogPin(p) ( (p) >= 24 && (p) <= 31 ? 31 - (p) : -1 )
#define analogPinToChannel(p) ((p) < NUM_ANALOG_INPUTS) ? (p) : ((p) >= 24) ? (31 - (p)) : -1 //required macro for mighty-1284p core

static const uint8_t SS = 4;
@@ -71,16 +71,16 @@

static const uint8_t SDA = 17;
static const uint8_t SCL = 16;
-static const uint8_t LED_BUILTIN = 7;
+static const uint8_t LED_BUILTIN = 13;

-static const uint8_t A0 = 24;
-static const uint8_t A1 = 25;
-static const uint8_t A2 = 26;
-static const uint8_t A3 = 27;
-static const uint8_t A4 = 28;
-static const uint8_t A5 = 29;
-static const uint8_t A6 = 30;
-static const uint8_t A7 = 31;
+static const uint8_t A0 = 31;
+static const uint8_t A1 = 30;
+static const uint8_t A2 = 29;
+static const uint8_t A3 = 28;
+static const uint8_t A4 = 27;
+static const uint8_t A5 = 26;
+static const uint8_t A6 = 25;
+static const uint8_t A7 = 24;

#define digitalPinToPCICR(p) (((p) >= 0 && (p) < NUM_DIGITAL_PINS) ? (&PCICR) : ((uint8_t *)0))
#define digitalPinToPCICRbit(p) (((p) <= 7) ? 1 : (((p) <= 15) ? 3 : (((p) <= 23) ? 2 : 0)))
@@ -151,14 +151,14 @@
#define BIT_D21 5
#define BIT_D22 6
#define BIT_D23 7
-#define BIT_D24 0
-#define BIT_D25 1
-#define BIT_D26 2
-#define BIT_D27 3
-#define BIT_D28 4
-#define BIT_D29 5
-#define BIT_D30 6
-#define BIT_D31 7
+#define BIT_D24 7
+#define BIT_D25 6
+#define BIT_D26 5
+#define BIT_D27 4
+#define BIT_D28 3
+#define BIT_D29 2
+#define BIT_D30 1
+#define BIT_D31 0

As title says.

http://forum.arduino.cc/index.php?topic=235521.msg1745263#msg1745263

[quote author=pico link=topic=235521.msg1745263#msg1745263 date=1401459137]
[quote author=pekasus link=topic=235521.msg1745179#msg1745179 date=1401455748]
I suggest removing the 2 'Original Mighty 1284p' boards from the boards.txt file, because Maniacbug wrote 2 years ago that they were only for reference then and did not recommend using them. I doubt that anyone will be using them in this release, so it could reduce potential for error of choosing the wrong the board, and at minimum reduces clutter.
[/quote]

I support this simplification as well. The original Maniacbug repo is still going to be there for the historical reference if need be.

[/quote]

When you updated the pin mapping, did you change the location of any of the pins, or will they fit the pinout of the older version. For example, do I have to change the digital or analog pin number of anything in my software in order to port to the 1.05 version?

Library Manager installs libraries to the sketchbook/libraries folder. This folder takes precedence over the mighty-1284p\avr\libraries folder so after a user updates the standard version of any of the Mighty 1284P patched libraries using Library Manager the unpatched library will be used instead of the patched library. The only solutions I can think of are:

1. Instruct the users to do the updates but then to move the updated libraries to arduino/libraries where they will not take precedence over mighty-1284p\avr\libraries when a Mighty 1284P board is selected.
   • This is probably the best of the 3 but a bit complex.
2. Instructing the users to not do Library Manager updates of any of the libraries that have been patched in Mighty 1284P.
   • This is a bad solution because updates are a good thing.
3. Rename all the patched libraries.
   • This will require the user to change their includes.

This issue is being discussed here: arduino/Arduino#4064 but of course any solution found there will only be available in Arduino IDE 1.6.6. If you let me know how you want to handle this issue I'm willing to do the work and submit a pull request.

The Readme.txt and pins_arduino.h.old under the sleepingbeauty directory were not intended to be commited to the tree.

I'd like to use the variant files from this repository in my fork of the Ariadne bootloader that has ATmega1284P support added but only the avr_developers variant has license information.

I'd like to be able to run the 1284p at 4mhz or 8mhz (ideally, 4mhz) so I can run off a lower voltage source for longer periods of time.

Is it as simple as changing AVR_FREQ from 16000000L to 8000000L or 4000000L in the optiboot Makefile?

There used to be a 8mhz bootloader included in the original bootloader directory, but if I understand correctly, that's deprecated now.

I have already contacted pico-- about this but thought I'd add it here to avoid anyone else duplicating my effort.

I have implemented a working Arduino 1.6.4+ Boards Manager install for Mighty 1284P. The Boards Manager install URL is:
https://per1234.github.io/mighty-1284p/package_JChristensen_mighty-1284p_index.json

I would like to submit a pull request to add this capability to Mighty 1284P. To make this happen two files need to be added somewhere in the repository, the _package index(the .json file in the link above) and the _installation archive. I would need to know where you want these to be put. It's worth giving the location of the package index file some thought because it is best not to change the URL after people have already added it to their preferences. Here are some possible Github locations for these files, you could use a combination of these locations, one for the package index and another for the installation archive:

1. gh-pages branch(e.g., Adafruit)
   • Pros: URL is shorter(e.g., https://JChristensen.github.io/mighty-1284p/package_JChristensen_mighty-1284p_index.json instead of https://raw.githubusercontent.com/JChristensen/mighty-1284p/v1.6.3/package_JChristensen_mighty-1284p_index.json).
   • Cons: Adds another branch.
   • I would need you to create the _gh-pages_ branch
2. Preexisting branch(e.g., Sparkfun)
   • Pros: Doesn't add any more branches to the repository.
   • Cons: Adds files that are useless to someone doing a manual install.
3. Github Releases(e.g., Sanguino)
   • Pros: This is already a standard Github way to handle versions.
   • Cons:
     • The folder structure of the Boards Manager install file is different than the manual installation file(no _avr_ folder) so this requires a separate Boards Manager install file to be added to each release. This may be confusing to users trying to figure out which file they need to download for manual installation. You may want to add wording to explain the purpose of the file.
     • Releases can't added or modified via pull request so updates will always be the responsibility of a project collaborator's.
     • The package index file could be added to a release but this is a bit confusing because a single file contains all the versions and you don't want to change the URL with each version.
   • I would need you to create the release.

Note: Using the archive file automatically generated by Github for each commit(e.g., https://github.com/user-name/project/archive/{commit ID}.zip) as an installation archive file is not a good idea because Github may later modify the file, making the checksum in the package index file incorrect which will cause a CRC mismatch error during installation in Boards Manager.

If you create the installation archive file then notice that the folder structure is slightly different. All files should be moved up a level from the avr folder and the avr folder should be removed(see https://per1234.github.io/mighty-1284p/mighty-1284p_1.0.0.zip).

Even when i try to run simple program like this:
`void setup() {
// put your setup code here, to run once:
Serial2.begin(9600);
}

void loop() {
// put your main code here, to run repeatedly:

}`
I keep getting error: 'Serial2' was not declared in this scope.

the optiboot makefile configures the high fuse

# 1024 byte boot
atmega1284_isp: HFUSE = DE

according to ATMega 1284 manuals chapter 26.8.17 this would result in

0xDE = 
1 1 0 1 1 1 1 0             -> 512 byte, start at 0xFE00
          | | |
          | | BOOTRST
          | BOOTSZ0
          BOOTSZ1

after my understanding, this would be correct

0xDC = 
1 1 0 1 1 1 0 0             -> 1024 byte, start at 0xFC00
          | | |
          | | BOOTRST
          | BOOTSZ0
          BOOTSZ1

May be can you create a json file for the baord manager ?