chipKIT® Development Platform

Inspired by Arduino™

Arduino Libraries actually working with chipKIT

Created Thu, 23 Jun 2011 21:58:48 +0000 by deepthought-64


deepthought-64

Thu, 23 Jun 2011 21:58:48 +0000

The argument that made me buy the chipKIT was the announced "100% compatibility" with arduino and it's libs.

As I came across a few libs which in fact weren't working with chipKIT because of dependencies on the low-level avr-files. Now I'm confused about what is working on this hardware and what isn't.

So I want to start a survey abour which libraries actually work out of the box with the mpide. I would be glad if you could do a quick post if you have tested a lib (on the hardware) and tell me/us if it works or not

The libs I actually tested:

  • Serial [color=#00BF00]WORKING[/color]
  • Wire [color=#FF0000]NOT WORKING[/color]

Jacob Christ

Thu, 23 Jun 2011 22:52:02 +0000

This is a great idea... I've started a header page on the wiki where I was trying to sort some of this stuff out myself...

chipkit.org/wiki

Here's what I've verified.

SPI works, but I don't know if its 100% compatible... I suspect not because I Arduino libs appear to be written with the AVR in mind. For example, if you start SPI on an AVR the same way as on a PIC32 the clock speeds maybe different. The AVR SPI lib may not have taken into account the speed of the clock or the clock rates may not line up due to clock freq and divider register differences between the chips.

Maybe it would be good to keep track of this on the wiki possibly in a tabular form such as:

Lib, Port State (no progress, in progress, complete), Issues (if any)

Finally, I think its possible to make 100% compatible libraries, but the stumbling block will not be the PIC32 but the AVR since it will require that the AVR libs be changed to support cross platform compatibility.

Jacob


Toley

Thu, 23 Jun 2011 23:57:52 +0000

[color=#FF0000]WIRE IS WORKING[/color] with the new test release that can be found here

http://www.chipkit.org/forum/viewtopic.php?f=20&t=115

This DS1307 library works perfectly

https://github.com/davidhbrown/RealTimeClockDS1307


Mark

Thu, 23 Jun 2011 23:58:34 +0000

I have started the wiki page with a list of libraries

[url]http://www.chipkit.org/wiki/index.php?title=Library_Status[/url]


robotguy

Fri, 24 Jun 2011 00:23:02 +0000

I have started the wiki page with a list of libraries [url]http://www.chipkit.org/wiki/index.php?title=Library_Status[/url]

Good idea! This is important stuff for those of use waiting to purchase a chipKit board. I'll most likely get a Max32 to tinker with in August. :roll:

8-Dale


deepthought-64

Fri, 24 Jun 2011 11:46:38 +0000

[color=#FF0000]WIRE IS WORKING[/color] with the new test release that can be found here http://www.chipkit.org/forum/viewtopic.php?f=20&t=115

Sorry, but Wire doesn't work with my version of mpide (0022-chipkit-linux32-20110619).


Toley

Fri, 24 Jun 2011 13:47:22 +0000

I don't want to start a debate but it works for me. I also made it work with a LM75 temperature sensor. Maybe it's platform dependant I'm using the mpide-0022-chipkit-win-20110619 and a Max32 board.

Maybe someone else can tell if it works or not for him.


deepthought-64

Fri, 24 Jun 2011 13:58:28 +0000

strange... is there somebody else with the mpide running under linux?


Jacob Christ

Fri, 24 Jun 2011 18:17:43 +0000

I'm running in Linux, but I haven't had anytime to play with I2C if that is what your referring too?

Jacob


robwasab

Sat, 25 Jun 2011 02:38:06 +0000

The servo library doesn't work. It's only pwm, so idk, bogus, I was looking forward to use my uno 32. Also, the uno 32 isn't fully compatible with I guess 3rd party libraries. I can't import "MeetAndroid" which blows even more. Fully compatible my balls.


Mark

Sat, 25 Jun 2011 04:33:25 +0000

Any library, such as Stepper and LCD, which only uses the abstraction layer (i.e. digitalWrite). will work fine

Any library which talks directly to the hardware has to be re-written.

At release we had all of the core files working properly. We hope to have all the main libraries done in another month.

3rd party libraries will be as those 3rd parties get to them or when others get to them.

Mark


deepthought-64

Sat, 25 Jun 2011 18:02:49 +0000

@Jacob:

Just try to compile any sketch that uses the Wire lib, like

#include <Wire.h>
void setup() {
  Wire.begin();
  Wire.beginTransmission(0xc0);
  Wire.send(0x12);
  }

  void loop() { /* empty*/ }

you don't actually need the hardware or anything that actually uses i2c. just create a new sketch, add the code and hit the play button.

i would be glad if you can tell me if that works for you or not.

greetings


Jacob Christ

Sun, 26 Jun 2011 22:28:33 +0000

@Jacob: Just try to compile any sketch that uses the Wire lib, like

#include <Wire.h>
void setup() {
Wire.begin();
Wire.beginTransmission(0xc0);
Wire.send(0x12);
}
void loop() { /* empty*/ }

you don't actually need the hardware or anything that actually uses i2c. just create a new sketch, add the code and hit the play button. i would be glad if you can tell me if that works for you or not. greetings

No dice...

I'm using mpide-0022-chipkit-linux32-20110529

Wire/Wire.cpp.o: In function TwoWire::begin()': Wire.cpp:(.text+0xa4): undefined reference to twi_init' Wire/Wire.cpp.o: In function TwoWire::begin(unsigned char)': Wire.cpp:(.text+0xbc): undefined reference to twi_setAddress' Wire.cpp:(.text+0xc8): undefined reference to twi_attachSlaveTxEvent' Wire.cpp:(.text+0xd4): undefined reference to twi_attachSlaveRxEvent' Wire/Wire.cpp.o: In function TwoWire::requestFrom(unsigned char, unsigned char)': Wire.cpp:(.text+0x118): undefined reference to twi_readFrom' Wire/Wire.cpp.o: In function TwoWire::endTransmission()': Wire.cpp:(.text+0x188): undefined reference to twi_writeTo' Wire/Wire.cpp.o: In function TwoWire::send(unsigned char)': Wire.cpp:(.text+0x208): undefined reference to twi_transmit' Wire/Wire.cpp.o: In function TwoWire::send(unsigned char*, unsigned char)': Wire.cpp:(.text+0x2a8): undefined reference to twi_transmit' collect2: ld returned 1 exit status

Jacob


deepthought-64

Mon, 27 Jun 2011 20:30:01 +0000

would you do me a favor and update to mpide-0022-chipkit-linux32-201100619 and try again? i think this is the release which should include the wire-lib


raphael

Tue, 28 Jun 2011 04:19:14 +0000

Doesn't work for me either. Running Linux, with the mpide version: 2011 06 19

Wire/Wire.cpp.o: In function TwoWire::begin()': Wire.cpp:(.text._ZN7TwoWire5beginEv+0xc): undefined reference to twi_init' Wire/Wire.cpp.o: In function TwoWire::begin(unsigned char)': Wire.cpp:(.text._ZN7TwoWire5beginEh+0x10): undefined reference to twi_setAddress' Wire.cpp:(.text._ZN7TwoWire5beginEh+0x1c): undefined reference to twi_attachSlaveTxEvent' Wire.cpp:(.text._ZN7TwoWire5beginEh+0x28): undefined reference to twi_attachSlaveRxEvent' Wire/Wire.cpp.o: In function TwoWire::send(unsigned char)': Wire.cpp:(.text._ZN7TwoWire4sendEh+0x5c): undefined reference to twi_transmit' Wire/Wire.cpp.o: In function TwoWire::send(unsigned char*, unsigned char)': Wire.cpp:(.text._ZN7TwoWire4sendEPhh+0x8c): undefined reference to twi_transmit' collect2: ld returned 1 exit status


davec

Tue, 28 Jun 2011 12:59:25 +0000

I can't import "MeetAndroid"

This is a clash with the definition of BYTE in Print.h and GenericTypeDefs.h. Find Print.h and comment out this line:

// #define BYTE 0


Trev

Sun, 03 Jul 2011 06:29:41 +0000

i would be glad if you can tell me if that works for you or not.

Works fine with MPIDE 20110619 under OS X.


WestfW

Wed, 27 Jul 2011 06:07:24 +0000

This is a clash with the definition of BYTE in Print.h and GenericTypeDefs.h. Find Print.h and comment out this line: // #define BYTE 0

The typedef of BYTE in GenericTypeDefs.h is more questionable, IMO. Any chance of just omitting that file for ChipKit? I mean, there are standards for that sort of thing now (uint8_t) There may be reasons for having that file for legacy PIC apps, but I don't think anything chipKit-like should bother. The libraries won't care, though some of the private .h files might need changed?

This is also one of the things stopping the ethernet libraries from working. SPI.h for picKit uses the Microchip BYTE typedefs, and of course Stream/Print/etc uses the Arduino defines, and ethernet wants them both.


GeneApperson

Wed, 27 Jul 2011 16:30:46 +0000

@WestfW,

Maybe this should be addressed in a more comprehensive way. It might be a good idea to develop some recommended coding standards for chipKIT. We don't want to get into religious issues like where to put braces, but there have been several recommendations made on the forum (such as Mark Sproul's recommendations on how to wrap code that is AVR/PIC32 specific), and as you suggest, variable typing that is more consistent with current practices.

What do you think?

Gene Apperson Digilent


jasonk

Wed, 27 Jul 2011 17:41:33 +0000

Yes, here at Microchip, we're trying to get people to move from GenericTypedefs.h to stdint.h for our own app notes and libraries.

I think some coding guidelines for chipKIT is a great idea, maybe on the Wiki?


WestfW

Wed, 27 Jul 2011 22:42:15 +0000

we're trying to get people to move from GenericTypedefs.h to stdint.h

How seriously? It looks like most of the use of GenericTypedefs.h in the picKit source is a result of using the Microchip-provided libraries/includes. To get a rough idea of how bad things would be, I emptied out GenericTypedefs.h and tried to compile the ethernet libraries, and the complaints are all about:

pic32mx/include/peripheral/i2c.h:126:5: error: 'UINT8' does not name a type
pic32mx/include/peripheral/uart.h:76:11: error: 'UINT' does not name a type
pic32mx/include/peripheral/CAN.h:276:2: error: 'BOOL' does not name a type

and similar. This sort of legacy can take a really long time to eliminate, given anything less than really Herculian efforts.


jasonk

Wed, 27 Jul 2011 23:25:51 +0000

There's a group updating the coding guidelines for these types of things. However, getting everyone to go back and update their existing code will take a while.


Ddall

Thu, 28 Jul 2011 08:47:59 +0000

The Tlc5940 library is not working :( I need Tlc5940 to work or my project is dead (A rbg led matrix driven by a TLC5940 array). The problem seem's to be: Tlc5940.cpp :

#include <avr/io.h>
#include <avr/interrupt.h>

I read somewhere in the forum that interrupt.h and io.h both need to be rewritten to work on chipkit. Any idea when they'll be available?


Magelan

Thu, 28 Jul 2011 15:03:36 +0000

Hello,

I've the same problem with softPWM library.

Thanks,

Magelan.


avenue33

Sat, 30 Jul 2011 20:17:41 +0000

Hi,

I tested some of my projects I developed for Arduino on my bold new chipKit UNO32. Projects are available at: sites . google . com / site / vilorei / arduino

I manage to make I2C / Wire.h [color=#00FF00]work[/color] with

  • BlinkM RGB LED
  • HMC6352 2x Compass
  • ADXL345 3x Accelerometer [color=#FF0000]Updated![/color]
  • ITG3200 3x Gyroscope [color=#FF0000]Updated![/color]
  • HMC5843 3x Magnetometer [color=#FF0000]Updated![/color]

[color=#FF0000]Updated![/color] But all the procedures involving int required to be rewritten based on stdint.h naming, i.e. int8_t, int16_t, uint16_t, and alike. Also, the string object [color=#FF0000]doesn't[/color] work.

Two possible [color=#0000FF]hints[/color]

  • libraries release roadmap
  • coding guidelines to avoid using Arduino instructions that aren't chipKIT compatible

Good luck to the development team :!:


Ddall

Wed, 03 Aug 2011 10:55:08 +0000

LCD4Bit_mod works, The screen works, but the keypad is buggy. I think it's just a glitch, because analogRead might read different values on chipkit.

It's the library used for the two lines LCD shield from nuelectronics


avenue33

Wed, 03 Aug 2011 11:10:42 +0000

The library for the i2c / SPI character LCD backpack from Adafruit (based on MCP23008 and LiquidCrystal) works fine.

It requires

  • Adding #include <WProgram.h>
  • Changing #include <intypes.h> for #include <stdint.h>
  • Removing #include <avr/pgmspace.h> and #include <Print.h>

in the .cpp and .h files.


SXRguyinMA

Thu, 04 Aug 2011 18:39:39 +0000

Anyone have any idea how to get the HL1606 strip library working? The Arduino version is available from Adafruit under the "Digital Addressable RGB LED Strip" name. I tried to post a link, but the forum won't let me as it thinks I'm spam :lol:

Thanks!

Will


davec

Thu, 04 Aug 2011 19:56:38 +0000

Anyone have any idea how to get the HL1606 strip library working? The Arduino version is available from Adafruit under the "Digital Addressable RGB LED Strip" name.

It uses low-level SPI rather than the SPI library, so hard to port (link). The ledstrip library looks like it would work.


SXRguyinMA

Fri, 05 Aug 2011 02:13:26 +0000

It uses low-level SPI rather than the SPI library, so hard to port ledstrip library looks like it would work.

I looked all over that site but can't figure out how to get the code :?:

Also, I put int he HL1606StripPWM library, and when I try to compile it says it's not found. Any ideas?


davec

Fri, 05 Aug 2011 02:50:08 +0000

I looked all over that site but can't figure out how to get the code :?:

You can either use SVN (client programs are linked from that page) or on project site go to here, click on each file, click on view raw file, and save the page.

Also, I put int he HL1606StripPWM library, and when I try to compile it says it's not found. Any ideas?

It really won't compile in MPIDE without rewriting. ;)


SXRguyinMA

Fri, 05 Aug 2011 03:43:46 +0000

Also, I put int he HL1606StripPWM library, and when I try to compile it says it's not found. Any ideas?

It really won't compile in MPIDE without rewriting. ;)[/quote]

well then the code does me no good does it? :lol:


davec

Fri, 05 Aug 2011 04:28:22 +0000

well then the code does me no good does it? :lol:

Sorry maybe I'm getting confused, HL1606StripPWM is the Ladyada library which uses low-level AVR stuff and won't work on PIC32 without a lot of changes, ledstrip which I linked to in my previous message is a different library for the same chip which uses higher-level functions and should work on PIC32 with a bit of luck.


SXRguyinMA

Fri, 05 Aug 2011 21:54:26 +0000

Alright I saved the raw files as needed, now I just need to figure out how to make it work :lol:


WestfW

Fri, 05 Aug 2011 22:08:29 +0000

then the code does me no good does it?

Sure it does. Working code from some platform is almost always better than starting from scratch, even if your target platform is substantially different from the original target and needs major modifications.


avenue33

Sat, 06 Aug 2011 12:20:38 +0000

Hi!

I developed a library for the :arrow: μLCD-32PT(SGC) 3.2” Serial LCD Display Module by 4D LABS, which packs a 320x240 LCD 16-bit colour display with touch control and a micro-SD-card reader, powered by its own 12 MHz controller.

Porting my Serial_LCD.h library for the from Arduino to the chipKIT UNO32 wasn't a major task, provided some precautions:

  • Coping with implicit types as int, which don't mean the same on a 8-bit environment and a 32-bit one: all variables require explicit types.
  • Adding full support to the chipKIT UNO32 hardware second serial port, without loosing the software emulated serial port.
  • Making the main Serial_LCD.h library immune from hardware / software serial port: I added an abstraction layer.
  • Trying to understand why an #if #include statement doesn't work.
  • Dealing with over-speed, a 80 MHz board working with a 12 MHz display.

Enjoy ;)