UECIDE Support for chipKIT Pi

Created Mon, 02 Dec 2013 15:21:17 +0000 by majenko

majenko

Mon, 02 Dec 2013 15:21:17 +0000

UECIDE now completely supports the chipKIT Pi board, in more ways than one!

Yes, it provides the same interface as MPIDE does to the chipKIT Pi board itself, but now we have taken it a step further.

You can now program the actual Pi itself from within UECIDE as well. That's both boards together in one IDE, with one common language, and one common API.

Libraries (within reason) can be used on either board. Code can be copied and pasted between the two boards and should be compilable (again, within reason) on both.

What could be simpler than that...?

Pi support is still in development, so I'd appreciate any comments and feedback on it. I may not have written all the API functions just yet, but it's pretty much there.

Note that Pi support requires UECIDE to be run from the Pi as it uses the native GCC compiler and toolchain. Once a suitable cross-compiling toolchain for the other three main systems can be found I will be investigating remote compilation on your PC as an option.

ChristopheDupriez

Mon, 02 Dec 2013 15:46:07 +0000

Congratulations for this!

It is very interesting if you want to place the developper/customer in a single environment where you have field devices (PIC32s for instance) and a "controller" accessible through Ethernet (Internet) like a RaspberryPi. Now, all can be programmed in a single environment: VERY NICE!

I would only appreciate some documentation in uecide.org/wiki about "How a Library must be organized to be considered as "Packaged" " : I do not succeed moving from MPIDE to UECIDE because of this.

Wishing you a very nice day!

Christophe

majenko

Mon, 02 Dec 2013 16:02:27 +0000

Here's the pinout for the chipKIT Pi's "rPi Passthrough Header", which is not the same as the real Pi's header. The pin numbers reflect the pin numbers in UECIDE for the Pi with ckPi board.

[attachment=0]PiPo.png[/attachment]

A library should be packaged as a zip file, with a clean "standard" library layout. For example, if you have a library "FooBar" the zip file will contain, at least:

FooBar/ FooBar/FooBar.h

It should really also contain FooBar/FooBar.cpp

Other files can exist, and they are installed as they are named.

If you have a file FooBar/FooBar_Baz.h

then you get a second library entry for FooBar_Baz.h as a sub-library of the main library. This is useful for things like LiquidCrystal.h, LiquidCrystal_I2C.h, LiquidCrystal_SPI.h, etc.

The file name for the whole zip file isn't really important, but would normally be FooBar.zip or similar.

I am toying with the idea of a centralized library repository that people can publish their libraries through, and it deals with proper packaging, validation and dissemination for them.

ChristopheDupriez

Mon, 02 Dec 2013 17:09:26 +0000

Thanks Majenko for the "Pi à la Arduino Pinout"!

About the libraries:

• I was trying by pointing the "Import Library" menu to the MPIDE directory for the library: I understand that I have to ZIP a copy of the libraries before making them available to UECIDE. Question: if one develops a library in UECIDE, (s)he has to ZIP its sources each time before testing it in the "client" projects?

• Testing UECIDE with a Sketch using your library ChangeNotification (which is really nice and that works well with MPIDE), I have the following error:

In file included from C:\Users\Christophe\AppData\Roaming\uecide\cores\chipKIT\api/WProgram.h:12:0,
                 from C:\Users\Christophe\Documents\uecide\libraries\ChangeNotification\/ChangeNotification.h:4,
                 from C:\Users\Christophe\Documents\uecide\libraries\ChangeNotification\ChangeNotification.cpp:2:
C:\Users\Christophe\AppData\Roaming\uecide\cores\chipKIT\api/wiring.h:204:31: error: declaration of C function 'uint32_t ReadCoreTimer()' conflicts with
C:\Users\Christophe\AppData\Roaming\uecide\compilers\pic32-gcc\bin\../lib/gcc/pic32mx/4.5.1/../../../../pic32mx/include/peripheral/timer.h:190:40: error: previous declaration 'unsigned int ReadCoreTimer()' here
C:\Users\Christophe\AppData\Roaming\uecide\cores\chipKIT\api/wiring.h:204:31: error: 'ReadCoreTimer' redeclared with conflicting 'nomips16' attributes

• Central repository: Nice idea, especially if ChipKit project is supporting your initiative. Please avoid something complex and error prone like Maven!!!

Have a nice evening,

Christophe

ChristopheDupriez

Mon, 02 Dec 2013 17:23:00 +0000

Follow up on "using UECIDE on Windows for FubarinoSD" (I should change for another thread!), After changing : C:\users\Christophe\AppData\Roaming\uecide\cores\chipKIT\api*wiring.h* the following way:

//extern uint32_t ReadCoreTimer();
extern unsigned int __attribute__((nomips16)) ReadCoreTimer(void);

It compiles but no luck with ld:

C:/Users/Christophe/AppData/Roaming/uecide/compilers/pic32-gcc/bin/../lib/gcc/pic32mx/4.5.1/../../../../pic32mx/bin/ld.exe: cannot find -lsupc++
C:/Users/Christophe/AppData/Roaming/uecide/compilers/pic32-gcc/bin/../lib/gcc/pic32mx/4.5.1/../../../../pic32mx/bin/ld.exe: cannot find -lpic32
C:/Users/Christophe/AppData/Roaming/uecide/compilers/pic32-gcc/bin/../lib/gcc/pic32mx/4.5.1/../../../../pic32mx/bin/ld.exe: cannot find -lmchp_peripheral_32MX795F512H
collect2: ld returned 1 exit status

By the way, for french accented letters typed into source code usgin MPIDE, "Fix encoding" does not fix anything! Example: LED à définir température

Sorry to put different problems in one post: I can certainly wait and also I hope to help, at least by documenting projects in "project pages" common to ChipKit and UECIDE.

Wishing you a very nice evening,

Christophe

majenko

Mon, 02 Dec 2013 17:30:32 +0000

I've just published a new chipKIT core that should fix that problem. The fix, instead of your way, just includes <peripheral/timer.h> which is where that function is defined properly. I don't know what those other linker entries are for or where they came from. Any chance of a SSCCE?

No, you don't have to zip the library every time you want to test it. The "Add Library..." menu entry just takes the zip file, tests it for the right format, then extracts it into your normal "libraries" folder (in your sketchbook folder, wherever that is). You can just copy the files direct into that libraries folder by hand uncompressed as you would with MPIDE or the Arduino IDE. It's no different from that PoV.

There is a "Rescan Libraries" menu entry that will check for new libraries without you having to restart the IDE. It also looks for new files added to existing libraries. When developing libraries the "Purge Cache Folder" menu entry can also be a real help, if you have a library that didn't compile properly and left itself in a mess.

ChristopheDupriez

Mon, 02 Dec 2013 19:53:33 +0000

I duly appreciate this caching process which makes UECIDE a lot faster for compiling.

For the LD errors, I uninstalled/resintalled ChipKit Core (using the impressive Plugin Manager), and the problem is gone. I suppose in the future that some checksum mechanism could help detect corrupted installations.

Please do not forget the UTF-8 issue (everything everywhere should be UTF-8!)

Thanks a lot!

Christophe

majenko

Mon, 02 Dec 2013 20:33:16 +0000

The editor supports entry of extended chars, so it may be UTF-8 (or so it would seem), and the serial terminal kind of supports it sometimes (I guess if the letters come in fast enough and at the right timing)... [attachment=0]french.png[/attachment]

matt@dell:~/sketchbook/blart$ file blart.ino 
blart.ino: UTF-8 Unicode text

Yep, it's UTF-8 alright...