SPI on A5..A7 not accepted... - ERROR: Pin A5 is not capable of SPI SCK...

Wanted to use A5..A7 for SPI CLK, MISO, and MOSI as Espruino 1v3 board specification lists

SPI2.setup({sck:A5, miso:A6, mosi:A7, baud: 1000000});

but get the following console output:

 1v70 Copyright 2014 G.Williams
>echo(0);
ERROR: Pin A5 is not capable of SPI SCK
Suitable pins are:
B13
undefined

Do I miss something here?

A5-7 is SPI1, not SPI2.

There must be more to how the x in SPIx of code maps the n in SPIn of the board description at http://www.espruino.com/ReferenceESPRUINOBOARD, because SPI1 is mentioned twice...

Intuitively from the code and the reference I mistakingly(?) concluded that the SPIx, x=1..3, are just three instances of code SPI, and the setup assigns the actual pins. For sure that is not correct... and for sure the error message wrong or at least fuzzy, but it seems not to be the only thing behind the mapping and the reference of SPI1 twice and SPI3 sharing pins with SP1 for some cases.

A better error message would say something like:

Suitable pins are: A5 B3(AF) ```

because setup knows obviously for what x it is...

Btw, above message hints that B3 uses a different pin setup than A5... that may be the issue that I'm having in communication with F RAM in post http://forum.espruino.com/conversations/257994

A bit confusing... (not only here but there as well... most likely I did not yet come across the doc that explains the details 'here' as well as 'there').

There are 3 SPI peripherals (physical bits of hardware) and you can choose which pins these map to - but you don't get much choice. Most peripherals have very simple choices:

• Use pin set 1 (eg A5/6/7)
  
• Use pin set 2 (eg B3/4/5)
  
  

Sadly you don't just get to choose exactly what you want where... Unless you use 'software' SPI

@Gordon was thinking along your lines... Software SPI? ...but not supported (yet) in Espruino's firmware, correct?

Yes, it is supported... Just use it like this:

var spi = new SPI();
spi.setup({sck:A5, miso:A6, mosi:A7});
var nrf = require("NRF24L01P").connect( spi, B0, B1 );

Ic... first I though software SPI is on ANY pin - but it meant to say: an SPI object on any of the SPI supported pin sets.

Instead of using the existing SPIx (instances), I crate a new one (from the SPI 'class' definition). That is the part I missed. Then I can call it what ever I want... like:

var spiLCD = new SPI();  spiLCD.setup(...); ...
var spiFRAM = new SPI();  spiLCD.setup(...); ...
var spiWifi = new SPI();  spiWifi.setup(...); ...

This are all my SPIs I have to work with. And since the onboard SD card sits fixed on one of the SPI pin sets, I already have to use the chip select. As long as the baud rate is compatible (I don't know if baud rate can switch after setup/connect), sharing the the pin sets should not be too much a challenge (I have another SD card in the game: the sd card on the display break out board, and it does not have separate pin outs... if I want to use it, it looks that I have to do some hardware setup - open/close solder-'jumpers'.

My understanding is that software SPI (ie, created with new SPI() ) can use any pins, not just any set of SPI pins.

It doesn't let you set the baud, like the hardware SPI's do - it goes as fast as it can, and that works for a lot of hardware.

The F RAM is able to handle up to 40 MHz. With a 72 MHz clocked machine that takes care of bits with software, the free running clock / baud could be a high single digit to low two digit fraction.

@DrAzzy, with a free running clock / baud rate, is the clock regular enough?

The clock on software SPI won't be that regular - it'll be fast, with pauses between bytes. If you need solid timing, just use hardware SPI.

edit: I'm still not convinced the device will care that much about timing - especially as it can take such a wide range of input speeds. After all, that's what the clock is for...