Chip Kit Pi: Personal Thoughts

Joey, I partially agree to what you write but I think that there are some mistakes in the general approach for the creators of ChipKit PI. In my opinion, they has used this "pin compatible with Arduino" more as a marketing leverage than some other really depth technical reason. I try to answer what I see in your post that is a very complete screening of the board. Including what I haven not yet clear on ChipKit PI

-The Servo Library is broken when using I2c

It is not the first time I read this somewhere else but I have not clear what do you mean. Is the I2C exclusive with servo library? If so should be investigated, maybe that some complementary pins are used. But it is a question of software (that is very new respect the generally crap but long-time assessed Arduino core and libraries).

-The I2c only receives 1 byte at a time, or rather the callback function is called for each byte received in a block.

In between the START and STOP conditions, the data transfer takes place. The unity of data transfer on the I2C bus is the byte. Data is transferred from a master to a slave, or back to the master in bytes. The first byte in each data transfer is the slave address. Only seven of the eight bits in the address byte are used to define the slave address. The lowest order bit indicates a read, or write request. A low bit indicates a write, a high bit a read request. Data is transferred with the most significant bit first.

(I cited the definition above from the I2C interface protocol definition. Here there is the full document)

My idea - I have already discussed elsewhere about this - is that Arduino, at least the Java IDE level + sketches etc., is a illusion for everywhere - the makers - that electronics is something like a silly game. It's not, what I think is that this approach generate an impoverishment of the knowledge; the ChipKit PI approach is correct, I2C works as any hardware and firmware designer will expect. Probably in all the cases you mention the wrong thing is that they have put this high level board under a point of view so that there is a lot of people thinking that it is faster and better than Arduino but totally Arduino like. Personally I dislike alo the concept of Sketch that is a bare C / C++ program. In fact what I appreciate is that the entire gnu toolchain is managed simply for compilation and this is a great advantage for the newbies.

-There are7 missing I/O pins, but they are present on the breakout board.  After some research I realized they are just duds.

I took a look to this when I read it for the first time on the pages of Element14. It's true, but if you check in dept, I mean with the AVR328p and the PIC microcontroller datasheet you see that the only real "Arduino compatibility" is that the available I/O pins are in the same position so if you have a previous hardware that fits in your Arduino, it fits too in your ChipKit PI. Nothing more

-Some of the pins are there but require jumpers to be set.

This approach is not so bad. The use of the jumpers grant the availability of certain features that are alternative to others. Approach that I see as a general view in many other board, not last one that is also part of our SciFi Challengers kit: PiFace Digital 2. Me too I have followed almost the same principle with the Digital potentiometer Arduino shield; in the next future one of the updates (software) I will do is the Raspeberry + ChipKit PI compatibility of this board.

-It connects to the RPi and eats up half the pins on the pi, and yet its not using any of them except power.  However they are not all exposed on the top of the unit either.

    -The serial pins of the Pi are completely covered and required me to solder wires on the break out to be able to use the serial pins.

    -A few GPIO pins are just simply covered, and not used.

As for as I know, it is not true. As the  prototyping better solution (maybe or not but no matter here) is a board that fits on another, this is exactly what the ChipKit do to get the power from the Raspberry PI. Not only but there are alo two power sources for the board itself (one non-regulated and ont from mini USB). The other Pins (check the circuit with a tester) are replicated on the upper side of the ChpKit PI (shifted respect the standard Raspberry positions so you can use easily. The remaining PINs are instead covered and to be managed needs a 45Deg connectors fitted in. As all the solutions this can be considered not the century idea but has a sense: the board is granted for the compatibility with all the Raspberry PI boards, included the A+ and the first model and the GPIO pins extension is present only starting from the model B. I suppose this is the reason they have not replicated all the PINs on the ChipKit pi.

-The MPIDE doesn't detect the Pi's serial port and requires a symbolic link /dev/ttyS0 to be created

This is true and is a mistake. But - take in account that I am not a fanatic of this board, simply I try to observe what I have in my hands - think to the Arduino IDE 0.xx the infinite number of beta versions crap and wrong working that thousand of people has used before these 1.5 and up last releases. Then, about the IDE as mentioned above I have my prejudices: to manage a real development with all the tools Arduino - the breakout of the AVR  bit microcontrollers class, to be more precise - you need a development platform. For the AVR I am using by a couple of years the AVR Studio recently compatible with Arduino boards and frankly I have not yet checked what is the analogue dev env for the PIC.

-The MPIDE recompiles ALL the code regardless of what changed, and this includes all the internal libraries.  (lots of fun on the Pi).

-Honestly, other than getting power and form factor, I see no reason this thing should connect up to the Pi, it should just be stand alone.

This is another mistake of something. But the MPIDE is in evolution and I remain of the idea that the Java IDE is a toy. As you love the command line, it is not difficult to find the documentation (in the IDE itself) to manage the compiling toolchain with your own make files. That is what the IDE do in a rough way

The last point, there is little support.  Many of the issues have been tossed around online since 2012 and in the Uno32 case, 2011.  Its almost like the support is the open source community but there only seem to be a few people working on it.

The lack of support is a problem, but as this is a community-driven I suppose that are our blog posts, tutorials and discussions that may evolve this process.

All good points, as you can tell I am looking at from the an Arduino perspective, and it quickly diverges into something else.

The servo library interferes with I2C and vise versa, however someone created a SoftwarePWMServo library that works better.  One of the developers I spoke to recognized this issue, but told me to use the different library.  With this new library, conversion of code from Arduino is necessary but its not hard.

The MPIDE is junky, I agree.  there is another IDE call UCIDE or something like that, all it did was crash on my Raspberry Pi.  I was told the MPIDE does not support command line compilation, and a quick look shows there are not make files in there.  I am certain I can figure it out but I do not have time with my current project, so I will stick with MPIDE.  I do agree it is under construction, but it is years old and these problems should of been addressed a long time ago.

The lack of IO pins is ok, but if you are expecting them to be there because you are thinking it is like an Arduino, it will make you frustrated    As I mentioned before once I got out of the Arduino mindset it makes sense now, and is much better overall to use.  That is why I continue to use it.   Same thing with the jumpers, if you are not expecting it, it is frustrating,

Not all the pins the covered by the ChipKit Pi are available on top.  Further, they are in a completely different order.  I know they are not being used except power, because I can unplug it while it is running code and it continues to function if I apply power.  There is no reason for it to be connected to the Pi except to say the name "ChipKit Pi"    I am sure a 45 degree connector can be used but that is not making me happy   ChipKit is trying to use other successful platforms to try to break into the market, and I think that is GOOD.  But they need more software support as most do not want to learn the specifics of a microprocessor at first and instead focus on high level tasks.

From all the I2C implementations I have seen, at the driver level, you can send and receive multiple bytes using the start/stop bit protocol.  Once the driver is finished, you do not get to see the start stop bits, so you cannot take advantage of that.  I had to write my own block receive method using a start and stop byte.  This in fact is a bug and caused many people to abandon the platform.  From my understanding, it is a hardware bug and cannot be fixed directly without using a "delay" statement in the ISR.  I single byte send and receive is OK but you must have a protocol in place to keep things in sync.  Unfortunately due to overhead I can only process 10 bytes per second.  I hope it is fast enough.

Keep in mind I LIKE the chipkit pi.  I just want to complain about my headache figuring it out.  Now I have done so I will continue to use it over arduino, and look into the Fubrino breakout.  If I do stay with the AVR, I want to use the AVR studio like you do, perhaps you can show me how?

As I mentioned before, I am looking to replace Arduino and  AVR.    I like Pic32 and other PICs, but now that Parallax propeller has a C compiler, that may be my next thing I use exclusive for real time projects.

THANK YOU for your  responses and listening to me complain    you are a good friend.

All good points, as you can tell I am looking at from the an Arduino perspective, and it quickly diverges into something else.

The servo library interferes with I2C and vise versa, however someone created a SoftwarePWMServo library that works better.  One of the developers I spoke to recognized this issue, but told me to use the different library.  With this new library, conversion of code from Arduino is necessary but its not hard.

The MPIDE is junky, I agree.  there is another IDE call UCIDE or something like that, all it did was crash on my Raspberry Pi.  I was told the MPIDE does not support command line compilation, and a quick look shows there are not make files in there.  I am certain I can figure it out but I do not have time with my current project, so I will stick with MPIDE.  I do agree it is under construction, but it is years old and these problems should of been addressed a long time ago.

The lack of IO pins is ok, but if you are expecting them to be there because you are thinking it is like an Arduino, it will make you frustrated    As I mentioned before once I got out of the Arduino mindset it makes sense now, and is much better overall to use.  That is why I continue to use it.   Same thing with the jumpers, if you are not expecting it, it is frustrating,

Not all the pins the covered by the ChipKit Pi are available on top.  Further, they are in a completely different order.  I know they are not being used except power, because I can unplug it while it is running code and it continues to function if I apply power.  There is no reason for it to be connected to the Pi except to say the name "ChipKit Pi"    I am sure a 45 degree connector can be used but that is not making me happy   ChipKit is trying to use other successful platforms to try to break into the market, and I think that is GOOD.  But they need more software support as most do not want to learn the specifics of a microprocessor at first and instead focus on high level tasks.

From all the I2C implementations I have seen, at the driver level, you can send and receive multiple bytes using the start/stop bit protocol.  Once the driver is finished, you do not get to see the start stop bits, so you cannot take advantage of that.  I had to write my own block receive method using a start and stop byte.  This in fact is a bug and caused many people to abandon the platform.  From my understanding, it is a hardware bug and cannot be fixed directly without using a "delay" statement in the ISR.  I single byte send and receive is OK but you must have a protocol in place to keep things in sync.  Unfortunately due to overhead I can only process 10 bytes per second.  I hope it is fast enough.

Keep in mind I LIKE the chipkit pi.  I just want to complain about my headache figuring it out.  Now I have done so I will continue to use it over arduino, and look into the Fubrino breakout.  If I do stay with the AVR, I want to use the AVR studio like you do, perhaps you can show me how?

As I mentioned before, I am looking to replace Arduino and  AVR.    I like Pic32 and other PICs, but now that Parallax propeller has a C compiler, that may be my next thing I use exclusive for real time projects.

THANK YOU for your  responses and listening to me complain    you are a good friend.