Post by thread:[PIC]: simple 16F877 long call strategy needed

My first (unsuccessful) attempt to locate some routines on Page 1 and to call them from Page 0 has sent me scrambling for the datasheets and whatever other online resources I could find. There seems be a variety of approaches to the PCLATH issue, most of which have confused the daylights out of me. Perhaps someday I'll be up to the more sophisticated techniques (macros, etc.), but for now, could I not just make every single CALL in my program an LCALL and call it good? Would that work, or would that cause the PIC's PC to go on some unwanted long-call sallies? As always, I would extremely grateful for any and all guidance. Rob Robson -- http://www.piclist.com hint: To leave the PICList spam_OUTpiclist-unsubscribe-requestTakeThisOuTmitvma.mit.edu

> My first (unsuccessful) attempt to locate some routines on Page 1 and to > call them from Page 0 has sent me scrambling for the datasheets and whatever > other online resources I could find. There seems be a variety of approaches > to the PCLATH issue, most of which have confused the daylights out of me. > Perhaps someday I'll be up to the more sophisticated techniques (macros, > etc.), but for now, could I not just make every single CALL in my program an > LCALL and call it good? LCALL isn't documented in the MPASM manual I have (DS33014G), although it may be old. I strongly recommend that you don't just try to cheap out and make this project work "somehow" quickly instead of sitting down and learning this right. You're going to have to do that sooner or later, and the sooner you do it the more you will benefit from it and the less messy code you will have around. Macros ARE a good way of dealing with this issue, and the macro language is trivial to learn. You will find them a powerful tool with many uses. The convention I use is that PCLATH is always set for the page the current module is located in, and modules don't cross page boundaries. That means I can use GOTOs and CALLs inside a module without having to worry about PCLATH. For calling outside a module, I use my GCALL (Global Call) macro. It sets PCLATH to the target page, and then does a CALL. Just as important, on return it restores PCLATH to the local page. You also need to think about RAM banks. Take this first project as a learning exercise and either write out all the paging and banking instructions or create yourself some dumb macros to help a little. After you've attained a good understanding of paging and banking, then you'll be ready to look at a bunch of more sophisticated macros I have. You'll find a whole PIC development environment at http://www.embedinc.com/pic. It handles paging, banking, abstraction of I/O pins, portability between processors, and a few other things in a nice integrated way. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com -- http://www.piclist.com hint: To leave the PICList piclist-unsubscribe-requestKILLspammitvma.mit.edu

> Olin Lathrop wrote: > > I strongly recommend that you don't just try to cheap out and make this > project work "somehow" quickly instead of sitting down and learning this > right. You're going to have to do that sooner or later, and the sooner > you do it the more you will benefit from it and the less messy code you > will have around. Macros ARE a good way of dealing with this issue, and > the macro language is trivial to learn. You will find them a powerful > tool with many uses. This has the ring of Good Advice, and I am presently following it (despite the funhouse challenges posed by some latent dyslexia). Thanks again for steering me in the right direction. By the way, LCALL and LGOTO appear in the Quick Reference Guide that came with a recent PICSTART Plus, but I haven't spotted an elaboration on their function elsewhere. They seem to take care of PCLATH <4,3> for the initial leap, but don't clean it up again on RETURN. Into the Fire Swamp I go. Rob Robson -- http://www.piclist.com hint: To leave the PICList .....piclist-unsubscribe-requestKILLspam.....mitvma.mit.edu

Rob Robson <EraseMEPICLISTspam_OUTTakeThisOuTmitvma.mit.edu> wrote: > My first (unsuccessful) attempt to locate some routines on Page 1 > and to call them from Page 0 has sent me scrambling .... could I > not just make every single CALL in my program an LCALL and call it > good? Would that work, or would that cause the PIC's PC to go on > some unwanted long-call sallies? Rob: LCALL will set the PCLATH bits appropriately for the destination of the CALL, but it won't reset PCLATH after the RETURN. Therefore, you'll have to change EVERY ONE of your CALLs and GOTOs to LCALL and LGOTO. Macros that adjust PCLATH on both sides of the CALL have been posted numerous times to the list; I'm sure Olin will post a link to his macros. Be careful when using long-call (and long-goto) macros; if you replace a fragment like: BTFSS PORT,BIT CALL BIT_IS_LO with: BTFSS PORT,BIT XCALL BIT_IS_LO your code will break, since that second fragment REALLY says something like: BTFSS PORT,BIT BSF PCLATH,3 BCF PCLATH,4 CALL BIT_IS_LO BCF PCLATH,3 BCF PCLATH,4 For cases like that, what you really want is: BTFSC PORT,BIT GOTO $+6 BSF PCLATH,3 BCF PCLATH,4 CALL BIT_IS_LO BCF PCLATH,3 BCF PCLATH,4 ... and the easiest, least-error-prone way to do THAT is to never use BTFSS/CALL at all; instead, write "LCALLIF" and "LCALLIFNOT" macros that do the whole thing for you, from the initial BTFSC/BTFSS to the final PCLATH adjustment. For a long-call macro to be correct in all cases, it must adjust all the relevant PCLATH bits, even when only one bit actually NEEDS to be adjusted. Just about everyone tries to avoid this by writing a macro that conditionally includes the second bit-adjustment only if it's necessary. Unfortunately, MPASM can't deal with macros that aren't fixed-length, so the conditional macros don't work. If you want maximal efficiency, then, you need a whole bunch of macros, one for each combination of source and destination page. To ensure that you never use the wrong one, each macro should include IF/ERROR lines that check for source and destination pages that match the ones for which the macro was written, then display an error message if there's an inconsistency. Personally, I wouldn't bother maximizing the efficiency for most projects. If you're only using two pages, it's pretty easy to arrange things so very few cross-page calls are necessary; if you're using more, it usually isn't necessary to squeeze every last byte and instruction cycle out of your code. -Andy === Andrew Warren -- aiwspam_OUTcypress.com === Principal Design Engineer === Cypress Semiconductor Corporation === === Opinions expressed above do not === necessarily represent those of === Cypress Semiconductor Corporation -- http://www.piclist.com hint: To leave the PICList @spam@piclist-unsubscribe-requestKILLspammitvma.mit.edu

I think the lcall "command" is actually a supplied macro. If you disassemble the assembled program you find that you now have a line setting/resetting the appropriate PCLATH bit. followed by a line performing the call itself. This is fine unless you immediately precede the lcall with a conditional skip instruction. In this event you only skip the bit set/clear command but still execute the call (to a local address). Things can get very confusing & hard to figure what's gone wrong. (I found this (eventually) the hard way!) I find it better to avoid the lcall etc. "commands" and use an obvious macro. - or just set/clear the PCLATH bit manually. Richard P My first (unsuccessful) attempt to locate some routines on Page 1 and to call them from Page 0 has sent me scrambling for the datasheets and whatever other online resources I could find. There seems be a variety of approaches to the PCLATH issue, most of which have confused the daylights out of me. Perhaps someday I'll be up to the more sophisticated techniques (macros, etc.), but for now, could I not just make every single CALL in my program an LCALL and call it good? Would that work, or would that cause the PIC's PC to go on some unwanted long-call sallies? As always, I would extremely grateful for any and all guidance. Rob Robson -- http://www.piclist.com hint: To leave the PICList KILLspampiclist-unsubscribe-requestKILLspammitvma.mit.edu -- http://www.piclist.com hint: To leave the PICList RemoveMEpiclist-unsubscribe-requestTakeThisOuTmitvma.mit.edu

> Unfortunately, MPASM can't deal with macros that aren't > fixed-length, so the conditional macros don't work. Huh!? I have many macros that result in varying numbers of instructions depending on assembly time state. One example is the DBANKIF macro in STD.INS.ASPIC at http://www.embedinc.com/pic. It generates, 0, 1 or 2 bit setting instructions depending on the old and new register bank settings. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com -- http://www.piclist.com hint: To leave the PICList spamBeGonepiclist-unsubscribe-requestspamBeGonemitvma.mit.edu

Olin Lathrop <TakeThisOuTPICLISTEraseMEspam_OUTmitvma.mit.edu> wrote: > > Unfortunately, MPASM can't deal with macros that aren't > > fixed-length, so the conditional macros don't work. > > Huh!? I have many macros that result in varying numbers of instructions > depending on assembly time state. One example is the DBANKIF macro in > STD.INS.ASPIC at http://www.embedinc.com/pic. It generates, 0, 1 or 2 bit > setting instructions depending on the old and new register bank settings. Good point. Let me rephrase: Unfortunately, MPASM can't deal with macros that aren't fixed-length. Fortunately, however, Microchip now include a separate linker with their dev tools, so if you're one of those people who use MPLINK, you can go ahead and write all the varying-length macros that you want. You kids today have it so easy... -Andy === Andrew Warren -- RemoveMEaiwTakeThisOuTcypress.com === Principal Design Engineer === Cypress Semiconductor Corporation === === Opinions expressed above do not === necessarily represent those of === Cypress Semiconductor Corporation -- http://www.piclist.com hint: To leave the PICList piclist-unsubscribe-requestEraseME.....mitvma.mit.edu

> Good point. Let me rephrase: > Unfortunately, MPASM can't deal with macros that aren't > fixed-length. I still don't understand what you mean. And what do you mean by length anay, the number of instructions that are generated? MPASM deals perfectly with macro's that generate a number of instructions that varies, depending for instance on macro parameters, the current location, global settings etc. I can not handle macro's that create a varying number of instructions depending on the pass (pass 1 or pass 2, yes, such macro's can be written!), but I guess no two-pass assembler can. Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products -- http://www.piclist.com hint: To leave the PICList EraseMEpiclist-unsubscribe-requestmitvma.mit.edu

> Unfortunately, MPASM can't deal with macros that aren't > fixed-length. Fortunately, however, Microchip now include a > separate linker with their dev tools, so if you're one of > those people who use MPLINK, you can go ahead and write all > the varying-length macros that you want. Everyone should be using the linker. Talking about absolute mode here is just a waste of bandwidth and does a disservice to newbies who might get the impression it is a reasonable option. Unfortunately many Microchip examples still use the archaic absolute mode, which gives the impression that it's the preferred way to use MPLAB. It's not. Relocatable mode allows you to write much cleaner software, takes about the same effort to learn, but makes writing the code easier and less error prone. This issue only comes up because there is an absolute mode, which is there for historic reasons. Relocatable code using a linker is the normal way to do software development in general. Nobody complains that all Windows development uses relocatable objects. It's just the way it's done. Microchip would do a big service if they supported absolute mode only with a special -OLD command line option and said it was not recommended for new designs. I know I've probably offended some people that still cling to absolute mode because relocatable mode is "too hard to learn". Usually this means they haven't really looked at it and are using absolute mode from long ago and feel threatened by the "new" stuff. In reality, all instructions are the same, and most directives too. Some directives have different names (CODE instead of ORG), but work pretty much the same way. Then there are things that make relocatable mode easier to write, like separate modules each with its own namespace, properly working macros (I didn't know about the fixed size limitation before), no page boundaries within a module, and no more manually trying to fit various routines into specific pages. All in all, relocatable mode is clearly better and a little easier than absolute mode. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com -- http://www.piclist.com hint: To leave the PICList RemoveMEpiclist-unsubscribe-requestEraseMEEraseMEmitvma.mit.edu

Olin's right. Use C and you won't know the difference. Andy At 05:28 PM 11/12/02 -0500, you wrote: {Quote hidden}>> Unfortunately, MPASM can't deal with macros that aren't >> fixed-length. Fortunately, however, Microchip now include a >> separate linker with their dev tools, so if you're one of >> those people who use MPLINK, you can go ahead and write all >> the varying-length macros that you want. > >Everyone should be using the linker. Talking about absolute mode here is >just a waste of bandwidth and does a disservice to newbies who might get >the impression it is a reasonable option. Unfortunately many Microchip >examples still use the archaic absolute mode, which gives the impression >that it's the preferred way to use MPLAB. It's not. Relocatable mode >allows you to write much cleaner software, takes about the same effort to >learn, but makes writing the code easier and less error prone. > >This issue only comes up because there is an absolute mode, which is there >for historic reasons. Relocatable code using a linker is the normal way >to do software development in general. Nobody complains that all Windows >development uses relocatable objects. It's just the way it's done. >Microchip would do a big service if they supported absolute mode only with >a special -OLD command line option and said it was not recommended for new >designs. > >I know I've probably offended some people that still cling to absolute >mode because relocatable mode is "too hard to learn". Usually this means >they haven't really looked at it and are using absolute mode from long ago >and feel threatened by the "new" stuff. In reality, all instructions are >the same, and most directives too. Some directives have different names >(CODE instead of ORG), but work pretty much the same way. Then there are >things that make relocatable mode easier to write, like separate modules >each with its own namespace, properly working macros (I didn't know about >the fixed size limitation before), no page boundaries within a module, and >no more manually trying to fit various routines into specific pages. All >in all, relocatable mode is clearly better and a little easier than >absolute mode. > > >***************************************************************** >Embed Inc, embedded system specialists in Littleton Massachusetts >(978) 742-9014, http://www.embedinc.com > >-- >http://www.piclist.com hint: To leave the PICList >RemoveMEpiclist-unsubscribe-requestspam_OUTKILLspammitvma.mit.edu > > ------------------------------------------------------------------- Race Boats - RemoveMEandyTakeThisOuTspamRC-Hydros.com http://www.RC-Hydros.com Airplanes - EraseMEandyspamspamBeGoneFlyingHobbies.com http://www.FlyingHobbies.com Electronics - RemoveMEandyKILLspamMontanaDesign.com http://www.MontanaDesign.com ------------------------------------------------------------------- -- http://www.piclist.com hint: To leave the PICList piclist-unsubscribe-requestSTOPspamspam_OUTmitvma.mit.edu

Wouter van Ooijen <spamBeGonePICLISTSTOPspamEraseMEmitvma.mit.edu> wrote: > > Unfortunately, MPASM can't deal with macros that aren't > > fixed-length. > > I still don't understand what you mean .... MPASM deals perfectly > with macro's that generate a number of instructions that varies > [but it] can not handle macro's that create a varying number of > instructions depending on the pass Wouter: Actually, you clearly DO understand what I mean, even though I phrased it much more poorly than you did. -Andrew === Andrew Warren -- KILLspamaiwspamBeGonecypress.com === Principal Design Engineer === Cypress Semiconductor Corporation === === Opinions expressed above do not === necessarily represent those of === Cypress Semiconductor Corporation -- http://www.piclist.com hint: To leave the PICList EraseMEpiclist-unsubscribe-requestEraseMEmitvma.mit.edu

Unfortunately, MPASM can't deal with macros that aren't fixed-length. I still don't get it? Most macro assemblers have problems with macros that evaluate to different lengths during different assembler passes due to unresolved forward references (or values that change) during the first pass (and most assemblers have two passes), but that's a pretty small subset of "macros that aren't fixed length"... I CAN do something like this, right: mystring macro text dt text endm Isn't that a non-fixed-length macro? BillW -- http://www.piclist.com hint: To leave the PICList @spam@piclist-unsubscribe-request@spam@spam_OUTmitvma.mit.edu

> For a long-call macro to be correct in all cases, it must adjust all > the relevant PCLATH bits, even when only one bit actually NEEDS to be > adjusted. Just about everyone tries to avoid this by writing a macro > that conditionally includes the second bit-adjustment only if it's > necessary. Unfortunately, MPASM can't deal with macros that aren't > fixed-length, so the conditional macros don't work. Actually, MPASM will work just fine with conditional (variable size) macros, as long as the code expands to the same number of instructions on both assembly passes for any given invocation of hte macro. The problem with most schemes to generate optimized long calls is that, on the first pass, all the target addresses are seen as being zero if they haven't beend defined yet. One way around this is to define symbols at the front of your code identifying the page that each routine is going to be in: P_Routine1 = 0 P_Routine2 = 1 etc. Then your LCALL macro takes two arguments: LCALL Routine1,P_Routine1 It can use the second argument to determine what has to be done to PCLATH. Finally, you use a macro to define the entry point of the subroutine: ENTPT Routine1,P_Routine1 which defines the entry point, and also verifies that it is indeed in the page that the P_Xxxxx symbol indicated it would be in. Note that none of this magic is likely to work when using the linker. Bob Ammerman RAm Systems -- http://www.piclist.com hint: To leave the PICList spamBeGonepiclist-unsubscribe-requestKILLspammitvma.mit.edu

Olin, I know you go on and on about using the linker. However, I have recently done one job on an '876 that just plain would not have worked using a linker. Timing was very tight and I had to carefully place code in just the right places so that PCLATH would be set up right at various points. Note that I don't just mean in the right 2K pages which would be reasonable with the linker, but actually aligning code properly across 256-byte boundaries. With a little discipline it really isn't that hard to manage. btw: as I mentioned in a previous post, variable length macros is not a function of whether or not you use the linker, but rather whether the macros expand to the same size on both assembly passes. Bob Ammerman RAm Systems -- http://www.piclist.com hint: To leave the PICList TakeThisOuTpiclist-unsubscribe-request.....TakeThisOuTmitvma.mit.edu

Ah, but which is which?? Bob Ammerman RAm Systems ----- Original Message ----- From: "Bob Blick" <TakeThisOuTbblickKILLspamspamSONIC.NET> To: <.....PICLISTRemoveMEMITVMA.MIT.EDU> Sent: Tuesday, November 12, 2002 7:28 PM Subject: Re: [PIC]: simple 16F877 long call strategy needed {Quote hidden}> On Tue, 12 Nov 2002, Bob Ammerman wrote: > > Note that none of this magic is likely to work when using the linker. > > Ahh, wizards and muggles again! > > -Bob > > -- > http://www.piclist.com hint: To leave the PICList > RemoveMEpiclist-unsubscribe-requestspamBeGonemitvma.mit.edu > > -- http://www.piclist.com hint: To leave the PICList spamBeGonepiclist-unsubscribe-request@spam@spam_OUTmitvma.mit.edu

I see where you're coming from, Bob. A sledge hammer isn't the right tool for finishing trimwork. The right tool for the job. What a concept! Andy At 07:35 PM 11/12/02 -0500, you wrote: {Quote hidden}>Olin, > >I know you go on and on about using the linker. However, I have recently >done one job on an '876 that just plain would not have worked using a >linker. Timing was very tight and I had to carefully place code in just the >right places so that PCLATH would be set up right at various points. Note >that I don't just mean in the right 2K pages which would be reasonable with >the linker, but actually aligning code properly across 256-byte boundaries. >With a little discipline it really isn't that hard to manage. > >btw: as I mentioned in a previous post, variable length macros is not a >function of whether or not you use the linker, but rather whether the macros >expand to the same size on both assembly passes. > >Bob Ammerman >RAm Systems > >-- >http://www.piclist.com hint: To leave the PICList >TakeThisOuTpiclist-unsubscribe-requestspammitvma.mit.edu > > ------------------------------------------------------------------- Race Boats - andyEraseMERC-Hydros.com http://www.RC-Hydros.com Airplanes - RemoveMEandyEraseMEspam_OUTFlyingHobbies.com http://www.FlyingHobbies.com Electronics - @spam@andyRemoveMEEraseMEMontanaDesign.com http://www.MontanaDesign.com ------------------------------------------------------------------- -- http://www.piclist.com hint: To leave the PICList EraseMEpiclist-unsubscribe-request@spam@mitvma.mit.edu

----- Original Message ----- From: Andy Kunz <@spam@montanaspam_OUT.....FAST.NET> To: <spamBeGonePICLISTEraseMEMITVMA.MIT.EDU> Sent: Tuesday, November 12, 2002 10:30 PM Subject: Re: [PIC]: simple 16F877 long call strategy needed > Olin's right. Use C and you won't know the difference. > > Andy Actually the next version of the xcasm assembler (which is due for imminent release) will automatically generate RAM (data) and ROM (code) paging instructions if enabled. It analyses the generated code and inserts the minimum number of instructions necessary to maintain the correct pages. You could liken this to some kind of intelligent link phase except that by doing it in the assembler you actually get tight control from within the assembler which allows further optimisation. Below is an example of a short section of assembler which decides which RAM page to put a data section into. By doing this within the assembler, any macros used can take advantage of knowing where the data is located (user written macros can take advantage of fixed addresses and constants when generating code - yes the assembler can cope with variable length output from macros). The automatic paging further benefits from this feedback. Regards Sergio Masci http://www.xcprod.com ;---------------------- The following section of assembler is generated by the XCSB compiler and fed straight into the XCASM assembler. It allows the assembler to directly decide in which RAM page to place some floating point variables used by some floating point macros (yes the assembler handles floating point numbers as well). .sect prog_data2_group_base_sect .org 0xA0 .group prog_data2_group, prog_data2_group_base_sect xgroup_val .set 0 .if DEFINED("prog_data_group") xgroup_val .set GROUP_SIZE("prog_data_group") .endif .if DEFINED("code_gen_data_sect") xsect_val .set SECT_SIZE("code_gen_data_sect") .if xgroup_val + xsect_val < 0x70 .group prog_data_group, code_gen_data_sect xgroup_val .set xgroup_val+xsect_val .else .group prog_data2_group, code_gen_data_sect .endif .endif .if DEFINED("code_gen_fp_data_sect") xsect_val .set SECT_SIZE("code_gen_fp_data_sect") .if xgroup_val + xsect_val < 0x70 .group prog_data_group, code_gen_fp_data_sect xgroup_val .set xgroup_val+xsect_val .else .group prog_data2_group, code_gen_fp_data_sect .endif .endif -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

----- Original Message ----- From: William Chops Westfield <billwspamBeGoneCISCO.COM> To: <RemoveMEPICLIST@spam@spamBeGoneMITVMA.MIT.EDU> Sent: Tuesday, November 12, 2002 11:22 PM Subject: Re: [PIC]: simple 16F877 long call strategy needed > Unfortunately, MPASM can't deal with macros that aren't > fixed-length. > > I still don't get it? Most macro assemblers have problems with macros that > evaluate to different lengths during different assembler passes due to > unresolved forward references (or values that change) during the first pass {Quote hidden}> (and most assemblers have two passes), but that's a pretty small subset of > "macros that aren't fixed length"... > > I CAN do something like this, right: > > mystring macro text > dt text > endm > > Isn't that a non-fixed-length macro? > > BillW A variable length macro would by something like st16 .macro dst, arg .if (arg & $ff) == 0 clrf dst+0 .else movlw arg & $ff movwf dst+0 .endif .if (arg & $ff00) == 0 clrf dst+1 .else movlw (arg >> 8) & $ff movwf dst+1 .endif .endm calling st16 with an undefined label (a forward reference) would result in zero the first time round (generating two instructions the first time) and then a non zero the second time round (generating three or four instructions the second time) Regards Sergio Masci http://www.xcprod.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: > > > Unfortunately, MPASM can't deal with macros that aren't > > fixed-length. Fortunately, however, Microchip now include a > > separate linker > > Everyone should be using the linker. Talking about absolute mode here is > just a waste of bandwidth and does a disservice to newbies SURELY that decision should be left to the majority, and *maybe* that majority are still using (and prefer) absolute mode?? ;o) For the "control freaks" like myself there is little alternative to absolute mode, how else to you get the absolute maximum amount of code into that 512 bytes of ROM? Many of my projects use very carefully designed code blocks and tables and need to have every word in the right spot to get the speed and size... I do understand the benefits of linked and re-usable modules in LARGER projects where they are very superior. But as the PIC size gets smaller and development time becomes less critical than PIC size, a point is reached where absolute mode gives the BEST end result. As a consultant it benefits you to develop code very quickly using a "standard" larger PIC and linked modules. But as a manufacturer it benefits me to use the SMALLEST PIC possible even it takes weeks of fiddly absolute coding to make it all fit. Saying cars are better than motorcycles is a rather closed minded attitude. Next you'll be saying talking about 16F PICs is "doing newbies a disservice" as they should be learining on 18F, heck why stop there, they should be soldering Pentiums into their led flasher and we can all throw our PICs away. <grin> -Roman -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

{Quote hidden}> -----Original Message----- > From: Roman Black [SMTP:.....fastvid@spam@EraseMEEZY.NET.AU] > Sent: Wednesday, November 13, 2002 8:06 AM > To: .....PICLISTRemoveMEmitvma.mit.edu > Subject: Re: [PIC]: simple 16F877 long call strategy needed > > Olin Lathrop wrote: > > > > > Unfortunately, MPASM can't deal with macros that aren't > > > fixed-length. Fortunately, however, Microchip now include a > > > separate linker > > > > Everyone should be using the linker. Talking about absolute mode here > is > > just a waste of bandwidth and does a disservice to newbies > > > SURELY that decision should be left to the > majority, and *maybe* that majority are still > using (and prefer) absolute mode?? ;o) > The point that Olin made was that if the majority are using absolute mode, it's most likely due to the perceived complexity of writing relocatable code and using the linker. Of course I agree that you should use the right tools for the job, and in a few cases relocatable code may not be the best solution. However, for many projects it is, and I agree that it's worth learning. Regards Mike -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

>That makes me curious! Which assemblers do you know >that can handle such things, how do they handle it >(varying number of passes?). Well I have heard of assemblers (mini or mainframe based IIRC) which would do more then two passes to do the best optimisation. IIRC figures like 8 passes spring to mind, with it being able to do more if necessary, and a maximum being command line specified to stop infinite loops on the pass count. Also I'm not sure that the original Intel Macro86 assembler did not do multiple passes (more than 2) to handle the optimisation of short/long jumps and calls. -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

> One way around this is to define symbols at the front of your code > identifying the page that each routine is going to be in: > > P_Routine1 = 0 > P_Routine2 = 1 > > ... > > Note that none of this magic is likely to work when using the linker. No, it would work better. You define the P_xxx constants in an include file, then use them to guarantee each routine is placed onto the chosen page. Your ENTPT macro then doesn't need to verify that it is on the right page, it puts it on the right page. Here is what some of the code would look like assuming linker sections called .PAGEn where N is the page number: p_suba equ 0 ;set page for SUBA .page#v(p_suba) code suba <body of SUBA goes here> I actually use a very similar scheme for placing variable in specific banks, but otherwise let the linker allocate memory within the bank. ***************************************************************** 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 know you go on and on about using the linker. However, I have recently > done one job on an '876 that just plain would not have worked using a > linker. I don't believe that. How familiar are you with the linker, Bob? There seem to be a lot of myths out there about relocatable mode that just aren't true. I suspect that you haven't used the linker much (at all?) and therefore aren't aware of all the things you can do in relocatable mode. One way to think of it is that relocatable mode is a superset of absolute mode. If you want to specify every last address, you can. However, for the vast majority of cases when you don't care, you can let the linker do it's allocation magic. In either case you still get nice things like private name spaces for each module. > Timing was very tight and I had to carefully place code in just the > right places so that PCLATH would be set up right at various points. Note > that I don't just mean in the right 2K pages which would be reasonable with > the linker, but actually aligning code properly across 256-byte boundaries. Of course you can do this in relocatable mode. You can hard wire any section to a specific address if you wish. I've occasionally had tables and critical routines that I stuck at specific addresses just like what you're talking about. I bet that you only needed a small subset of your code at known addresses, and could have let the linker place the rest wherever is wanted to. ***************************************************************** 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

> For the "control freaks" like myself there is > little alternative to absolute mode, how else > to you get the absolute maximum amount of code > into that 512 bytes of ROM? Many of my projects > use very carefully designed code blocks and tables > and need to have every word in the right spot to > get the speed and size... This seems to be Standard Linker Myth #1 again. See my response to Bob. > I do understand the benefits of linked and > re-usable modules in LARGER projects where they > are very superior. But as the PIC size gets > smaller and development time becomes less critical > than PIC size, a point is reached where absolute > mode gives the BEST end result. Again, same argument same response. > As a consultant it benefits you to develop code > very quickly using a "standard" larger PIC and > linked modules. But as a manufacturer it benefits > me to use the SMALLEST PIC possible even it takes > weeks of fiddly absolute coding to make it all fit. Some of my projects are high volume too. In some cases I have to give the linker a little less freedom, but I only need to do that in those cases where it matters. ***************************************************************** 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

Bob stated: > > I know you go on and on about using the linker. However, I have recently > > done one job on an '876 that just plain would not have worked using a > > linker. Olin replied: > I don't believe that. How familiar are you with the linker, Bob? There > seem to be a lot of myths out there about relocatable mode that just > aren't true. I suspect that you haven't used the linker much (at all?) > and therefore aren't aware of all the things you can do in relocatable > mode. One way to think of it is that relocatable mode is a superset of > absolute mode. If you want to specify every last address, you can. > However, for the vast majority of cases when you don't care, you can let > the linker do it's allocation magic. In either case you still get nice > things like private name spaces for each module. Ok, Let me rephrase. Yes, it would have worked using the linker, but it would have involved a lot of fussing with the .LKR file. Sometimes several code pieces were carefully packed into single 256-word chunks (so that I could run state machines by simply copying state values toPCL). Other chunks just had to fit within the same 2K page as the state machines they supported. In some cases I had to ensure that several distinct 256-word chunks, each containing the code for one or more state machines all were within the same 2K page. I was able to ensure that everything fit where it was supposed to by using appropriate IF checks in the asm code. And, btw, not using the linker doesn't mean you can't modularize (although you lose scoping of variables). > I bet that you only needed a small subset of your > code at known addresses, and could have let the linker place the rest > wherever is wanted to. Actually, most of the code had to be carefully laid out. Again, not to say the linker isn't wonderful (it is), but it is not a panacea, and is not _always_ the right answer. Bob Ammerman RAm Systems -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

part 1 1567 bytes content-type:text/plain; (decoded 7bit) > Let me rephrase. Yes, it would have worked using the linker, but it would > have involved a lot of fussing with the .LKR file. I don't see anything in your description that would require this. I've attached my standard linker control file for the 16F876, which creates a separate section for each page. By the way, all my linker control files are available in the PIC development tools download at http://www.embedinc.com/pic/dload.htm. > Sometimes several code > pieces were carefully packed into single 256-word chunks (so that I could > run state machines by simply copying state values toPCL). Other chunks just > had to fit within the same 2K page as the state machines they supported. In > some cases I had to ensure that several distinct 256-word chunks, each > containing the code for one or more state machines all were within the same > 2K page. I was able to ensure that everything fit where it was supposed to > by using appropriate IF checks in the asm code. ; This module contains blocks of instructions that need ; to be in the same 256-word block, and all these blocks ; need to be on the same code page. ; bstart set h'0800' ;start the blocks here (start of page 1) ; ; Block 1 ; .block1 code bstart <code for block 1> if ($ - bstart) > 256 error "Block 1 larger than 256 words" endif bstart set bstart + 256 ;make start address for next block ; ; Block 2 ; .block2 code bstart . . . part 2 1327 bytes content-type:application/octet-stream; (decode) part 3 328 bytes ***************************************************************** 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

Roman Black wrote: > > Everyone should be using the linker. Talking > > about absolute mode here is just a waste of > > bandwidth and does a disservice to newbies > > SURELY that decision should be left to the > majority, and *maybe* that majority are still > using (and prefer) absolute mode?? ;o) "Majority" things can't determine the best practice, I think. > Saying cars are better than motorcycles is a rather > closed minded attitude. Next you'll be saying talking > about 16F PICs is "doing newbies a disservice" as > they should be learining on 18F, heck why stop > there, they should be soldering Pentiums into their > led flasher and we can all throw our PICs away. <grin> Actually, as for me, he said " Everyone should be using modern vehicle, not horses". Talking about 16F PICs is really "doing newbies a disservice", in my opinion and for newbies only, of course. 18 pins 18F are coming. The 8-bit core must be the same in all the Microchip 8-bit controllers and in learning process as well. Can't see reasons why 18F shouldn't be cheaper then 12-16F. Best regards. Mike. -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads