Chipkit up and running on Arduino 1.5 IDE

Created Wed, 31 Oct 2012 19:30:07 +0000 by bperrybap

bperrybap

Wed, 31 Oct 2012 19:30:07 +0000

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 .

Jacob Christ

Sun, 18 Nov 2012 01:50:38 +0000

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

bperrybap

Sun, 18 Nov 2012 04:36:23 +0000

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

porting the core to 1.5

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

pito

Sun, 18 Nov 2012 11:57:11 +0000

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-note/warless-program-your-iteaduino-bt-2/ http://arduino.cc/forum/index.php/topic,132006.0.html

bperrybap

Sun, 18 Nov 2012 18:12:28 +0000

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

Jacob Christ

Sun, 18 Nov 2012 18:30:45 +0000

[/quote]

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

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.

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

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

Have you used git / github?

Jacob

bperrybap

Sun, 18 Nov 2012 20:15:01 +0000

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.

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

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.

--- bill

Jacob Christ

Sun, 18 Nov 2012 21:04:18 +0000

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

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.

However, I don't do Windows.... I guess I should say I can, I just really really don't like to ever use it.

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

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.

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