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.

Tuesday, June 17, 2008

Re: [oopic] Re: Serial To LCD messing up

At 02:21 PM 6/17/2008, rtstofer wrote:
>I can't speak for the new compiler but that logical expression in the
>first IF statement caused the identical symptoms in V5 and B.2.2+.
>Just breaking the statement into two if <expr> then ... end if solved
>the problem.

Ah yes, you're right. The statement:

if ((serial.received == TRUE) & (serial.value == 123))

produces this code:

55: 44 206 Get Serial.Received
57: 1 Pushb(1)
58: 152 IsEqual

59: 41 225 Get Serial.Value
61: 123 Pushb(123)
62: 152 IsEqual

63: 141 And
64: 137 0 71 BranchOnFalse(71)
130

which obviously evaluates the entire expression before deciding where
to branch to next. Gawd, I hate toy programming languages!


>I suspect there is an issue with not short circuiting the evaluation
>when the first equality is false. So what happens when you read the
>port and it hasn't received anything? That's exactly what would
>happen if the evaluation is not short circuited.

And you have a nasty race condition - if Serial.Received is false and
the trigger character arrives in time to get snagged by the "Get
Serial.Value", the entire expression fails (FALSE & TRUE = FALSE) and
the trigger character isn't detected.


>Kind of like 'what happens if I read a circular buffer ahead of the
>insert pointer'? Well, I'm going to read the entire buffer again...

Which is really dumb, since the firmware can easily do a test and
only advance the read pointer if it's not equal to the write pointer:

get_serial_dot_value:

// don't advance to next character if there isn't one

if (read_pointer != write_pointer)
increment read pointer (and wrap if now past end of buffer)

// return next available character
// (or same as last time if we don't have any new ones)

return (buffer[read_pointer])


It's really not rocket science...

Scott proclaimed one time that the (2.2+?) firmware only has one bug
in it. I doubt he meant this one.


...Andy

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

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: