Honest oversight, probably because I didn't know any better. This current project of mine has challenged me well beyond my knowledge of embedded programming and AVR uC. So let me try to spell out details.
The uC is performing 3 primary tasks:
Task-1)
Continuously reading (via the external interrupt on pin#2) a RF module. The ISR does some low level decoding of the signal, and also filtering out high frequency noise. The signal is encoded such that each bit (0/1) & sync pattern, is represented by 4 level transitions, spaced differently for each bit. My ISR is invoked roughly every 50us due to the "noise", but with a small set of instructions, it determines that the transition isn't valid signal and returns. If valid transitions are found, bit-level decoding is performed, and result is pushed into a ring-buffer. The ring-buffer is monitored within main loop() continuously, trying to decode the string of bits into a valid message. A message has address and data bits. After decoding the message, I need to check if the message is indeed for this node, i.e. check the address, and invoke a callback function (registered at startup), to handle the message.
Task-2)
Act as an I2C slave, receiving commands from another uC, intermittently, and sharing status updates back. Also if there is any interesting event detected, that is informed back to the master.
Task-3)
Periodically uC also needs to generate a pattern of level transitions, with variation in delay between the transitions, in a way very similar to the received signal from the RF module. This generated pattern of level transitions, which make up the message-packet, is fed to the RF module for transmission. This is what I was hoping to use Timer1 for, i.e. to space out (precisely) the level transitions, that take care of the lowest level of encoding.
Coming to 64-addresses, the wireless comm data is packetized. A packet has 6 bits of address, and 6 bits of data. Each node (s.a. this Arduino / equivalent device) has a unique address, and that is how they communicate with each other. The transmission of actual message packets is "bursty", i.e. the devices could be silent for long periods, except for a periodic Heartbeat message (similar to Watchdog in theory). Non-heartbeat message transmission might happen as fast as say 100 message/sec but for a brief period (1-2 seconds), or several hours apart.
What this means is --
-
Noise filtering logic is the highest overhead and "always-on", but this part of the logic in ISR is fairly short. I haven't counted instructions, but it is the bare minimal logic of comparing last transition timestamp and this one, checking against min. valid signal transition length and discard as noise if it is shorter. Very rarely, some noise transitions do get characterized as valid signal, and further processing filters it.
-
The logic of processing valid transmission, including Heartbeat messages happens (in the main loop(), not in ISR) i.e. to validate address, validate other message contents etc., and forming Heartbeat-Ack message, or other message is performed (again in main loop()). The communication between ISRs (i.e. one which is EXT INT0 ISR for data reception, and one which is Timer1 ISR for timing the sending of data) is using ring-buffers (with overflow indicator).
-
Finally, there is the I2C communication with a main processor. Potentially something like a Beagleboard running a Linux based GUI rendering a map of activities in this wireless network, and providing some sort of automated "game commentary". The wireless network is a bunch of sensors that read open/close of gates in a mega-maze to track participants and their movement.