Hi @Aubrey Champagne, Welcome and nice to meet you. Ah, let me see. (1) You setup looks correct. (2) For newbies, I usually suggest to do SPI "loop back" test first, to make sure SPI software and hardware (hardware wiring correct, no poor electrical connect, broker jumper wires (sometime bent too often and broken inside and not visible outside).

If you have a multi-meter, you can try "open, short" tests, ie, all point to point connection are shorted (very low resistance， approaching zero), and neighbour points are open, ie not "stuck" together, therefore very very high resistance, approaching 10Mega ohm.

You can google for "UART", "serial", "SPI" loop back test to get a rough idea what is meant by loop back, and the setup (For SPI, MOSI (output) connected/shorted to MSIO (input). then send something out to MSOI, and read back from MISO. If send characters are echoed, loopback to input, then basic steup is OK. WARNING, usually basic out to input short test does NOT check CS pin operation, so not 100% proof.

For spi loopback tests in Rpi python 3.5x and 3.7x, you can search this forum using key words "SPI", "loopback". If you add the search word "tlfong01" you might find a couple of my answers with loopback python test programs, colourful waveforms illustrating the CLK, MOIS, MISO, CSn waveforms. You don't need to understand the details of the programs. My programs are "plug and play/run" no library is required. Though you need to "uncomment" to select slight variation of loopback, say one, two, or three characters, or control characters such a <control x> etc. Happy testing, cheers!

@tlong01 I performed the loopback test, and i got hexadecimal characters, just like the tutorials said I should.

@joan I hooked it straight to 3.3V, and still got 0

Hi @Aubrey Champagne. How nice you have made a successful SPI loopback. Congratulations! Let me tell you why this should be congratulated and the significance or implications. (1) SPI or UART loopback filters away many possible/potential problems, include (a) bad power supply (too low), (b) bad wiring, too long wiring, acting as antenna absorbing noise, especially at high frequencies,

(b) intermittently poor contact connections (better use cable tie to do strain relief). BTW this loopback test is very useful for trouble shooting later, in case your MCPO3008 breaks down, or when you squeeze more SPI devices and crash things.

@tlfong01 I have an extra pi, so tomorrow I am going to use a clean version of Raspian to find the problem. Hopefully it works

I read your tutorial and found the critical function read ADC result is bit complicated, with the following two statements: (1) r = spi.xfer2([1, 8 + adcnum << 4, 0]) (2) data = ((r[1] & 3) << 8) + r[2]. This is the most critical part. You need to understand every word, every symbol, =, &, <<, + etc then you can troubleshoot in case you made a typo error. It is unlikely that your Rpi is bad. It is more likely the human newbie makes a stupid mistake somewhere.

Anyway, you already passed the SPI loopback test, so you are already a junior ninja. Perhaps I should give you another test called "Ping MCP3008 Test", to help you upgrade to middle level ninja! :)

@tlfong01 you can ping the device? I thought there was no way of detecting it through the pi

@AubreyChampagne Well, it depend what do you mean by "ping". Bats ping by sending and receiving signal in the form ultrasound waves. So does submarine pings their friends or foes. For UART/I2C/SPI devices, there are different way of pinging (1) read the "device id" byte in the device id byte. For example, I am playing with AXDL345 accelerator, which has a id register (address 0, if I remember correctly) with an unique byte 0x5b or 0x5e, if I remember correctly.

So pinging simply means reading that register. Another example is MCP23017 or MCP23s17. I usually write to the config reg (address 0x00) a config byte such as setting input or output of its GPIO, then immediately read back, to make sure what I have written can be read back. Some devices have default POR reg contents. So you can just read the default POR byte, ... You might like to read MCP3008 datasheet to let me know how to ping it.

By the way, so you have used loop back to make sure basic wiring, timing etc are ok to do spi send receive bytes with SCL, MOSI, and MSIO. But CSn's are not checked. You can read my old answers on UART/SPI loop back posts the following "Check CSx" trick, WITHOUT using scope, just use a multi-meter. The trick is repeatedly, say 200,000 times doing loopback or repeatedly send a byte (function included in my loopback demo programs).

And at the same time check the voltage at CSn, if CSn jumping up and down, multi-meter should read around 3V3/2 == 1.7v (actuslly it is not simple average, but rms) Of course you can also use your cheapy meter to check other SPI pins, ...

Now you can try to test (1) CS pin is working, (2) ping MCP3008. Then you can claim yourself a junior SPI ninja, :)

Now I have uploaded your wiring and my pinout to compare.

Everything looks so far so good.

Update using multi-meter to measure CS pin voltages. Earlier I mentioned that you can use multi-meter to measure the average/rms voltage of the CS pin which toggles between Low level (when select device) and High level when not selecting device. The more precise voltage depends on how frequent you repeat the chip select device.

So if you don't select any device, CS should measure around Vcc of 3.3V. If you repeat select device, CS pin level would drop to Low level more if more frequently selecting devices. I experiment with repeatedly sent one byte (as in my loopback back test demo functions), with 1mS/10mS pause between selection, CS as measured by multimeter drops to about 2.7V. Anyway, if CS is around Vcc 3.3V, and drops to below 3V when repeated sending bytes, then it is very likely that CC is working OK.

To conclude, if loopback OK, then CLK, MOSI, MISO are OK. And if CS when not repeatedly sending bytes and repeatedly send bytes, multi-meter measured voltage is around 3.3V and below 3V down to 2.7V, then CS should also be working OK.

Now let us see how to pink the one. First we, need to read the datasheet, and focus at the SPI write read bytes details. The following is the most critical picture.

Now I am thinking of "ping" as send/receive three bytes as below.

Let me see, the first send byte is 0x01, second send byte = sing/diff d0 d1 d2 xxxx.

First receive byte = ????? Null B9 B8, Second Receive Byte = B7 to B0.

Now I am going to modify the loopbackThreeBytes function to pingMcp3008 function, as below.

In other words, first second send byte = start bit and sin/dif d0, d1, and d2.

Second and third receive byte contains 10 bit ADC results.

Thank you so much for the help with understanding this chip