No clock when using the SPI library (Uno R3)

Development Tools IDE 1.x
1

I can't seem to get a clock signal generated on my Arduino Uno R3.
Example code includes the Examples -> SPI -> BarometricPressureSensor sketch, this one:

#include <SPI.h>

void setup() {
  pinMode(13, OUTPUT);
  SPI.begin();
}

void loop() {

}

and this one:

#include <SPI.h>

void setup() {
  pinMode(13, OUTPUT);
}

void loop() {
  digitalWrite(13, HIGH);
  delayMicroseconds(2);
  digitalWrite(13, LOW);
  delayMicroseconds(2);
}

The first one, with SPI.begin(), gives 0 voltage on pin 13 at all times. The second sketch with the manual square wave works.

To be honest, I don't have an oscilloscope at the moment... so I tried to measure the voltage with a DMM, with a cap in parallel to charge up. With SPI, I get 0.00 V. With the manual square wave, I get ~2.3 volts. Seems to work.

I have the full code of my actual project available here, but I don't see why it would matter if the barometer sketch doesn't work. Needless to say, this gives the same result as the ultra-boiled-down SPI code above.

Any ideas? :~

2

There are clock pulses only when the SPI is used to send/receive. You are not sending anything.

3

Oh, that easy, huh? Though in that case, I'm lost as to why the code in the link isn't working. Any ideas?

Edit: To add a few details. I've tried different clock dividers, all in range for what the chip can do (the breadboard probably limits, but <1 MHz is also a no go), as well as different modes (0/3) for clock phase and polarity. I know that the MSB should come first, so I haven't tried LSBFIRST.

4

In your project code's setup() routine you have:

digitalWrite(SS_PIN, HIGH); /* unselect the device */

That blows you out of the water :slight_smile:
If you set pin10 high, it forces the Arduino SPI code into slave mode. You must NOT set pin10 high.

Pete

5

According to the docs, setting the default SS pin to INPUT sets slave mode. As long as it is OUTPUT, it can be HIGH or LOW and still be in MASTER mode.

6

Setting SS to HIGH seems to not be the problem, indeed. :confused:
I changed SS_PIN to 9 and moved the wire, same problem.

7

In that code, this is the source of the clock pulses.

  digitalWrite(SS_PIN, LOW); /* CS is active low */
  Serial.print("Sending data: 0x"); Serial.println(out, HEX);
  // These would cause clock pulses
  SPI.transfer(out & 0xff00);
  SPI.transfer(out & 0xff);
  digitalWrite(SS_PIN, HIGH);
8

SurferTim:
According to the docs, setting the default SS pin to INPUT sets slave mode.

Yes, you're right. I can't read and understand my own notes!

But, even if you don't use pin 10, you must still set it as an output.

Pete

9

and in that code, this statement won't do what is probably intended and expected:

SPI.transfer(out & 0xff00);

You have to shift the high end byte down to the low order.

SPI.transfer(out >> 8);

Pete

10

The default SS pin must remain an OUTPUT for master mode.
According to the docs, SPI.begin() will set all the SPI pins correctly, including the default SS pin to OUTPUT.

There are no clock pulses unless you are using SPI.transfer(). If there is no device listening, it would not matter what you transfer if all you want is clock pulses. You could transfer all zeros or all 255's.

edit: If you haven't seen the maths to this, every call to SPI.transfer() generates exactly 8 clock pulses. There are no clock pulses generated between calls. If you were looking for a continuous clock pulse train there, that isn't it.

11

My source of info about pin 10 derived from a comment in the listfiles example code in the SD library distribution:

// Note that even if it's not used as the CS pin, the hardware SS pin
// (10 on most Arduino boards, 53 on the Mega) must be left as an output
// or the SD library functions will not work.

Sometimes the online docs are not correct, or are at least imprecise. It would be interesting to know for sure which of these is correct.

Pete

12

It sets the SS pin to OUTPUT. If you have an Uno, that is pin 10. If you have a Mega, that is pin 53. But in either case, if you use SPI.begin(), it gets the correct pin.

13

I decided to experiment to find out if that comment is right. I used the SD library's readwrite example.
First I compiled it as distributed just to be sure it worked and indeed it does.
Then I changed the code so that it uses pin6 as the chip select and wired the SPI SD card accordingly. That works fine too.
Then I added a statement after the SPI initialization to set Pin 10 as an input, which according to the comment should have caused problems. It didn't. I even tried writing a 1 to pin 10 and it still worked.
So, the comment was wrong.
BTW. This was on a Nano (328) with IDE V1.0.1.

Pete

14

el_supremo:
and in that code, this statement won't do what is probably intended and expected:

SPI.transfer(out & 0xff00);

You have to shift the high end byte down to the low order.

SPI.transfer(out >> 8);

Pete

Ahh, goodness, and I missed that reading through the code several times. Thanks! It works now. :slight_smile: