This Forum is Dedicated For all The Object Oriented PIC Lovers .......... The concept behind OOPic is straight forward. Use preprogrammed multitasking Objects from a library of highly optimized Objects to do all the work of interacting with the hardware. Then write small scripts in Basic, C, or Java syntax styles to control the Objects. During operation, the Objects run continuously and simultaneously in the background while the scripts run in the foreground telling the objects what to do.

Saturday, November 10, 2007

[oopic] Re: OOPIC and CMUCAM

> I'm doing this as a project for a university course. If it makes any
> difference, they've got a lot of equipment lying around. I can have as
> many oopics as I need. They've also got cmucam2's.
>
> Would it help if I had the processing power of more than one oopic?
>
> Also, this is from the cmucam2's manual:
>
> "For even slower processors, the camera can operate in "poll mode". In
> this mode, the host processor can ask the CMUCAM2 for just a single
> packet of data. This gives slower processors the ability to more
> easily stay synchronized with the data."
>
> I'm thinking... I only need the X position to move the base of my
> robot. One sample a second is plenty fine. Can't the oopic do even that?

The problem is that the hardware USART (the oSerialPort object) only
has a 4 byte FIFO. Your code needs to prevent overflow at the data
rate established for the camera. You do this by setting the Track
command to return the minimum amount of data required for the
application. There's a way to do this but I don't have the manual in
front of me.

Next, you need to be waiting in a loop for the data to arrive. You
need to grab it and put it in a buffer as quickly as possible so you
can get back to the polling before the queue overflows. Once you have
the complete response, you can begin to process from the buffer.

I would think there is a problem sitting around waiting on the USART
rather than driving the 'bot. Part of that is resolved by making the
'bot motion run from virtual circuits. This pushes the logic out of
code and down to the interpreter object evaluation loop, a very good
thing to do. Or at least make sure that your loop gets back to the
USART as quickly as possible.

If you don't want to buffer the data, have your loop look like a state
machine that is interpreting the data as it arrives.

Serial I/O is not a strong point for the OOPic.

You could try two OOPics connected by oDDELink. One OOPic handles
only the serial I/O and leaves the value in a variable that the
oDDELink object serves up.

People have had problems with the I2C link. Check to be sure you have
pull-up resistors on the order of 2.2k or so. Higher values may be a
problem. OTOH, I have heard that OOPic-R boards don't like the low
value resistors but that is specific to the 16F877A chip and not the
OOPic-II+ which is based on the 16F877 chip.

Richard



Yahoo! Groups Links

<*> To visit your group on the web, go to:

http://groups.yahoo.com/group/oopic/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:

http://groups.yahoo.com/group/oopic/join

(Yahoo! ID required)

<*> To change settings via email:
mailto:oopic-digest@yahoogroups.com
mailto:oopic-fullfeatured@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
oopic-unsubscribe@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:

http://docs.yahoo.com/info/terms/

No comments: