Re: [oopic] Re: Using IO Lines? R to R Board Comm

Don't forget that you can filter using VC's as well. oMath and others
work well for this. Sadly, I have found that oDDELink is anything BUT
real time, it can take a few hundred milliseconds for the data to
transfer - If this is acceptable, go for it. Another way is to put the
data on an oDIO8 with signal pairs between the two ooPIC R boards to
send data back and forth. This is simpler than using oDDELink in that
the cable is easier to make. ;) oDDELink has an issue when two ooPIC R
boards are used, we've never been able to figure this out either, but
they just don't talk unless you do <something> just right with just the
right value of resistors. The oDIO8 bus approach is faster and simpler
to implement. In fact, by using oDIO8 you can probably do the whole
thing with VC's and never run any interpreted code. Since this is a
class I'm not going to give you the answer, but look at these objects:
oDIO8
oDIO1
oBus
oWire
oTimer
oFlipFlop
oCountDown
oChanged

It might just be possible to do it all in VC's. Do some careful state
diagrams.

Have fun,
DLC

rtstofer wrote:
> --- In oopic@yahoogroups.com, "red71956" <kdwyer@...> wrote:
>
>> Question:
>> If I have only one compass (CMPS03) that connects to the I2C bus on an
>> R board, what is the simplest method to ensure a second R board, also
>> connected via I2C, gets the same reading in near realtime? Board 1
>> (with the compass) also has IR rangers that must transfer data.
>> Options include:
>> Only two basic units of information need to be transferred, 'Heading'
>> and 'ObstacleRange'. Use DDELink? Or IO lines? Hardwired to Serial Port?
>>
>
> One thing you CAN'T do is connect the two LOCAL I2C buses together and
> hang the sensors on the resulting single bus. The fact that the
> EEPROMS would be visible to both machines and the resulting collisions
> make that obvious.
>
> oDDELink is probably workable. The host CPU gets the values and
> stuffs them in the shared object. The client CPU sees the values
> immediately thereafter.
>
> The OOPic is almost useless when it comes to serial IO. I think I
> would avoid that approach.
>
>
>
>> Extra credit:
>> Extensive use of Virtual Circuits
>>
>
> Sure, use a timer to trigger an event to read the sensors and stuff
> the results. I haven't looked to see if a timer event can be slow
> enough to be reasonable. Or, a first firing of the event starts the
> sensing operation, a second firing grabs the values and a third firing
> stuffs the results. The advantage to this is that the event code
> doesn't tie up the processor for a long period of time.
>
>
>> Show all work.
>>
>
> The function of my code is ALWAYS obvious to the most casual observer.
> Comments are never needed because any competent person can see what I
> had in mind.
>
> Richard
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>

--
------------------------------------------------------
Dennis Clark ooPIC Tech Support
www.oopic.com
------------------------------------------------------

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/