Post by thread:[PIC:] Migrating code from 12c671 to 12f675

part 1 619 bytes content-type:text/plain; charset="utf-8" (decoded base64) I posted this question a couple months ago. I have some legacy c671 assembly code that needs to be migrated to the f675. I have not had much success. I have attached the original code for review. I'm realizing that I will probably never be a PIC assembly guru. Thus, if this looks like something that can be done quickly, I will pay for the consultation. If someone has time and would like to make a few $$, please contact me off-line. Best regards, Mark Richards Applied NanoBioscience Center Arizona State University Phone: 480-727-8163 email: spam_OUTmark.richardsTakeThisOuTasu.edu part 2 7864 bytes content-type:application/octet-stream; name=v2302.asm (decode)

Mark, I think I have this figured out, but I can't get to it right at this moment. I will have a look later in the day when I get the chance. If I'm correct, it should take about 15 minutes or less to fix. I'll let you know what I find. Unless you have some else already looking at it. Regards, Jim {Quote hidden}> I posted this question a couple months ago. I have some legacy c671 > assembly code that needs to be migrated to the f675. I have not had > much success. I have attached the original code for review. I'm > realizing that I will probably never be a PIC assembly guru. Thus, if > this looks like something that can be done quickly, I will pay for the > consultation. If someone has time and would like to make a few $$, > please contact me off-line. > > Best regards, > > Mark Richards > Applied NanoBioscience Center > Arizona State University > Phone: 480-727-8163 > email: .....mark.richardsKILLspam@spam@asu.edu -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

Mark Richards wrote: > I have some legacy c671 assembly code that needs to be migrated > to the f675. I have not had much success. Hi Mark, I have a few helpful (hopefully) suggestions that could save you some future headaches with regard to code maintenance/portability: Let me just preface this by stating my intention is not to be critical to you. I'm just trying to offer helpful constructive criticism. In addition, I'm also not implying that the following suggestions will definitely fix anything in your problem porting to the 'F655', but anything that can done to help you minimize problems in the future is time well spent. I firmly believe that all assembly language source code written for the MPASM assembler should *never*, ever rely on any default or explicit 'global' radix. 1) The code you posted has weak typing with regard to radix of the constants used. I advocate that one should always explicitly specify (strong type) the radix for your constants: For example: movlw 24 From the context of your code, it appears that 24 should be decimal. If that assumption is correct then that statement should be written as: movlw .24 or movlw D'24' I would re-visit the code and explicitly specify the radix for all constants that do not have one. RADIX FORMATS: -------------- Decimal D'<digits>' D'100' .<digits> .100 Hexadecimal H'<hex_digits>' H'9f' 0x<hex_digits> 0x9f Octal O'<octal_digits>' O'777' Binary B'<binary_digits>' B'00111001' ASCII A'<character>' A'C' '<character>' 'C' 2) This would be a good project to convert to relocatable code. 3) What specific problems were you encountering in your port? Best regards, Ken Pergola -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

Ken Pergola wrote : > I would re-visit the code and explicitly specify the radix > for all constants that do not have one. *and* move all constants into EQU'etad symbols in one common place so there is no numeric constants in the code itself at all... Jan-Erik. This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

Hi Mark, It didn't take long but I did find a couple of small problems. A couple were: 1. need to set page bit before doing the OSCCAL thing. 2. more page problems around TRIS-ing the outputs. 3.ADCON0 is now ADSEL. ADRES is now ADRESH and ADRESL. Also, I justified ADRESH left. This drops the lower 3 bits. If you wanted to justify it right, set bit 7 of ADCON0 and change all the ADRESH to ADRESL. I'll send you the file directly. No promises or guarantees, but it compiled. BTW, this was a copy of the first one you sent a while back. Bill {Original Message removed}

Ken Pergola wrote: > From the context of your code, it appears that 24 should be > decimal. > > If that assumption is correct then that statement should be > written as: > > movlw .24 That syntax is obsolete and only supported for backward compatibility - for now. I don't think it's even shown in the current documentation. > or > > movlw D'24' > > I would re-visit the code and explicitly specify the radix for all > constants that do not have one. Frankly I think that's a bit extreme. I can see wanting to protect yourself form whatever MPASM thinks the default radius should be. However, if you set it explicitly with a RADIX directive, then it is certainly safe to use that radix. I always set the radix to decimal as the first statement of the master include file that is always included in every module. This is what the MPLAB default should be, as it is with nearly every other compiler or assembler. If the MPLAB default were decimal, we probably wouldn't be having this discussion. Personally, I don't want to see all of my numbers cluttered up with d''. Since decimal default is the rule for all my source code, it causes no confusion. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

I noted that the oscilator calibration command was write at the end of the code. My question is does it matter if this code is at the start of the program and can I put it after I state org etc as shown here or does it need to be after the "Start" of the program ie as part of the main programs code? ;___________________________________________________________________________ _ org 0x00 ;Set program orgin (Start of code) goto Start ;Start of program ; org 0x04 ; goto ISR ;Interrupt service routine ;___________________________________________________________________________ _ ;Get oscillator calibration bits and sav in the OSCCAL register. bsf STATUS, RP0 call 0x3FF movwf OSCCAL bcf STATUS, RP0 ;______________________________ --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.577 / Virus Database: 366 - Release Date: 3/02/2004 -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

Olin Lathrop wrote: > That syntax is obsolete and only supported for backward > compatibility - for now. I don't think it's even shown > in the current documentation. Hi Olin, I would agree with you if the specific case was using the trailing 'h' radix designator for hexadecimal, but using '.' for a decimal radix is still in the current documentation. As far as I know, Microchip has not made that notation obsolete as of yet. When and if it happens, no biggie, I'll start using the D'<decimal number>' notation. However, what does not appear in the current documentation is the trailing 'h' radix designator (i.e. 27h) for hexadecimal and MPASM does not choke on it at this time (MPLAB v6.42). > Frankly I think that's a bit extreme. I can see wanting to > protect yourself > form whatever MPASM thinks the default radius should be. However, if you > set it explicitly with a RADIX directive, then it is certainly safe to use > that radix. I know you disagree with me on this, but please hear me out: The whole point is you *have* to be extreme in your process methods if you want to minimize potential problems down the road. The whole reason I brought this up is because I did not even see an explicit global radix directive in the original poster's source code as was posted. Like I said here on the PICLIST before (see archives), within one's own environment, things work out well but the big problem is when you don't strong type the radix of constants and you share code with others -- problems can arise that are easily avoided but avoiding weak type radix constants in the first place -- you see people post snippets out of context without any reference to any radix directive that was used (like in this thread). Specifying a radix in from of every constant does not mar readability for me at all. It 100% guarantees that the source code that I produce will *always* compile the way it was intended in anyone's MPLAB environment -- even if the person overrides the default radix for some reason. Like I said before, everyone has free will. I'm no better than anyone else. But I'm passionate about doing things a certain way just like everyone else is. That's why I'm risking sounding like a broken record to raise awareness. I thank you for at least listening to me. Best regards, Ken Pergola -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

On Friday, Feb 6, 2004, at 15:22 US/Pacific, Ken Pergola wrote: > >> Frankly I think that's a bit extreme. I can see wanting to >> protect yourself >> form whatever MPASM thinks the default radius should be. However, if >> you >> set it explicitly with a RADIX directive, then it is certainly safe >> to use >> that radix. > > I know you disagree with me on this, but please hear me out: > > The whole point is you *have* to be extreme in your process methods if > you > want to minimize potential problems down the road. > Hmm. Combining a couple of ideas, how do you feel about: ; constant definitions RADIX D'10' hz_7 equ 240 ;140 mS hz_17 equ 140 ;59 mS hz_28 equ 95 ;36 mS ms_35 equ 8 ;time that LED is on volt7 equ 180 ;battery 7 volts ; ; Now the radix can change, and my constants will still be OK. Be careful not to use #define instead of EQU, though! BillW -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

Ken Pergola wrote: > I would agree with you if the specific case was using the trailing > 'h' radix designator for hexadecimal, but using '.' for a decimal > radix is still in the current documentation. Oh really? Where? I'm looking in "MPASM User's Guide with MPLINK and MPLIB", DS33014G, Section 8.4 "Numeric Constants and Radix", Table 8.2 on page 91. Only the D'' form for decimal is shown. I don't remember seeing the "." for a long time? > Like I said here on the PICLIST before (see archives), within one's > own environment, things work out well but the big problem is when you > don't strong type the radix of constants and you share code with > others Actually no problem for me at all. My code is intended to work with my environment. If someone tries to use it outside that environment *they* may have a problem, but not me. It's no different than requiring case-insensitivity or specifying the processor. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

William Chops Westfield wrote: > hz_7 equ 240 ;140 mS > hz_17 equ 140 ;59 mS > hz_28 equ 95 ;36 mS > ms_35 equ 8 ;time that LED is on > volt7 equ 180 ;battery 7 volts I don't like this, but not for the reason we've been discussing. If you want a battery level of 7 volts, there should be a constant that lets selects that in obvious human-readable units, like millivolts: battmv equ 7000 ;battery threshold, mV After that you can use assembler math to compute the 180 value using whatever conversion is required. Any conversion constants should also be defined in reasonable user terms. This not only documents what the battery threshold is, but allows easy changes in the future without having to know the conversion magic from 7 to 180. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

Olin Lathrop wrote: > Oh really? Where? I'm looking in "MPASM User's Guide with MPLINK and > MPLIB", DS33014G, Section 8.4 "Numeric Constants and Radix", Table 8.2 on > page 91. Only the D'' form for decimal is shown. I don't remember seeing > the "." for a long time? Hi Olin, As far as your comments are concerned, it just depends on what documentation you are looking at. I'm just in a habit of using the '.' decimal radix notation because I cut my teeth on Microchip MPALC -- the precursor to MPASM. Yes, you are correct, I do not see the '.' decimal radix notation listed in "MPASM User's Guide with MPLINK and MPLIB", DS33014G, which was printed in 1999. Does that mean it IS obsolete? Not necessarily. The '.' decimal radix notation is alive and well in the MPASM on-line help. Does that mean it is NOT obsolete? Once again, not necessarily. All I know is that I have seen Microchip give advice and defer customers to the on-line help indicating that it contains, for the most part, the latest information. I guess only Microchip can tell us their position on this one. Take care Olin, Ken Pergola -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

William Chops Westfield wrote: > Hmm. Combining a couple of ideas, how do you feel about: > > ; constant definitions > RADIX D'10' > hz_7 equ 240 ;140 mS > hz_17 equ 140 ;59 mS > hz_28 equ 95 ;36 mS > ms_35 equ 8 ;time that LED is on > volt7 equ 180 ;battery 7 volts > ; > ; Now the radix can change, and my constants will still be OK. Hiya Bill, Personally, I would still specify an explicit radix for each constant, but that's just me. Jocular tone: Well, you did ask me how I felt about it right? :) Minor detail: I know what you meant with RADIX D'10' (should be RADIX DEC). You would have found out when you hit 'compile'. :) Best regards and take care Bill, Ken Pergola -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

>However, what does not appear in the current documentation >is the trailing 'h' radix designator (i.e. 27h) for >hexadecimal and MPASM does not choke on >it at this time (MPLAB v6.42). I think you will find that the only way to specify this is as 0xHH as having the trailing 'h' gives the parser problems. Personally I have no problem with always specifying the radix. then you know exactly what it should be when you get it assembled. -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email listservKILLspammitvma.mit.edu with SET PICList DIGEST in the body

Hopkins wrote : > I noted that the oscilator calibration command was write at > the end of the code. What is the "command" ? The RETLW that Microchip puts in place ? Or *your* code calling the RETLW ? > My question is does it matter if this code Again, which code ? The RETLW that Microchip puts in place ? Or *your* code calling the RETLW ? > is at the start of the program > and can I put it after I state org etc as shown here or does > it need to be > after the "Start" of the program ie as part of the main programs code? I'm not realy sure of what you are asking here. Of course you have to put your call to 3FF anyplace that will be *run* through by your code ! How could it be executed otherwise ? In your example : {Quote hidden}> org 0x00 ;Set program orgin (Start of code) > goto Start ;Start of program > ; org 0x04 > ; goto ISR ;Interrupt service routine > ; > ; XXX Get oscillator calibration bits and sav in the OSCCAL register. > bsf STATUS, RP0 > call 0x3FF > movwf OSCCAL > bcf STATUS, RP0 how is the PIC going to come to the part (that I have) marked XXX ? And where is the START label ? You actual call to 3FF to set the OSCCAL could be done anyware, I'd guess. And if you don't care about precision of the internal osc, you don't have to set OSCCAL at all... Jan-Erik. -- http://www.piclist.com hint: To leave the PICList .....piclist-unsubscribe-requestKILLspam.....mitvma.mit.edu

All ! It seems as I have been replying to a message (from Hopkins) several days old. I noticed that after posting. Sorry about that. I'll watch my incomming mails a bit more carefully for a while. Note, I *did* get the post I replied to just a few minutes ago, but from the headers it looks like it have been stuck in some internal mails servers since the 7-Feb... As I said, sorry ! Jan-Erik. PS. B.t.w, *was* Hopkins message delivered to the list the 7-Feb (as the headers tells me) ? citerar Jan-Erik Soderholm <EraseMEjan-erik.soderholmspam_OUTTakeThisOuTTELIA.COM>: > Hopkins wrote : > > > I noted that the oscilator calibration command was write at > > the end of the code. > > What is the "command" ? > The RETLW that Microchip puts in place ? > Or *your* code calling the RETLW ? snip, snip, snip... -- http://www.piclist.com hint: To leave the PICList piclist-unsubscribe-requestspam_OUTmitvma.mit.edu