Not to disparage the design, it is well thought out, especially the use of 12V! There have been several occasions when lightning has tripped the power, and the gate carries on merrily; it is exceptionally sturdy from the mechanical perspective; the charging circuit is well protected (MOVs inc) etc, but the PIC just doesn't respond! They use a 16C57, which is a big bugger, for the various options, but then proceed to use IC-like DIP switches, which conduct at the slightest sign of humidity. Under rainy conditions, the gate is in permanent ``pedestrian mode'', where it only opens so far, and closes again after 5 sec. If you keep triggering, you can get it to open, but to close it, you have to fool it by ``double triggering'', ie trigger, it closes a quarter of the way and stops. Trigger, wait for 1/2 sec, trigger again, and it closes another quarter. If you miss sync the double trigger, it opens a quarter instead, and you have to trigger it all the way open again.
Frustration isn't the word. When you've almost got it closed, it will re-open of its own accord since it now thinks its closing it. Attempting to keep the thing dry has no apparent benefits-the design itself is just too sensitive. They probably used 10 and 100k resistors where 1K or lower would have been more robust. They have fancy sensitivity pots which control the stopping of the gate should it encounter resistance. Its just too fancy.
In really cold weather, the PIC simply slows down (Couldn't find a crystal on the board, they probably use the RC mode which is very sensitive to temp). The pedestrian mode is obviously on a timed basis (there is no feedback mechanism), and the colder it is, the less space you get to walk past!
The primary problem is it's response time. Come hell or high water, you can VERY seldom stop the gate mid-flow. Clearly they are either using a VERY long debounce cycle, or a large capacitively coupled input (I haven't really investigated) As a result, if it is about to bash into someone's car, it bloody does. The ``autoclose'' facility is great, since certain members of the family have a tendency to forget... :-), but at a max of 40 Seconds, its a pain in the arse when multiple guests are leaving :-)
So...... what I want:
The philosophy is thus that a fancy pressure sensitive thingy is not necessary, but that I can judge when I want the action aborted, but then I want it done!!!
One of the problems is that the battery supply voltage drops below 12V when the gate motor is operating. The QD receiver then does not listen to a keypress. (Designed for 12-24V, but clearly needs at least 12V - will address with monster cap and diode, I think.)
A trigger during opening or closing operation must stop the gate and reverse.
A pedestrian input must open the gate for a period of time, so that it only partially opens the gate, followed by 10 seconds of being open, and must close fully. Only after this cycle is complete must it again listen to the pedestrian input. ie it must not be possible to re-trigger it all the way open. (Pedestrian mode not yet implemented)
The Direction output feeds a relay to reverse the polarity of the juice to the motor when this is given via the MotorOff output. I could also use an H-bridge I guess.
The use of the n/c contacts ensure that the gate is always closed, as power is always applied in that direction, until the cams cut it off. ie with both relays de-energised, the gate closes-hence MotorOff!
The instruction cycle thus runs at 451 550/4 = 112 887.5 Hz! meaning that an instruction takes 8.86mSec. Using the full 1:256 Prescalar, we get to an RTCC rollover of 2.27mSec.
To get a 0.1Sec processing cycle, we therefore need 44.0967 counts :-). Thus at 44 counts, we get 0.09978 Secs, which is pretty good enough as a time base.
Thus in terms of the system scaling granularity, the RTCC rollover occurs at 2.27mSec, and the smallest (logical) time interval avaliable is a tenth of a second, which is perfectly adequate for this simple project. Since an instruction cycle is 8.86 muSec, we have 11 264 instructions per processing cycle!!!
My standard RTOS requires 1 label to be defined-UserProgram, and requires a goto Wait at the end of the task list. In this way, I prevent the unnecessary use of a stack level, and since I designed the RTOS originally for the 16C54, with only 2 stacks...