Don't reset REG_FIFO_ADDR_PTR

[torntrousers]

As per the discussion in https://github.com/sandeepmistry/arduino-LoRa/issues/268 and https://github.com/sandeepmistry/arduino-LoRa/issues/218

[morganrallen]

After digging into the datasheet I cannot find a compelling reason resetting REG_FIFO_ADDR_PTR should be done.

[mchacher]

I do confirm. could be good as well to create a task that is calling the callback function instead of having this call in the ISR which is not safe at all. Sharing below the code I have used on my side. Hope this can help.

volatile int _dioRiseInterruptCounter = 0; portMUX_TYPE mutexDioRise = portMUX_INITIALIZER_UNLOCKED;

/**

• onDio0Rise
• Handle Dio0 interrupt */ void IRAM_ATTR LoRaClass::onDio0Rise() { portENTER_CRITICAL(&mutexDioRise); _dioRiseInterruptCounter++; portEXIT_CRITICAL(&mutexDioRise); //LoRa.handleDio0Rise(); }

/**

• Manage RX / LoRa data received. To be executed in a separate task

  • / void LoRaClass::taskRxLoop(void pvParameters) { // configure dio0 interrupt vTaskDelay(1); pinMode(LoRa._dio0, INPUT); LoRa.writeRegister(REG_DIO_MAPPING_1, 0x00); attachInterrupt(digitalPinToInterrupt(LoRa._dio0), LoRaClass::onDio0Rise, RISING); while (true) { if (_dioRiseInterruptCounter > 0) { portENTER_CRITICAL(&mutexDioRise); _dioRiseInterruptCounter--; portEXIT_CRITICAL(&mutexDioRise); LoRa.handleDio0Rise(); } // give the opportunity to the IDLE task to run, and so avoid the TaskWatchDog timer to trigger a reset vTaskDelay(10); } }

[morganrallen]

This isn't related to this pull request.