chipKIT® Development Platform

Inspired by Arduino™

I guess I'm here...

Created Thu, 11 Apr 2013 20:47:25 +0000 by majenko

majenko

Thu, 11 Apr 2013 20:47:25 +0000

I wasn't planning on working on chipKIT development, but it seems I have inadvertantly started doing things in the internals of the IDE...

So... I have kind of tackled task #5 (boards menu) in that the boards menu now has submenus in it to make it much easier to find your board, and I have a local version in testing for task #9 (command line programmers) that I intend to push up in the next day or so. Just gotta test it on a few more operating systems.

Since I have been platying wth the boards.txt system already I am thinking I may tackle task #10 (boards.txt in variants folders) as well. I am thinking as well to make things in the variants as overrides for all other files, including a variants-level tools folder that will be picked in preference to the system tools dir (if the file requested is in there).

majenko

Thu, 11 Apr 2013 22:43:41 +0000

Ok, I have a working (on Linux at least) task #10 solution.

It has the boards.txt, the bootloaders.txt, the tools directory, and the linker script all able to be put into the variant directory and it picks them up.

I'll test more tomorrow on my noisy Windows machine, and see about pushing it p by the weekend.

Jacob Christ

Sat, 13 Apr 2013 02:49:45 +0000

Kudos and thank you.

Jacob

majenko

Sat, 13 Apr 2013 09:44:43 +0000

Call me sick if you like, but I am actually quite enjoying programming Java.

Considering I'd never touched it before now on general principal (it's not the language I'm against, but how the language gets abused), it's actually been quite pleasurable to work with.

Right now I am experimenting with a complete ground-up re-working of the whole boards / platforms system. Separating out the "variants" from the platforms (Target), and making them into "boards" instead. These boards (the Board object) will be in their own separate area away from the Target structures, and will internally point to the Target for the Board. The Board object will contain all the code to deal with board level things, like the bootloading process. So, a user has a new board, they just drop their board folder into ~/sketchbook/boards (or something similar - not decided yet) and it picks it up and ties it in with the right Target.

That is if it all works ;)

Should clean up the internals a little methinks.

Jacob Christ

Sat, 13 Apr 2013 13:52:20 +0000

I have been an advocate of making it easy to add a new board in this manner for sometime. My lack of time is the only thing that has kept me from working on this myself. What would be really great is if mpide could hit a web site to look for new variants. It should be able to support hundreds of variants imho and yet allow for easy picking such as how mikes suggests.

Also another issue that I don't have answer for is how to support different versions of boards, maybe its a simple as just putting a rev in the variant name. We currently have three different revs of the Quick-240 in the field and all have slightly different variants. Additional the variant for the board currently is mostly a clone of the Max32 yet could benefit from refactoring the pin out (creating yet a fourth rev).

Libraries also suffer from this rev issue as well. In addition we like to track our libs with out app all in git. The inability of mpide to handle libs properly in the project directory is very frustrating.

Jacob

majenko

Sat, 13 Apr 2013 14:07:22 +0000

My experiments seem to be being successful...

I have completely done away with AvrdudeUploader.java and Uploader.java and replaced them with a generic Board.java. Works a charm. Much cleaner. There's also a boardsTable with all the boards listed in it within Base.

I don't have any bootloader burning support yet though. That needs abstracting into some config file(s) somehow - maybe as part of the bootloaders.txt file - so that different ways of burning the bootloader (e.g., with a pickit2 and pic32prog) can be easily supported.

I'm thinking I may push this experiment up to my own repo as a special branch so that people can take a look and experiment with it, see what they think.

[url]https://github.com/majenkotech/chipKIT32-MAX/tree/new_board_structure[/url]

When you checkout / pull be sure to specify the new_board_structure branch...

majenko

Sun, 14 Apr 2013 10:58:01 +0000

Fair play, this is a bigger task than I was thinking - It's like wallpapering while drunk ;)

No offence intended to anyone at all - this is just what happens when software evolves over the years when worked on by different teams, each with different ideas and priorities (first Processing, then Arduino, then chipKIT).

My "new_board_structure" branch's changes are now too numerous to list. But in summary (i.e., those that I can remember off hand ;) ):

The system is leaning towards being "board centric". Most requests for file / folder locations are made through the board, and the board passes it on to the target if needed. Libraries, examples, bootloaders, etc all go through the board.

I have overhauled the menus somewhat, mainly due to the fact that most stuff now goes through the Board class, so the imports menu is cleaned up, the examples menu has proper sub-menus, the menu labels (where appropriate) now actually make sense, etc.

The compiler system is starting to make more sense. A key in the platforms.txt file (compiler.masterinclude) specifies what the "head of the sketch" include file should be - WProgram.h for pic32 core, and Arduino.h for avr core. This is really a transitional feature to get Arduino 1.0.4 core working for avr targets. Once the pic32 core is up to version 1.0.x it can be dropped as that would use Arduino.h. Well, it could stay I guess, for flexibility...

I have started a proper bootloader burning system. Instead of it burning for the current board with the programmer you select in the menu (which is always a bit dodgy, especially if you are programming with Arduino ISP to a different target board to the one you loaded the programmer sketch on), it brings up a proper window to select the target board and the programmer you want to use. Doesn't do anything yet, but it's a start ;)

Oh, and I have tested this commit as compiling from clean, which I suspect some of the earlier ones didn't... :oops:

Oh, and for reference:

$ git clone -b new_board_structure git://github.com/majenkotech/chipKIT32-MAX.git

majenko

Sun, 14 Apr 2013 21:19:44 +0000

ooooh.... I just used my new version of MPIDE to burn the bootloader to my UNO32 using a pickit2 and pic32prog... Smooth as silk.

I just looked at the git commit statistics for this branch...

Showing 921 changed files with 225,671 additions and 15,582 deletions.

I think I've been a tad busy...

W4GNS

Mon, 15 Apr 2013 03:17:50 +0000

I think I've been a tad busy...

Yup, and we appreciate your work !! :D

majenko

Mon, 15 Apr 2013 09:10:07 +0000

Yup, and we appreciate your work !! :D

Appreciation is all very well (my bread and butter ;) ) but it can't beat a bit of feedback from the powers that be to say if I'm heading in the right direction and this isn't just an exercise in learning java / mpide internals (which is still a worthwhile activity) :P

It's such a departure from the way it's all working at the moment, and the changes are so big, that it may be too over the top and extreme for mainstream adoption ;)

If you like I could create some test packages for Linux and Windows (I don't have OS X, and still no feedback on my question about cross-compiling / packaging for OS X on Linux) so you don't have to have a development system set up to try it out...

[url]http://autobuild.majenko.co.uk/mpide/[/url]

Edit: I have "managed" to compile mpide for OS X on Linux. It won't package, due to a lack of DMG manipulation tools, but the .app is there. It might work, or it might not. Being Java it should work (since that is the whole original point of Java), but who knows...? Give it a try, let me know.

Jacob Christ

Mon, 15 Apr 2013 15:07:42 +0000

Here are some core ideas (not all of them) but it would be good to start this discussion and then we can formalize them on the chipKIT.net web page.

  • The spirit of chipKIT is to stay inline with the spirit of Arduino. That is making it easy for the new user or non-technical user. So if the changes don't confuse a new user or an existing user (that is new to embedded development) then we are okay. EDIT: Can a user download a new version of MPIDE and it works as well or better than a previous version?

  • chipKIT is a fork of Arduino project and we don't have to stay compatible, but doing so may help us improve MPIDE by being able to pull innovations from Arduino (and visa versa in that changes that started in MPIDE escalated development of Due)

  • What your doing is inline with ideas that have floated around for awhile. May not have been the way I would have done it, but its hard to argue with working.

  • I'm a lone voice and these are only my opinions.

Jacob

majenko

Mon, 15 Apr 2013 15:25:16 +0000

Here are some core ideas (not all of them) but it would be good to start this discussion and then we can formalize them on the chipKIT.net web page.

  • The spirit of chipKIT is to stay inline with the spirit of Arduino. That is making it easy for the new user or non-technical user. So if the changes don't confuse a new user or an existing user (that is new to embedded development) then we are okay. EDIT: Can a user download a new version of MPIDE and it works as well or better than a previous version?

Ideal outcome of all this: The user downloads a new version, doesn't see any immediate difference, and wonders why they upgraded ;)

I have spent a long time on the Arduino forums, so I know pretty well the abilities of the average Arduino user. Most of the changes are entirely beneath the hood and the average user shouldn't even know they're there. All they'll know is that it works, and that they can download a "board" from a third party and drop it into their boards folder and it "just works". Should make things simpler for them - means they never have to edit config files, etc.

Some of the changes take an existing system and improve upon it whilst fitting it into the new internal structure - such as the bootloader burning system. With it now providing a proper GUI for selecting what to burn and what with it should be far more intuitive than the old system.

  • chipKIT is a fork of Arduino project and we don't have to stay compatible, but doing so may help us improve MPIDE by being able to pull innovations from Arduino (and visa versa in that changes that started in MPIDE escalated development of Due)

Ideal situation: Arduino forks MPIDE :D

Compatibility with Arduino is important to me - at least as far as the end user is concerned. That's why I have upgraded the AVR core to 1.0.4 and ensured that sketches compile with it. I use both Arduino and chipKIT boards, and being able to reliably use one single environment for them both would be a real bonus.

  • What your doing is inline with ideas that have floated around for awhile. May not have been the way I would have done it, but its hard to argue with working.

I am always open to suggestions and ideas. This current iteration of my code is just my own personal thoughts about how the goals* can be achieved. It may not be the best way, nor the most efficient (remember, I am new to Java, so don't know all the "wonderful" things it can do), so input from others both with Java experience, MPIDE internals experience, and even just end user experience (that last may be one of the most important of all) is vital.

  • I'm a lone voice and these are only my opinions.

Everyone's opinions are unique, and always backed by a lone voice. Get lots of lone voices together and you either have a committee (in which case you have 99% arguing and 1% output), or a choir (in which case it's pretty much all output ;) ). I'm hoping for the choir - I've been told I have a good tenor voice :D

=M=

  • Goals as I see them: 1. API compatibility with Arduino 1.x. 2. Simple to add new boards. 3. Simple to add new target platforms. 4. Simple to install and use. 5. Doesn't confuse someone moving from Arduino to chipKIT. If 2 and 3 can be done with a simple drag-and-drop of folders, then that is simple enough for me.

driedeker

Tue, 16 Apr 2013 18:14:23 +0000

just tried to get the widows version but got a no permission reply

majenko

Tue, 16 Apr 2013 18:18:06 +0000

Try again - just fixed it...

ricklon

Tue, 16 Apr 2013 21:39:26 +0000

Majenko, I love the fact that you are making Linux packages. I was wondering if that can be automated into the build.xml file? If not I'd like to make a basic procedure to get it going.

Also, I want to release the next official MPIDE ASAP. The changes you made recently I'm totally happy with. I think the uploader and other changes would go in the next release.

--Rick

majenko

Tue, 16 Apr 2013 21:50:27 +0000

I already have the deb creation in my recent build.xml (ant deb -> deb-linux) - grab it from my repo. It's mainly a copy of the dist-linux target with very basic deb creation instead of tarballing. There's some files in linux/dist/usr that will need to be included too. I could work on adding it to master and creating a pull request for it if you like.

I'm not expecting anything I have been doing recently to be going straight into an MPIDE release (except the stuff I've done pull requests for) - all this "new" stuff is mainly experimental and for a final release I am expecting some bits to make the cut and others not. I am always having ideas and thoughts, and the best way for me to work them out is to implement them. Anything that comes of it that's desirable can be taken at will, and anything not suitable can be scrapped. It's sort of the sum total of the strangeness that goes on in my head ;) Explore what I have done (am doing), and let me know what you like and what you don't like. There's quite a lot in there now...

The most recent additions:

  1. Per-board libraries. You can now add libraries to a board folder so they only show up if that board is selected. Allows you to bundle support libraries for the hardware on your board with the board definition. Great for custom hardware.
  2. Sketchbook menu broken into chunks. My sketchbook menu was useless as it had more entries in it than could be displayed. Now it displays only 20 entries in a menu with a "More..." menu at the top which opens another sub-menu. Makes it actually usable.

Oh, btw, as well as that download location I also have the debs on my development apt repository:

deb http://autobuild.majenko.co.uk/dist/ <distribution> main

(eg deb http://autobuild.majenko.co.uk/dist oneiric main)

gpg key (add with "sudo apt-get add autobuild.key): [url]http://autobuild.majenko.co.uk/dist/autobuild.key[/url]

Then you can apt-get update, and apt-get install mpide (and it does the dependencies too).

driedeker

Wed, 17 Apr 2013 06:20:00 +0000

Have test on win xp sp3 and chipkit max , uploads the first time to io board but failes from then onwards. reset max32 and same problem. here is what appears at download will test on mega2560 next

Binary sketch size: 36504 bytes (of a 520192 byte maximum) Communications subsystem: [null] [C:\mpide-0023-windows-20130415-23-nbs\hardware\tools\avr/bin/avrdude] [-cstk500v2] [-P\.\COM7] [-b115200] [-D] [-Uflash:w:C:\DOCUME~1\DRIEDE~1\LOCALS~1\Temp\build4091754129542664626.tmp\driedekerV4_9.cpp.hex:i] [-CC:\mpide-0023-windows-20130415-23-nbs\hardware\tools/avr/etc/avrdude.conf] [-q] [-q] [-p32MX795F512L]

majenko

Wed, 17 Apr 2013 08:11:14 +0000

When it's failing, try the upload in verbose mode (shift and click) for more detail. Also, run the IDE from a command prompt window so that you can get more debgging information.