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?))
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:
Produce a diff between the 1.0 core files and the mighty-1284p core files.
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.
[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.
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:
Produce a diff between the 1.0 core files and the mighty-1284p core files.
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.
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
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?
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.
Full Swing Oscillator; Start-up time: 16K CK + 65 ms; Crystal Osc.; slowly rising power; [CKSEL=0111 SUT=11]
This seemed to be the best and simplest 'fix' for people having problems with serial data problems on the first uart pins. Problem was sensitive to board layout and there were other hardware fixes that were effective, but simply using the full swing option seems to be the best method and doesn't cost anything and is board agnostic.
I'm not sure it will help, and sorry if this was posted before (I didn't follow any linked threads) but I was doing some searches today and ran across a blog posting that has new core files for the 644P/1284P based on 1.5.6-R2.