I am also interested in this. I was wondering if there is a commands/packets sent & received per second / millisecond property that can be queried in ARC.

The red led indicates client communication activity as described in the ezb v4 datasheet.

Throw a capacitor on the digital line to hold it higher for longer - or a latch with a 555 to reset it every x interval - or even easier is an arduino/pic that counts interupts and can be queried over i2c.

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.

DJ, thanks for replying! I have my dumb head on today (its my age!) and do not get how an I2C interrupt counter could work as the v4 does not seem to have interrupts to count? Could you give me some more hints on how to do this? If I understand the principles, then I can easily write some PIC code to do this.

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.

Tony

I might be understanding more of what you're asking in the second response. To be clear, let me know I'm understanding the question...

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?

Yes DJ, its sensory data from the EZ:1 head (thermal imaging, ambient temp, head IR ranger, left/right PIR detect and light level) all this is compressed into 3 bytes - this data is to be analysed by the v4 where it gives a response back to the master_head_PIC as what to do next.

Tony

Ah, the fastest way is to check the uart buffer for available data. Only read the data if the expected number of bytes for a valid packet has been received in the ezb uart buffer. If you start reading uart 5 bytes, and there are only 3 bytes in the buffer, the ezb will block the connection and wait for the next 2 bytes - based on the pic to ezb baud rate, could take well over 500 ms. So do not read unless a valid packet length is within the ezb buffer.

Simply use the uart is data available command - that will be the quickest for your situation.

Here's an example....

# This is a demo on how to wait for a specific UART packet size
# and process the data when it has been received

# Initialize the UART (this also resets the ez-b's input buffer)
UARTInit( 0, 0, 9600 )

:loop

# Only process data if the packet size is available (packet size is 2 bytes)
if (UartAvailable(0, 0) >= 2)

  # A valid packet is ready. Read the packet
  UARTReadBinary( 0, 0, 2, $inputData )

  if ($inputData[0] == 0x01)

    # this is a sonar response packet

    $sonarDistance = $inputData[1]

  ELSEif ($inputData[1] == 0x02)

    # this is an ADC value

    $adcValue = $inputData[1]

  endif

ELSE

  # no valid packet is available
  # pause before we check again
  # to be friendly on the communication channel
  
  sleep(100)

endif

goto(loop)

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.