Yet Another Nordic nRF24L01 thread

T Chap

I am studying Mark T's Nordic driver found in Duanes thread

http://forums.parallax.com/showthread.php?130707-Looking-for-Faster-Objects-for-Nordic-Wireless-Modules-nRF24L01-and-nRF2401A/page3

I can get Duane's demo to work on the Sparkfun modules. Mark's driver does not include a demo, and is written in PASM. I am purely guessing at a lot of things here. If Mark checks in maybe he can clarify. Otherwise, there is a little confusion regarding the long construction of several parameters. I think have it correct but have tried it in reverse, no luck getting any response on the receiver. I did manage to get some error responses from the driver when putting in bad commands, but this does not insure that the module is communicating, only that the driver was responding with bad commands as it should.

The master code should output a single byte per second $FF. An LED shows that the repeat is working.

On the receiver, an LED should show if the IRQ was pulled low. In fact, if I use the reverse order of long construction, the LED stays on all the time, which cannot be correct. With the order = 0 which I think is correct, it never blinks indicating data received.

If someone could verify the order of my long construction of the various parameters as the PASM code is un packing it, that would at least insure that I have the module configured right.

nordicMasterPASM is my demo that is an attempt at getting the nRF24L01p driver of Marks to work. I have no idea if this is even close.

nordicSlavePASM is the receiver side.

nRF24L01p is Mark's driver as is from the original thread. In the PASM driver section RF_INIT you can see where the longs are unpacked into separate parameters. In my demo, I created options for var ORDER to easily switch between which directions the parameters are packed into the longs. In

Any suggestions appreciated!

Dave Hein

T Chap, I looked at the code, and I think the problem is with the variable buffer. This variable should contain the address of the data buffer instead of the value you want to send. So instead of setting buffer to $FF you should set buffer to a location that contains the $FF. It would look something like this:

  buffer := @data_buffer
  data_buffer[0] := $FF

You should do the same thing on the receive side also. Since you could receive up to 32 bytes of data I would suggest making data_buffer 32 bytes in size, such as declaring it in a VAR section as "byte data_buffer[32]".

As far as the parameter order, setting order equal to zero is correct.

Dave

EDIT: I noticed your code uses waitcnt after sending a command. The driver clears the value of command after it is done, so you could wait for this by doing a "repeat while command". You should also check the value of error after the command is processed. error will be zero if the command was processed OK, and it will have a nonzero value if there was an error.

Mark_T

Sorry, been busy. First observation is that you must wait for commands to complete - the command word is set back to COMM_NOP when its been done.

The buffer is indeed a pointer to a buffer large enough for the packet size specified at setup. A sequence to setup cleanly into receive mode and start getting packets would be like:

command := COMM_IDLE_MODE
  repeat until command == COMM_NOP

  command := COMM_RX_MODE
  repeat until command == COMM_NOP

  buffer := @packet
  command := COMM_RECV_PKT
  repeat until command == COMM_NOP

To pick apart the setup, first the paramater block is declared so:

long  command
  long  buffer
  long  error
  long  spipins
  long  args1
  long  args2

All of these MUST be long, and MUST be in this sequence - only the address of the first is passed to the nRF cog so it cannot find the others unless they are in the right sequence.

The setup parameters are encoded so:

spipins := SCLKpin | (MOSIpin << 5) | (MISOpin << 10) | (CSNpin << 15) | (CEpin << 20) | (IRQpin << 25)
  args1   := $00040302  ' retries = 0, channel = 4, power = max, rate = 2M
  args2   := $00000220    ' crc bytes = 2, packet len = 32

  radio.Begin (@command)

This starts up the cog and it will initialize and start waiting for commands. The args1 and args2 are split into bytes - there are 6 byte sized parameters encoded in them, 4 in args1 and 2 in args2.

T Chap

Thanks Mark and Dave for the comments. I did get it to work finally, another big problem with my test code is that I had it looking for a low on IRQ. Mark has the IRQ flagged off, so when I turned in on I could use IQR to trigger the read. One strange thing with this code, I am getting false triggers which I do not get on the other demos. I didn't take time to view what the data was on the false triggers. At least this is a good PASM example to study so thanks for posting it.