Mighty-1284P core updated for Arduino 1.0.6

I have tried to use the Mighty-1284p core with Arduino 1.6, but for me, even with the filing system right:
/arduino-1.6.0/hardware/atmegaxxx4p/AVR/...
It always says:
Arduino: 1.6.0 (Windows 7), Board: "ATmega324P"

Selected board depends on 'arduino' core (not installed).

Well, it sounds to me like you're mixing things that aren't the same thing, so not too surprising it doesn't work. I've never tried the 324, and not tried using the 1284 support for anything other than 1284 chips. If you look around in the core and the libraries, you'll find statements like this literally everywhere, and if 324 is not listed, then I don't see it is supported.

#if defined(__AVR_ATmega1280__) || defined(__AVR_ATmega2560__) || 
defined(__AVR_ATmega1284__) || defined(__AVR_ATmega1284P__) || 
defined(__AVR_ATmega644__) || defined(__AVR_ATmega644A__) || 
defined(__AVR_ATmega644P__) || defined(__AVR_ATmega644PA__)

So... why does it work for 1.0.6 but not 1.6?

I knew that was going to be your next question, :-), and all I can say is, I have no idea why it would work when there is absolutely no support for it in the IDE. ??

When I started using the 1284 back in early 2013, I went into essentially every source file in the IDE core and libraries, and "fixed" them to add 1284 support where it did not exist. And that's what all these dozens of 1284 threads have been about too.

AHA!!! I found the error: the file hardware/mighty_1284p/AVR/... should be /avr !
It compiles now! (Sadly, still with the sync errors I describe in my other thread)

Note to everybody else: directory names are CASE SENSITIVE!

legonick22:
AHA!!! I found the error: the file hardware/mighty_1284p/AVR/... should be /avr !
It compiles now! (Sadly, still with the sync errors I describe in my other thread)

Note to everybody else: directory names are CASE SENSITIVE!

Good tip! I just typed in lower case without thinking it has to be. Guess [Aa][Vv][Rr] was not used for searching the folder :wink:

legonick22:
So... why does it work for 1.0.6 but not 1.6?

I've actually recently discussed this offline with Bill (bperrybap). The reason it works in 1.0.x but not in 1.6.x is because the arduino core in 1.0.x is located in

hardware/arduino/cores/arduino

but in 1.0.6 this has changed to

hardware/arduino/avr/cores/arduino

why did they do this? Because now they also have a sam core files under hardware/arduino

So, they differentiated the two architectures by changing the path name, to include the architecture.

So far so good. But this is where it gets ugly.

The syntax for locating a core in boards.txt is like this:

bobuino.build.core=arduino:arduino

where the path to the core is vendor-id:[core-id]

This is the same as in 1.0.x. You would think that would change in 1.6.x to something like

bobuino.build.core=arduino:avr:arduino

i.e.

so that the architecture is in the path is specified, and the two paths

hardware/arduino/avr/cores/arduino

and

hardware/arduino/sam/cores/arduino

are disambiguated, for example.

Otherwise, just using arduino:arduino how do the IDE know which core to use?

But no. Explicitly specifying vendor-id:[architecture]:[core-id] would be too, er, straightforward.

Instead, what they appear to have done is to infer the architecture implicitly from the path name of the boards.txt file that refers to the core file.

So, basically, it gets the avr part of the path name for

hardware/arduino/avr

from the fact the boards.txt file it is reading is located at

hardware/mighty_1284p/avr

Which is why you have to specify the architecture of the mighty_1284p as avr in 1.6.x but you don't need to do this in 1.0.x.

Even though, of course, there is never going to be a mighty_1284p/sam (or any other architecture besides avr) among the mighty_1284p variants.

I told you it got ugly.

What were they thinking? (Which, upon reflection, seems to be the eternal question when looking at the design decisions behind any version of the Arduino IDE...)

But that's what they've done.

Anyway, because we've got to take all this stuff into consideration when packaging up the mighty_1284p download for 1.6.x, I've started a new thread just on this topic.

Pico,

Thanks for the explanation.

I have a question: in arduino's own boards.txt core=arduino is sufficient to specify arduino's arduino core (default vendor being Arduino?!) but in a custom vendor hardware folder, you need core=arduino:arduino to specify the same arduino core within arduino IDE folder?

liudr:
Pico,

Thanks for the explanation.

I have a question: in arduino's own boards.txt core=arduino is sufficient to specify arduino's arduino core (default vendor being Arduino?!) but in a custom vendor hardware folder, you need core=arduino:arduino to specify the same arduino core within arduino IDE folder?

If you don't specify the vendor-id, it appears the vendor-id is inferred from the location of the boards.txt file.

So if the boards.txt is in hardware/arduino/avr, and the vendor-id is not specified, the vendor-id is assumed to be arduino.

Similarly, if the boards.txt is in hardware/mighty_1284p/avr, and the vendor-id is not specified, the vendor-id would be assumed to be mighty_1284p.

So "arduino" is not actually the default vendor-id per se, but rather is assumed form the boards.txt location in that case.

Some of what creates confusion is that Team Arduino used the term "arduino" to refer to literally everything

  • the name of the board
  • the name of the IDE
  • the name of the "language"
  • the name of the libraries
  • the vendor name
  • the name of the core
  • a philosophy
  • a way of life
    (the last two were mentioned by a couple of the Team Arduino members)

Because of this when you see a string like "arduino" in something like a boards.txt file
you can't be quite sure what it is referencing.

When there as a thread about the confusion over the term "arduino" 5-6 years ago,
I kind bashed the arduino team for not coming up with better terms for things
and then I wrote a paragraph that used all of them correctly; however,
it was literally impossible to tell what it meant.
It was actually comical to see all the various references together and made the point as to how
how it was impossible to know what somebody means when they say "arduino".

A few of them were not amused.

--- bill

So "everything is included" can be translated into (-arduino,+arduino) or Arduino considering the arduino symbol already includes - + and infty.
:wink:

After reading quite a few posts I managed to compile my code for a atmega1284 (the non pico-power version) in the new version of the IDE 1.6.1 based on the following:

I loaded the Mighty-1284P core definition by Jack Christensen (many thanks for making this available on GitHub) in the 'hardware' subdirectory of my sketches directory.

In IDE 1.6.1 you no longer need the "core" subdirectory because the atmega1284 (and atmega1284P) is now known in the defaults Arduino cores.

But I did need to adapt the "boards.txt" file to get the compilations error free. I'm also using the "standard" pinout definitions in the Mighty-1284P files (standard under variants).

Since I loaded my atmega1284 with the Optiboot bootloader using the sketches by Nick Gamon (another great thanks to him !!!), I needed to change the signature for my chip version.

Also the self detect sketch needs to be updated with the signature of the atmega1284, since it only contains the signature of the atmega1284p.

I temporarily changed the signature of the atmega1284p in his boot loader sketch to match the signature of the atmega1284 (last byte is 06 instead of 05) and then programmed the atmega1284p version of optiboot into the atmega1284. Doing this allows me to use both types when programming sketches via the FTDI cable.

So first the changes in the boards.txt file. To keep from mixing with the existing files I made my own boards.txt file with the content below. This can also be changed in the original boards.txt file. The prefix "gsan_opt_" is not relevant.

##############################################################
gsan_opt.name=atmega1284 16MHz using Optiboot
gsan_opt.upload.tool=arduino:avrdude
gsan_opt.upload.protocol=arduino
gsan_opt.upload.maximum_size=130048
gsan_opt.upload.maximum_data_size=16384
gsan_opt.upload.speed=115200

gsan_opt.bootloader.tool=arduino:avrdude
gsan_opt.bootloader.low_fuses=0xf7
gsan_opt.bootloader.high_fuses=0xde
gsan_opt.bootloader.extended_fuses=0xfd
gsan_opt.bootloader.file=optiboot/optiboot_atmega1284p.hex
gsan_opt.bootloader.unlock_bits=0x3F

gsan_opt.bootloader.lock_bits=0x0F
gsan_opt.build.mcu=atmega1284
gsan_opt.build.f_cpu=16000000L

gsan_opt.build.board=AVR_ATMEGA1284
gsan_opt.build.core=arduino:arduino
gsan_opt.build.variant=standard

The change in Nick Gamon's sketch to load Optiboot was as follows:

In Atmega_Board_Programmer (v1.31):

around line 322:

// ATmega1284P family
{ { 0x1E, 0x97, 0x05 }, "ATmega1284P", 128 * kb, 1 * kb,
#if USE_ATMEGA1284
optiboot_atmega1284p_hex,

Needs to be changed into

// ATmega1284P family
{ { 0x1E, 0x97, 0x06 }, "ATmega1284P", 128 * kb, 1 * kb,
#if USE_ATMEGA1284
optiboot_atmega1284p_hex,

I would prefer if the sketch incorporated a second signature for the non-pico power version, the Optiboot version can be the same in both cases.

Another sketch where the signature would need to be added is the one where another Arduino is used as ISP for the target atmega1284. Since I use an FTDI cable directly to my breadboarded atmega1284, I did not change this. This is future work.

But with the above changes I was able to compile my sketch under IDE 1.6.1

Uploading with an FTDI friend from Adafruit worked without a problem, under the condition that I changed the crystal oscillator setting to full swing.

I use my atmega1284 in a minimal breadboard setup.

For those with problems loading large sketches on the atmega1284: make sure you fuses are set for Full Swing oscilation (f7 instead of ff on the low fuses setting of the boot loader).

I tested loading several sketches up to 130029 bytes in length and it works consistently. They also run until the end as expected.

Knowing that Optiboot does not use the full 1024 bytes now reserved for the boot section, one could imagine making another 512 byte available for programs, but I'm not greedy at the moment. 130048 bytes is plenty for what I need now. Me izz happy bunny :slight_smile:

You guys are amazing. I started using the 1284p a few years back before switching most of my work to Teensy. However, some things are better done on an AVR, and the 1284p is perfect for my latest project, monitoring a multitude of 1-wire devices. Thank you for updating the core/board/etc files to make it possible!!!

Quick question: why is the AVR-developer version not more popular a configuration? Having the hardware interrupt pins on otherwise unassigned pins seems like a much better solution than having them do double duty with RX1 and TX1.

I don't know what the developer variant says, but INT0,INT1 are fixed in chip hardware on the mega1284 on the same pins as RX1,TX1. Atmel did that, we have to live with it. If you want to use UART1, then you have only INT2 left, besides the pin-change interrupts.

Oric-Dan, thank you so much! Now I'll get to immerse myself in pcint libraries vs. suffering for ages trying to figure out why the AVR developer version of the chip isn't working.

Too bad the hardware interrupts can't be handled by those pins. Would make life a lot easier for me. Anyhow, thank you, thank you, thank you. You probably just saved a tuft full of hair from early extinction.

@Constantin- you mention pcint libraries. Thought I'd mention that 644/1284(p) support has been added to the EnableInterrupt library. See EnableInterrupt library- to attach interrupts to Arduino pins - Exhibition / Gallery - Arduino Forum

Constantin:
You guys are amazing. I started using the 1284p a few years back before switching most of my work to Teensy. However, some things are better done on an AVR, and the 1284p is perfect for my latest project, monitoring a multitude of 1-wire devices. Thank you for updating the core/board/etc files to make it possible!!!

Just to note that development is still continuing with support recently added for the 1.6.x IDEs. I've created a new thread just for the 1.6.x updates:

Mighty-1284p repo updated for IDE 1.6.x

I am still having trouble with my ATMEGA1284 with cores on 1.6.3

here is the trouble, if I try and output to a port (in C) it ALWAYS directs it to PortD

#define PIN 7
// PA7 drives PD7
// PD7 drives PD7 !
// PC7 drives PD7
// PB7 drives PD7
// Pin 7 drives PD7

void setup() {
  pinMode(PIN, OUTPUT);
}

void loop() {
  digitalWrite(PIN, HIGH);   
  delay(10);              
  digitalWrite(PIN, LOW);   
  delay(10);

if I do this is ASM using

[port] "i" (_SFR_IO_ADDR(PORT_X))

then it works fine

This has driven me round the bend !
can anyone help please ?

but yet it knows about port B because this works...

void setup() {
  DDRB = 11111111; //  pinMode(PIN, OUTPUT);
}

void loop() {
  PORTB = 11111111; // digitalWrite(PIN, HIGH);   
  delay(10);              
  PORTB = 00000000; //digitalWrite(PIN, LOW);   
  delay(10);  
}

If you are using the v1.6.3 branch of the repo, I suggest moving the question to that thread:

http://forum.arduino.cc/index.php?topic=321805.30

Don't forget to mention what variant you are using.