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
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

Actually i want to use what you suggested
(uM FPU Ver 3.1) but we're a little short handed
right, now you see i live in the Philippines so we
don't have that much components in here and we all
need to buy it from other country which also takes
time.. Our project submission is due next week
Thursday. We just recently discovered that the oopic
cant handle the gps data and we're still trying to
make a program maybe just maybe it will store the data
we need.... we're also doing the PIC as a backup but i
think we'll probably use it since where under time
constraint hope you understand thats why i'm asking
for any suggestion. i really appreciate what you said
from the previous post well aside from make me down
thinking that our project is not feasible from what we
components we have right now. Well anyway aside from
using the I2C what else can we use to make the PIC and
OOPIC communicate?
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

--- In o...@yahoogroups.com, alvin sy 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



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

Yes,

You can talk to the ooPIC over the DDELink (network) port and it will
look like a 256 byte EEPROM in terms of addressing. An easier way to do
this is to talk to it over the serial link using SCP commands, they are
WAY easier to do than the arcane bit masking that you'll have to do if
you use the I2C link to the ooPIC.

BTW, why are you using the ancient '877A? If I were you I would use a
newer 18F part. They are cheaper, faster and easier to do. Also, you
can use the Microchip educators version of C18 to write code to it.

DLC

alvin sy 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
> ____________________________________________________________________________________
> Never miss a thing. Make Yahoo your home page.
> http://www.yahoo.com/r/hs
>
>
>



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

--- In o...@yahoogroups.com, ooPIC Tech Support
wrote:
>
> Yes,
>
> You can talk to the ooPIC over the DDELink (network) port and it
will
> look like a 256 byte EEPROM in terms of addressing. An easier way
to do
> this is to talk to it over the serial link using SCP commands, they
are
> WAY easier to do than the arcane bit masking that you'll have to do
if
> you use the I2C link to the ooPIC.

If you can get oDDELink working with the PIC as the master and the
OOPic as the slave, your life is simplified. The PIC just stuffs
updated values into known locations of the OOPic memory as though it
is an EEPROM. You probably need some kind of handshaking (via a flag
variable) so that the OOPic doesn't grab an updated Lat while the Lo
is stale.

I would try using the I2C Tools to see how it works and then write
the same functions for the PIC.

Richard



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

There isn't much you need to do. You can talk to the ooPIC like it is
a 256 byte EEPROM by connecting to the network port. But, you have to
play lots of games with bit masking and such to access everything. The
source Richard mentions shows how to do that. SCP is a bit more
straightforward and the pages on it in the manual help out with the bit
masking stuff as well.

DLC

rtstofer wrote:
> --- In o...@yahoogroups.com, ooPIC Tech Support
> wrote:
>
>> Yes,
>>
>> You can talk to the ooPIC over the DDELink (network) port and it
>>
> will
>
>> look like a 256 byte EEPROM in terms of addressing. An easier way
>>
> to do
>
>> this is to talk to it over the serial link using SCP commands, they
>>
> are
>
>> WAY easier to do than the arcane bit masking that you'll have to do
>>
> if
>
>> you use the I2C link to the ooPIC.
>>
>
> If you can get oDDELink working with the PIC as the master and the
> OOPic as the slave, your life is simplified. The PIC just stuffs
> updated values into known locations of the OOPic memory as though it
> is an EEPROM. You probably need some kind of handshaking (via a flag
> variable) so that the OOPic doesn't grab an updated Lat while the Lo
> is stale.
>
> I would try using the I2C Tools to see how it works and then write
> the same functions for the PIC.
>
> Richard
>
>



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

The ooPIC looks like a 256 byte EEPROM to any I2C master when
connected to the network bus. You have to know how to mask bits and
twiddle things, but the source Richard mentions shows how this is done.
The SCP pages in the manual help with the bit mask work as well. Using
SCP directly to the serial port is a little easier though I think.

DLC

rtstofer wrote:
> --- In o...@yahoogroups.com, ooPIC Tech Support
> wrote:
>
>> Yes,
>>
>> You can talk to the ooPIC over the DDELink (network) port and it
>>
> will
>
>> look like a 256 byte EEPROM in terms of addressing. An easier way
>>
> to do
>
>> this is to talk to it over the serial link using SCP commands, they
>>
> are
>
>> WAY easier to do than the arcane bit masking that you'll have to do
>>
> if
>
>> you use the I2C link to the ooPIC.
>>
>
> If you can get oDDELink working with the PIC as the master and the
> OOPic as the slave, your life is simplified. The PIC just stuffs
> updated values into known locations of the OOPic memory as though it
> is an EEPROM. You probably need some kind of handshaking (via a flag
> variable) so that the OOPic doesn't grab an updated Lat while the Lo
> is stale.
>
> I would try using the I2C Tools to see how it works and then write
> the same functions for the PIC.
>
> Richard
>
>



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

There's another way to handle GPS data with the OOPic and it might
actually work!

Use the Parallax GPS Module! It has an SX processor on the board that
allows the host uC to request specific information and have it
delivered on demand rather than asynchronously and continuously. See
http://www.parallax.com/Portals/0/Downloads/docs/prod/acc/GPSManualV1.1.
pdf

Look at 'Smart Mode'. With this scheme the uC requests a specific
piece of data, say Lat, and the sensors sends back just that
information. This allows a slow uC like the Basic Stamp to interface
with GPS.

Richard



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

On Feb 21, 2008, at 11:27 AM, rtstofer wrote:

> 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.

This is probably philosophy but do people use oDDELink enough to
justify essentially eliminating the hardware I2C gadget?

> 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.

I am getting ready to interface to a bunch of I2C devices and just
need to use I2C. It seems so silly to make the hardware I2C widget in
the PIC unusable to talk to other sensor devices. This is looking like
it might turn out to be a real pain. I am just wondering about the
logic or whether Savage Innovations is considering making a change.

--

73 de Brian, WB6RQN
Brian Lloyd - brian HYPHEN wb6rqn AT lloyd DOT com



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

> I am getting ready to interface to a bunch of I2C devices and just
> need to use I2C. It seems so silly to make the hardware I2C widget
in
> the PIC unusable to talk to other sensor devices. This is looking
like
> it might turn out to be a real pain. I am just wondering about the
> logic or whether Savage Innovations is considering making a change.
>
> --
>
> 73 de Brian, WB6RQN
> Brian Lloyd - brian HYPHEN wb6rqn AT lloyd DOT com
>

I wouldn't count on the change... Sometimes there is just a limit to
what the OOPic can be expected to do.

I certainly wouldn't plan on hanging more than a couple of I2C
devices on the local bus. I did some code for an I2C ultrasonic
ranger and an I2C based LCD display. The update rate was GRIM.

In any event, the hardware I2C module is fully capable of talking to
the EEPROM and a general purpose I2C bus. Why it wasn't used escapes
me. Maybe because the code was derived from an even earlier chip
that may not have had an I2C gadget.

There are other microcontrollers...

Richard



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

On Feb 25, 2008, at 6:21 AM, rtstofer wrote:

>> it might turn out to be a real pain. I am just wondering about the
>> logic or whether Savage Innovations is considering making a change.
>>
>> --
>>
>> 73 de Brian, WB6RQN
>> Brian Lloyd - brian HYPHEN wb6rqn AT lloyd DOT com
>> I wouldn't count on the change... Sometimes there is just a limit to
> what the OOPic can be expected to do.

Which is why I am surprised that peripherals are on the bit-banged buss.

> I certainly wouldn't plan on hanging more than a couple of I2C
> devices on the local bus. I did some code for an I2C ultrasonic
> ranger and an I2C based LCD display. The update rate was GRIM.

That is precisely what I am worried about.

> In any event, the hardware I2C module is fully capable of talking to
> the EEPROM and a general purpose I2C bus.

I know.

> Why it wasn't used escapes me.

We are in the same boat then.

> Maybe because the code was derived from an even earlier chip
> that may not have had an I2C gadget.
>
> There are other microcontrollers...

Yes. I am quite impressed with the Propeller from Parallax. If only it
had A:D on the chip ...

Regardless, I have several kids who are-building/have built MarkIIIs
and they want to add things like a Devantech compass module and the
sensor board (2-axis accelerometer) to help them with rudimentary
mapping.

Brian Lloyd
Granite Bay Montessori School 9330 Sierra College Bl
brian AT gbmontessori DOT com Roseville, CA 95661
+1.916.367.2131 (voice) +1.791.912.8170 (fax)

PGP key ID: 12095C52A32A1B6C
PGP key fingerprint: 3B1D BA11 4913 3254 B6E0 CC09 1209 5C52 A32A 1B6C



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

--- In o...@yahoogroups.com, Brian Lloyd wrote:
> Regardless, I have several kids who are-building/have built MarkIIIs
> and they want to add things like a Devantech compass module and the
> sensor board (2-axis accelerometer) to help them with rudimentary
> mapping.

Sure, the LCD update was grim but there were other things going on
besides I2C. STR$() comes to mind.

In the case of a compass or sensor board, the amount of IO will be
considerably less than writing full sentences to an LCD one character
at a time.

It won't be blistering fast but I suspect it will work fine. It's been
done before and I haven't heard a lot of complaining. The big
stumbling block for the OOPic is serial IO.

Richard



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

On Feb 25, 2008, at 9:37 AM, rtstofer wrote:

> --- In o...@yahoogroups.com, Brian Lloyd wrote:
>> Regardless, I have several kids who are-building/have built MarkIIIs
>> and they want to add things like a Devantech compass module and the
>> sensor board (2-axis accelerometer) to help them with rudimentary
>> mapping.
>
> Sure, the LCD update was grim but there were other things going on
> besides I2C. STR$() comes to mind.
>
> In the case of a compass or sensor board, the amount of IO will be
> considerably less than writing full sentences to an LCD one character
> at a time.
>
> It won't be blistering fast but I suspect it will work fine. It's
> been
> done before and I haven't heard a lot of complaining. The big
> stumbling block for the OOPic is serial IO.

I have one student who is doing voice-control of her MarkIII from her
Mac using a bluetooth link. The commands are single characters coming
in over the hardware UART port after SCP is disabled (\A). She will be
using oSerial to receive the characters but the rate will be very
slow, i.e. one character per command every couple of seconds. I
suspect that the OOPic can handle that rate without difficulty.

We have 4 weeks until the science fair and I will be very busy helping
kids debug their OOPic programs. ;-)

Brian Lloyd
Granite Bay Montessori School 9330 Sierra College Bl
brian AT gbmontessori DOT com Roseville, CA 95661
+1.916.367.2131 (voice) +1.791.912.8170 (fax)

PGP key ID: 12095C52A32A1B6C
PGP key fingerprint: 3B1D BA11 4913 3254 B6E0 CC09 1209 5C52 A32A 1B6C



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

Can i ask whats the really problem of the serial IO
of the oopic? i mean you said the "big stumbling block
for the OOPic is serial IO." can you explain why... thanks
____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

The OOPic only has a 4 character input buffer and operates so slowly
that it can't even keep up with a 4800 bps datastream. If you're
only sending the OOPic short commands (4 characters or less), you're
OK. Anything more and data is lost.

At 03:46 AM 2/26/2008, alvin sy wrote:
> Can i ask whats the really problem of the serial IO
>of the oopic? i mean you said the "big stumbling block
>for the OOPic is serial IO." can you explain why... thanks



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

Andrew Porrett wrote:
> The OOPic only has a 4 character input buffer and operates so slowly
> that it can't even keep up with a 4800 bps datastream. If you're
> only sending the OOPic short commands (4 characters or less), you're
> OK. Anything more and data is lost.
>
>
Unless you are using flow control, which very few things do.

DLC
> At 03:46 AM 2/26/2008, alvin sy wrote:
>
>> Can i ask whats the really problem of the serial IO
>> of the oopic? i mean you said the "big stumbling block
>> for the OOPic is serial IO." can you explain why... thanks
>>
>
>



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )