Polling to get an accurate time doesnt seem like it would ever be very successful.
I suspect you need external signal conditioning so that you can convert the impulse into a digital signal, that you can use to trigger an ISR.
If you don't have enough interrupts available, you'd need to OR the triggers through some external hardware (OR gates), and then get the Arduino to read the status of the individual inputs to see which one triggered the interrupt (this is a common method around the problem of not having enough interrupt pins)
Sending data will still be an issue because you'll need to make sure that your data capture interrupts are not effected by other interrupts.
AFIK, you can re-enable a interrups inside the an ISR (see http://stackoverflow.com/questions/5111393/do-interrupts-interrupt-other-interrupts-on-arduino
However, I think you may be better off running your sending code in the main loop and modify the core Serial code to send using polling rather than interrupts.
You could take a look at the software serial library (both the old and new versions) as they may be easier to convert to not using interrupts however 250kpbs is probably out of the question for software serial
You could also consider using SPI, as generally it operates via polling from what I recall.
A final problem is time accuracy. The Due clock sucks for stuff like
I've not checked this on a Due but it seems odd that you'd need to check every 5 secs
In fact, how are you doing this. Does your RTC return the time to that level of precision?
I just looked at the spec on the RTC http://datasheets.maximintegrated.com/en/ds/DS1337-DS1337C.pdf
and it only returns the time to the nearest second.
So you'd have either use the Alarm Interrupt or continuously poll the device and wait for the second value to change.
If you need it to be as accurate as you say, I'd suggest that those RTC's arent accurate enough for you in the first place.
I suggest you connect a GPS module, as once they have lock, they are exceedingly accurate as they get their data from the atomic clocks on the GPS satellites.
However you'd still have an issue of determining how long it was taking to retrieve the time data from the GPS or RTC module and whether there was any variability in the time taken for the data comms
If you think that the clock freq is too far off, I'd suggest that rather than continously reading the external reference, that you initially run a calibration process for 5 mins or more , and then calculate a correction factor to apply to the time that the Arduino is keeping.
Note the time keeping of the Arduino is also done on an ISR, so this too will affect your results.
What is your desired level of time accuracy, you mention 40nS at one point, however I'm surprised that you are getting it that accurate i.e accurate to about 1/3 of the Due's clock rate.
How are you measuring this time accuracy, do you have an external atomic clock etc which you are using to measure this ?
Q1) One main problem I'm having trouble with is data offloading. Currently, I have a computer send a byte to the Arduino telling it to initiate offload (Serial.print() @ 250kbps the timestamps in memory) every quarter second.
Why are you sending the data this often ?
Is it because the upstream systems need to be notified quickly of a change of input.
Or do you get loads of data all the time.
If you are not getting data all the time, it seems pointless swamping the upstream systems with the same data they got in the last 1/4 sec ????
(Serial.print() @ 250kbps the timestamps in memory)
Where is the data going? To a PC or another arduino or are you just recording the data over a long period
I think unless you describe the whole system, you are not likely to get completely use response from anyone to this question