> I want to know if there is information available on the time delay > from arrival of a wakeup interrupt to actual processing start on a > 16C84. The time, in XT mode, is 1024 cycles minimum, where those cycles are whatever speed the crystal runs before it stabilizes. > I want to use my '84 as a code receiver and have it sleep > between transmissions. Codes are sent at 1200 baud and I use > a 1MHz resonator as clock source (configured as XT type). > Is the wakeup time short enough and stable enough to not miss > the first information bit? Dicey at best. At 1200 baud, the wakeup will probably eat a good chunk of your start bit, but probably none of the first data bit. If you really want to do this, I'd guess you should probably sample the first data bit about 1000us after you wake up (sample the rest at 833us intervals thereafter). Dwibble an unused port pin when you sample the first data bit and check with a scope to see how well centered it is. > In the documentation they say that the time delay is 1024 clock > cycles, but what about the time for the oscillator to start? > Is this startup time temperature dependent? If so how much? The startup time will be somewhat dependent upon ambient temperature, the make of crystal, the caps you use with it, the phase of the moon, etc. If you're lucky, though, it will more-or-less consistent. > I hope someone out there knows the answer to this one... :-) It will be highly dependent upon many factors. The only thing you can do is experiment (and if you mass-produce this thing, test each unit to ensure that it samples the first bit within a small tolerance of center). Depending upon what else your CPU is doing, another option might be to use an RC oscillator and adjust your baud rate so it's correct (i.e. analyze the incoming data to determine how fast or slow your RC is, and adjust your read logic accordingly). This would have the advantage that the oscillator would start "instantly", but would have the disadvantage that you'd need to deal with the RC's inaccuracies. This is assuming, btw, that you're not going to be idle for so long between data bytes that the ambient temperature will change significantly. If you are, then you're sunk.