Go Down

Topic: Mighty-1284P core updated for Arduino 1.0.6 (Read 24546 times) previous topic - next topic

oric_dan

I find it easier to just use the chips interchangeably after the bootloaders have been burned, but I guess you concur that a 'new' variant would need be defined when doing it as you described.

legonick22

Is your folder hardware/mighty-1284p/avr/ or do you still have the /arduino-1.6.0/hardware/atmegaxxx4p/AVR/... as your earlier post?
It was the latter, but I changed it to the former. Still gives the same error.
My mother said I could be anything I wanted. But I don't want to be anything I wanted. I want to be an engineer!

oric_dan

I may be wrong, but I don't think there is any support at all for the 324 chip in the IDEs. You can't use 1284 core or variants.

legonick22

@oric_dan I have been able to burn bootloaders to the 324p in 1.0.6 just fine - it's 1.6 that's my issue.
My mother said I could be anything I wanted. But I don't want to be anything I wanted. I want to be an engineer!

oric_dan

Quote
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.
Code: [Select]
#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__)

legonick22

So... why does it work for 1.0.6 but not 1.6?
My mother said I could be anything I wanted. But I don't want to be anything I wanted. I want to be an engineer!

oric_dan

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.

legonick22

#67
Mar 03, 2015, 06:22 pm Last Edit: Mar 03, 2015, 06:25 pm by 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!
My mother said I could be anything I wanted. But I don't want to be anything I wanted. I want to be an engineer!

liuzengqiang

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 ;)
Serial LCD keypad panel,phi_prompt user interface library,SDI-12 USB Adapter

pico

#69
Mar 03, 2015, 11:59 pm Last Edit: Mar 04, 2015, 12:17 am by pico
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.

   [vendor-id]:[architecture]:[core-id]

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

liuzengqiang

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?
Serial LCD keypad panel,phi_prompt user interface library,SDI-12 USB Adapter

pico

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

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

liuzengqiang

So "everything is included" can be translated into (-arduino,+arduino) or Arduino considering the arduino symbol already includes - + and infty.
 ;)
Serial LCD keypad panel,phi_prompt user interface library,SDI-12 USB Adapter

GertSanders

#74
Mar 15, 2015, 12:20 pm Last Edit: Mar 15, 2015, 04:20 pm by GertSanders
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 :-)

Go Up