RE: Chip Kit Pi: Personal Thoughts

screamingtiger — Tue, 12 May 2015 17:59:44 GMT

In case it is not apparent, I am very new to most of this, but I learn fast. So bare with me as I struggle through what might seem basic concepts to some.

RE: Chip Kit Pi: Personal Thoughts

balearicdynamics — Tue, 12 May 2015 17:33:24 GMT

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 [View:/resized-image/__size/16x16/__key/commentfiles/f7d226abd59f475c9d224a79e3f0ec07-2d33f8ef-4381-4d41-943b-f5bf8b9a6a04/contentimage_5F00_1.png:16:16]

-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.

RE: Chip Kit Pi: Personal Thoughts

clem57 — Tue, 12 May 2015 17:08:00 GMT

I like the summary even with the g00d, the bAd, and the ugly.[View:/resized-image/__size/16x16/__key/commentfiles/f7d226abd59f475c9d224a79e3f0ec07-2d33f8ef-4381-4d41-943b-f5bf8b9a6a04/contentimage_5F00_938.png:16:16]