Welcome to Synthiam!

The easiest way to program the most powerful robots. Use technologies by leading industry experts. ARC is a free-to-use robot programming software that makes servo automation, computer vision, autonomous navigation, and artificial intelligence easy.

Get Started
United Kingdom
Asked — Edited
Resolved Resolved by DJ Sures!

Question For Dj On V4 Digital Port Latency

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


ARC Pro

Upgrade to ARC Pro

Your robot can be more than a simple automated machine with the power of ARC Pro!

#1  
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.
#2  
The red led indicates client communication activity as described in the ezb v4 datasheet.
PRO
Synthiam
#3  
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.
PRO
United Kingdom
#4  
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
PRO
Synthiam
#5  
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?
PRO
United Kingdom
#6  
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
PRO
Synthiam
#7  
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.
PRO
Synthiam
#8  
Here's an example....


Code:


# 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)
PRO
United Kingdom
#9  
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
PRO
Synthiam
#10  
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.
Login to post a comment