So I decided how difficult it would be to get chipkit (uno32 is what I've tested)
up and working on the latest Arduino IDE 1.5 (the one just released for DUE).
It wasnt' that bad. (I'm using Ubuntu 10.10)
Attached is a screen shot.

I grabbed the hardware/pic32 directory from a mpide release
as well as the hardware/tools/tools directory (for avrdude)
The real work was creating a platform.txt (vs platforms.txt) and boards.txt
to work with the Arduino 1.5 IDE
boards.txt was close (the arduino IDE does not use "::" for spaces)
The Arduino platform.txt format/syntax is actually much nicer than the mpide one
in that you can use real names rather than {0} {5} etc... It makes things MUCH easier
to read and correct.

I did have a few issues. The most notable was with autoreset during uploads.
It doesn't work from avrdude (the one that ships with mpide).
I'm guessing some RTS magic is still being done in mpide but is no longer being done
in Arduino 1.5 IDE.
NOTE: avrdude supplied with mpide doesn't work with autoreset from the commandline either
(same reason)

To get it to work, I had to create a bash wrapper script that does
stty hup and stty -hup to trigger the autoreset before calling the avrdude command.
While this probably would also work on MAC OS,
I'm not sure how to deal with it on legacy OS's like WIndows.
The real solution is to update avrdude to properly handle autoreset by creating a custom
type like the arduino guys did or perhaps change
the bootloader to use stk500v1 so it can use the "arduino" protocol option which
toggles DTR and RTS and then uses stk500v1.

Overall, it wasn't too bad.
After going through this, it further stresses a need to alter the tree to separate things
between different architectures more cleanly.
For examples, having a single "examples" at the top level rapidly becomes unworkable.
There needs to be a way to have architecture/core specific examples.
Same is true for libraries.
Arduino 1.5IDE handles library separation better than mpide does.
They have a top level set of libraries for "common" libraries that are for all architectures/cores
and then architecture/core specific libraries down under the individual architecture/core area.
The way mpide works today, there is no common area.
This library separation also needs to apply to the users area, and so far neither IDE is
addressing this.


--- bill

Oh, I guess I should have said I added everything under a "pic32" directory to keep everything
together. (all the s/w, tools etc..) that means adding it to Arduino IDE 1.5 is as easy
as merely dropping this pic32 directory into their tree .

Wicked cool... want to help with porting the core to 1.5? One of the guys that I work with has got most of the features of the 1.0 version of the SD lib working.

Jacob

ok. I'm up for helping.
I'm not sure what you mean by:


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.

Its a tough cookie to crack in that if the underlaying cores are allowed
to drift apart it can create issues for common libraries.

But I'm up for helping as long as everyone is on the same page
and all moving in the same/common direction to a well defined goal.

--- bill

The wireless upload via BT (IDE 1.5.1r2) - they use a new rxtxserial (itead?) which closes/opens the comm before upload in order to create a reset signal. Maybe useful for chipkit somehow.
http://blog.iteadstudio.com/application ... uino-bt-2/
http://arduino.cc/forum/index.php/topic,132006.0.html

I've seen some other "hacks" for auto-reset when native USB is used.
Things like setting the baud rate down to some magic level then back up again.


With respect to using signals that trip auto-reset at serial port open:
I really would like to see everything and everyone move away from using & depending on DTR for autoreset.
It is a total hack and doesn't allow the uploader/downlaoder or other applications
to have control of the auto-reset function.
RTS is a much better option as it allows the application to wiggle the line when it wants
*AFTER* the port is opened, to cause a reset vs having to accept
a reset happening every time the port is opened.
This allows auto reset to work when uploading but a reset will not happen when
you connect to the board for serial monitoring.

DTR was a kludge that was done early one to avoid having to put the few lines
of code in the uploader. But now I think it is time to leave it behind.

Why the Arduino guys are still using DTR in their AVR chip that does USB to serial
chip is beyond me. It is a simple change to the firmware to switch.

Looking forward,
there are also some things that could be done to improve the use of the serial port.
For example, if the IDE and uploader (avrdude or whatever tool) would open the serial port in non exclusive mode, then there could be multiple opens to the serial port.
The value of this would be that the IDE could have a serial connection open for the
serial monitor and leave it open for the download.
OR have the serial connection open for the serial monitor and have a [RESET] button
on the IDE that allowed the IDE to reset the board while still maintaining the serial
monitor open.

You cannot do this kind of stuff with DTR but you can with RTS.


--- bill

[/quote]


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.



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



Have you used git / github?

Jacob

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.



Libraries not being able to call libraries is an artificial artifact of the way the IDE does
itts builds.
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
header as:
#include <library/libraryheader.h>
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.


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.

--- bill

So typically the way we've been working that is easiest for everyone is like this:

1. You create your own github account (this does not cost anything).
2. You fork the MPIDE project into your github account.
3. You clone the project onto your computer.
4. You make changes in your local repo and push them to your github fork.
5. When your happy with your code you issue a pull request. This can be to others (such as myself) to check out what you have done or to the master MPIDE project to request that the changes get rolled into the master project.



I won't hold it against you. I don't use OS X. I do however bounce between Linux and Windows.



You sound like an ideal human too bad there are not more like you. I started programming in the early 80's and started learning embedded in the early 90's. In the early 70's I was wearing diapers.

Jacob