I want to use the GrovePi with my board like RaspberryPi,but when I read the i2c use the function read_i2c_block_data(0x04,1),there is always a error occur.
but when I read the i2c of other standard i2c device it’s ok could anyone help me,thanks a lot
Hey alading,
Are you using the read_i2c_block_data() function with the GrovePi? What are you using it for ? Can you attach the code that you are trying out and the output that you are getting.
-Karan
Hi Karan:
The function I used and the error I got as bellow:
code:
import smbus
bus=smbus.SMBus(0) #in my board is i2c-0
bus.read_i2c_block_data(0x62,1) # this is ok 0x62 is the address of LCD in grovepi
bus.read_i2c_block_data(0x04,1) #after I do this the error would occur
error:
IOError:[Error 11] Resource temporarily unavailable
I am still a bit confused. What hardware are you using and what are you trying to do with the code above. Do you have something different from the Pi that you are trying to interface.
In the code above, why are you using i2c-0, that does not work with the Pi’s. Also the read_i2c_block_data() won’t be doing anything here. It was written for the GrovePi to send back data in a particular way when the GrovePi gets a command.
-Karan
Hi karan：
1，the board I used is a arm architecture board and the system is linux (ubuntu) 2,actually I used dht() (the API of grovepi) it will call the function read_i2c_block_data(0x04,1) and died here 3,in my board the i2c adapter is i2c-0,in the raspberry is i2c-1.
4,I have debug in linux kernel when I call read_i2c_block_data(0x04,1),this will die in the kernel i2c driver ,but if I call read_i2c_block_data(0x62,1) is ok. (note:0x62 is the address of lcd,0x04 is grovepi)
add more information：
I have visted this site：https://github.com/DexterInd/GrovePi/tree/master/Firmware/Source/v1.2 ，the firmware of version 1.2.5 said Bug with DHT sensor and Analog read removed ，I suddenly find in my code is died here too,so I updateed the firmware ,but this error is still.so do you have some ideas
Hi alading,
Can you give a little more information about the Board that you are using. The GrovePi python code was pretty much written for the Rapsberry pi and I think the problems that you are facing are related to the low level I2C calls here: https://github.com/DexterInd/GrovePi/blob/master/Software/Python/grovepi.py#L163-L189.
This would be easier to debug if you had a logic analyzer and could scope the data going back and forth to the Pi and compare it with your board.
-Karan
Hi karan :
actually,I used the grovepi.py and debuged，when I call function dht() it will died in read_i2c_block()
Hi alading,
I think it would have pretty much have died here: https://github.com/DexterInd/GrovePi/blob/master/Software/Python/grovepi.py#L184. This might be because this function has only been tested for the RaspberryPi and the functionality might be different for your linux board. Can you first get something on I2C to work with your board and then try to get the GrovePi working.
Hi karan ：
as you say，it died here exactly.but when i use this function to read the LCD(address=0x62)，it works OK,the address of arduino(0x04) it died.
Hi alading,
When you read from the LCD, do you get anything legible back? There might be a timing issue too with the readblock. Since this is not the Raspberry Pi, I am not really sure I can help out much to find the source of the problem.
-Karan
Hi karan ：
1，when i read the i2c i can read something
2，you mean it is a timing isue，does it mean the i2c rate or something else ，can you give me some ideas
If you can read something via I2C, it would be worth trying to test some I2C sensor to see if those work. You might just be getting some junk bytes with the LCD.
The whole GrovePi software has been written to work with I2C at 100Khz with the Raspberry Pi. So I am not really sure how your board handles it. Also, the I2C kernel driver on the Pi is a mix of https://www.kernel.org/pub/linux/kernel/people/marcelo/linux-2.4/include/linux/i2c-dev.h and https://github.com/jrowberg/i2cdevlib/blob/master/Arduino/I2Cdev/I2Cdev.h. So it would be worth checking how the drivers look on your board and if it’s implementation is similar.
Usually it is best to debug this kind of problem with an logic analyzer to see what is actually failing. Since we spent a lot of time fine tuning the GrovePi to work with the Pi, there can be a lot of factors in play.
-Karan