SPIS select pin

RE: SPIS select pin

Edvin — Tue, 13 Oct 2020 13:47:15 GMT

You can of course try to add 0x00's or 0xff's as padding (the same amount of bytes that the "fetch" and "status" messages are.

Unfortunately, there are no events that you can use in between the EVENTS_END, which is the event that triggers the NRF_DRV_SPIS_XFER_DONE event:

spis_irq_handler() -> spis_state_change(p_spis, p_cb, SPIS_XFER_COMPLETED); -> spis_state_entry_action_execute() -> event.evt_type = NRFX_SPIS_XFER_DONE; -> NRF_DRV_SPIS_XFER_DONE -> spis_event_handler().

RE: SPIS select pin

hossein_m — Mon, 12 Oct 2020 15:41:07 GMT

Thanks,
I don't understand your note about "delay spots". Clock speed of this protocol is OK with NRF52840 requirements if that's what you mean.

RE: SPIS select pin

hossein_m — Mon, 12 Oct 2020 15:36:26 GMT

[quote userid="26071" url="~/f/nordic-q-a/67010/spis-select-pin/274372#274372"]Is there any cases where the SPI master will send something other than "Fetch" in the beginning and "status" in the end[/quote]

There are, but for now we only need this part.

[quote userid="26071" url="~/f/nordic-q-a/67010/spis-select-pin/274372#274372"]does it matter that the data is sent before the fetch is complete?[/quote]

I don't think it would be possible, since there is a time delay between fetch and command in the protocol.

Are you suggesting to put command on the output and when SS goes high read fetch and status together?

RE: SPIS select pin

Edvin — Mon, 12 Oct 2020 14:12:21 GMT

Is there any cases where the SPI master will send something other than "Fetch" in the beginning and "status" in the end?

If not, does it matter that the data is sent before the fetch is complete? What happens if the nRF Starts pushing data at the same time as it receives the "fetch"?

Best regards,

Edvin

RE: SPIS select pin

Turbo J — Mon, 12 Oct 2020 13:52:28 GMT

Redesign the SPI protocol. It is not doable with an NRF chip (and BLE running).

Reason is that BLE basically blocks the CPU during radio operation. If that occurs during the Fetch/Slave cycle either the master must wait for a looooong time or the slave will misses the timing. Also the master has no way of predicting when these radio operations will occur.

Very bad for throuput and implementation complexity even in the master.

Side note: If these "delay slots" are small, this protocol would need an FPGA as SPI slave.