I2C Expansion Board

[Artyom]

Testing humidity and temperature sensor with KH GOH patch for I2C POT Board.





As you see sensor work. Great thanks all who help solve this problem.

If you want repeat this experiment you can download test programm from github.com here:
Https://github.com/ControlEverythingComm...C/SI7021.c

After downloading source file compile them:
gcc SI7021.c -o test
Then run it:
./test

And now we test light sensor. As you see all work fine. Link to source on the picture.

WARNING!!! DO NOT FOGET CHANGE I2C ADDRESS IN SOURCE CODE! ON THE PICTURE I SET CURSOR ON PROPER LINE IN SOURCE CODE.

IOCTRL (FILE, I2C_SLAVE, 0X39);

CHANGE 0X39 TO 0X49!!!!

[dkryder]

dang, i just ordered temp/humidity sensor from ce yesterday. they also have a 20 inch 4-pin cable. I want to put it along side the pine64 one and watch variations. what would be maximum length for a cable?

[Artyom]

dang, i just ordered temp/humidity sensor from ce yesterday. they also have a 20 inch 4-pin cable. I want to put it along side the pine64 one and watch variations. what would be maximum length for a cable?

Try read Wikipedia.

[martinayotte]

The EnableI2cPullup.c is doing much more than just adding PullUps on I2C GPIOs, it seems to do the same with all those GPIOs :

PC5,PC9,PH2,PH3,PH5,PH6,PL8,PL9

There 2 I2C in the list, the PH2/PH3 which are TWI1 (btw, TW0 on PH0/PH1 seems to have been forgotten), and PL8/PL9 which is S_TWI, not defined or initialised yet in the Kernel.
So, I doubt that POT boards are using S_TWI, but simply using the TWI1 on PiHeader pins 3/5 instead of pins 27/28.
Maybe someone can verify the traces on the board, I don't have such board and Wiki doesn't provide schematic for this ...

For the other GPIOs which PullUps have been initiaized, PC5/PC9/PH5/PH6, I don't know why they have done that (for PH5/PH6 maybe to prevent breaks on UART3, but no other UARTs have that done).

Last thing, if S_TWI on pins 27/28 is really useful, than the current DTS of the Kernel will need to provides new entries which will bring it probably as /dev/i2c-4.

BTW, for the TWI1, it would be probably pretty easy to have the pullup mode done directly in the DTS too, but why there are external pullups on those pins already ?

[xalius]

Yeah I was also wondering if I was looking at the right I2C interface... I had a look at the devicetree-file we use for the Linux kernel. Seems the I2C Interface for pin PL8/9 is not mapped. I then checked the usermanual and found out that this particular interface is actually different from TWI0/TWI1/TWI2.... it is named R_TWI and while it is the same hardware block, it does not sit on the APB2 bus like the others, it sits in the secure domain of the SoC on the APBS bus... so you can't just copy the dts entry from the others, fix the addresses/clocks/pins and call it a day... I am not sure what implications this has for adding it to the devicetree-file but I looked at R_UART - which is already configured (the name in the dts is s_uart though....) and found out that the secure devices have their own pin-control section, so that seems to be doable. What I do not know, what clock needs to be assigned to drive devices on the APBS bus? Also what are the correct IRQ definitions, I looked at the GIC IRQ table from the usermanual but couldnt figure out how the IRQ line numbers and vectors translate to the interrupt entries in the dts...

[martinayotte]

I think I've succeed to place new DTS entries for S_TWI (PL8/PL9), it is now appearing as /dev/i2c-3 as I've prescribed in an DTS alias.
The only thing is that I didn't test with some hardware yet, I'm usually using TWI0 (/dev/i2c-0).
I will probably try tomorrow using dupont jumpers and will post back.

[dkryder]

dang, i just ordered temp/humidity sensor from ce yesterday. they also have a 20 inch 4-pin cable. I want to put it along side the pine64 one and watch variations.   what would be maximum length for a cable?

Try read Wikipedia.

well, it is specific to device and sensor. i thought you might have more information based on what you are testing.

[martinayotte]

Can someone confirm ?

So, I doubt that POT boards are using S_TWI, but simply using the TWI1 on PiHeader pins 3/5 instead of pins 27/28.
Maybe someone can verify the traces on the board, I don't have such board and Wiki doesn't provide schematic for this ...

@tllim, we need schematic for PoT as well at the revised one for PinA64@2GB itself !!!

[khgoh]

Hi,
This is the schematic  for the i2c POT board.

The summary of the connection are as below,
PH2,PH3 - SCL1/SDA1 connected to Connector below,
With 4pin Connector, CN1, CN2, CN3, CN4
With 5pin Connector, CN5, CN6
PH5 - Interrupt pin on CN5
PH6 - Interrupt pin on CN6


PL8,PL9 - TWI-SCL/TWI-SDA  connected to Connector below,
With 4pin Connector CN7, CN8, CN9, CN10
With 5pin Connector CN11, CN12

PC5 - Interrupt pin on CN11
PC9 - Interrupt pin on CN12

The interrupt pin on the 5 pin connector is to allow the I2c device to interrupt the Host when the device has new information for the Host to read. eg. the Ambient Light Sensor.
The pull-up enable that I wrote has already enable all the above I/O pin.

Regards,
KH Goh

[DonFL]

Hi,
This is the schematic  for the i2c POT board.

Thanks for sharing. Hoping this can be added to the wiki for easy reference (along with the other POT device schematics....).