SPI woes

I've been going through hell using SPI to communicate with a digital potentiometer.

Check this out:
I send this to Espruino:

SPI2.setup({scl:B13,miso:B14,mosi:B15});­

digitalWrite(C4,1);

var digipot=require("MCP4xxxSPI").connect(SP­I2,C4,1,128);

so digipot.getVal(0) should return 319 (actual value is 63, but it's adding 256 to it due to a bug in my module code - not accounting for differences between parts). Look what happens!

 _____                 _
|   __|___ ___ ___ _ _|_|___ ___
|   __|_ -| . |  _| | | |   | . |
|_____|___|  _|_| |___|_|_|_|___|
          |_| http://espruino.com
 1v69 Copyright 2014 G.Williams
>echo(0);
=undefined
>digipot.getVal(0);
=0
>fs.readdir("");
=[
      "BlackBerry",
      ".Trash-1000",
      "dash"
    ]
>digipot.getVal(0);
=319 
> 

I have had it in failing state for hours, then one file system access, and bam, it's fixed.

Module code is here:
https://github.com/SpenceKonde/EspruinoD­ocs/blob/master/devices/MCP4xxxSPI.js

Could it be to do with the SPI clock speed? The SD card code sets it to 1000000, so you could try specifying that when initialising SPI2 and see if that helps?

Identical behavior when I changed my code to this:

SPI2.setup({scl:B13,miso:B14,mosi:B15,ba­ud:1000000});

digitalWrite(C4,1);

var digipot=require("MCP4xxxSPI").connect(SP­I2,C4,1,128);

Interestingly enough, once it has worked, reset() doesn't make it stop working. IE, if I do the above, then fs.readdir(), then press "send to espruino" again (resetting the espruino), it works immediately without having to do anything.

It's something in the espruino - if I power cycle the part after making it with with fs, it continues to work.

if I power cycle the part after making it with with fs, it continues to work

Not sure I understand what you're saying?

I think I know what the issue is. Try changing scl: to sck: :)

It doesn't error because it's perfectly valid to not want sck to be brought out on a pin. If you don't mention it, it won't be set up.

Strange that reset() doesn't stop it working though. The pin states are all set back to defaults so I'm not sure I get why it would then keep going.

Wow...

Just wow. If that's what it is, I hang my head in shame! That's the code I was sending, copy/pasted out and all...

And I checked that I had the right several times, but somehow I think I got the abbreviations backwards, and was explicitly checking that I had it saying scl, because I was convinced that was what it was.

Very expensive error - over 5 hours of time spent debugging this. I was going crazy, doing things like ohming out the wires, checking every combination of pins for shorts, etc. Had it not been for this, I'd have two more modules tested and submitted, plus more sleep.

:( I've done the exact same thing before too. I suppose it would make a lot of sense to actually test for unexpected things in the object and warn about it... I'll file an issue.

In this case it makes it worse that I2C uses scl and SPI uses sck :)