To do the timing on the Z, you'd need to be confident that your userland program would be able to measure the timings of events with 10 to 20mS accuracy - preferably 10mS or better. I lacked that confidence, but I'd be very interested if anyone could prove me wrong.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=160035\"][{POST_SNAPBACK}][/a][/div]
10 mS is a long, long time to the computer. I make video games for a living, and we try to get 60 frames per second. Every 16.7 mS, the games I work on need to do physics calculations, transform and draw thousands of polygons, process artificial intelligence, and so on. Granted, the hardware we develop for is designed for this sort of thing, but you can do a whole heck of a lot in twenty milliseconds of computational time.
I would be really surprized if multitasking on the Z would skew your timings too much. I expect you could use a standard message pump and take for the time stamp the time that you get the callback to process the event, and that the amount of time that this would be off -- probably on the order of microseconds -- would be far less than the amount of variation time your program has to account for when looking at human-provided input.
[Hmm... It appears that a single task may get up to ten milliseconds in one go, on the high end. That computing quantum is higher than I thought, and may actually cause you a problem. I don't know what the actual time is for the Z. It may be, though, that multiple timings are skewed by the same amount, and, especially since your task will be the only one running, I don't think it'll be an issue.]
Armagon
[div align=\"right\"][a href=\"index.php?act=findpost&pid=160140\"][{POST_SNAPBACK}][/a][/div]
I think you're very likely to be right - and for the archive, I agree with your point.
I note your "Hmm" though. I was trying to avoid getting involved with issues I couldn't measure, which is why I didn't want to go down that road. I don't have a problem with the amount the machine can do in a stated period of time, but I did worry about how long my program could potentially be backgrounded,
In my particular case:
Given that I'm developing this for one single individual, and given his particular situation, I'm not in the position where I can carry out experiments. Either it works first time when he's presented with it, or it's dead in the water. I feel more confident that my (let's say, in general terms unnessarily elaborate) solution will work out of the box, because I don't know how long the Z could take control away from my program, and I think I've evolved a solution where it isn't necessary to know that.
There's still the other issue: debouncing. A typical Morse key has brass contacts, and when contact is made, there's a whole lot of noise there. In my experiments, I found that the noise would persist for about two thirds of the length of a 20wpm dot. In my solution, the PIC does the debouncing, which makes the Z program a lot simpler. If the debouncing had to be done on the Z, I think the timing requirements would be an order of magnitude more severe. Well, either that, or I'd have to be a cleverer programmer than I am. Which is not likely to happen any time soon :-(
We've already seen in this thread the solution that I entirely missed: the use of the audio port, which by definition capures samples at regular and known intervals, and buffers them until you're ready for them. If I were starting again on this project, I think I might well begin there. That does seem to be a way of getting the Z to do the timings with accuracy.