chipKIT® Development Platform

Inspired by Arduino™

Break away from hard-coded executables

Created Thu, 07 Mar 2013 15:33:31 +0000 by majenko

majenko

Thu, 07 Mar 2013 15:33:31 +0000

At the moment MPIDE is hard coded to use avrdude.

That sucks.

I want to use MPIDE on a board which won't be workable with avrdude.

What MPIDE really needs is an enhancement to the config system (maybe boards.txt, programmers.txt, whatever) which will allow you to specify the command to run to perform the uploading of the hex file to the target board.

Ideally it would replace all the current avrdude stuff and give a simple "myBoard.upload.command=..." setting, where the command can include special tokens for run-time replacement, for instance %B for the baud rate, %H for the hex filename, %P for the port name if one is needed, etc.

I have been having a dig in the source, and it looks like this should be a simple enough thing to do (though a big change nontheless), but as I am no expert in Java (never touched it, and to be honest I would rather keep myself pure and never touch it - I feel dirty just from looking) it's not something I could happily tackle.

EmbeddedMan

Thu, 07 Mar 2013 17:13:28 +0000

YES! The chipKIT development team has been discussing this quite a bit, for over a year now. I want it so that I can use the Microchip HIDBootloader.exe to bootload sketches onto my UBW32 board.

The Arduino developers have also been pondering this problem. They want to solve the problem in a generic way as well.

We (MPIDE) may be best served to let Arduino folks come up with a good solution, and then bring that method down into MPIDE.

*Brian

majenko

Thu, 07 Mar 2013 18:58:24 +0000

YES! The chipKIT development team has been discussing this quite a bit, for over a year now. I want it so that I can use the Microchip HIDBootloader.exe to bootload sketches onto my UBW32 board.

Very similar to what I want it for ;) Except I want to use pic32prog and the RetroBSD bootloader (which is based on MCP HID). [quote="EmbeddedMan" The Arduino developers have also been pondering this problem. They want to solve the problem in a generic way as well.

We (MPIDE) may be best served to let Arduino folks come up with a good solution, and then bring that method down into MPIDE. [/quote] Like that's ever going to happen ;)

If it's Arduino it's bound to be a half-arsed job that just works for them, like the rest of the Arduino software (and hardware come to that).

A single upload.command parameter which replaces all the current different upload. preferences with basic token replacements is all that's needed, and would give a completely 100% generic solution that is easy to implement. I have done similar in other systems time and time again, and it works well.

JTRelectronics

Sun, 24 Mar 2013 10:56:39 +0000

I too am also VERY interested in this and having been looking into the situation over the last few weeks.

The current chipkit bootloader is not very code efficient as it follows a protocol that just does not put 32-bit variables on naturally alined 32-bit boundaries forcing parameters to be handled as bytes. This bloats the bootloader somewhat and for PIC32 parts with only a 3K boot block it limits the amount of functionality available, even for hand coded MIPS16e assembler.

There are other issues too that I could point out but all these would be solved if custom bootloader drivers could be used.

To be sure there is no way I will even try to kludge fit what I have into the current arrangement...

I don't expect the chipkit team to be supporting every bootloader but a way to spawn third party bootloader drivers would be fantastic and allow a much greater range of hardware to be part of the chipkit family. :idea: :?:

majenko

Sun, 24 Mar 2013 11:33:46 +0000

I noticed the other day when ChipKit released their list of up-coming changes and priorities, that this was in the list to be done, on a medium priority.

That's good news for us all. I'll be able to use my custom modified MPHID based bootloader with MPIDE then :) It'll let me program with mphidflash, and even auto-reboot using special USB CDC commands as long as the firmware on the chip at the time supports it ;)

majenko

Wed, 10 Apr 2013 18:09:47 +0000

I have been having a play, and I think I have done it.

I have an extra text file in the hardware/pic32 directory, which contains bootloader commands:

mphidflash.command=mphidflash %V -r -w %H
mphidflash.verbose=-v

Then in the boards.txt I set the "upload.using=" entry to one of the bootloader.txt file entries:

prfm.upload.using=mphidflash

Then my system matches one with the other, does string replacements of the tokens (%H = hex file path, %V is whatever is in the .verbose entry if verbose compilation is on, etc), and executes that command.

It also supports xxx.command_windows, xxx.command_linux and xxx.command_macosx which are used in preference to the generic xxx.command.

At the moment it still adds tools/ (or tools/avr/bin if on Windows) to the beginning - that's hard coded in the function that does the executing and is needed for avrdude only, so that want to be nobbled ASAP ;)

If the upload.using doesn't match an entry it just goes on as normal and uses avrdude.

Now I need a shower after playing in Java.

majenko

Wed, 10 Apr 2013 21:48:35 +0000

Hmmm..... I have just run up against a small stumbling block that I really don't understand...

If I try and use avrdude through my new system it doesn't reboot the board for me - I have to press the reset button. Using the normal embedded way of calling avrdude, it resets the board fine.

The command lines are (as far as I can tell) exactly the same apart from the number of -v entries for verbose (I don't want it that verbose), and the order of the arguments.

Is there something special that happens to the serial port when calling avrdude? I can't see anything, and anyway my system is run from pretty much the same place in the code as the avrdude executable.

It makes no sense - unless it's purely the order of the arguments that matters...?

Edit: Nope, something special must be happening. If I copy and paste the generated avrdude command for the normal embedded version and run it from a terminal it doesn't reboot the board ... ? Why? What is special about it?

majenko

Thu, 11 Apr 2013 08:50:03 +0000

I have done more digging and tracing of the flow of the software, and I can find absolutely no reason for this at all. Both instances are executed in the same way with the same parameters from within the same function, yet they behave differently.

Btw, Linux, uno32, git repo latest.

majenko

Thu, 11 Apr 2013 09:28:20 +0000

Ok, this is strange. This morning I fire up my code and it all works fine.

I am now completely confuzzled.

Ah well, it works now, so I'll stop worrying. Now to see about cleaning it all up and giving it some real testing.

majenko

Thu, 11 Apr 2013 10:15:06 +0000

In other news...

I have got so annoyed with the size of the boards menu (and the fact that you can't get at the lower portion of it on my computer), that I have implemented a "group" entry in the boards.txt file - groups boards together in submenus. Makes it much much cleaner and easier to find your desired board. I'll push it up to my fork in due course along with my bootloaders.txt system for possible pulling into the master repo (if ricklon likes it).

mikes

Thu, 11 Apr 2013 11:13:11 +0000

Good Work I was thinking more like a favorites menu where you can add the boards you want from the full list that way the average user would have only one or two. Since you have done something and I haven't yours is better :) I just wanted to make the suggestion.

Mike

majenko

Thu, 11 Apr 2013 11:16:20 +0000

Heh... I don't think the IDE as it stands is really geared towards such an advanced thing as favourites.

I have pushed the changes, just waiting for ricklon to get out of bed and see it ;)

Some time soon on my hitlist is the cruddy sketchbook menu. Mine is overflowing and I can only get at about 2% of the entries in it.

I am thinking an MRU menu is urgently needed.

majenko

Thu, 11 Apr 2013 21:50:44 +0000

Right... back to the topic at hand.

I now have it dynamically calculating the "tools" location depending on where it can find the file you are trying to execute.

Given the file "avrdude", it first looks for it as (for example):

hardware/pic32/variants/Uno32/tools/avrdude

And if not found, it then tries

hardware/tools/avrdude

Given the file "avr/bin/avrdude" (the windows command line) it first looks at (on a windows machine):

hardware/pic32/variants/Uno32/tools/avr/bin/avdude.exe

Then

hardware/tools/avr/bin/avrdude.exe

If it's not found, it aborts and tells you the command is not found. If it is found, the token replacement (of which there is now more) is performed, including replacing %T with the tools path where the executable was found (so either hardware/pic32/variants/Uno23/tools/ or hardware/tools/ from the above examples).

This now means that you can bundle a bootloader program in with the board variant. One step closer to a single directory for all the config for a new board.

Oh, and the current list of tokens:

%H = Filename of hex file (including path) %P = Port name as selected in menu %B = Baud rate %V = Verbose flag if verbose turned on %O = Protocol from boards.txt %T = Location of tools directory %M = CPU Specification

I haven't tested this on windows yet (the windows examples are pure theory), and I can't test on OS X as I don't have a mac, but it certainly seems to work on Linux. More testing is needed.

Any more thoughts on what should be added into this system, or what tokens should be available for the command line? At the moment the tokens are just ones I have needed to get mphidflash and avrdude working.

majenko

Thu, 11 Apr 2013 22:38:48 +0000

Wowzers... I now have per-variant configurations.

A variant folder can now have:

Board_Devs.h
Board_Data.c
boards.txt
bootloaders.txt
tools/whatever
myLinkerScript.ld

Yes, that's right - board configuration file, bootloader configuration file, AND a local variation linker script if needed (I know my mphidflash bootloader needs it).

Still needs more testing - I'll get round to booting up my windows machine in the morning and give it a thorough going over.

ricklon

Fri, 12 Apr 2013 13:15:35 +0000

The changes are looking good so far. --Rick

JTRelectronics

Sun, 14 Apr 2013 00:20:59 +0000

Thanks for your work on this majenko. It appears to be paving the way for smaller bootloaders and other tricks that are possible even in 3K bytes. 8-)