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.

Thursday, February 21, 2008

[oopic] Re: using oDDELink

--- In oopic@yahoogroups.com, alvin sy <alvinsy2000@...> wrote:
>
> Since oopic cant handle the data coming from
> the gps, we decide to use another
> microcontroller(PIC16F877A) where the PIC will receive
> and store the data and send it to the oopic, i was
> wondering since the PIC will be using the serial, can
> i use the oDDELink to link the two? Another question
> is my compass is already using the I2C pins and if im
> read the manual right the oDDLink also uses I2C right?
> so any suggestion how can i connect my oopic to the
> PIC? thanks
>

I doubt you will get oDDELink to work although I previously told you
of the I2C Tools in the Files section. That code is written in Visual
Basic and intended for use on a PC.

The hardware I2C gadget inside the OOPic is used ONLY for oDDELink.
All other I2C peripherals connect to the local I2C bus the OOPic uses
to talk to the EEPROM. This is bit-banged and pretty slow.

You compass (and every other device you want to interface with I2C)
will connect to this low speed, bit-banged, I2C bus. Be careful about
capacitive loading (long cables).

Your PIC will have to operate as an I2C slave because the OOPic is
always the bus master. For this to have a chance of working, you
should probably write the PIC serial IO routines as fully interrupt
driven with a large circular buffer (not that the PIC has very much
RAM!). The I2C gadget is normally coded as an interrupt driven state
machine. Code is available at Microchip and on the web.

All the PIC mainline code has to do is grab the sentences from the
serial buffer, do some interpretation and post the results to an area
of memory that the I2C code can grab.

Frankly, I wouldn't do it this way. I2C is hard to implement, much
harder than SPI. I would spend a little time looking at the OOPic
oSPI object and the PIC datasheet and see if SPI would be easier.

Or I would look at that uM FPU Ver 3.1 that I just posted about.

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: