Jacob Christ wrote:
ok. I'm up for helping.
I'm not sure what you mean by:
porting the core to 1.5
From 0023 to 0100 many return types were changed as well as many other changes were made to core libraries that broke some older projects that relied on them. The chipKIT plan is to be able to maintain both the 0023 and 0100 functionality going forward, but this effort is not complete (nay even started). I'm not sure what is different between 0100 and 0150.
Ok. I understand what you mean now.
I'm very familiar with these.
I'm the developer for the glcd Arduino library. So I've dealt with this
as I make sure my library works on pre and post 1.x releases.
I ragged on the Arduino team pretty hard about it and even wrote them an open letter
about it in a thread. It was a hot thread over there for a while.
It was sad because much of what they did didn't have to be done the way they
did it, particularly going into the 1.0 release with no interrum release to test things.
Even sadder is that there are a few simple things that can be done in header files
to ensure backward compatibility with 90% or so of existing pre 1.x sketches.
Most of it is pretty trivial to deal with.
I'd recommend adding the few extra items to a few headers to create
the backward compatibility - which is something the Arduino team
was not open to. Why? I have no idea. It was in their own best interest
and was trivial to do.
Unfortunately, some items. like the serial.flush() stuff is a total
disaster. And there is no way to fix that. Their code is so broken
that flush() does not even work the same between HardwareSerial and SoftSerial.
The whole "Arduino" term as the Arduino guys defined it always
seemed very odd and frustrating to me.
They use the word "Arduino" to define everything
so there is no way to refer to individual components.
I tend to think more in blocks like
IDE, libraries, core code, compiler/tools
that can all be revved and updated independently.
One of things I think needs quite a bit of attention is dealing
with libraries. There needs to be a better way to have common libraries
that work across multiple cores that live in the same place.
I believe this is a good idea too. One of this biggest issues with trying to do this is that libraries can't use other libraries. This has caused Ardunio developers to not reuse abstractions but drop to ATMEL register level coding (say when a lib needs SPI). Although not difficult to make a cross platform library using ifdef's it is troublesome send changes upstream to Arduino if chipKIT core functionality is not at the same level at Arduino.
This issue of libraries that can't use libraries has also been identified by Arduino developers as a issue that needs to be addressed. (For making 8-bit Atmel libs work with DUE has the same issue).
Libraries not being able to call libraries is an artificial artifact of the way the IDE does
One of the biggest issues is include paths.
For example, some things could be resolved if the IDE simple include
a path to the libraries in its include path.
That way if a library needed to access another library class it would include that libraries
As it is today, since the include path does not include a path the libraries
libraries have no way to locate the other lbraries paths.
I have several ideas on how to resolve the library using other libraries issue.
Have you used git / github?
I've looked at and familiar with git
but I've not yet done a project with git/github but I have used:
sccs, rcs, rcs, cvs, svn, and mercurial on many projects
so I don't think it would be a big deal
However, I don't do Windows....
I guess I should say I can, I just really really don't like to
ever use it.
btw, I'm an embedded guy. Been doing this kind of stuff
personally and professionally on lots of different processors
and environments since the late 70's.