GrovePi support

[lucavallin]

Hello, I tried to make Gobot work with my GrovePi (https://www.dexterindustries.com/grovepi/) but no success. I can't actually understand whether this is supported at all. So, is it?
Or should I add a new adapter to use this?

This is how I currently interact with the GrovePi without Gobot: https://github.com/lucavallin/hytta-pi/blob/master/cmd/hytta/main.go

[deadprogram]

Hello @lucavallin there is not yet GrovePi support for Gobot, but it looks like a relatively modest task to add a new i2c Driver for it, and then implement the DigitalReader/DigitalWriter and AnalogReader interfaces.

Let me know if I can be of assistance. I have a GrovePi+ around here in the lab somewhere...

Thanks!

[lucavallin]

Hey @deadprogram! Thanks for your reply: I'd like to give it a shot, just starting with this kind of low level stuff so it'd be good for me to play around with it. However, do you know if there's documentation about the architecture of Gobot? Like, besides adding a dexter driver for the GrovePi, do I need to take care of anything else?
I am going to work on it this week, maybe the next one as it's getting busy now.

[lucavallin]

Started to work on it, however not very clear to me the bigger picture (is this a platform? or a driver?).

Anyways, this is it so far: https://github.com/lucavallin/gobot/blob/feature/grovepi-i2c-driver/drivers/i2c/grovepi_driver.go

I'm not sure about the read methods in particular... I used to specify a size for the amount of data to read. I don't see support for that in the i2c connection we're using... any suggestions?

[deadprogram]

Hi @lucavallin I think the functions you are looking for are d.connection.Read() and d.connection.Write().

I would expect your implementation of AnalogRead() to be something like this:

func (d *GrovePiDriver) AnalogRead(pin string) (value int, err error) {
	nPin, err := strconv.Atoi(pin)
	if err != nil {
		return 0, err
	}

	if _, err = d.connection.Write([]byte{CommandReadAnalog, nPin, 0, 0}); err != nil {
		return
	}

	time.Sleep(100 * time.Millisecond)

	if _, err = d.connection.Write([]byte{1, 1}); err != nil {
		return
	}

	val := make([]byte, 4)
	_, err = d.connection.Read(val)
	if err != nil {
		return
	}

	return ((int(val[1]) << 8) | int(val[2])), nil
}

[lucavallin]

I see, looks good, that should be enough for me to go on with it.
Still two questions tho:

• You're doing strconv.Atoi(pin) but, pin can be "D7" or "A2" for example, is there a particular reason why these values should be converted to int?
• (int(val[1]) << 8) | int(val[2]) : I understand we're left shifting int(val[1]) by 8 bits and then OR it with int(val[2]). But why are we doing so? Also why are casting it to int first? (Just lacking some knowledge on this one!)

Thank you!

[deadprogram]

The only reason for the mapping to "int" is that is seems like that is what is expected by the GrovePi's i2c interface.

That, along with the bitshifting, I copied from the @DexterInd repo here https://github.com/DexterInd/GrovePi/blob/master/Software/Go/grovepi/grovepi.go#L67

Also, looks like a 0x1 needs to be written as the first byte in any command sent to the GrovePi. Which means that the code above should actually be changed to this:

if _, err = d.connection.Write([]byte{1, CommandReadAnalog, nPin, 0, 0}); err != nil {
	return
}

I have not found my GrovePi yet, so I have not been able to test it out myself.

[lucavallin]

Thanks again! Tonight I will play around with it a bit more :)

[lucavallin]

Update: I've successfully implemented DigitalWrite. Now I can turn on my leds...
One more question: in my project I have digitalRead, analogRead and dhtRead. The last one is basically a digitalRead, but it does something extra on the raw data because the DHT sensor sends a few bits, but some represent the humidity and some other the temperature. I think this should go to some kind of "parser" but I don't think we have such concept here. Where do you think that operation belongs?

[deadprogram]

The DHTXX is a pulse based device, similar to some ultrasonic range finders. There is in fact already an issue discussing this #361

The "best" solution is probably to use some edge-detection/epoll type solution. Some ongoing work in this area within Gobot, but still as of yet not released anywhere.

[lucavallin]

Alright, thanks. Not directly related but good for the record: https://www.dexterindustries.com/GrovePi/programming/grovepi-protocol-adding-custom-sensors/

[lucavallin]

Update: I just ordered a digital sensor from which I can read from, with this I should be able to add the digitalRead part

[deadprogram]

Hi @lucavallin any chance of still getting a PR for this?

[lucavallin]

Hi @deadprogram, need to check what I have left. I remember I had the digitalwrite working but no tests, then I moved to arduino because it's just simpler to work with. Will check asap.

[lucavallin]

@deadprogram No luck so far, I don't think I'll be submitting a PR any soon, sorry!

[deadprogram]

Thanks for the update, @lucavallin

[deadprogram]

Hi @lucavallin I've just merged into the dev branch a driver for the GrovePi based to some extent on the code from your branch.

https://github.com/hybridgroup/gobot/blob/dev/drivers/i2c/grovepi_driver.go

It implements the DigitalReader, DigitalWriter and AnalogReader interfaces, so you can just use it with any of the GPIO or AIO drivers. Here are a couple examples:

https://github.com/hybridgroup/gobot/blob/dev/examples/raspi_grove_pi_button.go
and
https://github.com/hybridgroup/gobot/blob/dev/examples/raspi_grove_pi_rotary.go

Should be useful for anyone with the @DexterInd hardware. I will have to acquire a GrovePi Zero to test if that also works in the same way.

[lucavallin]

Hi @deadprogram, that's awesome news! I will take another look at it so I can see what I was missing, maybe I can help maintaining too or something... Thanks!!!

[lucavallin]

Hi @deadprogram, just got back from my holidays, the driver works nicely, approved!

[deadprogram]

This was just release as part of v1.12.0 thank you. Now closing.