I recently obtained a GrovePi+ and I’m testing it on my 2 Raspberry Pi’s. It is working on the 2B, but not on the B.
GrovePi+ on Pi 2B
GrovePi+ on Pi B
Both devices run Rasbian and are fully updated.
Any ideas
It seems like I’ve solved this problem.
I tried to write to GPIO 8, without any luck.
Then I flashed the firmware to 1.2.2, that didn’t solve i either.
Then I found the following code (Thanks KARAN) to reset the mcu 328 with the following code:
avrdude -c gpio -p m328p
Trying the i2xdetect showed devices at every id, so I needed a reset.
After a reboot, i2cdetect showed my GrovePi+ on ID 04.
Everything is OK now.
Great, good to hear. How can we improve our documentation to help folks out in the future?
I have experienced the same on my Raspberry Pi’s with the same GrovePi+ board (newest version).
Pi B
-When plugging in the adapter with the plug on the Pi, the reset LED lights up, need to run “avrdude -c gpio -p m328p”
-When taking out the adapter from the wall socket and plugging the adapter back into the wall socket, the Pi runs fine! So it seems to have to do something with how the Pi B takes in the power at first. I can reproduce both cases a 100% consistently.
-With Dexter Raspbian image, the reset LED lights up as well, but eventually stops doing this (I assume there is a script that runs “avrdude -c gpio -p m328p” on your image) but with the normal Raspbian image, it doesn’t go away until after running “avrdude -c gpio -p m328p” so I put it in the rc.local script, then when the Pi is done booting the reset LED is off and the GrovePi+ works without the need for user intervention. Though I think running the script as a high priority /etc/init.d/ script would be better when you want the Pi to boot automatically with other scripts needing the GrovePi board. If those scripts would run before the rc.local script and rely on the GrovePi board, it might cause problems.
Pi2
No problems whatsoever.
EDIT:
I have just added an init.d script, but it still is pretty slow in enabling the board (i.e. turning off the reset LED). What did you use in your Dexter Raspbian image to reset the board to the working state? The Raspbian Jessie image boots way quicker, though it takes about 22 seconds for the reset LED to go off. On your image it only takes about 10 seconds, while the whole boot sequence is a lot slower (as it has a lot more services booting than the cleaner Raspbian Jessie installation), so there has to be something going on before even the init.d sequence is starting.
I came up with a really simple init.d script which works, but still starts very late, setting it before some modules messes up other modules.
I tried to see what the script is on the Dexter image, but couldn’t find it. I would really love to know what you use in your image, to implement it on the lighter Raspbian image.
Enabling the serial port also doesn’t really help, it stops pushing out the log after a certain part, seems there is some violation to the GPL of Linux going on here as it is very hard to find out what is happening exactly with your image. I hope I am just being goofy and just too incapable to figure it out though.