nRF24

[Turbinenreiter]

I just started to work on the nRF24, but I got stuck and then I remembered - the nRF24 was one of the stretch goals!
Has there been any work done on it yet?

I also found a module for the raspi - https://github.com/r3ek0/python-nrf24

I'm gonna try to port it/use it as bluprint.

[Turbinenreiter]

I gave up on this.
It uses SPI, which should be easy, but whatever command I send, I only get 0xff's back.

[dhylands]

SPI is an interesting protocol, since it's essentially full-duplex all the time.

In order to read you need to write, and whenever you write you also need to read.

So normally for every write you need to do a dummy read, and in order to actually read data you need to write dummy data.

Looking at the micropython SPI implementation, it looks like when you call send it internally reads and tosses the incoming data, and when you do recv it transmits dummy data. send_recv does writes data and collects the results. So which one you use when will depend on the particular device. Most of the SPI devices I've used are normally what I call half-duplex, you either logically send or recv but not both (so you need to be aware of the dummy data thing). More sophisticated devices may do both.

I'm not familiar with the nRF24, but I know that the way SPI works often trips up people who just start working with it.

The other thing to do is to check the chip select and make sure that it's hooked up and behaving properly. If the device doesn't sense the chip select then it will act like a black hole.

[Turbinenreiter]

I used send_recive() and sent the command + dummy data types. It does return, but as said only ever 0xff's.

I did look at the signals with an oscilloscope - and it looked wired^^ The signal seems right, but it only oscillates between 1 and 1.5v (1.8v would be high?).

I'll try again next week. The BMP180 and the MPU9150 also tried to mock me, but in the end I figured it out.

Thanks for the help, again. Really appreciate.

[dhylands]

Hmm. The signals should be going between 0 and 3.3v.

CMOS has a trip point right around the middle, so approx 1.65v so any voltage under that is considered a zero and anything over is considered a 1. Of course manufacturing variations and other factors will influence this and may move the trip point around a bit.

I'd try removing all of your circuitry and watching the pins from the pyboard with nothing else attached. Which pins are you using? You should double check that the pins are actually configured properly as well.

With the latest code base, you could do something like this:

Code: Select all

>>> def spi_pins():                      
...   for name in ('X5', 'X6', 'X7', 'X8', 'Y5', 'Y6', 'Y7', 'Y8'):
...     pin = pyb.Pin(name)                                        
...     print(pin)                                                 
... 
>>> spi = pyb.SPI(1, pyb.SPI.MASTER)
>>> spi_pins()                      
Pin(Pin.cpu.A4, mode=Pin.AF_PP, pull=Pin.PULL_UP, af=Pin.AF5_SPI1)
Pin(Pin.cpu.A5, mode=Pin.AF_PP, pull=Pin.PULL_UP, af=Pin.AF5_SPI1)
Pin(Pin.cpu.A6, mode=Pin.AF_PP, pull=Pin.PULL_UP, af=Pin.AF5_SPI1)
Pin(Pin.cpu.A7, mode=Pin.AF_PP, pull=Pin.PULL_UP, af=Pin.AF5_SPI1)
Pin(Pin.cpu.B12, mode=Pin.IN)
Pin(Pin.cpu.B13, mode=Pin.IN)
Pin(Pin.cpu.B14, mode=Pin.IN)
Pin(Pin.cpu.B15, mode=Pin.IN)
>>> spi = pyb.SPI(2, pyb.SPI.MASTER)
>>> spi_pins()                      
Pin(Pin.cpu.A4, mode=Pin.AF_PP, pull=Pin.PULL_UP, af=Pin.AF5_SPI1)
Pin(Pin.cpu.A5, mode=Pin.AF_PP, pull=Pin.PULL_UP, af=Pin.AF5_SPI1)
Pin(Pin.cpu.A6, mode=Pin.AF_PP, pull=Pin.PULL_UP, af=Pin.AF5_SPI1)
Pin(Pin.cpu.A7, mode=Pin.AF_PP, pull=Pin.PULL_UP, af=Pin.AF5_SPI1)
Pin(Pin.cpu.B12, mode=Pin.AF_PP, pull=Pin.PULL_UP, af=Pin.AF5_SPI2)
Pin(Pin.cpu.B13, mode=Pin.AF_PP, pull=Pin.PULL_UP, af=Pin.AF5_SPI2)
Pin(Pin.cpu.B14, mode=Pin.AF_PP, pull=Pin.PULL_UP, af=Pin.AF5_SPI2)
Pin(Pin.cpu.B15, mode=Pin.AF_PP, pull=Pin.PULL_UP, af=Pin.AF5_SPI2)

So make sure that pins have actually been configured as SPI pins.