Searching \ for '[PIC]: Testing with non-consecutive values' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: massmind.org/techref/microchip/devices.htm?key=pic
Search entire site for: 'Testing with non-consecutive values'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Testing with non-consecutive values'
2001\11\06@221023 by David Duffy

flavicon
face
Hi all,
I currently have an application where in the comms receive
handler, I test the received command byte and branch off
to other places depending on the value. As the values are
not consecutive, is there a better way to test them than just
doing the following time after time?

...
movf    rx_cmd,w        ;get the received command byte
xorlw   msg_eg1 ;compare with msg_eg1 (a constant)
btfsc   zero            ;is it msg_eg1 ?
goto    rx_eg1          ;yes, jump to that handler
...

Block repeats for as many test cases as I need.
It just seems ugly - is there a better/shorter way?
The msg constants are all over the place value wise.
I can't arrange them to be in continuous blocks.
Regards...

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spam_OUTlistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body


2001\11\06@222043 by Bob Ammerman

picon face
From: "David Duffy" <.....piclistKILLspamspam@spam@AUDIOVISUALDEVICES.COM.AU>
> Hi all,
> I currently have an application where in the comms receive
> handler, I test the received command byte and branch off
> to other places depending on the value. As the values are
> not consecutive, is there a better way to test them than just
> doing the following time after time?
>
> ...
> movf    rx_cmd,w        ;get the received command byte
> xorlw   msg_eg1 ;compare with msg_eg1 (a constant)
> btfsc   zero            ;is it msg_eg1 ?
> goto    rx_eg1          ;yes, jump to that handler
> ...
>
> Block repeats for as many test cases as I need.
> It just seems ugly - is there a better/shorter way?


You can improve it quite a bit like this:

   movf    rx_cmd,w    ; get received command byte
   xorlw    msg_eg1    ; compare to msg 1 (w is zero if this is msg 1)
   skpnz                      ; (this is the same as btfsc zero)
   goto      rx_eg1
   xorlw    msg_eg1^msg_eg2    ; now w is zero if this is msg 2
   skpnz
   goto      rx_eg2
   xorlw    msg_eg2^msg_eg3
   skpnz
   goto      rx_eg3

etc.

This works because  xor is its own inverse operation.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body


2001\11\06@224247 by David Duffy

flavicon
face
> > I currently have an application where in the comms receive
> > handler, I test the received command byte and branch off
> > to other places depending on the value. As the values are
> > not consecutive, is there a better way to test them than just
> > doing the following time after time?
> >
> > ...
> > movf    rx_cmd,w        ;get the received command byte
> > xorlw   msg_eg1 ;compare with msg_eg1 (a constant)
> > btfsc   zero            ;is it msg_eg1 ?
> > goto    rx_eg1          ;yes, jump to that handler
> > ...
> >
> > Block repeats for as many test cases as I need.
> > It just seems ugly - is there a better/shorter way?

Bob replied:
{Quote hidden}

This gets me 1 less instruction per test. (except 1st one)
Call me a dummy but what's the ^ operator ?
The only other option is a table to jump to the required places
but this would only be worth it if you had a lot of commands.
It would make adding extra commands very easy though.
Regards...

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam.....mitvma.mit.edu with SET PICList DIGEST in the body


2001\11\06@230621 by Bob Ammerman

picon face
^ is exclusive-or

0 ^ 0 = 0
0 ^ 1 = 1
1 ^ 0 = 1
1 ^ 1 = 0

This has the special property that A ^ B ^ B == A

In other words, if I exclusive-or an input value (A above) twice with the
same value (B above), I get the original value back.

Bob Ammerman
RAm Systems

{Original Message removed}

2001\11\06@235237 by Tony Nixon
flavicon
picon face
David Duffy wrote:

> This gets me 1 less instruction per test. (except 1st one)
> Call me a dummy but what's the ^ operator ?
> The only other option is a table to jump to the required places
> but this would only be worth it if you had a lot of commands.
> It would make adding extra commands very easy though.
> Regards...

^ = XOR

You wouldn't need too many commands for the table method to be
attractive. It's faster as well.

--
Best regards

Tony

mICros
http://www.bubblesoftonline.com
EraseMEsalesspam_OUTspamTakeThisOuTbubblesoftonline.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body


2001\11\07@080008 by Olin Lathrop

face picon face
> I currently have an application where in the comms receive
> handler, I test the received command byte and branch off
> to other places depending on the value. As the values are
> not consecutive, is there a better way to test them than just
> doing the following time after time?
>
> ...
> movf    rx_cmd,w        ;get the received command byte
> xorlw   msg_eg1 ;compare with msg_eg1 (a constant)
> btfsc   zero            ;is it msg_eg1 ?
> goto    rx_eg1          ;yes, jump to that handler
> ...
>
> Block repeats for as many test cases as I need.
> It just seems ugly - is there a better/shorter way?
> The msg constants are all over the place value wise.
> I can't arrange them to be in continuous blocks.

Do you have some program memory to spare?  If so, a jump table is probably
the simplest and also the clearest and easiest to maintain.  Warning, this
code was just typed in without being checked:

    movlw   high table   ;get high byte of table start address
    movwf   pclath       ;init jump address high byte
    movlw   low table    ;get low byte of table start address
    addwf   opcode, w    ;make low byte of table entry address
    skip_ncarr           ;no carry into upper address byte ?
    incf    pclath       ;propagate the carry
    movwf   pcl          ;jump to the selected table entry
;
;   Opcodes table.  There is one table entry for each of the 256
;   possible opcodes.  Each table entry jumps to the handler code
;   for that opcode.
;
;   NOTE:  All handler routines must be in the same code page as
;     this table.
;
table
    goto    handler0     ;opcode 0
    goto    handler1     ;opcode 1
    .
    .
    .


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, @spam@olinKILLspamspamembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
KILLspampiclist-unsubscribe-requestKILLspamspammitvma.mit.edu


2001\11\07@080022 by Olin Lathrop

face picon face
> You can improve it quite a bit like this:
>
>     movf    rx_cmd,w    ; get received command byte
>     xorlw    msg_eg1    ; compare to msg 1 (w is zero if this is msg 1)
>     skpnz                      ; (this is the same as btfsc zero)
>     goto      rx_eg1
>     xorlw    msg_eg1^msg_eg2    ; now w is zero if this is msg 2
>     skpnz
>     goto      rx_eg2
>     xorlw    msg_eg2^msg_eg3
>     skpnz
>     goto      rx_eg3

It improves the instructions a bit but makes a horrible mess in the code.
If you're going to do this, use a macro else you'll end up with a
maintainance headache.  Something like:

    check_opcode <opcode>, <handler address>


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, RemoveMEolinTakeThisOuTspamembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-requestspamBeGonespammitvma.mit.edu


2001\11\07@134815 by alice campbell

flavicon
face
One way to decide is the number of lines of messy tests versus a 256-entry table.  This problem is similar to identifying whether a recieved char is a number, a lowercase letter, or an uppercase letter.  Let's say you wanted to output the character to a 7-seg dispaly, and you had a table for the letter shapes.  You could do a big table with shapes for everything you wanted, and a ? for anything else, or do the messy test business first.  I chose the messy test version, because it was a lot shorter for what I needed.  Including overhead, my letter-and-number parser was about 120 lines including character shape tables,  half of what a full 256-line ascii shape table would have taken.

alice


{Quote hidden}

--

_______________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup


1 cent a minute calls anywhere in the U.S.!

http://www.net2phone.com/cgi-bin/link.cgi?170

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestspamTakeThisOuTmitvma.mit.edu


2001\11\07@154718 by Drew Vassallo

picon face
>One way to decide is the number of lines of messy tests versus a 256-entry
>table.  This problem is similar to identifying whether a recieved
.
.
.
>Including overhead, my letter-and-number parser was about 120 lines
>including character shape tables,  half of what a full 256-line ascii shape
>table would have taken.

I guess I don't see any correlation between his application and yours at
all.  I would all but guarantee that a comparison-code section in his
application would be over twice as long as a table in terms of simply
comparing incoming data bytes and branching off to an appropriate address.

Note that his table isn't necessarily 256 entries long.  Besides, he's not
doing graphical ASCII representation, he's just comparing two bytes.

--Andrew

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestEraseMEspam.....mitvma.mit.edu


2001\11\07@174740 by David Duffy

flavicon
face
I asked:
> > I currently have an application where in the comms receive
> > handler, I test the received command byte and branch off
> > to other places depending on the value. As the values are
> > not consecutive, is there a better way to test them than just
> > doing the following time after time?
> >
> > ...
> > movf    rx_cmd,w        ;get the received command byte
> > xorlw   msg_eg1 ;compare with msg_eg1 (a constant)
> > btfsc   zero            ;is it msg_eg1 ?
> > goto    rx_eg1          ;yes, jump to that handler
> > ...
> >
> > Block repeats for as many test cases as I need.
> > It just seems ugly - is there a better/shorter way?
> > The msg constants are all over the place value wise.
> > I can't arrange them to be in continuous blocks.

Olin replied:
>Do you have some program memory to spare?  If so, a jump table is probably
>the simplest and also the clearest and easiest to maintain.  Warning, this
>code was just typed in without being checked:

One of the problems is that I need to ignore some of the commands depending
on other bytes in the received packet. I should have mentioned this before. The
incoming packet could either have a "normal" (0x01 - 0xfe) destination byte
or a
"global" one. (0xff) There are some commands should only work with "normal"
destination bytes - I can't have every board replying to a "global" message!
There is also another special condition to check for. So what I currently do is
split up the messages into "global", "local" & "special" messages based on
other bytes in the received packet, then parse them for specific messages
within
each group. That means that some of the message checking appears in 1, 2 or
all 3 groups. It's really a matrix of parsing when I think about it.
Something like in the table below:

msg type        msg1    msg2    msg3    msg4

local           Y       Y               Y
global          Y       Y       Y
special Y               Y

As you can see, I have to have the message parsing in 3 different places.
I can't think of any other way apart from 3 * 256 byte tables or the old way.
Maybe create a "access" byte where I do the global/local/special logic.
It could be anded with an access constant in each subroutine and only
execute if the result is non zero. Hmm... that might just work!  :-)
Regards...

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspammitvma.mit.edu


More... (looser matching)
- Last day of these posts
- In 2001 , 2002 only
- Today
- New search...