Updating the mighty-1284p core

It was brought up in another thread that the mighty-1284p core was a couple years behind. I'm not claiming to know what I'm doing here, but I did clone the repo and took a look through the commits. There are only a handful of the core files that are changed. Most of the changes concern the pins files, boards.txt, bootloader, etc., as opposed to the code in the "cores" directory. And the changes to those core files that are modified are not extensive.

I'm not in a position to make any promises, and I will continue to think about it, but it seems that an update would not be a huge amount of work. My purpose for this post was just to give that assessment of the situation and see how that matches with others' perceptions.

The core files that have changes are:

cores/standard/WInterrupts.c
cores/standard/wiring_private.h
cores/standard/Arduino.h
cores/standard/Print.h
cores/standard/wiring_analog.c
cores/standard/WString.h

I use the 1284, so a refresh would be nice although I have had no issues under 1.0.5r2.

Ray

Will you be targeting 1.0, 1.5, or both?

The "core" hasn't updated much, so probably there isn't a lot of "need" for an update to the 1284 core, either. An add-on version compatible with 1.5 build system would be nice, if that has "finalized." (but last I looked, it wasn't great for targets that wanted to share some of the "core" core code. (although perhaps one shouldn't care, and just do a separate set of core files anyway?))

[quote author=Coding Badly link=topic=235521.msg1695226#msg1695226 date=1398394006] Will you be targeting 1.0, 1.5, or both? [/quote]

I haven't had any need to go to 1.5 as of yet, actually been avoiding it. So I'd start with 1.0.5 (if and when I decide to do anything at all that is ;)) ... What are your thoughts on that?

Trying to think through what the process would be. How does this sound:

  1. Produce a diff between the 1.0 core files and the mighty-1284p core files.
  2. Review these vs. the 1.0.5 core files and make the corresponding changes.

That's a fairly manual approach. Wondering if I can use Git to just to a merge between the mighty-1284p core files and those of 1.0.5.

Just my opinion, but I see little issues with 1.0.5 and eventually 1.5.x will rule. Would the effort not be more appropriate to 1.5.x and then to back-port to 1.0.5 anything that is “critical”? I run 1.5.x on the UNO and Mega fine (and Pro Mini and Nano) and without issue. But for Pro Micro (Sparkfun), I have been using 1.0.5r2. I was successful in using the Attiny core (tiny85) with 1.5.x, so I’ve moved that profile over, too. My belief is that 1.0.5 is drying-up on the vine.

Ray

mrburnette:

[quote author=Jack Christensen link=topic=235521.msg1695813#msg1695813 date=1398434837]

[quote author=Coding Badly link=topic=235521.msg1695226#msg1695226 date=1398394006]
Will you be targeting 1.0, 1.5, or both?

I haven’t had any need to go to 1.5 as of yet, actually been avoiding it. So I’d start with 1.0.5 (if and when I decide to do anything at all that is ;)) … What are your thoughts on that?
<…>
[/quote]

Just my opinion, but I see little issues with 1.0.5 and eventually 1.5.x will rule. Would the effort not be more appropriate to 1.5.x and then to back-port to 1.0.5 anything that is “critical”? I run 1.5.x on the UNO and Mega fine (and Pro Mini and Nano) and without issue. But for Pro Micro (Sparkfun), I have been using 1.0.5r2. I was successful in using the Attiny core (tiny85) with 1.5.x, so I’ve moved that profile over, too. My belief is that 1.0.5 is drying-up on the vine.

Ray

[/quote]

Just my opinion, but I think the download arduino page ( http://arduino.cc/en/Main/Software ) is pretty clear that 1.5.x is a beta release to add support for the newer 32 bit boards and while still supporting 8 bit avrs, the current 1.0.5r2 is the current ‘official’ release for 8 bit arduino boards.

There will come a time most likely when both flavors will be combined into a single official release but most likely given a newer number as in 2.0. So my vote would be to use the 8 bit only 1.0.5x version to be the one to refresh the now old 1284 adaption.

Lefty

[quote author=Jack Christensen link=topic=235521.msg1695813#msg1695813 date=1398434837]What are your thoughts on that?[/quote]

Downloads of the Tiny Core are nearly split in half (55% for 1.5). In theory a core will work unmodified with both IDE versions but I have had terrible luck getting the Tiny Core to work that way. So, I decided all new work would be against 1.5 and I would only do maintenance against 1.0.

It was not a huge effort to get the Tiny Core working with 1.5. (A big thank you goes out to the Italians!)

The two IDE versions run well side-by-side so it isn't too much to ask of the audience to "just use version 1.X".

In other words, it really does not make much difference which IDE version is targeted but the initial effort should be against just one version.

Trying to think through what the process would be. How does this sound: 1. Produce a diff between the 1.0 core files and the mighty-1284p core files. 2. Review these vs. the 1.0.5 core files and make the corresponding changes. That's a fairly manual approach.

It is but I suspect the changes are fairly minimal and, in my experience, it usually pays off to put eyeballs on the source code. (The OpenSSL folks could certainly have used a few more eyeballs on their stuff!)

Wondering if I can use Git to just to a merge between the mighty-1284p core files and those of 1.0.5.

And provide you with a diff.

I'm assembling my Bobuino so I can hopefully more actively participate. I should be done tomorrow (Monday) evening.

My Bobuino is assembled. No smoke. No big mistakes soldering. Time to bootload it.

What did you# use for a bootloader? Something from the mighty-1284p core?

# “You” meaning anyone reading this post who has tried to install a bootloader on a '1284 based board.

I used Optiboot.

Works fine, except I was a bit surprised that it blinks pin 0 (PB0) when the reset button is pressed. The pins file indicates the LED is on pin 7 (PB7, SCK) so that’s where I put the LED on my board. Minor issue, I might recompile the bootloader if it keeps me up nights :smiley:

Did you build it yourself or find a ready-to-use copy?

At 115200 baud?

[quote author=Coding Badly link=topic=235521.msg1701765#msg1701765 date=1398792921] [quote author=Jack Christensen link=topic=235521.msg1701747#msg1701747 date=1398792050]I used Optiboot.[/quote]

Did you build it yourself or find a ready-to-use copy?

At 115200 baud?

[/quote]

https://code.google.com/p/optiboot/downloads/list

That’s maybe the results of the pins_arduino file your using then the bootloader? My boburino board the bootloader (optibot) blinks the same pin that the blink sketch uses?

A big thank you to @westfw!

Ouch. That’s a little embarrassing…

Members arduino.tiny, westfw
Your role Owner

[quote author=Coding Badly link=topic=235521.msg1701765#msg1701765 date=1398792921] [quote author=Jack Christensen link=topic=235521.msg1701747#msg1701747 date=1398792050]I used Optiboot.[/quote]

Did you build it yourself or find a ready-to-use copy?

At 115200 baud? [/quote]

The one that came with maniacbug's core. Which if I'm reading things right, doesn't match the source code, at least as far as which pin the LED is on. Maybe that's the only difference.

Yes, 115200 baud.

I'll post the one I use, blinks SCK just like an Uno. Is on a different computer. Just 3 quick flashes I think.

The Bobuino has the on-board LED on SCK / B7. Where is the LED on other boards? Jack, did you also put the LED on B7?

[quote author=Coding Badly link=topic=235521.msg1702392#msg1702392 date=1398836921] The Bobuino has the on-board LED on SCK / B7. Where is the LED on other boards? [/quote]

Unknown.

Jack, did you also put the LED on B7?

Yes. (But I'm not necessarily married to the idea, my boards are just for prototyping and testing.)

Jack, have you been using the Bobuino board entry to program your board?

I suggest these fuse settings for '1284 boards...

bobuino.bootloader.low_fuses=0xF7
bobuino.bootloader.high_fuses=0xD6
bobuino.bootloader.extended_fuses=0xFD

Full Swing Oscillator; Start-up time: 16K CK + 65 ms; Crystal Osc.; slowly rising power; [CKSEL=0111 SUT=11]

Boot Reset vector Enabled (default address=$0000); [BOOTRST=0]

Boot Flash section size=512 words Boot start address=$FE00; [BOOTSZ=11]

Preserve EEPROM memory through the Chip Erase cycle; [EESAVE=0]

Serial program downloading (SPI) enabled; [SPIEN=0]

Brown-out detection level at VCC=2.7 V; [BODLEVEL=101]

Thoughts?