In the code, shouldn't I replace the "$" with its ascii decimal equivalent(i.e. 36)? Or is enclosing the character in double quotation marks fine?

____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs

[Non-text portions of this message have been removed]



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

--- In o...@yahoogroups.com, alvin sy wrote:
>
> In the code, shouldn't I replace the "$" with its ascii decimal
equivalent(i.e. 36)? Or is enclosing the character in double
quotation marks fine?
Short answer: yes

Longer answer: try it

Dim ch As New Byte
Sub main()
If ch = "$" Then
End If
End Sub

Does the compiler accept the code? Yes, it does

Then look at the compiler output in the IDE by View -> Compiler
Output and browse down to where the program code actually does
something:

L2.Proc.Begin ;This.main

L3.If.Begin ;If ch = "$" Then
C0047:111 ;This.ch.Address
C0048:247 ;Read Var Byte
C0049:036 ;"$"
C0050:152 ;Is Equal.
C0051:137 ;16-Bit Value.
C0052:000 ;L3.If.End.HighByte
C0053:027 ;L3.If.End.LowByte
C0054:130 ;Branch On False.
L3.If.End
C0055:129 ;Branch.
L2.Proc.End

Notice the part where "$" is put in code as 036?

I would have pointed you to the place in the documentation that
answered your question but I couldn't find a sample of a simple
character literal used in an assignent.

Richard



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

Virtually everything I have seen so far uses the BASIC syntax as=20=20
opposed to C/Java syntax for code for the ooPIC. Is there a functional=20=20
reason for this or is it purely personal preference?
--

Brian Lloyd Granite Bay Montessori
brian AT gbmontessori DOT com 9330 Sierra College Blvd.
+1.916.367.2131 (voice) Roseville, CA 95661, USA
http://www.gbmontessori.com

I fly because it releases my mind from the tyranny of petty things . . .
=97 Antoine de Saint-Exup=E9ry

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

=20

=20


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

Richard, my oopic can detect the serial data coming
from my gps but im confuse because the code cant
detect the $ at the start. we already follow the case
statement that you posted.... here's the part of my
code getting the reading of the gps and storing it, i
think its better for you to look at it so you can tell
what are we doing wrong thanks

The .doc file is the gps part of the code, i also post
the whole program.... btw the way the NMEA sentence
that we want to filter out is $GPGGA since GPGLL isnt
one of the available NMEA protocol in our GPS
The 14 and 120 at case 9,10,19-21 is the degree's part
of the coordinates we parse then since its constant
but the
If ((buff>47) And (buff<58)) part i dont know why my
groupmate put it like that...... the project we're
working on is Autonomous mobile robot using gps as
navigation if your wondering whats with the code...
thanks

____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs

[Non-text portions of this message have been removed]



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

--- In o...@yahoogroups.com, alvin sy wrote:
>
> Richard, my oopic can detect the serial data coming
> from my gps but im confuse because the code cant
> detect the $ at the start. we already follow the case
> statement that you posted.... here's the part of my
> code getting the reading of the gps and storing it, i
> think its better for you to look at it so you can tell
> what are we doing wrong thanks
>
> The .doc file is the gps part of the code, i also post
> the whole program.... btw the way the NMEA sentence
> that we want to filter out is $GPGGA since GPGLL isnt
> one of the available NMEA protocol in our GPS
> The 14 and 120 at case 9,10,19-21 is the degree's part
> of the coordinates we parse then since its constant
> but the
> If ((buff>47) And (buff<58)) part i dont know why my
> groupmate put it like that...... the project we're
> working on is Autonomous mobile robot using gps as
> navigation if your wondering whats with the code...
> thanks

Where did you post the code? You can put it in the Files section or
just embed it into your message. What you CAN'T do is attach it.
Yahoo won't allow that.

Richard



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

Sorry about that, i didnt know that yahoo dont allow
attachment of files here. I already posted in the
files section of the groups under Code Example folder,
my folder name is "storing data from gps to oopic"
sorry for the trouble... btw i was wondering my gps
pins is already in TTL is the serialport object the
right object to use?
____________________________________________________________________________________
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 )

--- In o...@yahoogroups.com, alvin sy wrote:
>
> Sorry about that, i didnt know that yahoo dont allow
> attachment of files here. I already posted in the
> files section of the groups under Code Example folder,
> my folder name is "storing data from gps to oopic"
> sorry for the trouble... btw i was wondering my gps
> pins is already in TTL is the serialport object the
> right object to use?

It looks like you accumulate the ASCII digits ok although I don't
understand why you are skipping the least significant fractional
digit in order to keep the most significant non-fractional digit.
Still, it's your choice...

I think the conversion of the string to a value is hosed. It should
go something like:

val = 0
for i = 1 to 5
val = (10 * val) + (array(i) - '0')
next i

And that 47 and 58 stuff? You should really use an ASCII literal so
the code is clear.

The idea of the state machine is correct, you only want to deal with
one char at a time. Personally, I would build a loop to accumulate
and convert on the fly rather than store the chars in an array.

It isn't the oSerialPort object that determines the pin electrical
specification but it is TTL compatible, more or less. There is
always something of a concern mixing TTL and CMOS in terms of logic
voltage thresholds. Still, it should work ok. If not, add a couple
of 10k pull-up resistors.

Richard



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

i see, but we did some testing like when the oopic
received the "$" the wheel will move left or right but
the result is it doesn't move, its like the oopic is
receiving data but can't find the "$" or the following
characters. what could be the problem? 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, alvin sy wrote:
>
> i see, but we did some testing like when the oopic
> received the "$" the wheel will move left or right but
> the result is it doesn't move, its like the oopic is
> receiving data but can't find the "$" or the following
> characters. what could be the problem? thanks

You are hanging in the DO..While loop to read the characters. The
objective is to call the GPS input function from the loop in main()
and, if it gets a char it processes it. If not, it simply returns.
But it needs to be called OFTEN! And it might as well loop
on .received and eat all the chars in the buffer while it is
executing.

When the function finally has a completed lat/lo, it updates the
variables accordingly.

For this to work, the other functions can't hang around either. The
incoming buffer is 4 bytes.

As Dennis said, the OOPic can't keep up with a GPS under any
condition or, as I might have said, it is darn difficult and it is
about the ONLY thing the OOPic can be doing.

Let's say the OOPic executes about 1000 instructions per second
(although there are certainly examples where it only executes about
400). Four incoming chars takes about 13 mS so the buffer is full
(if starting from empty) in somewhere around 13 (or 5!) lines of
code. That is the buffer will be completely full - starting from
empty.

As you declare more objects, the code evaluation slows down.

It may be possible for the OOPic to keep up with the GPS but not with
a program of 700 lines of code. That oI2C object doesn't help
because I2C is bit-banged and quite slow.

I think your program overwhelms the OOPic's capability.

Try a processor that can support interrupt driven IO and a much
larger buffer. I would suggest an Atmel ATmega128 or even one of the
ARM chips like the LPC2148. Considering all the things that are
going on, I might also use one of the real time operating systems
such as FreeRTOS which has ports for both of these processors.

Richard



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

At 09:07 AM 2/20/2008, rtstofer wrote:
>Let's say the OOPic executes about 1000 instructions per second
>(although there are certainly examples where it only executes about
>400).

I'd like to see an example that executes anywhere near 1000 user
source code lines per second. Hell, even 400 will impress me.

Since this is so easy for anyone to verify, can someone explain why
the 1000 LOC/sec figure persists?
...Andy



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

--- In o...@yahoogroups.com, Andrew Porrett wrote:
>
> At 09:07 AM 2/20/2008, rtstofer wrote:
> >Let's say the OOPic executes about 1000 instructions per second
> >(although there are certainly examples where it only executes about
> >400).
>
> I'd like to see an example that executes anywhere near 1000 user
> source code lines per second. Hell, even 400 will impress me.
>
> Since this is so easy for anyone to verify, can someone explain why
> the 1000 LOC/sec figure persists?
> ...Andy
>

When I use it, it is strictly a figment of my imagination. I thought
I did a simple For ... Next loop and timed a bunch of iterations a
long time ago. Nothing inside the loop, no objects defined, nada.
Still it is just a WAG.

Some lines of code are more complex than others. I would be just as
happy using 400 LPM or even 200 LPM. The point of my using the
figure is to point out how hopeless it is to plan on doing serial IO
with the OOPic unless flow control can be implemented. Even then, it
is hard to enforce flow control on such a small buffer. The sender
may not be able to stop that fast if it has any kind of FIFO.

Richard



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

For serial input I prefer to use an external dedicated processor for the
ooPIC, I've posted one such option, and it even does FP math on the GPS
strings. The ooPIC does not yet have good serial data processing
capability.

DLC

rtstofer wrote:
> --- In o...@yahoogroups.com, Andrew Porrett wrote:
>
>> At 09:07 AM 2/20/2008, rtstofer wrote:
>>
>>> Let's say the OOPic executes about 1000 instructions per second
>>> (although there are certainly examples where it only executes about
>>> 400).
>>>
>> I'd like to see an example that executes anywhere near 1000 user
>> source code lines per second. Hell, even 400 will impress me.
>>
>> Since this is so easy for anyone to verify, can someone explain why
>> the 1000 LOC/sec figure persists?
>> ...Andy
>>
>>
>
> When I use it, it is strictly a figment of my imagination. I thought
> I did a simple For ... Next loop and timed a bunch of iterations a
> long time ago. Nothing inside the loop, no objects defined, nada.
> Still it is just a WAG.
>
> Some lines of code are more complex than others. I would be just as
> happy using 400 LPM or even 200 LPM. The point of my using the
> figure is to point out how hopeless it is to plan on doing serial IO
> with the OOPic unless flow control can be implemented. Even then, it
> is hard to enforce flow control on such a small buffer. The sender
> may not be able to stop that fast if it has any kind of FIFO.
>
> Richard
>
>



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

At 06:20 PM 2/20/2008, rtstofer wrote:
>When I use it, it is strictly a figment of my imagination. I thought
>I did a simple For ... Next loop and timed a bunch of iterations a
>long time ago. Nothing inside the loop, no objects defined, nada.

I did the same thing - the number was ~350.
>Some lines of code are more complex than others. I would be just as
>happy using 400 LPM or even 200 LPM. The point of my using the
>figure is to point out how hopeless it is to plan on doing serial IO
>with the OOPic unless flow control can be implemented.

When you use a figure of 1000 LOC/sec, it moves the problem in to the
doable-if-you-use-enough-tricks realm. At 350 LOC/sec, it's impossible.
>Even then, it
>is hard to enforce flow control on such a small buffer. The sender
>may not be able to stop that fast if it has any kind of FIFO.

At 1000 LOC/sec, I could pass on flow control. It would be a hack,
but it would work.

A thought occurs to me - the V5 code generation isn't the greatest;
if V6 does a better job, the 350 figure gets revised up (to
400-500?), but I haven't looked at code V6 generates, so it's just
idle speculation at this point.
...Andy



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

> > rtstofer wrote:
> > Let's say the OOPic executes about 1000 instructions per second...

> Andrew Porrett wrote:
> I'd like to see an example that executes anywhere near 1000 user
> source code lines per second.
> ...Andy
Andy,

"instructions per second" and "user source code lines per second" are
two different things and cannot be compared. Its the old Apples and
Oranges thing.

"instructions per second" relate to the number of instructions the
processor can handle each second.

"user source code lines per second" relate to an average based on
coding style.

For instance:

a=1

compiles into 3 instructions.

a=abs((a*2+9)/2)

compiles into 12 instructions.

If (a=1) then a=abs((a*2+9)/2)

compiles into 20 instructions.

The details of how fast the 8-bit ooPIC interpreter chips operate can
be found on the following page which does a comparison to the Basic
Stamp which also publishes speed in "Instructions per second":

http://www.oopic.com/vsbs.htm

Scott Savage
------------------------------------



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

If you had been keeping up with this group all along, you'd know that
I'm well aware of the OOPic's script code execution speed. And
again, you've eliminated context by changing the thread subject (it
was "storing data to oopic").
The original context (written by another member):

"The incoming (serial) buffer is 4 bytes.

As Dennis said, the OOPic can't keep up with a GPS under any
condition or, as I might have said, it is darn difficult and it is
about the ONLY thing the OOPic can be doing.

Let's say the OOPic executes about 1000 instructions per second
(although there are certainly examples where it only executes about
400). Four incoming chars takes about 13 mS so the buffer is full
(if starting from empty) in somewhere around 13 (or 5!) lines of
code. That is the buffer will be completely full - starting from
empty."
Most GPS receivers send data at 4800 bps, which is 480 characters per second.

The OOPic "average lines of source code executed per second" figure
is LESS than 480.

The OOPic can't execute "13 lines of code" in 13 ms (more like 37
ms), hence my comment. And 4 characters at 4800 bps would take about
8.3 ms by my reckoning, so keeping up with a GPS is just that much
more impossible.
At 09:01 PM 8/5/2008, scottmsavage wrote:
> > > rtstofer wrote:
> > > Let's say the OOPic executes about 1000 instructions per second...
>
> > Andrew Porrett wrote:
> > I'd like to see an example that executes anywhere near 1000 user
> > source code lines per second.
> > ...Andy
>Andy,
>
>"instructions per second" and "user source code lines per second" are
>two different things and cannot be compared. Its the old Apples and
>Oranges thing.
>
>"instructions per second" relate to the number of instructions the
>processor can handle each second.
>
>"user source code lines per second" relate to an average based on
>coding style.
>
>For instance:
>
> a=1
>
>compiles into 3 instructions.
>
> a=abs((a*2+9)/2)
>
>compiles into 12 instructions.
>
> If (a=1) then a=abs((a*2+9)/2)
>
>compiles into 20 instructions.
>
>The details of how fast the 8-bit ooPIC interpreter chips operate can
>be found on the following page which does a comparison to the Basic
>Stamp which also publishes speed in "Instructions per second":
>
>http://www.oopic.com/vsbs.htm
>
>Scott Savage

------------------------------------



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

--- In o...@yahoogroups.com, Andrew Porrett wrote:
> If you had been keeping up with this group all along, you'd know that
> I'm well aware of the OOPic's script code execution speed.

My bad, I must have read it incorrectly.

Scott Savage

------------------------------------



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