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.
Upgrade to ARC Pro
Your robot can be more than a simple automated machine with the power of ARC Pro!
What you're experiencing is the ugliest issue with the remote processing approach. The solution is additionally hardware. This is because every time the port is queried, there is a period between the queries which can miss the signal. This is because there is no interrupt behavior on the ezb v4 - and an over sight on my part.
The solutions are there, they're just additional hardware. Jeremie has a task item to create an i2c interupt counter addon. It's a month or two away from hitting the store due to other priorities. It's essentially a microchip pic on a tiny pcb that counts interupts and can be queried and reset from the ezb.
Guess you can make one of those quite easily for your solution in the meantime.
I need something that lets my head_master PIC microcontroller flag (and synchronize) with the v4, so that the v4 knows data is waiting to be received from the PIC - extending the digital line does not help in my application as I would prefer it if a single data comms packet (to the v4) did not take over 500mS to be sent.
Thanks again for all your help, it is much appreciated.
A pic has data that needs to be sent to ARC through the ezb v4 - and you would like the pic to tell ARC when the data is ready to be read from the pic through the ezb?
Simply use the uart is data available command - that will be the quickest for your situation.
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.