Previous Posts
Application Information
http://www.element14.com/community/community/design-challenges/sci-fi-your-pi/blog/2015/04/22/some-information-from-my-application
ChipKit Pi Vs Arduino Pro Mini
http://www.element14.com/community/community/design-challenges/sci-fi-your-pi/blog/2015/05/01/quick-update-on-the-quadcop-and-the-chipkit-pi
Quadcopter Assembled (You call that a Quadcopter?)
http://www.element14.com/community/community/design-challenges/sci-fi-your-pi/blog/2015/05/06/quadcopter-assembled
QuadCop -The Control Switch
http://www.element14.com/community/videos/16202/l/control-switch-explanation
I continue to find issues with the ChiKit Pi and work around them as I can. Here is a brief list and then a more in depth explanation for those who are interested. My goal is to show our Hosts the amount of innovation it takes to use the ChipKit Pi and to also help others who may choose to use it.
1) Digital Pins 4,5,6,7 and analog pins A3,A4 and A5 are not present. While there are pinouts on the the CKP for the digital pins, they are connected to nothing. SDL and SCL are present but not in the form of A4 and A5.
2) There is a bug in I2C as a slave, where the callback routine only gets 1 byte at a time. This means if I send 3 bytes in a block, the call back will be called 3 times instead of 1 time. This isnt a show stopper but requires one to create a block protocol similar to a serial communication.
See https://github.com/chipKIT32/chipKIT32-MAX/issues/310 for the bug submission
3) If your code uses Serial.println statements, you need to change to Serial1.println to see the output on the pi.
4) The Servo library doesn't work for me, however the SoftwarePWMServo does, and work well it has. its very similar just different function calls. Its not object oriented though.
5) The serial pins for the Pi are covered up by the CKP. There is a small header on the top of the board next to the header that connects to the pi. Some of the GPIO pins are brought here from the pi, but they are NOT in the expected location. You need a pinout for this. However the Serial pins are not broken out. So to get around this I soldered wires to the serial pins so I can connect my GPS directly to the Pi.
6) Number 6 isn't found yet but I am sure it will be 
None of these bugs are show stoppers. However, they require innovation to work around. I need to solder on wires, develop a block protocol for I2c, and remap all my pins in software to work around the pins I used that are not present on the CKP.
Now for the more in depth explanations.
ChipKit Pi (CKP) notes
The CKP gives us a nice breakout for the PICPIC32MX250F128B in a format similar to the arduino uno.
However, because the PIC32 included on the board does not have as many pins as the AVR328p on an UNO, some of the
pins are present on the breakout but not actually connected to anything! This had me stumped for a bit until I
found the pinout located here:
http://wiki.kewl.org/dokuwiki/boards:chipkitpi
Once again I assumed this breakout was 100% arduino compatible and I assumed wrong. This meant I had to do some
reading, and it serves me right for not doing so up front. Thats ok, I still really like it.
My original pinout mapping for the Arduino Pro Mini used most of the pins. The chipkit Pi is missing Digital Pins
4-7 and A4,A5. On the Arduino A4 and A5 are used for I2C SDA and SCL respectively. The SDA and SCL are present on
the breakout and can be used to bring the CKP onto the I2C bus. Its unclear to me if these will actually function
as analog pins as well. A3 is nowhere to be found.
In my original code for the Aruino, I needed 7 digital pins to read PWM, 4 digital pins to write PWM (software
based), SDA, SCL, and 2 digital pins for signaling the RPI.
So 13 digital pins are needed in addition to the two for I2c. However the CPK only has 12 digital pins if I also
count A0 and A1 as digital pins. What to do?
Right next to the header where the raspberry pi
JP5
+---J4---+
NC 01 02 GPIO0/GPIO2
GPIO1/GPIO3 03 04 NC
GPIO4 05 06 GND
GPIO18 07 08 GPIO17
GND 09 10 GPIO21/GPIO27
GPIO23 11 12 GPIO22
GPIO24 13 14 3V3
GND 15 16 GPIO10
GPIO25 17 18 GPIO9
GPIO8 19 20 GPIO11
GPIO7 21 22 GND
+--------+
You can see some of the GPIO pins covered up by the Raspberry Pi are available for use. I "assume", and there is
that word again, this is a stright passthrough from the RPi.
Here are the items that need a digital pin:
Radio Channel 1 - Forward/Reverse
Radio Channel 2 - Left/Right
Radio Channel 3 - Climb/Dive
Radio Channel 4 - Rotate left/Right
Radio Channel 5 - Auto or manual pilot mode
Radio Channel 6 - Macro mode start/stop
Radio Channel 7 - Perform sensor sweep indicator
Motor ESC* 1
Motor ESC* 2
Motor ESC* 3
Motor ESC* 4
Automode Indicator - Connection to RPI to turn it to automode
Macromode Indicator - connection to RPI to tell it to start/stop recording
Sensor Sweep Indicator - connection to RPI to tell it to note a sensor sweep at these coordinates
*ESC = electronic speed controller, which given a PWM sets the speed of a brushless motor. In all technicality
these pins actually connect to the flight controller not the ESCs themselves.
One solution is to read one of channels 5-7 through one of the GPIO pins on the RPFS. Given the Raspian is not a
real time OS, this is generally not recommended. However channels 5-7 are simply "off/on" so they go from 1ms to
2ms and nothing in between. I feel that the variance that RPi will have is acceptable and will be less 100
microseconds anyways. This would be an issue if I needed more precise readings but on these pins I do not. if I
go this route I will take the reading 3 times in a row and use the average in case there is some 1ms delay for some
reason.
Another option is to instead of using 3 digital pins to signal the RPI, write commands through I2C. I originally
avoided this approach due to my original design of using the Arduino Minis. With all the reading and writing PWM
signals on top of some I2c stuff, I felt is was being overtaxed already. The CKP has so much power though I think it will be strong enough to handle more parsing.
With the bug in I2C its going to be more work to implement additional I2C commands. In the get hub bu submission at https://github.com/chipKIT32/chipKIT32-MAX/issues/310
There is a work around but it requires blocking the ISR. Given I need to update servos and read PWM input all ISRs must run fast. It would be better to work around the bug using non-blocking code.
Blocking code = When an ISR is called interrupts are disabled, so no other ISR can run. Servos are updated via an ISR so if an ISR takes too long, the servos will start to jitter.
Top Comments