Post by thread:[PIC]: Problem with Byte to HEX Routine

Hi guys, I've been trying to work out on a Byte to Hex routine for a project of mine. But the Table read mysteriously jumps back to a totally unrelated area on the PIC. Here is the code frag that was causing the problem. ;************************************************************ ;*****************BEGIN CODE Block******************* ;Enter with low nibble in W ;Exit with ASCII code for Nibble in W nib2hex: addwf PCL,f Mysterious Jump from Here dt "0123456789ABCDEF" ;Enter with byte in W ;Exit with Two ASCII chars in hex_hi : hex_lo byte2hex: movwf bintemp andlw 0x0F call nib2hex movwf hex_lo swapf bintemp,w andlw 0x0F call nib2hex movwf hex_hi return ;************************************************************ ;********************END CODE BLOCK***************** ;************************************************************ In MPLAB SIM, when the execution goes to the code commented as "Mysterious Jump from Here" , PCL = 0x1B PCLATH = 0x 00 and then the code suddenly jumps to a *random* location 0x21 (PCL). (I thought Retlw was supposed to Return back!) What kind of a problem is this ? Some sort of a bug ? And finally, anyone has done some similar routines ? Jeethu Rao -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

At 01:18 AM 3/9/2001 +0530, you wrote: It looks like you will jump to the address PCL+W. If W varies each time you call nib2hex then the jump position will also vary (random). There is a application note from Microchip on table reads. Good luck, Peter >Hi guys, > >I've been trying to work out on a Byte to Hex routine for a project of mine. > >But the Table read mysteriously jumps back to a totally unrelated area on the PIC. {Quote hidden}> >Here is the code frag that was causing the problem. > >;************************************************************ >;*****************BEGIN CODE Block******************* > >;Enter with low nibble in W >;Exit with ASCII code for Nibble in W >nib2hex: > addwf PCL,f Mysterious Jump from Here > dt "0123456789ABCDEF" > >;Enter with byte in W >;Exit with Two ASCII chars in hex_hi : hex_lo >byte2hex: > movwf bintemp > andlw 0x0F > call nib2hex > movwf hex_lo > swapf bintemp,w > andlw 0x0F > call nib2hex > movwf hex_hi > return > >;************************************************************ >;********************END CODE BLOCK***************** >;************************************************************ > >In MPLAB SIM, when the execution goes to the code commented as "Mysterious Jump from Here" , {Quote hidden}> >PCL = 0x1B >PCLATH = 0x 00 > > >and then the code suddenly jumps to a *random* location > >0x21 (PCL). >(I thought Retlw was supposed to Return back!) > >What kind of a problem is this ? >Some sort of a bug ? >And finally, anyone has done some similar routines ? > > >Jeethu Rao > >-- >http://www.piclist.com hint: The list server can filter out subtopics >(like ads or off topics) for you. See http://www.piclist.com/#topics > -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

Hi, >I've been trying to work out on a Byte to Hex routine for a project of mine. > >But the Table read mysteriously jumps back to a totally unrelated area on >the PIC. <snip> >Some sort of a bug ? >And finally, anyone has done some similar routines ? Yes it's a bug ;-) , just kidding it's one of the pitfalls with the pic's. You have the 255 bytes page boundary's to deal with. The supplied snippet will work if there's no page boundary in the table. However if there is an page boundary the program will jump to an 'random' ( or seamingly random ) location. There's everything you need to know here: www.piclist.com/techref/microchip/pages.htm ( very tricky to locate ...) /Tony Tony Kübek, Flintab AB ²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²² E-mail: spam_OUTtony.kubekTakeThisOuTflintab.com ²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²² -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

part 0 44 bytes his is a multi-part message in MIME format. part 1 2025 bytes content-type:text/plain; charset=us-ascii (decoded 7bit) The problem may be located in the handling of PCLATH register and/or page crossing boundaries. There is a lot of information about it in the archives. You can check Microchip Application note AN556 about table reads. There is also a chance that W register is being changed because of a bad/non saving environment interrupt. Jeethu Rao wrote: {Quote hidden}> Hi guys, > > I've been trying to work out on a Byte to Hex routine for a project of mine. > > But the Table read mysteriously jumps back to a totally unrelated area on the PIC. > > Here is the code frag that was causing the problem. > > ;************************************************************ > ;*****************BEGIN CODE Block******************* > > ;Enter with low nibble in W > ;Exit with ASCII code for Nibble in W > nib2hex: > addwf PCL,f Mysterious Jump from Here > dt "0123456789ABCDEF" > > ;Enter with byte in W > ;Exit with Two ASCII chars in hex_hi : hex_lo > byte2hex: > movwf bintemp > andlw 0x0F > call nib2hex > movwf hex_lo > swapf bintemp,w > andlw 0x0F > call nib2hex > movwf hex_hi > return > > ;************************************************************ > ;********************END CODE BLOCK***************** > ;************************************************************ > > In MPLAB SIM, when the execution goes to the code commented as "Mysterious Jump from Here" , > > PCL = 0x1B > PCLATH = 0x 00 > > and then the code suddenly jumps to a *random* location > > 0x21 (PCL). > (I thought Retlw was supposed to Return back!) > > What kind of a problem is this ? > Some sort of a bug ? > And finally, anyone has done some similar routines ? > > Jeethu Rao > > -- > http://www.piclist.com hint: The list server can filter out subtopics > (like ads or off topics) for you. See http://www.piclist.com/#topics part 2 422 bytes content-type:text/x-vcard; charset=us-ascii; (decoded quoted-printable) begin:vcard n:Romero Plaza;P�vel Ernesto tel;cell:5489528 tel;fax:6-7444829 tel;home:6-7464233 tel;work:6-7444829 x-mozilla-html:TRUE url:http://www.insitel.com.co org:Insitel Ltda.;Research & Development adr:;;Calle 21 # 16 - 46 Piso 7;Armenia;Quind�o;;Colombia version:2.1 email;internet:.....promeroKILLspam@spam@insitel.com.co title:Hardware Engineer fn:P�vel Ernesto Romero Plaza end:vcard part 3 144 bytes -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

Hi, here is an alternative nib2hex: andlw 0x0F ;; you do not need to do it twice addlw 246 ;; overflow if 10 or higher sknc ;; skip if not carry addlw 7 ;; difference between '9'+1 and 'A' addlw 58 ;; convert to ASCII return ;; 6 instructions instead of 17 Regards, Imre On Fri, 9 Mar 2001, Jeethu Rao wrote: {Quote hidden}> Hi guys, > > I've been trying to work out on a Byte to Hex routine for a project of mine. > > But the Table read mysteriously jumps back to a totally unrelated area on the PIC. > > Here is the code frag that was causing the problem. > > ;************************************************************ > ;*****************BEGIN CODE Block******************* > > ;Enter with low nibble in W > ;Exit with ASCII code for Nibble in W > nib2hex: > addwf PCL,f Mysterious Jump from Here > dt "0123456789ABCDEF" > > ;Enter with byte in W > ;Exit with Two ASCII chars in hex_hi : hex_lo > byte2hex: > movwf bintemp > andlw 0x0F > call nib2hex > movwf hex_lo > swapf bintemp,w > andlw 0x0F > call nib2hex > movwf hex_hi > return > > ;************************************************************ > ;********************END CODE BLOCK***************** > ;************************************************************ > > In MPLAB SIM, when the execution goes to the code commented as "Mysterious Jump from Here" , > > PCL = 0x1B > PCLATH = 0x 00 > > > and then the code suddenly jumps to a *random* location > > 0x21 (PCL). > (I thought Retlw was supposed to Return back!) > > What kind of a problem is this ? > Some sort of a bug ? > And finally, anyone has done some similar routines ? > > > Jeethu Rao > > -- > http://www.piclist.com hint: The list server can filter out subtopics > (like ads or off topics) for you. See http://www.piclist.com/#topics > > > > -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

The answer is not applicable. W is not random, but this is what intended by the programmer. The cause of the failure may be incorrect page switching or wraparound. Regards, Imre On Fri, 9 Mar 2001, Peter Grey wrote: {Quote hidden}> At 01:18 AM 3/9/2001 +0530, you wrote: > > It looks like you will jump to the address PCL+W. If W varies each time you > call nib2hex then the jump position will also vary (random). There is a > application note from Microchip on table reads. > > Good luck, > > > Peter > >Hi guys, > > > >I've been trying to work out on a Byte to Hex routine for a project of mine. > > > >But the Table read mysteriously jumps back to a totally unrelated area on > the PIC. > > > >Here is the code frag that was causing the problem. > > > >;************************************************************ > >;*****************BEGIN CODE Block******************* > > > >;Enter with low nibble in W > >;Exit with ASCII code for Nibble in W > >nib2hex: > > addwf PCL,f Mysterious Jump from Here > > dt "0123456789ABCDEF" > > > >;Enter with byte in W > >;Exit with Two ASCII chars in hex_hi : hex_lo > >byte2hex: > > movwf bintemp > > andlw 0x0F > > call nib2hex > > movwf hex_lo > > swapf bintemp,w > > andlw 0x0F > > call nib2hex > > movwf hex_hi > > return > > > >;************************************************************ > >;********************END CODE BLOCK***************** > >;************************************************************ > > > >In MPLAB SIM, when the execution goes to the code commented as "Mysterious > Jump from Here" , > > > >PCL = 0x1B > >PCLATH = 0x 00 > > > > > >and then the code suddenly jumps to a *random* location > > > >0x21 (PCL). > >(I thought Retlw was supposed to Return back!) > > > >What kind of a problem is this ? > >Some sort of a bug ? > >And finally, anyone has done some similar routines ? > > > > > >Jeethu Rao > > > >-- > >http://www.piclist.com hint: The list server can filter out subtopics > >(like ads or off topics) for you. See http://www.piclist.com/#topics > > > > -- > http://www.piclist.com hint: The list server can filter out subtopics > (like ads or off topics) for you. See http://www.piclist.com/#topics > > > > -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

>here is an alternative >nib2hex: > andlw 0x0F ;; you do not need to do it twice > addlw 246 ;; overflow if 10 or higher > sknc ;; skip if not carry > addlw 7 ;; difference between '9'+1 and 'A' > addlw 58 ;; convert to ASCII > return >;; 6 instructions instead of 17 > >Regards, >Imre I suspect this can be reduced even further. There used to be a nifty trick for doing this on 8080 and Z80 micros, which used the half carry flag. The PIC also has this flag available, so if anyone has an 8080 Cookbook or Z80 Cookbook handy they may like to look it up. From memory it totally does away with the skip instruction because you do not need to distinguish if it <=9 or >=A. actually on reflection looking over what I have written, I believe the technique was involved in converting a HEX nibble to ASCII, so may not be applicable here. -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

"promero" <promeroKILLspamINSITEL.COM.CO> wrote on Friday, March 09, 2001 6:46 PM > The problem may be located in the handling of PCLATH register and/or page crossing boundaries. > There is a lot of information about it in the archives. You can check Microchip Application note > AN556 about table reads. There is also a chance that W register is being changed because of a > bad/non saving environment interrupt. I don't think so. I ran it in MPLAB SIM and It did'nt work. all the Interrupts were disabled. I even tried to move the code to location 0x200 which must clear PCL and increment PCLATH. But it still does'nt work. And I Don't think Its a problem with the Simulator, Because, when I burned the code on a real 16f877 , the same problem persisted. It began Jumping mysteriously inbetween my ISR code . That means that It does'nt jump to 0x04 but it jumps somewhere to 0x21 Man, this is a really persistant bug. If all else fails, I'll post the whole code on piclist. Thanking you, Jeethu Rao -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

"promero" <.....promeroKILLspam.....INSITEL.COM.CO> wrote on Friday, March 09, 2001 6:46 PM > The problem may be located in the handling of PCLATH register and/or page crossing boundaries. > There is a lot of information about it in the archives. You can check Microchip Application note > AN556 about table reads. There is also a chance that W register is being changed because of a > bad/non saving environment interrupt. I don't think so. I ran it in MPLAB SIM and It did'nt work. all the Interrupts were disabled. I even tried to move the code to location 0x200 which must clear PCL and increment PCLATH. But it still does'nt work. And I Don't think Its a problem with the Simulator, Because, when I burned the code on a real 16f877 , the same problem persisted. It began Jumping mysteriously inbetween my ISR code . That means that It does'nt jump to 0x04 but it jumps somewhere to 0x21 Man, this is a really persistant bug. If all else fails, I'll post the whole code on piclist. Thanking you, Jeethu Rao -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

"dr. Imre Bartfai" Wrote > Hi, > here is an alternative > nib2hex: > andlw 0x0F ;; you do not need to do it twice > addlw 246 ;; overflow if 10 or higher > sknc ;; skip if not carry > addlw 7 ;; difference between '9'+1 and 'A' > addlw 58 ;; convert to ASCII > return > ;; 6 instructions instead of 17 > Thanks a lot Dr Imre. Your Solution is by far the best one I've ever seen for this problem. I had designed a solution without RETLWs but even that one was 17 bytes long. Never had i thought that it could be done in just 6 instructions. Thanking You, Jeethu Rao -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email EraseMElistservspam_OUTTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

Hello, not at all. That's why the PICLIST is there - to share experiences and ideas. I glad I could help you and maybe others. Regards, Imre On Sun, 11 Mar 2001, Jeethu Rao wrote: {Quote hidden}> "dr. Imre Bartfai" Wrote > > > Hi, > > here is an alternative > > nib2hex: > > andlw 0x0F ;; you do not need to do it twice > > addlw 246 ;; overflow if 10 or higher > > sknc ;; skip if not carry > > addlw 7 ;; difference between '9'+1 and 'A' > > addlw 58 ;; convert to ASCII > > return > > ;; 6 instructions instead of 17 > > > > Thanks a lot Dr Imre. Your Solution is by far the best one I've ever seen > for this problem. I had designed a solution without RETLWs but even that one > was 17 bytes long. Never had i thought that it could be done in just 6 > instructions. > > Thanking You, > > Jeethu Rao > > -- > http://www.piclist.com#nomail Going offline? Don't AutoReply us! > email listservspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body > > > > -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads