Resolved by DJ Sures!
DJ, I wonder if you can help with something that is truly baffling me?
The EZ:1 head has 3 PIC microcontrollers and one (the head_master_PIC) controls the 3 PICs and only this one links with the v4. Now without having interrupts on the v4, I had to figure a way of "Flagging" the v4 that data (from the head) needs to be sent to it, so I set up a STROBE line from the head_master_PIC to the v4 using a v4 digital port line. I first did some trials and set the head_master to send a 100mS positive going pulse in a five second frame. The v4 caught (counted) about 40% - I had to up the pulse to 500mS before the v4 caught all pulses with no dropouts.
This is half a second which in modern day computers/microcontrollers is a lifetime!
So it would seem from my setup that a digital (input) port on the v4 needs a minimum of 500mS to reliably (and repeatably) read just a positive going signal on its port line? I now have it working but it needs a 500mS (minimum) STROBE pulse then the PIC sends the data packet, any smaller STROBE pulses and it starts having dropouts. The v4 script is just looping round and doing nothing else but pooling the v4 port line.
I just do not understand what I am missing here, surely the above digital port latency issue cannot be right?
DJ, can you advise any better faster way to STROBE the v4 from the head_master_PIC so it can send data packets faster?
Also, sometimes the red LED on the v4 flashes when the STROBE pulse comes in, what is the red LED for?
Thanks in advance for any guidance that you can give on this.
Tony
Thanks DJ, I am going to drop the STROBE idea completely and receive the 3 byte packet every loop cycle in the main program script - then do a quick checksum to see if the data has changed since the last receive. I am using 19200 baud so the packet should only take a couple of milliseconds to be sent, so its not such a big timing overhead.
Tony
Perfect - change the code that I posted to 3 bytes instead of 2 for valid packet size - and voila!
If lots of lots of packets are coming in when the code checks, you can always grab all data rather than just one 3 byte packet. Parse it after, that will be even friendlier on the communication channel.