Post by thread:[PIC]: Testing with non-consecutive values

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_OUTlistservTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

From: "David Duffy" <.....piclistKILLspam@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 listservKILLspammitvma.mit.edu with SET PICList DIGEST in the body

> > 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}>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. 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 .....listservKILLspam.....mitvma.mit.edu with SET PICList DIGEST in the body

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_OUTTakeThisOuTbubblesoftonline.com -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email listservspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body

> 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@olinKILLspamembedinc.com, http://www.embedinc.com -- http://www.piclist.com hint: To leave the PICList KILLspampiclist-unsubscribe-requestKILLspammitvma.mit.edu

> 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, RemoveMEolinTakeThisOuTembedinc.com, http://www.embedinc.com -- http://www.piclist.com hint: To leave the PICList spamBeGonepiclist-unsubscribe-requestspamBeGonemitvma.mit.edu

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}> 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 TakeThisOuTlistservEraseMEspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body > > > -- _______________________________________________ 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-requestTakeThisOuTmitvma.mit.edu

>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-requestEraseME.....mitvma.mit.edu

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-requestmitvma.mit.edu