Hello,
I have came across with a weird glitch.
When I connect Grove Pi to Raspberry Pi 4 and then power up the Raspberry, Grove Pi is not detected also not communicating.
However, if I power up the Raspberry Pi and then connect the Grove Pi, it is detected and communicating.
What may be causing this? If I use it like that, will I encounter with any problems?
As far as I know Grove Pi does not work on Raspberry Pi 4 and from the lack of the response by the experts from DexterIndustries shows that they have no interest in updating the library anytime soon.
Hi all,
I’m sorry we never responded to this first post @hakan.eko2013. Dexter Industries was incorporated into Modular Robotics in late 2019 and there was a gap in coverage on the forum by our team.
The GrovePi is compatible with a Raspberry Pi 4, although you may want to first boot up using a previous version of the RPi. It’s true, the Dex GrovePi libraries haven’t been updated in a few years.
Please shoot us an email at support@modrobotics.com if you’d like our team to take a closer look. Let me know if you have any questions,
Sorry, I am not sure what you mean by compatible. Problems on Raspberry Pi 4 Model B still present in your latest update. For example, intermittent failure to control LED, software stalling when reading analog value, etc. You should try on Raspberry Pi 4 yourself to see these problems.
I’m using a Pi-4 and the 12/19 release of Raspbian for Robots for my GoPiGo 3.
What O/S are you using?
Raspbian
VERSION_ID=“10”
VERSION=“10 (buster)”
VERSION_CODENAME=buster
Is that a plain-vanilla download of Raspbian/Raspberry Pi O/S or is that one of the Raspbian for Robots images?
If it is NOT one of the Raspbian for Robots images, I would suggest downloading and trying this with the 12/19/2019 image of R4R Buster.
Though you can download and install the required libraries, and people have reported success with it, I would strongly suggest using an “official” image from Dexter/Modular Robotics as it will be easier for them to support and troubleshoot.
Also, do NOT try this with a 64-bit image yet. Though I am experimenting with building an image of R4R on a 64-bit version of Raspbian, it’s a moving target, and I have not yet got a build to work yet.
Stick with the tried and true software. Try spinning your own builds once you know it works with “standard” versions of the software.
Disclaimer:
Not only do I NOT work for Modular Robotics, (I’m an experimenter like yourself), I don’t even have a Grove board. All my experience is with the GoPiGo, but a lot of the problems I, and others, have experienced are common to most every system.
You have a point there and thanks for the suggestion. We have over 30 units of Raspberry Pi 4 Model B and I don’t intend to use older release of the OS and get locked into it because of Grove Pi.
I hacked a bit the Grove Pi library and its dependent code (di_i2c.py to be precise) to get it to work. However, once a while it stalls in the while-loop of read_identified_i2c_block(.) due to the SCL being pulled low indefinitely. I need to manually reset the ATMEGA MCU to release it. At the moment, I don’t have much time to look into the problem.
All of these libraries are open-source with a MIT license, (@cleoqc, can you confirm this?), so you can respin them any way you need to. (with the proper attribution, of course)
All we ask is that you share the modifications with the rest of us by feeding back changes upstream.
Yes, sure. I will share the modifications once I have checked that it works reliably. But at the moment, it is still buggy. After a failure, sometimes I need to reboot the RasPi to recover. At times, I just need to reset the Atmega. Very often, rerunning the program would do.
I dumped and studied the I2C transmission data of one of the problematic modules (DHT11) and having grokked the firmware source code (ATmega328P), I suspect the main cause is due to the way it handles the reply when data is not ready and ready.
I will feedback more when I have some spare time for this.
Do you know that the Raspberry Pi has a bug in the hardware based I2c?
What happens is that in certain very specific conditions, the Pi screws up clock stretching.
Dexter/Modular Robotics solved this problem by implemting a special software based interface.
You can read more here:
Yes, I knew about it. Somewhere in this forum, I read a post mentioning the decision to use the bit-banged I2C was because of that reason. But that is another issue.
The one that I brought up here is about the problem with the bit-banged I2C implementation in di_i2c.py. It does not work well with a faster CPU clock than the one it was written for. A quick fix is to insert delays at various points to slow it down so that the signals are not so badly distorted. I don’t like this bit-banged implementation. Dexter Industries should have instead used either UART or SPI.
The second issue is the firmware on the ATMEGA MCU. It handles rather poorly the incoming I2C read requests when data is not ready, so much so that, in the worst scenario, it goes out of sync with the requester after many retry attempts. Once that happens, the communication fails resulting in Python code stalling. My current quick fix to this is to delay sufficiently between a write-command-request and its read-data-request to avoid the data-not-ready issue. This means I have to estimate how long the MCU takes to process a request for each Grove Pi module that returns data. This is not an ideal solution, but it works for me. The best is to fix the firmware code. I think I have a solution for it, but at the moment I have very limited time. If I managed to fix it, I will issue a GitHub pull-request.
p/s: The Grove Pi modules with I2C interface communicate directly with Raspberry Pi. The code examples that I saw use hardware-assist I2C instead of the bit-banged I2C version; maybe because the modules do not do clock-stretching.