Using NRF24L01+ with pure assembler programing

RE: Using NRF24L01+ with pure assembler programing

ovrebekk — Fri, 09 Jun 2023 11:40:32 GMT

P means Primary. Since both devices will transmit and receive you can't just call them TX and RX. PTX is the device that transmits first, and receives the ACK second (primary transmit).

PRX is the device that receives first, and then transmits an ACK (primary receive).

[quote user="o.hojvat"] And the last question is if the Tx FIFOs used in PTX mode are the same Tx FIFOs used for ACK_PAYLOAD in a PRX mode device, so the the informations about Tx FIFO full or empty are in register 0x17 for both cases[/quote]

Yes. In PRX mode the TX FIFO is used to hold the ACK payloads, so the bits are the same.

Best regards
Torbjørn

RE: Using NRF24L01+ with pure assembler programing

o.hojvat — Fri, 09 Jun 2023 04:55:05 GMT

I had confused in my mind about names (my memory errors)

PRT- -> I wanted to say PTX

Now I noted that are RX and TX modes with a P letter at the begining. I guess I will remember well it.

What is the P letter meaning?

And the last question is if the Tx FIFOs used in PTX mode are the same Tx FIFOs used for ACK_PAYLOAD in a PRX mode device, so the the informations about Tx FIFO full or empty are in register 0x17 for both cases.

In data sheet page 62 there are mention of ACK_PLD TX_PLD RX_PLD as not numbered registers or FIFOs.

After several days I may have RFcomunication working in the proyect and more information and questions.

I will send it in a new ticket, as you sugested.

Best Regards, Osvaldo

RE: Using NRF24L01+ with pure assembler programing

ovrebekk — Thu, 08 Jun 2023 08:22:40 GMT

Hi Osvaldo

I also made a mistake earlier. I forgot you were using the nRF24L01+, and in this case you can't upload a packet for all FIFO's at once. This device only has 3 slots in the FIFO, so you would have to upload only 3 packets at first, and then upload the remaining packets as the ACK payloads are being picked up.

[quote user="o.hojvat"]Where is the information of TX FIFO full and empty available in the PRX?[/quote]

You can find information about this in the FIFO_STATUS register (register 0x17). Please refer to the product specification for more information.

[quote user="o.hojvat"]Is the same as the TX FIFO in PRT? I did not found it clearly stated in the data sheet.[/quote]

What do you mean by PRT? I see you mention this several times in your post. There are only two modes in the device, PTX and PRX.

Also, I would appreciate it if you create a new ticket if you have more questions where you summarize the latest status of your project and what questions are remaining. This ticket is getting big and messy, with a mix of old and new questions, and the devzone is not really designed to handle long running tickets very well.

Best regards
Torbjørn

RE: Using NRF24L01+ with pure assembler programing

o.hojvat — Wed, 07 Jun 2023 23:04:36 GMT

amistake, sorry: I wanted to said:

I will load the information for PIPES 0- 1 - 2 at first

RE: Using NRF24L01+ with pure assembler programing

o.hojvat — Wed, 07 Jun 2023 18:03:43 GMT

Thank you for your reply

I had similar ideas and If my timed sync works I will use only 1 frec. channel

There are a max. of 3 ack payload that may be for same of diferen PIPES

I will load the information for PIPES 1 - 1 - 2 at first

Where is the information of TX FIFO full and empty available in the PRX?

Is the same as the TX FIFO in PRT? I did not found it clearly stated in the data sheet.

By the moment I will try useing 3 PTX, later I will do the PTX sinr. and add more channels

I guess the PRX program is complete (partially tested) butI I will need to have also one PRT working for testing all.

Best Regards, Osvaldo

RE: Using NRF24L01+ with pure assembler programing

ovrebekk — Wed, 07 Jun 2023 09:02:46 GMT

Hi Osvaldo

[quote user="o.hojvat"]

My actual question is that some types of packets will be send to every PTX.

I need to copy the same packet information to the 6 buffers

--> Are some property of PIPE 6 the can be used for simplify this matter ?

[/quote]

There is no simpler way to do this, no. You need to upload a unique payload for each PTX, since you don't know when each PTX will transmit, and there is no mechanism in the ESB protocol for sharing one payload with multiple pipes.

[quote user="o.hojvat"]I have an idea for sincronizing the PTX trasmitions in order to avoid colitions.[/quote]

There are many ways to synchronize devices, which way to do choose depends on the application requirements.

One trick is to use a dedicated frequency for each PTX, and have the PRX cycle through each frequency in turn. The advantage of this method is that the PRX's won't be able to interfere with each other since they are not on the same frequency, but it does make things a bit more complicated on the PRX side.

If you manage to synchronize all the PTX's in time this is also possible, then there is no need to change frequency, but it makes things a bit more complex on the PTX side.

Best regards
Torbjørn

RE: Using NRF24L01+ with pure assembler programing

o.hojvat — Mon, 05 Jun 2023 16:43:37 GMT

Hi Torbjørn

I am still working in the proyect

As I had explained before , I will have 1 PRX several PTX

At the PRX with 485 comunication with a central unit, I do some decoding for the Usart incoming packet.

The 9 bites signals from central to the PTX will be reduced to 8 bites to be handled by the NRF

I have indentified for which PTX will be the packet sent a there in a separated buffer for each one

My actual question is that some types of packets will be send to every PTX.

I need to copy the same packet information to the 6 buffers

--> Are some property of PIPE 6 the can be used for simplify this matter ?

I can limit the number of PTX to 5 if it helps.

--------------------------------------------------------------

I have an idea for sincronizing the PTX trasmitions in order to avoid colitions.

I will do it later, but this may be usefull:

PRX will have a internal "clock" by example a register counting free 0 to 255.

Each PTX keeps a similar counter that will be sincronized al any comunication with PRX

Each PTX will have al time gate for allowed a TX/RX to RX Probabely 10 to 20ms

May be some some time gates intercalated for URGENT information

Except for an initial short time, will be not two TX at the same time

Best Regards, Osvaldo

RE: Using NRF24L01+ with pure assembler programing

ovrebekk — Tue, 02 May 2023 06:56:37 GMT

Hi Osvaldo

I am glad I could help. The best of luck with your project 🙂

Best regards
Torbjørn

RE: Using NRF24L01+ with pure assembler programing

o.hojvat — Sun, 30 Apr 2023 16:04:46 GMT

I guess that the usual star of 1 PRX and 6 PTX can be synconized as following:

At PRX, the procesor has a counter from 0 to 5 to 0 ... , repeating permanently with fixed 10ms (by expamle) in each step

PRX will upload actualized value in ack payload

Each PTX has asigned a pipe number 0 to 5 and has a similar counter 0 tofive

At power-on each PTX (with some diferent delay or at any moment) , may send a short packet and with the ack payload information can adjust his counter to sincronize it wuh the PRX

Fore more precision a precounter for the 10ms time can by used in all devices, andthis value upload also with the 0 to 5 information.

--- After a initial test packet , each PTX will tx only when PRX expect this pipe will do it.

PRX can pre-load the regarding information for each pipe

Any collision is avoided

------------------------ another aproach ------------

I guess If there will be only 3 pipes in use , each of the 3 available W_ACK_PAYLOAD can store the needed information and only the regarding one will be send with the ack

---------------------------------------------------------------------

I fully working in other matter , but my mind not

Best Regrds, Osvaldo

RE: Using NRF24L01+ with pure assembler programing

o.hojvat — Sat, 29 Apr 2023 16:58:51 GMT

I will keep all yours comments. Thank you

By the moment I am working on the complete system programms and it may arises reasons to prefer the use of one of the methods

Best Regards

RE: Using NRF24L01+ with pure assembler programing

ovrebekk — Fri, 28 Apr 2023 08:47:39 GMT

Hi Osvaldo

If each device only sends a couple of packets every second then the chance of collision should be very small. Sending one packet at 1M PHY takes at most ~320us when sending 32 bytes, even less if you send shorter packets. Sending 10 of these packets pr second means you only spend ~0.3% of the available RF time, and even if some other PTX is also transmitting it is very unlikely to send at the same time.

Once in a rare while it will collide, but then you can use the retransmission mechanism with different ARD to ensure that they will retransmit the packets at different times.

So that would be my recommendation, but obviously you are free to choose which option you prefer.

[quote user="o.hojvat"]--- I guess in each transmition, the PTX will change the tx adress (PIPE 0 ?) and also it will place the same address for PIPE 0 rx.[/quote]

The PTX doesn't change the address. You need to ensure that both the TX address and the RX PIPE0 address is configured to the same value, otherwise the PTX will not be able to receive the ACK.

[quote user="o.hojvat"]--- It may be used PIPE 0 in all 6 PRX ?[/quote]

Yes, you can use whatever pipe you want on the PRX side. The critical point is that you configure the addresses differently for all PRX's, so you don't get two or more receivers responding to the same packet.

[quote user="o.hojvat"]--- Perhaps it may be better to use a diferent PIPE for each PRX.[/quote]

It is up to you. Either you configure the same address set in all PRX's, but enable different pipes in each of them (use pipe 0-5 for PRX 0-5), or you just use pipe 0 for all of them but make sure to configure unique pipe 0 addresses for each PRX.

The pipe system is optimized for the use case where you have 6 PTX's and 1 PRX, and is not as streamlined when you have multiple PRX's and one PTX. It still works, but in this mode you will need to configure the TX and pipe 0 address on the PTX every time you want to switch to another PRX, you can't just tell the PTX to transmit to a different pipe (more modern Nordic devices like the nRF52 series have removed this limitation).

Best regards
Torbjørn

RE: Using NRF24L01+ with pure assembler programing

o.hojvat — Thu, 27 Apr 2023 16:30:32 GMT

Hi

I made public the ticket - there are not private information here.

----------------------------- Data rate ----------------------

From one handheld they may be two orders sent in 1 second, by example playing a short horn sound,
or turning ON / OFF some ligth for a controled locomotive
At maximun 5 Data in one second while modifying speed control position. But the most important is the last value, when the control stop moving.
.
I will prefer the 3) procedure because it is more clear for me, and it will have no interference or colitions problems.

It is a good idea your suggestion of sincronizing RF activationat PRX when it is expected a packet.
It is rather easy to do for only 6 devices. Probabely total 100 ms for the 6 PRX , so this will be the maximum delay to trasmit an handheld order.

I case of no receiving the packet at the expected time, PRX can extend the RF ON time. I will be not very often

--- I guess in each transmition, the PTX will change the tx adress (PIPE 0 ?) and also it will place the same address for PIPE 0 rx.

--- It may be used PIPE 0 in all 6 PRX ?

--- Perhaps it may be better to use a diferent PIPE for each PRX.

Please comment about this matters.

Anyway I must work (1 to 2 month) with TX / RX devices complete hardware and programms and some other problems may arises.

Thank you very much for your help. Now I can use the RF link with my own assembler.

Best Regards

Osvaldo

RE: Using NRF24L01+ with pure assembler programing

ovrebekk — Thu, 27 Apr 2023 07:19:03 GMT

Hi Osvaldo

Approximately how often do you expect an order to come in from each PTX?

I think the best approach is the one you detail in 1). Send a small ping packet from the PTX first, so that the PRX can prepare the ACK payload. Then you send a second packet from the PTX some milliseconds later to pick up the ACK payload.

Like you say it is much easier to achieve low average current on the PTX side, since each transmit only takes some hundreds of microseconds.
In order to also achieve low average current on the PRX side you need to keep the PTX's and PRX closely synchronized in time, so that the PRX knows when the PTX's will transmit and can enable the receiver just before the PTX starts the transmission.

[quote user="o.hojvat"]Please answer if there are posible interference for 2 PTX trasmiting at the same time but diferent frequency.[/quote]

If one signal is much stronger than the other it can still cause interference despite being on another channel, but if the distance between the 2 PTX's and the PRX is comparable it shouldn't be an issue.

As an example if the PTX on the wrong channel is laying next to the PRX, and the PTX on the right channel is far away, then you might get interference from the one on the wrong channel.

Best regards
Torbjørn

RE: Using NRF24L01+ with pure assembler programing

o.hojvat — Wed, 26 Apr 2023 16:21:18 GMT

I undestand well tis matter.

I will ask about some to specific questions that may be not usefull for other people , I guess it will better to no use the forum.

Anyway yo can go back this to public tickets if consider there may be usefull for other peoples.

I will begin with one order from one PTX to the PRX inside the handheld unit program but I am thinking in advance for posible problems with other orders received at central unit

Basically a handheld must have updated information before sending an order.

So at the moment I find 3 aproach:

1) Using the proposed star 1PRX to up to 6 PTX, as in data sheet

In this case the PRX does not knows which PTX will send the next packet and can not upload the regarding information in ack payload. The PTX may repeat the Tx in a very short time to get it.

2) each PTX can use a diferent frequency channel and the PRX may be receiving about 20 ms at one freq. and if there is no received packet, PRX moves to other diferent freq. not adyacent channel).

Please answer if there are posible interference for 2 PTX trasmiting at the same time but diferent frequency.

3) One PTX and up to 6 PRX devices (one in each handheld). Disadvantage may be Increased battery consumption. Most probabely RFmay be OFF most of the time

As I am using with RS485 cable , PTX sends a short packet for each PRX and wait a short time for a reply. If not, It moves to other PRX address

Best Regards

RE: Using NRF24L01+ with pure assembler programing

ovrebekk — Wed, 26 Apr 2023 07:51:42 GMT

Hi Osvaldo

I made this case private, so that you can share documents with Nordic support directly without everything being available publicly.

Please note that I am not able to validate your entire project. If you have issues with the Nordic chip, or have questions about the Nordic hardware/software, I will do my best to help, but the rest is up to you 😉

Best regards
Torbjørn

RE: Using NRF24L01+ with pure assembler programing

o.hojvat — Tue, 25 Apr 2023 16:05:22 GMT

devzone.nordicsemi.com/.../0601.NRF24L01-_2B00_-RFX2401---Blog-de-PatagoniaTec-Electronica.pdf

RE: Using NRF24L01+ with pure assembler programing

o.hojvat — Tue, 25 Apr 2023 15:58:42 GMT

I have a sample and the RFmodule with antena has a LNA and a RFX2401C power amplifier, so the simple modules used as PTX will receive a better signal.

I will try to attach some regarding information

Anyway I need to have the complete sistem working for a realistic test.

Normal user may have one or two handheld controllers with RF link and the PRx may be placed in the middle of the room.

By the moment I will beguin working to include the RF part in the actual handheld program and also the new program for the PRX interfase board.

I can send to you the updated information of my work by private mensage or email if it is posible

Best Regards

devzone.nordicsemi.com/.../2275.Modulo-Rf-Arduino-Nrf24l01-_2B00_-Transceptor-Armodlnrf24l01_2B00_-_2D00_-_2400_-45_2C00_00-en-Mercado-Libre.pdf

RE: Using NRF24L01+ with pure assembler programing

ovrebekk — Tue, 25 Apr 2023 11:16:19 GMT

[quote user="o.hojvat"]

- I guess dynamic payload also applies to the ack payload length,

and the Tx FIFO need to be loaded before receiving the packet Please confirm

[/quote]

Yes and yes. The ACK payload can be any length between 1 and 32 bytes, and you need to upload the ACK payload before you receive the packet from the PTX, otherwise it will not be included until the next packet arrives.

[quote user="o.hojvat"]

- If there are Tx from two PTX devices at the same time, I guess no one will be received OK

I think it may be needed to use diferent ARD in each PTX for avoiding the same problem in the retry

[/quote]

In case of packet collisions you will most likely lose both packets, yes, but if one of the packets have a higher signal strength than the other there is a chance you will receive it correctly.

It is correct that configuring a different ARD in different PTX's can help reduce interference between them, since they will not retransmit lost packets at the same time.

[quote user="o.hojvat"]- I need in a big room a 15m secure link , Is it convenient to use 250 Kb rate or 1 Mb rate is OK ?[/quote]

You should be able to reach 15m in 1M mode, as long as you don't have a lot of things blocking the signal (such as people, walls or heavy furniture).

The actual transfer rate is considerably lower than the PHY rate, so using 1M mode would be beneficial in ensuring you can reach 57k of actual throughput even if you have some packet loss and need to retransmit some of the packets.

[quote user="o.hojvat"]- At the RX unit, as it will have a power supply cable I can use a board with amplifier and external antena if it is necessary or the simplest available board may be OK ?[/quote]

You should be fine without this, but it depends on the environment. If there is a lot of interference in the area from WiFi, Bluetooth etc then you might benefit from having a FEM (front end module) on the receiver, but using a FEM device only on one side of the link is obviously not as efficient as having a FEM device both in the PTX and PRX.

Whatever you end up doing it is important that you run testing in an environment as realistic as possible, to see how well your implementation works in practice.

Best regards
Torbjørn

RE: Using NRF24L01+ with pure assembler programing

o.hojvat — Mon, 24 Apr 2023 19:54:13 GMT

Thank you for your reply

A wished to have at first some rf link working

I make a litle more advance and added ACKand ACK + payload and it is also working

At the end there is list of wht I had modifyed and added.

Now I will begin with the complete system programms.

Please comment about the following matters:

- I guess dynamic payload also applies to the ack payload length,

and the Tx FIFO need to be loaded before receiving the packet Please confirm

- If there are Tx from two PTX devices at the same time, I guess no one will be received OK

I think it may be needed to use diferent ARD in each PTX for avoiding the same problem in the retry

- I need in a big room a 15m secure link , Is it convenient to use 250 Kb rate or 1 Mb rate is OK ?

The RS485 cable rate is 57600K and not too busy, so with 250K and a processor (with buffers) in the Rf to 485 conversion I estimated they will be no a rate problem.

- At the RX unit, as it will have a power supply cable I can use a board with amplifier and external antena if it is necessary or the simplest available board may be OK ?

Best Regards, Osvaldo

-------------------- added/ modified for test with ack_payload ----------------------------------

PTX

CONFIG   01011010    (CRC enabled, 1 byte)

FEATURE    00000111

Data upload with command 0xA0

wait 1ms and read Rx FIFO for payload received with ack

----------------------------------------

PRX

CONFIG   01011011

FEATURE    00000111

At the end but inside of rx_wait loop
Data upload with command   10101000 (pipe number 0) for ack payload
data value selected by a switch
data = 0 if   PORTA,1 tied to Vcc
data = 1111111 if   PORTA,1 tied to GND

---------------------------------------------------------------------

RE: Using NRF24L01+ with pure assembler programing

ovrebekk — Mon, 24 Apr 2023 10:28:25 GMT

So everything is working fine?

Please note that with the CRC check disabled there is a risk that you will receive packets with incorrect data, caused by bit errors in the payload.

With CRC enabled any packet with a bit error will be discarded, and if you have ACK and retransmits enabled the packet will be sent again.

Best regards
Torbjørn

RE: Using NRF24L01+ with pure assembler programing

o.hojvat — Sat, 22 Apr 2023 04:01:13 GMT

;Short test program for Tx / Rx following Torbjørn instructions (from Nordic Forum)
;I have selected the procesor pins in order to keep posible USART pins free for next proyect step
;Procesor PIC16F1826    ( = PIC)
;Transceiver NRF24L01+ ( = NRF)         PTX = RF tx mode     PRX = RF rx mode
;Using default values at most NRF registers for low instructions count 
; RA4 pin open -> PTR mode   no interruptions
; RA4 to GND  ->  PRX mode   - IRQ used     ( the same program forboth modes )

; PIC definitions 
; INTERNAL OSCILLATOR 16MHZ
; SERIAL DATA OUT (MOSI): RA6      ; 
; SERIAL DATA IN (MISO):  RB1     ;
; SERIAL SPI CLOCK:  RB4 - 4MHz
; SPI  MASTERMODE for procesor  
; RB0 USED AS INPUT TO ENABLE INTERRUPT ON CHANGE (HIGH TO LOW) AND CONNECTED TO TRASCEIVER IRQ for use as TRP
; CSN - NRF SPI enable: RA7 
; CE  NRF24L01+ RF enable (data sheeet states: less than 4ms ON in Tx mode)

; Subrutines used for SPI
; sendSPI  - send WREG value to NRF - iniciate and wait 8 SPI CLK - return with banco0
; receiveSPI  - iniciate and wait 8 SPI CLK - return with banco0 and SPI received value in WREG (fron NRF)
; delay10u  - 10us
; delay1m   - 1ms
; delay200m - 200ms


#define 	banco0	movlb	0     ; 
#define 	banco1	movlb	1     ; OSCON - OPTION
#define 	banco2	movlb	2     ; APFCON   (some inputs/outputs can be moved between default pin to other one )
#define 	banco3	movlb	3     ; usart
#define 	banco4	movlb	4     ; SPI

#define		CSN		PORTA,7	
#define     CE		PORTA,0
#define     PTXsel	PORTA,4     ; 0 = PRX  mode ;  1 = PTX  mode
#define	    LED 	PORTA,2   ; PTR shows tx fifo not empty  -  PRX shows rx fifo with data
;#define 
;#define 
;#define 
;#define 
;#define 
 CBLOCK 	0x20    
  Reg1      ; for delay subrutines 
  Reg2      ; 
  Reg3      ;

  RxDATA1 
  RxDATA2 
  RxDATA3 
  RxDATA4 

  TxDATA1 
  TxDATA2 
  TxDATA3 
  TxDATA4   
 ENDC

 CBLOCK 	0x70    ; access from any bank
  Arg0   
  Arg1   
  Arg2   
  Arg3   
  Arg4   
  Arg5
  Arg6
  Arg7
  Flg 
 ENDC
 

        list    p=16F1826,  r=hex   
        INCLUDE P16F1827.INC    ;  F1826,INC  is not present in MPLAB

	__CONFIG _CONFIG1, _FOSC_INTOSC & _WDTE_OFF & _PWRTE_OFF & _MCLRE_ON & _CP_OFF & _CPD_OFF & _BOREN_ON & _CLKOUTEN_OFF & _IESO_OFF & _FCMEN_OFF
	__CONFIG _CONFIG2, _WRT_OFF & _PLLEN_OFF & _STVREN_OFF & _BORV_HI & _LVP_OFF     ; en el .INC ,     _BORV_19 = _BORV_LO es el trip point bajo   _HI alto


                   ORG 00

              GOTO START

;;;INT      ; not using INT for this test 
;;;	clrf	BSR

;;;retfie

                   
START         ;     
       ;   no poner dalay antes de ajustar oscilador  
      
; PIC initialize
  BANKSEL		TRISB
                   movlw    B'00000111' ; SETTING PORTB ACCORDING TO SPI, RB0 IS INPUT TO ENABLE TRANSCEIVER IRQ
                   movwf    TRISB  ;RB1 MISO   RB2  para Rx de 485 
		   		movlw    b'00010010'    ; tecla a GND en RA1 - pongo 10k a +5  - puente a GND para modo TRX
		   		movwf    TRISA           ;bit5 de MCLR no se baja- teclaa RA1 - LED en salida RA2
			movlw	b'01111010'    ; para 16M
			movwf	OSCCON					
			movlw	b'10000100'    ;con pull-up (ver def. individuales) ; RB0 = 0 INTERRUPT HIGH TO LOW EDGE = bit6
			movwf	OPTION_REG   ; presc 1/32 para TMR0 ( ver si lo uso) 
  BANKSEL PORTB           
                  MOVLW B'00000000'   
		  MOVWF	PORTB    
                  MOVLW B'10000000'   
		  MOVWF	PORTA    ; para CSN en alto 
		BANKSEL ANSELA 
		clrf	ANSELA
		clrf	ANSELB
  BANKSEL  SSP1STAT                     ; tested at, 4MZ also works with SMP = 0
                   MOVLW B'01000000'      ;;; SMP= 1   CKE = 1     ( smp = bit 7 11000000)
                   MOVWF SSP1STAT
                   MOVLW B'00100000'     ; frecSPIclk = fosc/4 = frec instruccion -> 4M  for 16M-osc            
                   MOVWF SSP1CON1            ; bit4 CPK = 0    mode 0,0   smp = 1 
                   MOVLW B'10010000'
  BANKSEL  APFCON0    ; banco2
 			movlw   b'11000000'     ;  RA6 MOSI  
 			movwf	APFCON0         ; (bit7) Tx  USART  RB2 -> RB5
 			movlw   1               ; Rx del USART  RB1 -> RB2
 			movwf	APFCON1
  banco0
;;;			movlw	b'10010000'    ; GIE  INTE   - PRX  uses IRQ  falling level
;;;		btfsc	PORTA,4      ; to GND -> PRX
			movlw	0       ; open -> PTX
			MOVWF INTCON ; for this test I will use poling RIRQ  ;;;  ENABLE GLOBAL INTERRUPTS + RB0 EXTERNAL INTERRUPT IN
      
 clrf	 RxDATA1
 clrf	 RxDATA2
 clrf	 RxDATA3
 clrf	 RxDATA4
 clrf	Arg0  
 clrf	Arg1  
 clrf	Arg2  
 clrf	Arg3  
 clrf	Arg4  
 clrf	Arg5
 clrf	Arg6
 clrf	Arg7  
 clrf	Flg
  movlw	1
movwf	TxDATA1	    ; for tests
 movlw	2	
movwf	TxDATA2
 movlw	3
movwf	TxDATA3
 movlw	4
movwf	TxDATA4

call	delay40ms   ; algo mas de 100ms  para el power-on del modulo NRF
call	delay40ms 
call	delay40ms 

btfss	PORTA,4      ; to GND -> PRX
goto	PRX

; NRF24L01 *************************** reference:  data sheet- commands table 20 page 51 and registers  9.1 page 57 ******************

; PTX:    -   IRQ is enabled but not used in PTR
; 1) Set the PWR_UP bit in the CONFIG register     -  
				bcf CSN       				 ; Open NRF SPI
                   MOVLW B'00100000'         ; write reg 0 - CONFIG    (command 001aaaaa = write to aaaaa register 
                   CALL SEND    
                   MOVLW B'01010010'         ;bit5 low: IRQ for Tx send,  POWER_ON   ; no CRC , PTX mode
                   CALL SEND            
				bsf CSN                      ; close SPI
; optional confirm CPNFIG value
	movlw	0			
	call	read_Regx
	movwf	Arg0
	
; necessary ??? disable auto-ack - uso tx sin ack ( o con ack, a mi gusto)
;;				bcf CSN       				 ; Open NRF SPI
 ;;                  MOVLW B'00100001'         ; write reg 1 -  EN_AA
 ;;                  CALL SEND    
;;                   MOVLW 0         ;
;;                   CALL SEND            
;;				bsf CSN                      ; close SPI	
	
; -----   2)  3) are the same for
; -----   2)  3) are the same for  PTX and PRX    
; 2) Set DYNPD to 0x3F   
				bcf CSN       				 ; 
                   MOVLW B'00111100'         ; write reg 1C - DYNPD    - b'00111100' = (0x20 + 0x1C)
                   CALL SEND    
                   MOVLW B'00111111'         ; dynamic PD all channels
                   CALL SEND                 ; 
				bsf CSN

; 3) Set the EN_DPL bit in the FEATURE register
				bcf CSN       				 ; 
                   MOVLW B'00111101'         ; write reg 1D - FEATURE   - b'00111101' = (0x20 + 0x1D)
                   CALL SEND    
                   MOVLW B'00000101'         ; dynamic PD  and EN_DYN_ACK enabled ; para tx sin ack 
                   CALL SEND                 ; 
				bsf CSN
;optional ? .............. flush tx fifo ..................
	bcf CSN	
	    movlw	0xE1   ; b'11100001'
	    call	SEND
	bsf CSN		
								
; 4) Upload a payload
new_payload:
 ; optional ..............   
    		call 	read_fifo_status	  ;  readed value in WREG
		movwf	Arg1   ;   before load  bit4 EMPTY must be = 1  empty
	btfss	Arg1,4
	bsf LED	; PORTA,2   ; a negated copy of Tx fifo EMPTY
	btfsc	Arg1,4
	bcf LED	; PORTA,2   ; led O = tx fifo with data
;...............
		bcf CSN   ; habilito SPI para cargar datos en TX FiFO
					movlw	0xB0       ;B0 es tx sin ack comando tx payload0 xA0
					call	SEND
					movf	TxDATA1,w    
					call	SEND
					movf	TxDATA2,w
					call	SEND
					movf	TxDATA3,w
					call	SEND
					movf	TxDATA4,w
					call	SEND   
			    bsf CSN	

;Optional:  read and check fifo status 
		call 	read_fifo_status	  ;  readed value in WREG
		movwf	Arg2   ;             bit4 EMPTY must be = 0  not empty
	btfss	Arg2,4
	bsf LED	; PORTA,2   ; a negated copy of Tx fifo EMPTY
	btfsc	Arg2,4
	bcf LED	; PORTA,2   ; led O = tx fifo with data
; 5) Pulse CE for 10 us   ******* DO NOT PLACE BREAKPOINTS HERE    ********
retry:  
				bsf	CE
				call	delay10us
				call	delay10us  ; minimum 10us
				bcf	CE
                  ; ***************  TX Rf 4MS MAXIMUN ***********************
;Optional:  read and check fifo status  130us for rf iniciate?
   call delay10us	; tx 4 bytes needs 40us at 1MHz rate -> for tx FIFO empty
   call delay10us      ;NEEDS MORE TIME - time for next read is added to a more sure value
		call 	read_fifo_status	  ;  readed value in WREG
		movwf	Arg3  ;  after tx the data bit4 txbuf EMPTY must be = 1 empty
	call	delay1ms    ; at  40us fifo not emty - after 1ms yes
		call 	read_fifo_status	  ;  readed value in WREG
		movwf	Arg4  ;  after tx the data bit4 txbuf EMPTY must be = 1 empty
	btfss	Arg4,4
	bsf LED	; PORTA,2   ; a negated copy of Tx fifo EMPTY
	btfsc	Arg4,4
	bcf LED	; PORTA,2

	; optional ????............ clr tx  IRQ ..............
 	
		call	read_status
		movwf	Arg5		
		
	bcf CSN	
	    movlw   0x27	; b'00100111' write to STATUS reg.
		call	SEND   ;  
	movlw	b'01110000'	; clr all interrupts flags
		call	SEND	
	bsf CSN                ; 56us from CE rise 
		call	read_status    ; CSN inside
		movwf	Arg6		; 72us from CE rise
	
		btfss	PORTB,0
		nop		
		btfsc	PORTB,0
		nop
	
; ......................................
	
		call	delay40ms

btfss	Arg4,4   ; if tx FiFO not  empty, do not load again
goto retry		

	incf	TxDATA1,f    ;  modified data for next packet trasmition	
; 6) Add a delay (1ms+) and repeat from 4)
	call delay200ms

goto	new_payload

;;; goto	moreProgram
;****************************************************
	; ; below - PRX 
;****************************************************

PRX:
; 1) Set the PWR_UP bit and PRIM_RX bits in the CONFIG register     -  
		bcf CSN       				 ; Open NRF SPI
            MOVLW B'00100000'         ; write reg 0 - CONFIG    (command 001aaaaa = write to aaaaa register 
            CALL SEND    
            MOVLW B'00110011'         ;Bit6 low: IRQ for Rx received,  POWER_ON   ; no CRC , PRX mode
            CALL SEND            
		bsf CSN                      ; close SPI

; optional confirm CPNFIG value
	movlw	0			
	call	read_Regx
	movwf	Arg0
	
; necessary ??? disable auto-ack  mejor lo dejo y uso tx sin ack ( o con ack, a mi gusto)
;				bcf CSN       				 ; Open NRF SPI
 ;                  MOVLW B'00100001'         ; write reg 1 -  EN_AA
 ;                  CALL SEND    
;                  MOVLW 0         ;
 ;                  CALL SEND            
;				bsf CSN                      ; close SPI	
	
; -----   2)  3) are the same for  PTX and PRX
; 2) Set DYNPD to 0x3F
				bcf CSN       				 ; 
                   MOVLW B'00111100'         ; write reg 1C - DYNPD    - b'00111100' = (0x20 + 0x1C)
                   CALL SEND    
                   MOVLW B'00111111'         ; dynamic PD all channels
                   CALL SEND                 ; 
				bsf CSN
 
; 3) Set the EN_DPL bit in the FEATURE register
				bcf CSN       				 ; 
                   MOVLW B'00111101'         ; write reg 1D - FEATURE   - b'00111101' = (0x20 + 0x1D)
                   CALL SEND    
                   MOVLW B'00000101'         ; dynamic PD  enabled y para tx sin ack
                   CALL SEND                 ; 
				bsf CSN
 ;optional
		call 	read_fifo_status	  ;  readed value in WREG
		movwf	Arg2   ;             bit0 EMPTY must be = 1 empty
 ;optional
		call	read_status
		movwf	Arg5		
		nop

; 4) Set CE high
		bsf		CE    ;  set RF  ON  for Rx

; 5) Wait for the IRQ line to go low   ; no used INT for this test 
rx_wait:
		btfss	PORTB,0
;;;loop extended to some lines below;	goto	rx_wait

; 6) Read out the RX payload  ( IRQ low )
		call	readPayload ;;goto
; 7) Repeat from 5) 
	call	delay1ms     ; read more frecuently than Tx send 
	;;	bcf	LED ; PORTA,2   ; 
;	call	delay40ms
;goto	rx_wait
 ;optional
		call 	read_fifo_status	  ;  readed value in WREG
		movwf	Arg3   ;             bit0 EMPTY must be = 1 empty
 goto	rx_wait
; required ? flush rx fifo   :+++++  empeora ++++++
;;	bcf CSN	
;;	    movlw	0xE2   ; b'11100010'
;;	    call	SEND
;;	bsf CSN
;goto	rx_wait
 ;optional
		call 	read_fifo_status	  ;  readed value in WREG
		movwf	Arg4   ;             bit0 EMPTY must be = 1 empty
;;;goto	rx_wait

;optional
	call	read_status
	movwf	Arg6		
	
; reset IRQ to 1  in the subrutine		
				
goto	rx_wait

; ***************** main program end ***** subrutines below **********
;............................................................
; -----------------------------------------------------------------

;************************* Subrutines ******************************

readPayload      ;; no INT for this test ;banco0     ;only for PRX
;optional	
;;	bsf	LED	; PORTA,2   ; 		
call	delay1ms   ; may be not needed
	call read_status
	movwf	Arg5
            bcf CSN	
                   MOVLW B'01100001' ;0x61 Comando SEND REQUEST READ PAYLOAD - en pag 51 el tercer comando
                   CALL SEND
                CALL RECEIVE		; get SPI data
                  MOVWF RxDATA1   ; lee 4 datos manteniendo CSN en bajo
                CALL RECEIVE
                  MOVWF RxDATA2
                CALL RECEIVE
                  MOVWF RxDATA3
                CALL RECEIVE
                  MOVWF RxDATA4                  
            bsf CSN			; cierra el /CS luego de leer 6 datos	  
    ;;;;;;;    BCF INTCON,INTF ; CLEAR RB0 INTERRUPT FLAG    bit1
	nop
	nop
	bcf CSN
	    movlw	b'00100111'	;  0x27 escribo en STATUS
		call	SEND
	    movlw	b'01110000'  ;clear flags  ;     pongo 1 en bit6 => borra flag RDb'01000000'
		call	SEND
	bsf CSN 
; show RxDATA1  counting
	btfss	RxDATA1,0	
	bcf LED
	btfsc	RxDATA1,0	
	bsf LED
	
	btfss	RxDATA1,1	
	bcf PORTA,3
	btfsc	RxDATA1,1	
	bsf PORTA,3
	return	        ; RETFIE
                   
   ; -----------------------------------------------------------------

SEND: 	  ; procesor SPI send WREG value to NRF
  BANKSEL SSP1STAT
                   MOVWF SSP1BUF ; MOVE BYTE TO W REGISTER BEFORE CALLING
;;;..........  wait 8 clk ........
                   BTFSS SSP1STAT,BF ; POLL RECEIVING COMPLETE
                   GOTO $-1
;;;;.......................................
  BANKSEL PORTB
                   RETURN

;*************************************

RECEIVE:    ; procesor receive SPI data from NRF
    BANKSEL SSPSTAT     ;  data was send by SPI before this sub.
				clrf	SSP1BUF   ; con cargar o borrar este registro inicia 8 clk
;;;..........  wait 8 clk ........
                   BTFSS SSP1STAT,BF ; POLL RECEIVING COMPLETE
                   GOTO $-1
;;;;.......................................
			MOVF SSP1BUF,W   ; received SPI data in WREG
  BANKSEL PORTB
                   RETURN

; *********************************************************





;------------------------ delay  subs ------------------------------------------

delay200ms: movlw .0   ;   
            movwf Reg1
            movlw .16     
            movwf Reg2
            movlw .5
            movwf Reg3
            decfsz Reg1,F
           goto $-1
            decfsz Reg2,F
           goto $-3
            decfsz Reg3,F
           goto $-5
            nop
        RETURN
; ---------------------------------------------------

delay40ms:  movlw	.202  ; 
            movwf	Reg1
	    movlw	    .208     ;  40ms    
            movwf	Reg2            
            decfsz Reg1,F
		  goto $-1
            decfsz Reg2,F
          goto $-3           
      return      

; ---------------------------------------------------

delay1ms:  movlw	.60  ;
            movwf	Reg1
	    movlw	    .6   ;   1ms        
            movwf	Reg2            
            decfsz Reg1,F
		  goto $-1
            decfsz Reg2,F
          goto $-3           
      return      

; ----------------------------------------

delay10us: movlw	.13   ; 10us  + 1us for call/return
			movwf	Reg1
            decfsz Reg1,F
        	goto $-1           
      return      

;;**************  subs for debug  ****************

read_fifo_status:     ; lo puse para debug - se puede usar en Tx y en Rx
	bcf	CSN ; PORTA,7
		movlw	0x17 ; 	(para lectura de un registro no sumar 0x20)
		call	SEND	
		    CALL RECEIVE
	bsf	CSN
		    return   ; valor leido en w y está en banco0
;--------------------------------
		    
read_status:     ; lo puse para debug - se puede usar en Tx y en Rx
	bcf	CSN ; PORTA,7
		movlw	0x7 ; 	(para lectura de un registro no sumar 0x20)
		call	SEND	
		    CALL RECEIVE
	bsf	CSN
		    return   ; valor leido en w y está en banco0
;---------------------------
read_Regx:     ; lo puse para debug - se puede usar en Tx y en Rx
	bcf	CSN ; PORTA,7
	; usa el valor en  w  ; (para lectura de un registro no sumar 0x20)
		call	SEND	
		    CALL RECEIVE
	bsf	CSN
		    return   ; valor leido en w y está en banco0
		    
;----------------------------



END

List of SPI commands needed for NRF24L01+ RF link working OK

The regarding assembler is also attached

With dynamic payload , no ack

After procesor settings, with SPI at 4MHz:

------------------ For PTX --------------------------------

Write Reg. Config(0) - value 01010010 ; Tx IRQ mask / no CRC /power on / PTX mode

Write Reg. DYNPD(0x1C) - value 00111111 dyn. payload all channels

Write Reg. FEATURE (1D) - value 00000101   EN_DPL

command: flush tx fifo (0xE1) ; opcional

; loop
new_payload:         ; Upload a payload

command   tx payload , no ACK (0xB0)
load 4 TxDATA bytes before CNS goes high

retry:

Set CE High - RF = ON
wait 20us
Set CE Low - RF go OFF when all the packet is sent

wait 1ms
; reset IRQ line - clear any posible flag (but IRQ not used in PTX)
command: 0x27 write STATUS(reg07) value 01110000

read FIFO_STATUS
Test bit4 Tx fifo EMPTY
If no empty, goto retry

; Packet wass ent
   incf   TxDATA1,f    ; modified data for next packet trasmition
; Add a delay and repeat new_payload
   wait    200ms ; (minimum 1ms)

goto   new_payload ; loop rate 4 times/ second

--------------------- for PRX ----------------

Write Reg. Config(0) - value 00110010 ; Set bits for: Rx IRQ mask, PWR_UP and PRIM_RX in the CONFIG register , no CRC , PRX mode

Write Reg. DYNPD(0x1C) - value 00111111 dyn. payload all channels

Write Reg. FEATURE (1D) - value 00000101   EN_DPL

Set CE High ; set RF ON for Rx

rx_wait:
test   IRQ line = low ?

if low: call readPayload ; in the subrutine: command 0x27 (write STATUS) value 01110000
                          ; so RX_RD bit is cleared and IRQ line goes HIGH

; if IRQ is high , do not read
   wait 1ms
   goto rx_wait

RE: Using NRF24L01+ with pure assembler programing

o.hojvat — Fri, 21 Apr 2023 04:59:19 GMT

Last news - working OK the corrected test program.

With your instructions added, I get an uniform Tx / Rx Data trasmition.

I am trasmiting a four data packet but the first one is incremented after each tx packet

in PTX I have one led as a negated copy of TxFIFO_Status bit4 (Tx fifo EMPTY)

With some delays added there is a rate of about 4 Tx packets/ second , LED flashing at this rate.

In PRx board, there are one led connected at IRQ line ( tied to Vd) that flashes each received packed

Two processor pins have copy of Received Data 1, bits0 and one

They show a uniform count following tx / rx packets rate

Later I will post a list of NRF settings , commands used and also the assembler for the test

-------------------------------------------------------------------

Next I will try adding ack and ack with pay load

Best Regards, Osvaldo

RE: Using NRF24L01+ with pure assembler programing

o.hojvat — Fri, 21 Apr 2023 01:28:00 GMT

Hi Torbjørn

I will apply your last sent information. I need to adquire some experience before next steps

We are a two people team makeing electronics parts for Ferromodelism - Model railroad

My final target is to replace actual cable connection with Rx links, for a Central unit that may be connected to several handheld controls, using RS485 serial cables.

Most of the time, the central unit send a call byte with the address of one control, wait 130us and if it is not a reply, it send a call with the following address of a control is sent.

I will replace it by NRF24L01+ using all the automaric features available.

I am making some simple tests before incorporate the RF part to the program of the Control units, PTX

I will place the PRX part in a special interfase that keeps updated information of controls and Central unit, and to convert RF Tx/ Rx data with the required timing.

One interfase for up to 6 controls. Usually no more that one or two controls will be connected

As data to be send from controls will be a result of a keyboard switch pressing, I expect it will be not a problem for the posibility than more than one control may Tx Data at the same time.

After the present initial test, I will use the enhanced shock burst in a new test as a second step.

I will post resulting assembler when it works well.

Best Regards, Osvaldo

RE: Using NRF24L01+ with pure assembler programing

ovrebekk — Thu, 20 Apr 2023 08:24:57 GMT

Hi Osvaldo

If you want to use the dynamic payload length feature you should not clear the bits in the EN_AA register (reg 1).

Instead you can use a feature called "dynamic ACK", that allows you to send packets that will not be acked while still being able to use dynamic payload length.

In order to use this feature you need to set bit 0 (EN_DYN_ACK) in the FEATURE register (reg 0x1D).

It also important that you enable the DPL bit in the DYNPD register for the pipe that you want to use (bit 0 for pipe 0 and so forth).

Then finally you have to use the W_TX_PAYLOAD_NO_ACK command (0xB0) to send the payload rather than the normal W_TX_PAYLOAD command (0xA0).

Another advantage of this method is that you can send some packets with ACK and other packets without, in case some packets are more critical than others.

Please note that when sending packets without ACK you will not know if the packets are successfully received or not, and you have to expect a certain amount of data loss.

Best regards
Torbjørn

RE: Using NRF24L01+ with pure assembler programing

o.hojvat — Wed, 19 Apr 2023 22:23:21 GMT

Thank you for the reply. I just saw it

I have corrected an error in FEATURE, in the bit position for dynamic payload enable.

Now I get the same Rx Data in PRX as the Tx Data in PTX

By the moment I like to not using ack

I found necessary two actions for my tests works:

*** Clear reg1 (auto ack) at the initial settings

*** Clear STATUS RX_RD after a received payload for have reseted the IRQ out ( I use poling)

I finally understand that this byte is cleared writing a 1, but the level becomes1 when activated and low when cleared

*** I guess than flux Rx/Tx FIFOs is not necessary at the beguining

I will inform when I may get trasmiting about 40 diferents packets and receive the same with no error

Distance is about 60cm

Best Regards