Created Sat, 21 May 2011 18:10:25 +0000 by Mark
Sat, 21 May 2011 18:10:25 +0000
The software is now ready to download
https://github.com/chipKIT32/chipKIT32-MAX/downloads
All 3 OS versions are ready to go (Mac, Windows, Linux)
As far as how it works, the core files and library files of course have been re-written to use pic32 hardware instead of avr hardware
The ide has been modified to have a platforms.txt in addition to the boards.txt. This allows multiple compilers to be used. The design idea is that any gcc compiler can now be made to work just by adding a text file (platforms.txt) Everything about the compiler is driven by that file.
The biggest difference in what we did compared to what maple did, is now you can select back and forth between AVR and PIC32 without changing programs. Just go up the boards menu and select a different board. Mega2560, Arduino-UNO, chipKit-MAX32 or chipKit-UNO. and click download. Thats all there is to it.
We are calling it MPIDE for Multi-Platform IDE
For anyone that has looked inside of the java ide code, the section that drives the compiler has been COMPLETELY re-written. This was a MAJOR undertaking.
I am at Maker fair this weekend if anyone wants to stop by and see it and learn more how it works
Mark lead programmer in the pic32 chipkit/Arduino project
Sun, 22 May 2011 23:46:22 +0000
A deeply impressive effort! I have only just started playing with this - will you be at the New York Maker Faire? I look forward to meeting you. Rob D
Mon, 23 May 2011 09:59:39 +0000
Hi, A question: the Arduino Library are fully compatible with this device? I developed a library for a GSM module, I can use my library in your device?
Mon, 23 May 2011 21:38:58 +0000
Hi, A question: the Arduino Library are fully compatible with this device? I developed a library for a GSM module, I can use my library in your device?
According to the specs on the device your GSM module SHOULD work. And at 20x the speed :) but then again I can't get MPIDE running so I have no idea if this works in reality :( -Matt
Tue, 24 May 2011 01:46:56 +0000
Matt
What seems to be the problem? what OS are you using. On the plane back today, Rick fixed a couple of issues, mainly with Linux.
Mark
Wed, 25 May 2011 04:05:39 +0000
Is there documentation on how to use "platforms.txt" ?
Wed, 25 May 2011 21:13:10 +0000
I'll put that together. Most of the documentation is my developer docs, and in the Arduino Developer mailing list.
Fri, 27 May 2011 23:14:41 +0000
This is an early description of the changes. I'll be cleaning this up.
The code for the following information is here, and functional. The major code changes are in place. I'm fixing a couple of path issues for windows, and small changes: https://github.com/ricklon/Arduino/tree/compilerupdate
A rewrite of Compiler.java to have global configuration objects, the takes the following preferences in order and overlays them into configPreferences HashMap. Also, cleaned up the properties so that empty strings appear instead of nulls in the HashMap values.
The sequence of compilation in the code is now clear. // 0. include paths for core + all libraries this.includePaths = new ArrayList(); getIncludes(this.corePath);
// 1. compile the sketch (already in the buildPath)
compileSketch(avrBasePath, buildPath, includePaths, configPreferences);
// 2. compile the libraries, outputting .o files to:
// <buildPath>/<library>/
//Doesn't really use configPreferences
compileLibraries(avrBasePath, buildPath, includePaths, configPreferences);
// 3. compile the core, outputting .o files to <buildPath> and then
// collecting them into the core.a library file.
compileCore(avrBasePath, buildPath, this.corePath, configPreferences);
// 4. link it all together into the .elf file
compileLink(avrBasePath, buildPath, includePaths, configPreferences);
// 5. extract EEPROM data (from EEMEM directive) to .eep file.
compileEep(avrBasePath, buildPath, includePaths, configPreferences);
// 6. build the .hex file
compileHex(avrBasePath, buildPath, includePaths, configPreferences);
==== The key to make toolchains, ldflags, ldscripts, and different compile optons is held in platforms.txt
hadware/yourchiptypehere/platforms.txt contains: The compile recipe/template for each step Then the overrides needed to make compilation occur properly.
example: avr.recipe.c.o.pattern={0}{1} {2} {3}{4} -DF_CPU={5} -D{6}={7} {8} {9} -o {10} avr.recipe.cpp.o.pattern={0}{1} {2} {3}{4} -DF_CPU={5} -D{6}={7} {8} {9} -o {10} avr.recipe.ar.pattern={0}{1} {2} {3}{4} {5} avr.recipe.c.combine.pattern={0}{1} {2} {3}{4} -o {5}{6}.elf {7} {8} -L{9} -lm avr.recipe.objcopy.eep.pattern={0}{1} {2} {3}.elf {4}.eep avr.recipe.objcopy.hex.pattern={0}{1} {2} {3}.elf {4}.hex
######################################################## avr.name=Atmel AVR (ATmega/Xmega) #avr.compiler.path=/usr/local/CrossPack-AVR/bin/ avr.compiler.c.cmd=avr-gcc avr.compiler.c.flags= -c -g -Os -w -ffunction-sections -fdata-sections avr.compiler.c.elf.flags= -Os -Wl,--gc-sections avr.compiler.S.flags= -c -g -assembler-with-cpp avr.compiler.cpp.cmd=avr-g++ avr.compiler.cpp.flags= -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections avr.compiler.ar.cmd=avr-ar avr.compiler.ar.flags=rcs avr.compiler.objcopy.cmd=avr-objcopy avr.compiler.objcopy.eep.flags= -O ihex -j .eeprom --set-section-flags=.eeprom=alloc,load --no-change-warnings --change-section-lma .eeprom=0 avr.compiler.elf2hex.flags= -O ihex -R .eeprom avr.compiler.elf2hex.cmd=avr-objcopy avr.compiler.ldflags= avr.compiler.cpudef=-mmcu= avr.compiler.upload.cmd= avr.compiler.upload.flags= #avr.library.path=/Applications/Arduino.app/Contents/Resources/Java/hardware/arduino/cores/arduino
=====
These defaults placed in platforms.txt, can be overridden by boards.txt so that your board can override the things it needs, and not have to override everything. No duplication in process needed.
In order to keep as much compatibly as possible and use templating I used the MessageFormat object to take care of the substitutions. This is really flexible, but most likely needs to be revisited a little. Something like stringProperty library might be a prefect match, but we would lose compatibility with Java 1.4. Also, dynamic arguments need to be implemented, but the current model support using less without throwing errors.
How MessageFormat templating works: ====example===
throws RunnerException
{
String baseCommandString =
configPreferences.get("recipe.objcopy.eep.pattern"); String commandString = ""; MessageFormat compileFormat = new MessageFormat(baseCommandString); String objectFileList = "";
Object[] Args = {
avrBasePath,
configPreferences.get("compiler.objcopy.cmd"),
configPreferences.get("compiler.objcopy.eep.flags"),
buildPath + File.separator + primaryClassName,
buildPath + File.separator + primaryClassName
};
commandString = compileFormat.format( Args );
execAsynchronously(commandString);
}
====
Now that I've got this in place the code shows where things can be optimized, allows for a lot more extendibility. New toolchains don't require a recompilation. Tweaking flags, and setting for the compile process don't require recompile. You can just follow the format, and have news chips, toolchains, and tweaks ready to go.
Fri, 27 May 2011 23:28:01 +0000
For AVR here's the example. The reason that there are numbers instead of property names was I wasn't sure which version of Java was the min version. Currently, the MessageFormat solution uses numbers for arguments. I would like use a library from string named propoerties, but then the min version would Java 1.5.x. It'll be a lot more readable updating to it.
The reason for :: is that at I had to break each argument into an array because of the way that Java runtimeexec (string) breaks everything on space. What I think would be a real solution is to conver the value to JSON. That way it would be annotated as an array from the start. Other option is to find a way to escape space for paths, and arguments. Then the lines could remain as strings.
########avr compile pattern ########## #avr.recipe.c.o.pattern={0=compiler.path}{1=compiler.c.cmd}::{2=compiler.c.flags}::{3=compiler.cpudef}{4=build.mcu}::-DF_CPU={5=build.f_cpu}::-D{6=ARDUINO}={7=Base.REVISION}::{8=-I/INCLUDE_PATHS}:: {8=SOURCE_NAME}::{9}::-o{10=OBJECT_NAME} #object name seems to have build path in it. avr.recipe.c.o.pattern={0}{1}::{2}::{3}{4}::-DF_CPU={5}::-D{6}={7}::{8}::{9}::-o::{10}
##compile cc object files #avr.recipe.cc.o.pattern={0=compiler.path}{1=compiler.cc.cmd}::{2=compiler.c.flags}::{3=compiler.cpudef}{4=build.mcu}::-DF_CPU={5=build.f_cpu}::-DARDUINO={6=Base.REVISION}::{-7=I/INCLUDE_PATHS}:: {8=SOURCE_NAME}::{9}-o{10=BUILD_PATH,OBJECT_NAME} avr.recipe.cpp.o.pattern={0}{1}::{2}::{3}{4}::-DF_CPU={5}::-D{6}={7}::{8}::{9}::-o::{10} ##create archives #avr.recipe.ar.pattern={0=compiler.path}{1=compiler.ar.cmd}::{2=compiler.ar.flags}::{3=BUILD_PATH}{4=CORE_NAME=core.a}::{5=BUILD_PATH,OBJECT_NAME} avr.recipe.ar.pattern={0}{1}::{2}::{3}{4}::{5}
##combine gc-sections, archives, and objects #avr.recipe.c.combine.pattern={0=compiler.path}{1=compiler.c.cmd}::{2=compiler.combine.flags}::{3=compiler.cpudef}{4=build.mcu}::-o {5=BUILD_PATH}{6=SOURCE_NAME}.elf::{7=BUILD_PATH}{8=SOURCE_NAME}.o::{9=BUILD_PATH,CORE_NAME=core.a}::-L{10=BUILD_PATH} -lm #avr.recipe.c.combine.pattern={0}{1}::{2}::{3}{4}::-o::{5}{6}.elf::{7}{8}::{9}::-L{10}::-lm avr.recipe.c.combine.pattern={0}{1}::{2}::{3}{4}::-o::{5}{6}.elf::{7}::{8}::-L{9}::-lm
##create eeprom #avr.recipe.objcopy.eep.pattern={0=compiler.path}{1=compiler.objcopy.cmd}{2=compiler.objcopy.eep.flags} {3=BUILD_PATH}{4=SOURCE_NAME}.elf {5=BUILD_PATH}{6=SOURCE_NAME}.eep avr.recipe.objcopy.eep.pattern={0}{1}::{2}::{3}.elf::{4}.eep
##create hex #avr.recipe.objcopy.hex.pattern={0=compiler.path}{1=compiler.objcopy.cmd}::{2=compiler.objcopy.elf.flags}:: {3=BUILD_PATH,SOURCE_NAME}.elf::{4=BUILD_PATH,SOURCE_NAME}.hex avr.recipe.objcopy.hex.pattern={0}{1}::{2}::{3}.elf::{4}.hex