I am starting this thread to garner discussion regarding modifying RFM69 library to make it extensible for features such as sessionKey management as proposed by dewoodruff in
https://lowpowerlab.com/forum/index.php/topic,878.0.html, and kobuki in
https://lowpowerlab.com/forum/index.php/topic,878.msg6103.html#msg6103, my proposal for auto transmit power control in
https://lowpowerlab.com/forum/index.php/topic,688.msg4031.html#msg4031, and, I'm sure a myriad of other ideas that people have for enhancing the library for their own use.
My current thinking is 'inspired' by a comment Felix made in
Dan, thanks for the contributions.
I would consider these extra features and so I would propose including these in a separate library that inherits from RFM69.h.
This seems like an appropriate place to start, so given this suggestion, what would be required to extend RFM69?
I've examined this and, given Dan's SessionKey and my AutoTransmit power control proposals as benchmarks, I see the following RFM69 functions need to be declared as 'virtual' so that a class that is derived from RFM69 will get called even by internal RFM69 methods so they can be overridden:
Functions to be overridden:
setMode
setPowerLevel
send
sendframe
sendWithRetry - just in case
sendAck
receiveBegin
receiveDone - just in case
setHighPower
setHighPowerRegs
select - in case the RFM69 library does NOT get updated with SPI transactions
unselect - in case the RFM69 library does NOT get updated with SPI transactions
From an RFM69 file perspective, this would simply require adding the 'virtual' keyword before the method declaration in 'RFM69.h'. The cases where I cite 'just in case' are cases where I haven't seen an immediate need for virtualizing them, but it doesn't hurt to make it feasible to extend these should a need arise. In the case of select/unselect IMO these shouldn't need to be extended, however, if the library is not updated to include the SPItransaction updates, then these NEED to be virtualized.
There is one place where I don't think it's wise to extend in this way. And that is in the 'interruptHandler'. The processing within this function is fairly critical and can't be extended in the same way as other method (outright replacement would be ok, but then you'd have to track any critical timing changes). In this particular case, however, the uncanny similarity between my extensions and Dan's leads me to conclude that adding a simple hook, that gets called as soon as the 'CTLbyte' is fetched, would certainly enable the two afformentioned proposals to be implemented. The hook, as implemented in the RFM69 libary would be virtual function that is merely an empty stub as in:
virtual void interruptHook(uint8_t CTLbyte) {}
Again, this would be a simple addition to the interrupt handler where:
void RFM69::interruptHandler() {
<...snip - code snipped so this post would FIT!>
DATALEN = PAYLOADLEN - 3;
SENDERID = SPI.transfer(0);
uint8_t CTLbyte = SPI.transfer(0);
ACK_RECEIVED = CTLbyte & 0x80; //extract ACK-requested flag
ACK_REQUESTED = CTLbyte & 0x40; //extract ACK-received flag
interruptHook(CTLbyte); // <==== NEW HOOK call point
for (uint8_t i = 0; i < DATALEN; i++)
{
DATA[i] = SPI.transfer(0);
}
if (DATALEN < RF69_MAX_DATA_LEN) DATA[DATALEN] = 0; // add null at end of string
unselect();
setMode(RF69_MODE_RX);
}
RSSI = readRSSI();
//digitalWrite(4, 0);
}
In the derived classes, the interruptHook would examine the CTLbyte, TARGETID, DATALEN, and SENDERID and make any adjustments necessary before returning to fetch the rest of the data. In my case, I'd strip off the receivedRSSI I include in the responses, while Dan and Kobuti would pull off the SessionKey info and we'd all adjust the DATALEN to account for this extra data.
Finally, this proposal would rely on some discipline on the part of the CTLbyte flags. Currently, in the RFM69 library there are only two bits used, bit 7 (0x80) & bit 6 (0x40). In my scheme I use 1 more bit. In Dan's scheme, he uses two bits. What I would like to propose is that the RFM69 library, 'officially' define bits 0-3 as reserved for derived classes. This leaves two spare for the library itself, and 4 bits for the rest of us to wrangle over.
Tom