Mikro Pi ADC Reading All Zeros

I was able to resolve the issue after contacting Mikroe directly.  The solution is rather simple.  The Raspberry Pi has two SPI interfaces, but the documentation from Raspberry Pi doesn't mention this.  It walks you through how to enable SPI, but it only enables SPI0.  So when you are done you would see /dev/spidev0.0 and /dev/spidev0.1.  But the ADC on the Pi Click Shield is wired up to SPI1 channel 3, which requires a different method to enable (see Enabling SPI1 on the Raspberry Pi B+/Zero/2/3).  All it took was to add the line:

dtoverlay=spi1-3cs,cs0_pin=16

to the end of /boot/config.txt and reboot my pi.  After that everything worked perfectly.

As an aside, the support from MikroElektronika was good, but the documentation is sparse at best with respect to Raspberry Pi.  The product page has a few links at the bottom, including a couple spec sheets and a link to the sample code.  Hopefully this will help some one else in the future.

Cheers!

I am using the Pi 3 Click Shield for a number of sensors for a project at work. I am horrified that, for a company that seems to want to get into the Pi market, they have such woeful data about how to connect the Click boards and make them work. I've had to pull together bits and pieces from different places, I have multiple breadboards chained together so I can probe individual pins to see what's going on. I wrote to them and suggested they get someone to put together a collection of Python libraries but they seem completely uninterested. I've spent a whole week faffing about trying to get the Noise Click working and your post regarding SPI Channel 3 has been a revelation. All I need to do now is to figure out how to use it!

Thanks so much for sharing.

The Click board range is really very comprehensive, but as I understand some MikroE stuff is not open source, or documented as well as desired. Unfortunately when documentation gets tough, the only solution is to dig out the chip datasheets, and follow the detail there. This is usually not too bad, but does mean some practice is needed examining chip data.

I'm not making excuses for MikroE (and agree with you that sample code from them would help), just suggesting that a usable approach in such circumstances (this also applies to many low-cost boards/modules from China too, and from other vendors too so MikroE are not unique) is to start examining the boards at a hardware level as you have done, and be prepared to write your own libraries.

For example, for many of the simpler I2C or SPI devices, I sometimes prefer to write my own libraries, since they can be less bloated by being tailored for my needs. Also by googling the chip number (rather than the Click board name) sometimes source code can be found.

You're absolutely right, Shabaz.

But I do think it would massively help if they provided a standard level of basic information for all their sensors - the quality of documentation varies wildly.

So yes: I'm writing the low level stuff myself (it's a case of having to!).

Thanks for replying.

You're absolutely right, Shabaz.

But I do think it would massively help if they provided a standard level of basic information for all their sensors - the quality of documentation varies wildly.

So yes: I'm writing the low level stuff myself (it's a case of having to!).

Thanks for replying.