Dexter Industries GrovePi Zero

I bought one of these because I needed a few analog inputs and a quadrature encoder input to a raspberry pi. I was hoping to just be able to use it as-is.The hardware is well done, but has a number of really bone-headed design decisions that make it less useful then it could be. Basically, the ATmega328P has 6 analog/digital pins. This board has 3 2-input analog inputs. You'd think that means the board has 6 inputs, right? Nope! For some spectacularly dumb reason, the analog in pins are shared across connectors, so you only actually get 4, and the last two analog input pins on the ATmega are just *not connected to anything*.This is also true of some of the other peripherals. For example, there's no reason the ATmega's USART couldn't be connected to the Pi's serial interface. If you don't enable it, it doesn't do anything, and the exposed serial connector would just work as normal. Did they do this? Nope! The serial interface on the ATmega is completely unconnected. They could have at least made the pins available on a connector!All these issues aside, the major, MAJOR problem with the board I ran into is the software. It is, to put it politely, really really terrible.For example, quadrature encoders are simple. They basically provide a + or - direction, and you integrate that to get the rotation. If you rotate it twice, you get 2 * pulses per rev. Does their implementation do this? NOPE. For some completely bizarre reason, they seem to be trying to use the encoder as a angle sensor (or something), so it wraps around to 0 at a small number of counts (I think 24). This is completely useless, and with a large CPR encoder (I'm using a 100 CPR encoder), you can't get anything meaningful out of it.Additionally, the python wrapper they have is also full of bizarre design decisions, and extremely unstable. I'm doing user-interface stuff, so I basically need to read the inputs at >= 30 hz. However, for no reason I can think of, they have a bizarre structure where there are 0.2 SECOND sleeps in the I2C interfacing routines to the hardware.It's also EXTREMELY unstable. If you just run a while-loop polling the hardware it will throw an exception within a few minutes, in general.On top of all this, I think the people writing the library didn't understand I2C. Basically, a I2C read is done by writing the address you want to read, and then doing a normal read. Since you write the address, you'd think it'd be easy to implement a memory-mapped peripheral interface, so that the different hardware modes are driven by the address. Is that how it works? NOPE. Instead, to read one of the IO, you instead issue a plain write to address zero (which is ALWAYS 4 bytes, for no reason), with the address value being ignored completely. You then issue a normal write to prepare the read, and THEN read your data.I can't think of any reason to do it like this, aside from not understanding how I2C addressing works.I made the hardware work for my application, but I did so by completely replacing all the software. I wrote my own program that runs on the ATmega, and am just using the python smbus package to talk to it directly (this is what their library uses too). The code quality of the default ATmega program is.... pretty bad. It may work (most of the time), but it's INCREDIBLY sloppy, with mixed indentation, tons of one-letter global variables, and lots of just odd crap.Basically, If you REALLY need a Pi-connected ATmega board, this is.... workable. If you want a stable platform to learn with, definitely look elsewhere.

Good Price!!

It works just fine on a Pi zero.

All of Dexter Industries are excellent.

It doesnt work on Raspberry Pi Zero W.