Created Sun, 25 Dec 2011 01:54:23 +0000 by ricklon
Sun, 25 Dec 2011 01:54:23 +0000
Official Release 20111221 is now upload to the main ChipKit Project site. Happy Holidays!
Official location: https://github.com/chipKIT32/chipKIT32-MAX/downloads
Windows https://github.com/downloads/chipKIT32/chipKIT32-MAX/mpide-0023-windows-20111221.zip Mac OS X https://github.com/downloads/chipKIT32/chipKIT32-MAX/mpide-0023-macosx-20111221.dmg Linux 32 https://github.com/downloads/chipKIT32/chipKIT32-MAX/mpide-0023-linux32-20111221.tgz
Issues Closed https://github.com/chipKIT32/chipKIT32-MAX/issues?sort=created&direction=desc&state=closed&page=1
New libraries: SoftSPI DSPI
Arduino core 0023 is supported. Variant support added for pic32.
I'll need the various team members to report on some of their work. They've done a great job.
So thank you everyone. This has been really exciting. Even more cool things are on the way.
--Rick
Tue, 27 Dec 2011 13:29:02 +0000
Even more cool things are on the way. --Rick
What a wonderful present, what else are you working on Santa Rick?
Jacob
Tue, 27 Dec 2011 18:11:37 +0000
Maybe Rick does not believe in the history of Santa ... :mrgreen:
Tue, 27 Dec 2011 20:11:47 +0000
This release has reduced it's dependency on plib.h, non open source file, so libraries don't need to depend on it any more. The next goal is get any and all libraries converted away from plib.h. I had problems with OneWire unfortunately. Some of the new libraries highlight the power of ChipKit platform like the SoftSPI library to create any number of bit banged SPI ports.
I also think Gene's work has made tackling Arduino 1.0 API easier. Additionally, I'm planning making it possible to switch between Arduino 0023, and Arduino 1.0.
The ground work is paved for using the pic32 compiler using newlib. This is the result of Jaon Kajita, and Microchip effort to make sure this project is meets it's goal of being open source all the way. So my next goal is to make sure that compiler is available first in the skethch/hardware user folder, and then in the core. Once in place we'll have an core and compiler that doesn't depend on non open source tools.
As for holidays, I get a little extra time to work on projects which makes getting builds out easier. I have to say the excitement of the people on the project is really great, and makes it a joy to work on this project.
Happy Holidays, -_Rick
Tue, 27 Dec 2011 20:47:10 +0000
Hi Rick,
Thank for the new release with many niceties!
Are the TCP/IP stack for MRF24WB0MA and related libraries still on the roadmap?
In the thread :arrow: Question: Which WiFi Board for UNO32?,
The ethernet library for the Network Shield uses the Microchip Application Library TCP/IP stack and we plan to add support for the MRF24WB0MA in an upcoming version.
Good luck with the development :)
Wed, 28 Dec 2011 11:48:16 +0000
Sounds good Rick! Where can we find out more info on the libraries and how to implement them?
Thanks and have a happy new year :)
Wed, 28 Dec 2011 14:29:15 +0000
Thank you for the Chipkit! I always thinked that using a 3.3v based board with an alternative CPU is something mandatory nowadays. The more chips supported are, the more doable projects will be.
Sun, 01 Jan 2012 00:33:44 +0000
OnWire is fixed in master Issue #179.
I had remove #include plib.h and compilation worked as expected.
--Rick
Sun, 01 Jan 2012 12:54:18 +0000
hmmm
/home/oppa/bin/mpide-0023-linux32-20111221/hardware/pic32/compiler/pic32-tools/bin/../pic32mx/bin/gcc/pic32mx/4.5.1/cc1plus: error while loading shared libraries: libelf.so.1: cannot open shared object file: No such file or directory
Is there any documentation on how to setup mpide ? Where have the libraries to go ? I've put the IOShield libs into ~/sketchbook/libraries but mpide does not show them. :(
OK, got that with the sketchbook location but still can't compile.
39403 [Thread-1] DEBUG processing.app.Base - Get boards for: pic32
39404 [Thread-1] DEBUG processing.app.Base - Get platformsfor: pic32
39404 [Thread-1] DEBUG processing.app.Base - Get sketchprefs for: pic32
39406 [Thread-1] DEBUG processing.app.Base - avrBasePath: {0}/hardware/pic32/compiler/pic32-tools/bin/
39409 [Thread-1] DEBUG processing.app.Base - corePaths: /home/oppa/bin/mpide-0023-linux32-20111221/hardware/pic32/cores/pic32
39409 [Thread-1] DEBUG processing.app.Base - 0. getIncludes
39409 [Thread-1] DEBUG processing.app.Base - corePath: /home/oppa/bin/mpide-0023-linux32-20111221/hardware/pic32/cores/pic32
39410 [Thread-1] DEBUG processing.app.Base - getSketchFlderPath: /home/oppa/sketchbook/libraries/IOShieldOled/examples/IOShield_Oled_Demo
39410 [Thread-1] DEBUG processing.app.Base - getImportedLibraries: /home/oppa/sketchbook/libraries/IOShieldOled
39410 [Thread-1] DEBUG processing.app.Base - 1. compileSketch
39411 [Thread-1] DEBUG processing.app.Base - compileSketch: start
39412 [Thread-1] DEBUG processing.app.Base - getCommandCompilerCPP: start
39413 [Thread-1] DEBUG processing.app.Base - Source: /tmp/build8197284589350762853.tmp/IOShield_Oled_Demo.cpp
39414 [Thread-1] DEBUG processing.app.Base - execAsynchronously: start
/home/oppa/bin/mpide-0023-linux32-20111221/hardware/pic32/compiler/pic32-tools/bin/../pic32mx/bin/gcc/pic32mx/4.5.1/cc1plus: error while loading shared libraries: libelf.so.1: cannot open shared object file: No such file or directory
Tue, 03 Jan 2012 23:09:20 +0000
Double check if libraries are one level too deep in libraries. Also, check in preferences that the parent folder of libraries is pointed to.
--Rick
Fri, 06 Jan 2012 16:34:10 +0000
I was anxiously for the release of this kit. i will certainly use it and provide feedback on its performance.
Fri, 06 Jan 2012 16:52:46 +0000
I noticed that the SPI performance seem to be a lot lower than before using the same settings... from 110 fps I now got 35 fps on my display using a newer release. Probably due to the timing fix (?) to make it more like an Arduino.
Is there any way around this, since I really want to use all the new bells and whistles?
Mon, 09 Jan 2012 15:50:45 +0000
I don't know where to put this, so I'm putting it here. I would like to have a couple of features requested:
Add option to Auto-open serial console after upload. It's quite tedious to manually open the serial console after each upload when developing serial-heavy applications.
It would be nice if the board and port setting was saved together with the PDE files instead of being global, and also changed automatically when a PDE is being focused/uploaded. I'm developing for several boards and it's tedious as well to manually remember to change the board and port etc. (Especially when they're named usbSerial0319312 etc..)
It would be nice to be able to double click the error messages to get to the line-number that fails to compile.
All of these seem simple enough to implement, but would mean a lot to those doing a lot of development. Thanks!
Mon, 09 Jan 2012 19:02:34 +0000
- It would be nice to be able to double click the error messages to get to the line-number that fails to compile.
It will be a little harder to implement, as .pde file is parsed and translated in a real .c file where the number of lines will differ (much more lines). Personally, I would like to have MPLAB X as the main IDE.
Tue, 10 Jan 2012 08:57:16 +0000
It will be a little harder to implement, as .pde file is parsed and translated in a real .c file where the number of lines will differ (much more lines). Personally, I would like to have MPLAB X as the main IDE.
Might be a little harder, yes - but still a function that would increase productivity. The output from the compiler is being read into the MPIDE and displayed, and should be accessible from it as well (making it a rather easy parsing process). :)
Tue, 10 Jan 2012 10:22:09 +0000
The standard IDE, based on Processing, is fine and provides out-of-the-box, ready-to-use, instant-rewarding experience. However, it's pretty limited.
I'm afraid Processing-based IDEs can't cope with all the nice features more serious developers ask for, such as: parameters tips, jump to definition, object hierarchy browser, refactoring among others, and a glimpse of debugging.
Best solution would be a plug-in for a standard OS-agnostic IDEs like Eclipse, NetBeans — Visual Studio, Xcode and alike are OS-bound.
Feel free to join the conversation at the Looking for a Better IDE thread :!:
Sat, 03 Mar 2012 16:00:31 +0000
The problem with error parsing is that there is a custom MessageStream it can parse things, but it should be implemented via logging. So it needs an overhaul. the replicatorG team implemented it as logging and it works fine there.
The lower left corner now at least shows the line number the cursor is on in source. I've got the newlib compiler working, and I'll double check the line numbers it provides for error reporting.
--Rick
Might be a little harder, yes - but still a function that would increase productivity. The output from the compiler is being read into the MPIDE and displayed, and should be accessible from it as well (making it a rather easy parsing process). :)