[Oberon] FPGA - nRF24L01 `RPI Net' server

[Tomas Kral]

On Wed, 16 May 2018 20:11:44 +0200
Tomas Kral <thomas.kral at email.cz> wrote:

> I wonder If I somehow reused payload instead, while resetting MAX
> count, were it still seen as a new transaction by the receiver? Would
> I get duplicates?

First of all thank you for bearing reading this. If I write too much,
please just give me a hint and I will stop.

Actually, when MAX_RT interrupt is triggered, anything transmitted
after is considered a new transaction, as per ch. 7.8.7.   

If the above correct, a multi-payload protocol may need to cater for:
[1] duplicate payloads
[2] lost payloads 
???

I have rewritten Write(), to be close to `SCC.SubSnd', reusing payloads
after MAX_RT with `5' retries. I now also report the full status.

bool RF24::write( const void* buf, uint8_t len, const bool multicast )
{
   uint8_t status;
   uint32_t stry;

   //Copy payload and start transmitting with ce(HIGH)
   startFastWrite(buf,len,multicast);

   stry = 5; // SEND_TRIES
   do {

   //Wait until complete or failed
   uint32_t timer = millis();
   while( ! ( (status = get_status()) & ( _BV(TX_DS) | _BV(MAX_RT) ))) {
         if(millis() - timer > 95){
            errNotify(); // no response from radio, check wires
            return 0;
         }
     
   }
   
   ce(LOW);

   printf("status %d %d\n", status, stry);
   if ( status & _BV(TX_DS) ) write_register(NRF_STATUS, _BV(TX_DS));
   else if ( status & _BV(MAX_RT) ) {
      // write_register(NRF_STATUS, _BV(MAX_RT)); flush_tx();
      delay(5); // some millis
      reUseTX(); // reuse payload reset MAX_RT and start over 
   }

   } while ( --stry && ! (status & _BV(TX_DS)) );

   flush_tx(); // clear TX_FIFO
   return ( status & _BV(TX_DS) );
}


Oberon end:
----------

Test.Mod receiving   640

0000000000000000000000000000000
1111111111111111111111111111111
2222222222222222222222222222222
3333333333333333333333333333333
4444444444444444444444444444444
5555555555555555555555555555555
6666666666666666666666665555555
6666666666666666666666666666666
7777777777777777777777776666666
7777777777777777777777777777777
8888888888888888888888888888888
9999999999999999999999999999999
0000000000000000000000000000000
1111111111111111111111111111111
2222222222222222222222222222222
3333333333333333333333333333333
6666666666666666666666666666666
7777777777777777777777777777777
8888888888888888888888888888888
9999999999999999999999999999


Transmit log:
------------

65 14 86 177
 Test.Mod sending
status 46 5
status 46 5
status 46 5
status 46 5
status 46 5
status 46 5
status 30 5
status 46 4 <== duplicate
status 30 5
status 46 4 <== duplicate
status 46 5
status 46 5
status 46 5
status 46 5
status 46 5
status 46 5
status 46 5
status 30 5
status 30 4
status 30 3
status 30 2
status 30 1 <== lost
17 0 86 177 512
status 46 5
status 46 5
status 46 5
status 46 5
status 46 5
18 0 86 177 128
 640

-- 
Tomas Kral <thomas.kral at email.cz>