Support for the ATmega1284p in 1.6.x ?

[Phillip Stevens]

I need to ensure that the Arduino IDE fully supports the ATmega1284p MCU, for a current project.

Some time ago there were issues with the 1284p,with assigning the analogue pins correctly, getting PWM timers to work, and utilizing the Timer2 for a RTC.

It looks like there has been lots of work on the core to support the 1284p over the past few years, and some github references that cite no further need to build a special core for this MCU for 1.0.6. There has also been some discussion on the Arduino Forum about the issue.

I've looked into the 1.6.6 code and there certainly are lots of references to the 1284p now within the code.

Am I right in assuming that this is a dead issue, and that everything has been tested and there's nothing more to do?

If there are remaining issues, then the question is whether to solve them in a separate core, or try to solve them for all in the main core?

Thanks in advance for any feedback.

[Andrew Kroll]

Wouldn't that be a third party variant?

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.

--

Visit my github for awesome Arduino code @ https://github.com/xxxajk

[Kristian Sloth Lauszus]

Hi Phillip,

I already did this a long time ago. Please see: https://github.com/Lauszus/Sanguino.

Best Regards

Kristian Sloth Lauszus

[Victor Aprea]

Hi Phillip,

WildFire also is based on the ATmega1284P and works great.

https://github.com/WickedDevice/WildFire-Arduino-Core

... also includes an extension to Optiboot to allow it to bootload from an intel hex file stored in an external SPI flash in addition to serial (fyi only).

Regards,

Vic

Victor Aprea // Wicked Device

victor...@wickeddevice.com

T: @vicatcu

p.s. Goldilocks was an inspiration for me, keep doing cool open source stuff!

On Fri, Dec 11, 2015 at 7:06 AM, Phillip Stevens <phillip...@gmail.com> wrote:

--

[William Westfield]

> everything has been tested and there's nothing more to do?

Code is never completely tested with nothing more to do. :-(
What you really need to know is “Is the Arduino team committed to supporting 1284 in the “standard" core, or are you better off using one of the 3rd party cores?”

(I don’t know. Even if the 1284 has all the core code, there are still several different pinout “variants” floating around, and you may need 3rd party for that regardless of core code.)

BillW/WestfW

[Victor Aprea]

Bill, your points are good. FWIW, WildFire sets the core to sets the core parameter in boards.txt.

wildfireo3.build.core=arduino:arduino

So I'm in no way customizing the core for my board at least. All the pin / function mapping business happens in pins_arduino.h.

Cheers,

Vic

Victor Aprea // Wicked Device

victor...@wickeddevice.com

T: @vicatcu

[Pierce Nichols]

Writing and supporting a variant file is a much smaller job than doing
the same for a significant portion of the core. This is of interest to
me b/c I am considering using a 1284P for the realtime portion of the
next variant of the Hackerboat hardware
(https://hackaday.io/project/8522-hackerboat).

-p

> --
> You received this message because you are subscribed to the Google Groups "Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.

--
Pierce Nichols
Principal Engineer
Logos Electromechanical, LLC

[David Mellis]

I use the Atmega1284P on my DIY cellphone (http://diy-devices.com/devices/cellphone/) and connected devices (http://diy-devices.com/workshops/connected-devices/) projects and haven't run into any problems. 

[Phillip Stevens]

Yes Bill puts the issue forward precisely.

What you really need to know is “Is the Arduino team committed to supporting 1284 in the “standard" core, or are you better off using one of the 3rd party cores?”

I've written a 1284p variant previously in 2013 and, after juggling the pins assignments about, still found crippling compatibility issues. I should have written a special core, but I didn't.

That was then. This is now, and the Arduino core supports non 8/16 MHz FCPU. And has many 1284p defines for multiple hardware serial, analogue pins, and additional timers support. It all looks very good. And from what has been commented, it seems the arduino:arduino core is well suited for 1284p too.

So I guess or interpret that there is enough support already there, through the work of others, that using the existing pins assignment is sufficient together with the standard core. And that failing a formal opinion, I will just test and call out any problems should any arise.

Thanks again for the feedback.

[Phillip Stevens]

Interesting

Having a SPI flash stored application library is a great idea. I have a board with 256kByte EEPROM, so I'll look at how to use your solution.

I've ported the NASA EEFS to AVR, so that could be used to support loading code from a simple bootloader file system based library.

Lets discuss elsewhere.

P.

[Cano]

A couple of years ago I started playing with 1284, there already were some projects based on this chip, but they all had some issues, so I created this: https://github.com/cano64/mega1284duino

I haven't worked on that project since then unfortunately. I would be awesome if there was a full support in arduino core for this chip and all we would have to do would be to create our own variant file with pin definition.

[Phillip Stevens]

 

I haven't worked on that project since then unfortunately. I would be awesome if there was a full support in arduino core for this chip and all we would have to do would be to create our own variant file with pin definition.

From what I've seen over the past month of investigation, it certainly seems as if issues faced in 2013 have been completely resolved. It really looks as if there is full support available.

Historically (2013), I found:

• F_CPU was either 8MHz or 16MHz, no other options, and this was used for timing calculation for millis(). This is no longer the case, and a much finer grained timing calculation is in place, including specific support for devices with F_CPU over 24MHz (like the Goldilocks Analogue).

• Analogue pins had to be numbered less than 22, unless it was specifically a 2560 MCU. This was addressed in 2013 by forcing the pin numbering to keep the 8 analogue inputs at digital pin 14 to 21, but the issue has now been completely resolved and there are generally no requirements now as to which pin number is assigned.
  

I'm still to go through all of the Arduino IDE example sketches to find any additional subtle issues, and I expect to have done that within a few weeks.

One irreconcilable difference will be the Timer Inputs and PWM capable outputs, which are on different pins to the 328p MCU. That means that shields that rely on PWM outputs may need to have pins reassigned (hardware hack) to work properly if I/O pins on a 1284p MCU board are assigned "naturally" (i,e. in numerical order).

Specifically to the Goldilocks Analogue 1284p board, a revised Arduino IDE Variant files for Goldilocks Analogue using the Arduino core are available on Github. There are two different arduino_pins.h files available. The old_arduino_pins.h file has the pin numbering assigned naturally, the only exception is to get the SPI interface onto Uno pin equivalent numbering. The arduino_pins.h file additionally moves the analogue pin assignments to low numbered digital pins to avoid the 2013 pin assignment issue.

For interest, optional libraries to provide support for each of the advanced features of the Goldilocks Analogue are available in the Arduino IDE Library Manager.

• DAC Library (including IIR Filtering), using Timer 3.
• SPI SRAM and SPI EEPROM Library (including Ring Buffer solution).
• C90 Real Time Clock Library, using Timer 2.
• FreeRTOS Library, using the Watchdog Timer.
  

Gratuitous Arduino R3 compatible 1284p picture follows.

[Phillip Stevens]

From what I've seen over the past month of investigation, it certainly seems as if issues faced in 2013 have been completely resolved. It really looks as if there is full support available.

 

The only small issue I've found is that the 1284p (644p, etc) is not included in the Servo Library ServoTimers.h file, which has the impact of not utilising the Timer 3 present.

Should I generate a pull request?

[Massimo Banzi]

please do

m

[Phillip Stevens]

Done. 

Pull #4547

Thanks, Phillip