You must be logged in to reply.

Page 1 of 2 out of 18 messages.

SPI TinyClr

Posted 1yr ago
by Bauland | Master | 6,336 exp
Posted 1yr ago
by Bauland | Master | 6,336 exp
I know TinyClr is not mature, but I've problem with SPI.
I want to code a driver for nRF8001 BLE module.
I need to share CS pin between SPI and Gpio. Is there a way to do that ?

In NETMF 4.3, when declaring SPI, in configuration GPIO_NONE can be passed:
_rst = new OutputPort(rstPin, true); 
_req = new OutputPort(reqPin, true); 
_rdy = new InterruptPort(rdyPin, false, Port.ResistorMode.PullUp, Port.InterruptMode.InterruptEdgeLow); 
_spi = new SPI(new SPI.Configuration(Cpu.Pin.GPIO_NONE, false, 0, 0, false, true, 100, spiModule));

So CS (_req in code), musn't be shared.
Reply #1 — Posted 1yr ago
by PHITEK | Senior | 2,250 exp
Reply #1 — Posted 1yr ago
by PHITEK | Senior | 2,250 exp
@Bauland - Using a SPI chip select as a GPIO could cause problems in several areas:
1. If the state of the SPI clock, MOSI changes when in GPIO mode, this may cause side effects to the SPI device(s).
2. Just changing state on the chip select signal could have side effects on the internal state of the SPI device.

Is you design I/O pin bound?

Phil
Reply #2 — Posted 1yr ago
by Bauland | Master | 6,336 exp
Reply #2 — Posted 1yr ago
by Bauland | Master | 6,336 exp
@PHITEK - No that's not my design but design of module...
Reply #3 — Posted 1yr ago
by PHITEK | Senior | 2,250 exp
Reply #3 — Posted 1yr ago
by PHITEK | Senior | 2,250 exp
@Bauland - Interesting, can you provide a schematic that shows the shared SPI chip select and GPIO. I know your question is about TinyClr not been able to share the these signals. But I want to understand the hardware case for the designing a module where there is a possibility of side-effects.

Phil
Reply #4 — Posted 1yr ago
by Bauland | Master | 6,336 exp
Reply #4 — Posted 1yr ago
by Bauland | Master | 6,336 exp
Thanks PHITEK to take time.

Full documentation of chip is here: https://www.nordicsemi.com/eng/nordic/download_resource/17534/16/19304811/2981.

Here some extract:
However, nRF8001 does not behave as a pure SPI slave device; nRF8001 can receive new data over-theair
at any time or be busy processing a connection event or new data. Consequently, the traditional CSN
signal used to initiate an SPI transaction is replaced by two active low hand-shake signals; RDYN and
REQN.
These hand shake signals allow nRF8001 to notify the application controller when it has received new data
over-the-air and also to hold new data exchanges initiated by the application controller until it is ready to
accept and process them. The ACI connections are shown in Figure 7.
1 like
Reply #5 — Posted 1yr ago (modified)
by PHITEK | Senior | 2,250 exp
Reply #5 — Posted 1yr ago (modified)
by PHITEK | Senior | 2,250 exp
@Bauland - After looking at the datasheet for the nRF8001, their use of the "chip select" does have a dual purpose which is a request a transaction and wait for the "RDYN" from the nRF8001 to indicate it is ready for a SPI transfer to begin. This is not a typical SPI bus transaction, hence your request to share a GPIO line with the SPI chip select seemed odd to me.

In looking at the Trr timing (page 26) there is no max. time giving to wait to the "RDYN" signal to indicate that the nRF8001 is ready. Note 1, does say this will take up to the time of a "radio event" plus the typical response time. I could not find any timing for "radio event" so this maximum time to wait is unknown to me. It may exist in the Bluetooth protocol how ever.

I was going to suggest that .NETMF typically sets the SPI chip select active well in advance of the data transfer, but with out knowing what the maximum time to expect before the nRF8001 will respond with "RDYN" this would not be reliable.

The one solution I can see is to build you own SPI bus protocol in software accounting for the "RDYN" pin. Yes would be quite slow.
Another solution would be to select an unused GPIO pin for the nRF8001 chip select line in the SPI.Confifguration (or possibly your code of GPIO_NONE may work), the before starting a SPI bus transaction, have a software bring "REQN" active (low) and then have the software poll for the "RDYN" signal to go active (low) then call the _spi.WriteRead method. There would be some extra delay, as the .NETMF time to assert the fake chip select is kind of wasted, but likely faster then the software SPI solution.

Good luck
Phil

P.S. This was kind of inline with my original post concerns that the SPI chip select can cause the SPI device to change state, at least the vendor described the behavior in your case.
1 like
Reply #6 — Posted 1yr ago
by Brett | Superhuman | 125,590 exp
Reply #6 — Posted 1yr ago
by Brett | Superhuman | 125,590 exp
from a hardware perspective, can you not jumper two pins together so you can use one as the traditional CS and one as the IO pin?
1 like
Reply #7 — Posted 1yr ago
by PHITEK | Senior | 2,250 exp
Reply #7 — Posted 1yr ago
by PHITEK | Senior | 2,250 exp
The unused chip select pin declared in the SPI.Configuration statement, in the second solution does not connect to any other device. The software controlled "REQN" signal connects to the nRF8001 chip select. The "REQN" signal request the start of a SPI transaction, the software must then wait for the "RDYN" pin to go active, the "REQN" is also held active (low) till after the WriteRead method returns when it is then returned to the inactive state (hi).

The "REQN" is an output from the .NETMF hardware and the "RDYN" is an input to the .NETMF hardware. It is the "RDYN" signal that causes the issue, as this signal is used to do flow control of the SPI bus transactions.
Reply #8 — Posted 1yr ago
by Bauland | Master | 6,336 exp
Reply #8 — Posted 1yr ago
by Bauland | Master | 6,336 exp
So if I understand, I must have a :
  • REQN signal as digital output signal,
  • RDY signal as input signal,
  • CS for SPI as an unused pin (just to let SPI think it is a true pin)
  • MOSI/MISO/CLK as usual SPI pin
Reply #9 — Posted 1yr ago
by Bauland | Master | 6,336 exp
Reply #9 — Posted 1yr ago
by Bauland | Master | 6,336 exp
Brett says:
from a hardware perspective, can you not jumper two pins together so you can use one as the traditional CS and one as the IO pin?

I prefer to not jumper pin together to avoid case where one is 1 and other is 0 !!!

Page 1 of 2 out of 18 messages.

You must be logged in to reply.