SPI Master Example Fix

Question

Hello, 
 i built a SPI Master example based on this: SPI Master example 
 The example is a bit outdated and needed some rework and fix to work. I don't know if i am missing something, but SES complains and refuse to open the example because of some lack of coherence between overlay files and dts configurations. To make it work i had to modify the file: 
 ..
RF
cs\zephyr\dts\bindings\spi
ordic,nrf-spim.yaml 
 In particular, this is how my yaml file is now: 
 # Copyright (c) 2019 Nordic Semiconductor ASA
# SPDX-License-Identifier: Apache-2.0

description: Nordic nRF family SPIM (SPI master with EasyDMA)

compatible: "nordic,nrf-spim"

include: nordic,nrf-spi-common.yaml

properties:
 miso-pull-up:
 type: boolean
 required: false
 description: Enable pull-up on MISO line

 miso-pull-down:
 type: boolean
 required: false
 description: Enable pull-down on MISO line
 
 ss-pin: <--ADDED FROM THIS LINE
 type: int
 required: false
 description: Chip Select (CS) pin
 
 spi-max-frequency:
 type: int
 required: false
 description: SPI bus frequency in Hertz 
 With this modification and some minor changes to code and prj.conffile, adding a jumper wire between pin 11 and 12, the loopback example works with actual SDK. I can share the full project if needed. 
 Frax

Håkon Alseth · Accepted Answer

Hi, 
 
 My apologies for the delayed answer. It has been Easter vacation period here in Norway. 
 
 Thank you for sharing. The SPI sample is currently out-dated, and it is correct; the ss-pin property does not exist, unfortunately. 
 Most driver implementations has its own property for SS pin, as this is essentially a GPIO output that is set/cleared (SPIM doesn't have a dedicated hardware CSN/SS pin). The nrfx_spim driver itself supports handling the SS pin, but this is disabled for the zephyr SPI port layer: https://github.com/NordicPlayground/fw-nrfconnect-zephyr/blob/master/drivers/spi/spi_nrfx_spim.c#L411 
 
 Having one SS pin for a driver only makes sense when you have one sensor that you're communicating with, but when adding more sensors, you want to add more SS-pins and the handling would shift towards the sensor driver instead. 
 
 Regarding atomic operations, these are more towards manipulating a variable without being interrupted, as explained in the documentation: 
 https://docs.zephyrproject.org/latest/reference/kernel/other/atomic.html 
 
 To disable/enable interrupts, this is the section you want to look at: 
 https://docs.zephyrproject.org/latest/reference/kernel/other/interrupts.html?interrupt#c.irq_lock 
 
 Kind regards, 
 Håkon

SPI Master Example Fix

Top Replies