WaitForInterrupt in a Task

[dkinzer]

One solution to a time-critical problem like this is to add some external hardware that can capture data from or otherwise respond to the event. In this particular case, data needs to be read from the TW-523 in a window from 100uS to 900uS following the zero crossing signal edge and stored until the ZX can read it. In this case, the repetition rate is fairly low - the ZX would need to read the sampled data with in 8.3mS of its capture.

The sampling circuit can be relatively simple as illustrated in the attached schematic. Here, a '123 one-shot, U2, provides the timing from the zero-crossing edge to the sample point - about 550uS. It is triggered by the edge detector, U1. The output from the one-shot not only clocks the flip-flop, U3, to capture the data but it can also be used as an edge-sensitive input to WaitForInterrupt() to tell the ZX that it is time to read the sampled data from the flip-flop.

[DH*]

In my case, it makes more sense to offload this task to a PIC and then interface with the PIC via RS232. That's true multi-tasking.

Also, while I did not get a screen capture, there were instances (probably when there was traffic on COM1) when 2-3 consecutive ZC periods were missed entirely.

However, it occurs to me that a simple 555 pulse stretcher circuit can accomplish the same thing as your circuit.

[dkinzer]

[DH*]

I think just the 555 is sufficient. Normally, if there's a data pulse from the TW523, it's a 1mS pulse that immediately follows the ZC transition. The problem is that WaitForInterrupt sometimes lags the ZC transition by more than 1mS, missing the pulse. Stretching the data pulse to ~3mS will allow the lagging interrupt to catch it.

Don't be misled by the 1mS pulses in my screen capture as those are just marker pulses I generate to indicate when WaitForInterrupt gets triggered.

[stevech]

[DH*]

No, I mean a PIC.

A CM11A will not interface with the high-end Home Automation controllers like JDS Stargate, HomeVision, HAI, Leopard, etc. which expect to be talking to a TW523.

My device already interfaces with a CM11A, MR26A, MR26X (has a different PIC to handle security RF), internal RF receiver, internal wide-band IR receiver, CM15X (CM15A with a daughterboard I designed to extend its capability), 2414S (Insteon), UPB PIM, Ocelot, Leopard and several other devices. It's an update of the BX24-AHT that I designed a few years ago. The ZX-40 has the interrupt driven software UARTs which really extend my original design.

[DH*]

[JC]

Another possible approach.
I understand your desire to maximize the performance of the ZX and software, and minimize the addition of extra hardware, such as a pic, etc., which increases the complexity of the design, board, and intra-cpu communications, etc.
If the main processor, the ZX-xx, is not heavily burdened regarding its workload, and does not have other significantly time sensitive tasks to simultaneously perform, one could consider a Task which is tracking the zero-crossing occurrences, and when it runs in a time slice within N mSec of the Next anticipated ZC it locks its task, and awaits the ZC by polling the bit. This gives rapid identification of the ZC, whereupon you then execute your required processing, unlock the Task, and move on.
Down side is 120 times a sec your system has to tolerate this one task temporarily suspending multi-tasking, albeit briefly. Up-side is no additional hardware/pics.
The Task can re-synch its timer/counter/RTC with each ZC.
The Task can be very brief if it has no data to process.
How soon BEFORE the next ZC this task has to seize the system and begin watching for the ZC is dependent upon how many TASKs can possible be queued, etc., and if it is likely (guaranteed) to run again before the next ZC occurs.
This technique might be enhanced by shortening the duration of each time slice. This would provide more slices within each ZC, allowing one to potentially seize the system closer to the ZC. This could increase the percentage of time spent in multi-tasking mode, at the expense of more time spent in task switching overhead. How soon to seize the system and lock out task switching would best be empirically measured.
Just a thought.
JC

[DH*]

[zbasicandy]

You must be Andy's centenarian neighbor
I resemble that remark.
There is no Stevech on my street!

[JC]

I may not have stated the concept clearly. The Task is not interrupt driven. It does require a timer, / counter / RTC / Tic value to anticipate when the next ZC will occur. This task runs simultaneously, with all other tasks, during its allocated time slots. Then, as the time closely approaches a ZC it temporarily stops multi-tasking, hence maintaining control of the CPU. It then precisely detects the ZC, processes whatever, and then resumes multi-tasking until it is almost time for the next ZC. It is not interrupt driven / triggered / controlled.

That said, the hardware option may be easier, especially if the CPU has other time critical tasks to perform. It is, however, always nice to have several options to evaluate, before committing to a specific one.
JC

[DH*]