Are you saying that the RPI’s serial TX/RX pins are being consumed by the GrovePi? It was my understanding looking at your documentation that you’re only consuming the I2C interface (and SPI for Ardunio firmware update) to communicate between the RPI and the GrovePi.
I’ve restored my cmdline.txt setting yet when it gets to the point of prompting for user login, it hangs.
Was able to get my serial debug tty working again. Looked through the install.sh script and saw that it was effectively disabled in the /etc/inittab file. So after repairing these two conditions, I was able to boot up and communicate via the debug serial connection with and without the GrovePi attached:
echo " - in /etc/inittab comments out lines containing AMA0"
echo " - in /boot/cmdline.txt removes: console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1"
Not sure. Perhaps Karan might be able to shed more light.
I am not really sure what you mean about the API for I2C.
The GrovePi board is basically a custom Arduino (Atmega328p) which exposes digital + analog pins as Grove 4 pin sockets, draws power from the GPIO and is reprogrammable over SPI. The I2C ports are pass-through. Scripts running on the pi can interact with I2C sensors directly as well as predefined commands in the GrovePi firmware, which makes it act sort of like a proxy for the sibling I2C sensors. You issue commands to the GrovePi over the I2C bus and it returns readings from it’s digital, analog, serial or uart ports, or it relays I2C commands to adjacent sensors and returns their response.
If you want to issue your own hand crafted commands to the GrovePi, you basically need to write i2c blocks in the format [GrovePi-i2c-address,command,pin,value1,value2]
The GrovePi listens on the wire for 4 ints then tries to execute the command on the specified pin (and adjacent pin if the sensor uses all 4x wires: DATA,CLOCK,VCC,GND or TX,RX,VCC,GND etc). Some commands use a single value, some use both values, some don’t need any values.
Some of the commands return values - you’ll receive ints back down the wire. Some commands return more ints than others.
By API I was meaning the actual data structure to be passed across I2C interface to perform specific operations (e.g., digital read, analog write, etc.). While waiting for a response, I found the version 1.1 sketch being run in the 328p and can see the command breakout. In general, the sketch is actually quite simple. The bit about the I2C ports being passthru is a good tidbit. I’ve yet to dink with I2C so that is good to know.
Also, looking at the port layout I see a port labeled RPISER with a description as a passthru from the RPI. So I would interpret that as being the reason the tty was taken out of the loop with the intent being that the RPI can directly control a serial interface sensor via TX/RX on the GPIO.
Sorry for the confusion with the usage of the Serial debug menu being disabled by default.
The reason that was done is because that the “RPISER” port is connected directly to the Raspberry Pi Serial pins, so that you can attach complex Serial Sensors like the Grove GPS and directly read and write values from the Raspberry Pi.
The GrovePi itself does not use Serial in any way and relies on I2C for communicating with the Raspberry Pi. So if you won’t be using Serial sensors, then you can enable the debug on Serial port without any conflicts.