next topic »

[on:]

I noticed during SPI testing that there is a weird glitch in the SS line. Maybe it's my fault - would be glad to hear that.
Here's my code:

Code:

#include <SPI.h>

const int sspin = 10;
const int mosipin = 11;
byte val = 0x18;

void setup()
{
// Digital pins are: SS=10, MOSI=11, MISO=12, SCK=13
pinMode (sspin, OUTPUT); // must be guaranteed to be output
pinMode (mosipin, OUTPUT);
SPI.setClockDivider(SPI_CLOCK_DIV32); // => 500 KHz
SPI.setBitOrder(MSBFIRST); // endian
SPI.setDataMode(SPI_MODE0); // clock idles low
SPI.begin(); // => SCK and MOSI low, SS high
}


void loop()
{
digitalWrite(sspin, LOW); // enable slave
SPI.transfer(val);
digitalWrite(sspin, HIGH); // disable slave
}

And here's the trace - notice the quick bursts in the SS line
Can~t insert image - attached instead (however that works)

[Reply #1 on:]

If we unravel the loop once we get this:

Code:

digitalWrite(sspin, LOW); // enable slave
SPI.transfer(val);
digitalWrite(sspin, HIGH); // disable slave   <--- "glitch" here
digitalWrite(sspin, LOW); // enable slave
SPI.transfer(val);
digitalWrite(sspin, HIGH); // disable slave

I would expect a brief high followed by mainly low. That's what you have written.

[Reply #2 on:]

Nick, that just leads one to wonder why the wide pulse of SS High then? Which I would submit is the commanded high followed by the code wrapping around back the start of the void loop.


The high glitch gives the appearance of occurring in the middle of this transfer
SPI.transfer(val);

Is the extra rising edge bothering anything in the circuit? Like prematurely moving data from the input register to the output register? If so, you may want to do something to take care of that.
Do you see that happen on other pins as well?

[Reply #3 on:]

Nick, that just leads one to wonder why the wide pulse of SS High then? Which I would submit is the commanded high followed by the code wrapping around back the start of the void loop.

Yes I was wondering about that too, but I assumed it was too large to be called a glitch.

I should point out too that the order of operations in the setup is a bit suspect. Check out what SPI.begin does:

Code:

void SPIClass::begin() {
  // Set direction register for SCK and MOSI pin.
  // MISO pin automatically overrides to INPUT.
  // When the SS pin is set as OUTPUT, it can be used as
  // a general purpose output port (it doesn't influence
  // SPI operations).

  pinMode(SCK, OUTPUT);
  pinMode(MOSI, OUTPUT);
  pinMode(SS, OUTPUT);
 
  digitalWrite(SCK, LOW);
  digitalWrite(MOSI, LOW);
  digitalWrite(SS, HIGH);

  // Warning: if the SS pin ever becomes a LOW INPUT then SPI
  // automatically switches to Slave, so the data direction of
  // the SS pin MUST be kept as OUTPUT.
  SPCR |= _BV(MSTR);
  SPCR |= _BV(SPE);
}

So the SPI.begin () overwrites some of the stuff you (maxmike) did before calling it. I can't really explain why SS becomes high during the transfer, except maybe the circuitry itself is responsible?

[Reply #4 on:]

Looks like this may be a problem with the display instrumentation.
If I remove CLK from the display I don't see the glitches any more.
Thanks for the comments everybody. I will talk to the guys that
built the MSO19 I'm using.  
OTOH the MSO19 is attached to a 2.4 GHz dual processor Windows server and the fast
sample/display may be more than ol' Windows can handle on that machine.
Will try on an XP asap.