Post by thread:[PIC]: 16f628 BTFSS & BTFSC curiosity

Scott, I solved with snippet1 which works fine, but snippet2 does not. The original code snippet2 just would not work properly. I first tried the following for lack of anything else intelligent to do... incf INDF,f ;TMR0 overflowed inc Pulse Width counter goto TstNxtFlg ; and it gave the expected results but not the required one. I agree with you, the snippets below are functionally the same, but in my prog behave differently. I will just leave it as a mystery and move on. Justin How *did* you solve it? {Quote hidden}> > > Snippet1 working as expected > > incf INDF,f ;TMR0 overflowed inc Pulse Width counter > BTFSS STATUS,Z ;Did the counter overflow > goto TstNxtFlg ;No > decf INDF,f ;Yes, Keep it at 255 > goto TstNxtFlg ; > > Snippet2 behaving strangely > > incf INDF,f ;TMR0 overflowed inc Pulse Width counter > BTFSC STATUS,Z ;Did the counter overflow > decf INDF,f ;Yes, Keep it at 255 > goto TstNxtFlg ;No Scott -- http://www.piclist.com hint: To leave the PICList spam_OUTpiclist-unsubscribe-requestTakeThisOuTmitvma.mit.edu -- http://www.piclist.com hint: To leave the PICList .....piclist-unsubscribe-requestKILLspam@spam@mitvma.mit.edu>

Richards, Justin P wrote: > Scott, > > I solved with snippet1 which works fine, but snippet2 does not. The > original code snippet2 just would not work properly. I first tried > the following for lack of anything else intelligent to do... > > incf INDF,f ;TMR0 overflowed inc Pulse Width counter > goto TstNxtFlg ; > > and it gave the expected results but not the required one. > > I agree with you, the snippets below are functionally the same, but > in my prog behave differently. > > I will just leave it as a mystery and move on. > > Justin This strikes a familiar chord with me. Recently, I was tinkering (but can't remember precisely what with) and I ran into an issue where I had an interrupt routine (running from timer events, and the capture module) and some main level code running in a somewhat tight loop. I had some "peculiar" results like yourself. It turned out to be some kind of "resonance" between the length of the ISR (number of cycles) and the length of the main level loop. By sticking nop's into either the main loop, or the ISR it would cause the problem to go away or to reappear. I'm sorry that I can't recall the exact scenario, but as I continued working on the code, it simply became a non-issue. Perhaps the timer interrupts were occuring at exactly the same place in the main loop every time causing my strange results. IOW, it's not the BTFSC or BTFSS that's the problem, it's the number of cycles being executed in the ISR, and the regularity of the ISR. I could be crazy, but that's what seemed to be the problem. ;-) michael brown {Quote hidden}> How *did* you solve it? >> >> >> Snippet1 working as expected >> >> incf INDF,f ;TMR0 overflowed inc Pulse Width counter >> BTFSS STATUS,Z ;Did the counter overflow >> goto TstNxtFlg ;No >> decf INDF,f ;Yes, Keep it at 255 >> goto TstNxtFlg ; >> >> Snippet2 behaving strangely >> >> incf INDF,f ;TMR0 overflowed inc Pulse Width counter >> BTFSC STATUS,Z ;Did the counter overflow >> decf INDF,f ;Yes, Keep it at 255 >> goto TstNxtFlg ;No > > > Scott > > -- > http://www.piclist.com hint: To leave the PICList > piclist-unsubscribe-requestKILLspammitvma.mit.edu Michael Brown Instant Net Solutions http://www.KillerPCs.net "In the land of the blind, he who has one eye is king" -- http://www.piclist.com hint: To leave the PICList .....piclist-unsubscribe-requestKILLspam.....mitvma.mit.edu>

On Tue, 25 Feb 2003, Richards, Justin P wrote: > Scott, > > I solved with snippet1 which works fine, but snippet2 does not. The > original code snippet2 just would not work properly. I first tried the > following for lack of anything else intelligent to do... > > incf INDF,f ;TMR0 overflowed inc Pulse Width counter > goto TstNxtFlg ; > > and it gave the expected results but not the required one. > > I agree with you, the snippets below are functionally the same, but in > my prog behave differently. > > I will just leave it as a mystery and move on. In my opinion, unsolved mysteries like this should *not* be left alone. It may be that you have a fatal bug that is being manifested in mysterious ways. If you slightly change the environment, then the bug may still be present but just exhibiting different symptoms. I'd suggest working it out! Hint, the difference between your two snippets is the state of the Z flag. If this code is an interrupt routine, then you may not be saving/restoring the Status register properly. So Z may be getting trashed. Scott -- http://www.piclist.com hint: To leave the PICList EraseMEpiclist-unsubscribe-requestspam_OUTTakeThisOuTmitvma.mit.edu>

At 07:19 AM 2/25/2003 -0800, you wrote: >In my opinion, unsolved mysteries like this should *not* be left alone. It >may be that you have a fatal bug that is being manifested in mysterious >ways. If you slightly change the environment, then the bug may still be >present but just exhibiting different symptoms. > >I'd suggest working it out! That's my experience. Things that go away by themselves come back by themselves. ALWAYS get to the bottom of it. <good hint snipped> Best regards, Spehro Pefhany --"it's the network..." "The Journey is the reward" speffspam_OUTinterlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com -- http://www.piclist.com hint: To leave the PICList @spam@piclist-unsubscribe-requestKILLspammitvma.mit.edu>

>BTW: I don't follow your comment on the Z flag being affected >differently in his 2 routines - the only difference is the extra >GOTO, which doesn't affect the Z flag. Or have I missed something?? I am wondering the same. In both cases the first instruction is the same, so the Z flag must be affected the same. The instruction affects only the Z flag. He correctly uses appropriately different BTFS instructions, to achieve the different solutions. The only time I can see something strange happening is when the FSR is pointing at a timer register, in which case there would be an extra cycle or two added to the time it takes to reach its count, but that would not affect the code snippet. -- http://www.piclist.com hint: To leave the PICList KILLspampiclist-unsubscribe-requestKILLspammitvma.mit.edu>

> This strikes a familiar chord with me. Recently, I was tinkering (but > can't remember precisely what with) and I ran into an issue where I had > an interrupt routine (running from timer events, and the capture module) > and some main level code running in a somewhat tight loop. I had some > "peculiar" results like yourself. It turned out to be some kind of > "resonance" between the length of the ISR (number of cycles) and the > length of the main level loop. By sticking nop's into either the main > loop, or the ISR it would cause the problem to go away or to reappear. > I'm sorry that I can't recall the exact scenario, but as I continued > working on the code, it simply became a non-issue. Perhaps the timer > interrupts were occuring at exactly the same place in the main loop > every time causing my strange results. > > IOW, it's not the BTFSC or BTFSS that's the problem, it's the number of > cycles being executed in the ISR, and the regularity of the ISR. > > I could be crazy, but that's what seemed to be the problem. ;-) Did you try waving a dead fish over it during a full moon too? Your analysis is rediculous. There isn't magic operating here. Everything has a reasonable explanation, it's just that you haven't found it yet. And you never will if you allow yourself excuses like "resonance" between the ISR and the foreground code. This would only matter if the foreground code did timing or was timing sensitive itself. Much more likely your interrupt routine was trashing some state, which can certainly make the foreground loop look like its operating on magic. The last thing you want to do is poke NOPs at it until the "problem" goes away. The problem was being helpful in providing you with a detectable symptom. Covering up the symptom doesn't make the problem go away, but it does make it hard to track down and, even worse, gives the impression of correct operation when in could fail in strange ways for just the right combination of conditions. Unless you can absolutely test all responses to all possible inputs, I suggest tracking down the problem for real it a good idea. ***************************************************************** 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-requestTakeThisOuTmitvma.mit.edu>

Richards, Justin P wrote: > > I solved with snippet1 which works fine, but snippet2 does not. The original code snippet2 just would not work properly. > I agree with you, the snippets below are functionally the same, but in my prog behave differently. > > I will just leave it as a mystery and move on. Dodgy jumps could indicate you're crossing a page boundary etc? Look in the program (hex) window to see where each snippet is located. A (possibly!) good habit for beginners is to force locate different chunks of your code on different pages by using orgs, it lets you keep track of how big your chunks are and when the time comes for larger projects you will have some experience with keeping modules on different pages and reducing long gotos and calls etc. I'm sure people will argue but as a control freak I like to know how big my code pieces are and where they are. I also like to put nops at the end of every 64 words, this forces the assembler to display the entire code memory in the absolute listing and is a great way to see at a glance where things are and how much room you have left. And it gives you a polite error every time you use up another 64 words of precious code space. :o) -Roman -- http://www.piclist.com hint: To leave the PICList TakeThisOuTpiclist-unsubscribe-requestEraseMEspam_OUTmitvma.mit.edu>

Olin Lathrop wrote: {Quote hidden}>> This strikes a familiar chord with me. Recently, I was tinkering >> (but can't remember precisely what with) and I ran into an issue >> where I had an interrupt routine (running from timer events, and the >> capture module) and some main level code running in a somewhat tight >> loop. I had some "peculiar" results like yourself. It turned out >> to be some kind of "resonance" between the length of the ISR (number >> of cycles) and the length of the main level loop. By sticking >> nop's into either the main loop, or the ISR it would cause the >> problem to go away or to reappear. I'm sorry that I can't recall the >> exact scenario, but as I continued working on the code, it simply >> became a non-issue. Perhaps the timer interrupts were occuring at >> exactly the same place in the main loop every time causing my >> strange results. >> >> IOW, it's not the BTFSC or BTFSS that's the problem, it's the number >> of cycles being executed in the ISR, and the regularity of the ISR. >> >> I could be crazy, but that's what seemed to be the problem. ;-) > > Did you try waving a dead fish over it during a full moon too? No. Is that what a professional engineer with two dozen PIC projects would do? > Your analysis is rediculous. Oh really? >There isn't magic operating here. Well, duh. > Everything has a reasonable explanation, it's just that you haven't > found it yet. And you never will if you allow yourself excuses like > "resonance" between the ISR and the foreground code. This would only > matter if the foreground code did timing or was timing sensitive > itself. Much more likely your interrupt routine was trashing some > state, which can certainly make the foreground loop look like its > operating on magic. Did I use the word magic anywhere? > The last thing you want to do is poke NOPs at it until the "problem" > goes away. The problem was being helpful in providing you with a > detectable symptom. Covering up the symptom doesn't make the problem > go away, but it does make it hard to track down and, even worse, > gives the impression of correct operation when in could fail in > strange ways for just the right combination of conditions. Unless > you can absolutely test all responses to all possible inputs, I > suggest tracking down the problem for real it a good idea. I didn't blindly poke nops into the code to just make the problem "go away". I've written a little too much code in my life to be satisfied that easily (easily >500,000 lines). I said that adding a single nop, would make the problem cease. It didn't matter where the nop was put, just that one was inserted somewhere. Everything was being properly saved and restored in the ISR, I'm not quite that inept at this stuff you know. Amazingly enough, you could stick the nop in the main level loop and it would make the problem go away too. I thought about presenting it to the list, but instead I just moved on. I'm sorry that I didn't save the example for you personally to ponder over. Since you insist that my analysis was "rediculous" (sic), then perhaps you can explain how the nop affected things, it was only a nop after all. At this point the only explanation that I can imagine is that the length of the routines was the critical issue. Now let's hear your "expert" opinion, or at least a "reasonable" explanation, instead of another ad hominem attack. Or at least tell me something that I don't already know. michael brown "In the land of the blind, he who has one eye is king" -- http://www.piclist.com hint: To leave the PICList piclist-unsubscribe-requestEraseME.....mitvma.mit.edu>

These snippets are located in the first 60 odd bytes of code. I do no context saving so and need to keep on I an that issue. I have included the interrupt service routine to indicate that it is doubtful that it is a boundary issue. thanks for all your thoughts and I agree it does need to be tracked down so I will continue to wattle away at it. Justin expand uart_baud d'115200' ; org 0 ;ProgramStart ;Originate Program at address 0 goto main ;Jump over Int Routine org H'4' ;InterruptStart Originate routine at Address 4 btfss INTCON,T0IF ;Was it a TMR0 overflow goto TstNxtFlg ;No, then test if it was Change on PORTB,7 movlw TMR0Rate ;Value to Timeout TMR0 after 26.2uS addwf TMR0,f ;Adding removes latency delay of code above bcf INTCON,T0IF ;clr the TMR0 overflow flag btfss Mode ;Is it mode 0 ie high res goto TMR0_ISR_Mode0 ;Flag is clear therefore Mode0 80 wide pulses TMR0_ISR_Mode1 ;Flag is set therefore Mode1 160 narrow pulses incf INDF,f ;TMR0 overflowed inc Pulse Width counter BTFSS STATUS,Z ;Did the counter overflow goto TstNxtFlg ;No decf INDF,f ;Yes, Keep it at 255 goto TstNxtFlg ; ; incf INDF,f ;TMR0 overflowed inc Pulse Width counter ; BTFSC STATUS,Z ;Did the counter overflow ; decf INDF,f ;Yes, Keep it at 255 ; goto TstNxtFlg ;No TMR0_ISR_Mode0 incf INDF,f ;TMR0 overflowed inc Pulse Width counter BTFSS STATUS,Z ;Did the LSByte overflow goto TstNxtFlg ;No bsf FSR,7 ;Yes, Select MSByte Bank and inc incf INDF,f ;inc MSByte of 2 byte counter bcf FSR,7 ;Select LSByte Bank ie Normal TstNxtFlg btfss INTCON,RBIF ;was the a change of state on RB7 goto Exit ;No then exit RB_ISR movf PORTB,w ;we must read the port for INT to work bcf INTCON,RBIF ;clear change on portb int flag btfss Mode ;Is it Mode0 or 1 goto RB_ISR_Mode0 ;It is clear therefore Mode 0 RB_ISR_Mode1 ;It is set therefore Mode 1 btfsc FSR,7 ;If FSR points to Bank0,Point it to Bank1 goto IncFSR ;Allready pointing to bank1 so inc FSR bsf FSR,7 ;Set FSR to point to Bank1 goto Exit ;Were done IncFSR bcf FSR,7 ;Point back to Bank0 RB_ISR_Mode0 incf FSR,f ;Yes then point to next memory location movlw PulseB0 + D'80' ;W = Address of last mem location + 1 xorwf FSR,w ;if equal set the Zero bit btfsc STATUS,Z ;is FSR pointing to the last+1 mem loc bsf ReadDone ;Yes signal end of capture. Learn complete Exit retfie ;Return and Enable GIE <snip> Dodgy jumps could indicate you're crossing a page boundary etc? Look in the program (hex) window to see where each snippet is located. <snip> -- http://www.piclist.com hint: To leave the PICList EraseMEpiclist-unsubscribe-requestmitvma.mit.edu>

You guys are great! I was happy with some code i'd just written (not tested yet) that dispensed with the context saving "because i'm not using STATUS or W"... You just reminded me that the other code does change banks in an area that will be running when the int is operational. Just moved 2 variables to the top (bank safe) ram. Thanks!! I should buy another piclist t-shirt. :o) -Roman Herbert Graf wrote: {Quote hidden}> > > > I do no > > > context saving so and need to keep on I an that issue. > > > > oops. That's your bug! You've got to save the Status register and W > > register. If not, you cannot write any code in the foreground that depends > > on status and W. It sort of defeats the purpose of interrupts. > > Even worse, you can't properly access file registers since the register > page your in could be changed. Context saving is a requirement, it's given > in the data sheet, I don't understand why doing it is so often "skipped". > TTYL -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2/25/03 7:46:28 PM, Herbert Graf <RemoveMEmailinglistTakeThisOuTspamFARCITE.NET> wrote: > Even worse, you can't properly access file registers since the register >page your in could be changed. Context saving is a requirement, it's given >in the data sheet, I don't understand why doing it is so often "skipped". I wonder if it's more common among people who cut their teeth on 8051s? They don't have a Z flag; conditional jumps on zero/nonzero work by examining the A register for a zero/nonzero state, so ISRs that don't affect the carry flag or the A register don't need to save any context. In most cases, though, I suspect it's just laziness in the form of premature micro-optimization. That's what the Perl community calls "false laziness"; saving yourself a little bit of work in the present at the likely expense of a lot of work in the future. -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

> Since you insist that my analysis was "rediculous" (sic), then perhaps > you can explain how the nop affected things, it was only a nop after > all. At this point the only explanation that I can imagine is that the > length of the routines was the critical issue. If you're really really sure the interrupt routine saves/restores things properly, then location of code is the next thing to look at. So, what constructs are sensitive to the location in program memory? Paging and all manipulation of PCL should be looked at carefully. Also, if it's repeatable you should be able to single step thru it and see what's happening. Does the forground code run correctly if you disable interrupts? ***************************************************************** 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

Richards, Justin P wrote: > These snippets are located in the first 60 odd bytes of code. > ... It would be helpful if you formatted your code to use shorter line lengths, at least when posting it to the list. A little wrapping is understandable on lines with long comments, but yours was wrapped to oblivion. Starting the opcodes in column 17, operands in 33, and comments in 49 as you did is just asking for this kind of problem. ***************************************************************** 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

> Even worse, you can't properly access file registers since the > register page your in could be changed. Context saving is a > requirement, it's given > in the data sheet, I don't understand why doing it is so often > "skipped". Especially when all the context saving and restoring is boilerplate code that you can just lift. One place you can get this from is my interrupt routine template QQQ_INTR.ASPIC at http://www.embedinc.com/pic. All the context saving/restoring is already there, with assembly time conditionals to customize to different environments. All anyone has to do it fill in the actual interrupt handling code. ***************************************************************** 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: >> Since you insist that my analysis was "rediculous" (sic), then >> perhaps you can explain how the nop affected things, it was only a >> nop after all. At this point the only explanation that I can >> imagine is that the length of the routines was the critical issue. > > If you're really really sure the interrupt routine saves/restores > things properly, then location of code is the next thing to look at. I was using a 16F628 so everyting was on one code page. ISR was saving W, STATUS, FSR and PCLATH for good measure. Is there anything else that could potentially get me? > So, what constructs are sensitive to the location in program memory? > Paging and all manipulation of PCL should be looked at carefully. Oh I did. > Also, if it's repeatable you should be able to single step thru it > and see what's happening. Does the forground code run correctly if > you disable interrupts? Without the ISR running, the foreground code wouldn't do anything but loop, as it was waiting for the ISR to fill in a RAM location. And since the ISR was hit repeatedly so quickly by an external interrupt, it would have been impossible to simulate with what I have available. I even thought that since I had two interrupt sources, that maybe somehow I was receiving another while the first was being serviced, but that can't happen unless I reenable GIE, right? I really wish that I had kept the "freaky" code, as it was quite perplexing, but I have run so many things thru my feeble mind since then that I can't recall the exact specifics of it. I honestly spent quite some time scratching my head (not that unusual ;-) and using the scope to monitor things before resorting to trying the nop thing. It's just that as the project developed, I completely changed the way that everything worked. It was when I was doing early fiddling with the I/R remote control stuff. Since the capture was new to me, I was doing analysis to make sure that the ISR would stay synched to the data and decode it correctly. I could press a button and sometimes get the correct info, but often it would decode it incorrectly. By just adding a single nop, it would work perfectly every time. The main level was in a really tight loop looking at a RAM variable, waiting for it to become non-zero by the ISR filling it in. It would then print it to an LCD, and then clear the RAM location, and go back into the tight loop. I thought that maybe jitter in entering the ISR was somehow affecting things, but that seems very unlikely as the scope showed that bit sampling was occuring on the trailing edge of the pulses. Sometimes, I really wish I could afford a logic analyzer and an ICE debugger. :-( But on the machines I've coded on in the past, I never had the luxury of even a simulator. BTW, it all works flawlessly now and has been running for several days without any hint of a problem. Believe me, I hated to move on without completely solving the mystery, as I well know how these things can come back to haunt you. When I get some time, I will try and duplicate the scenario. Who knows, maybe I found something akin to the famous GIE bit flicking issue, but then again probably not. When Justin posted his similar symptom, I was compelled to report my experience as it seemed quite coincidental. I certainly didn't figure that he wasn't saving any of his context. :-/ michael brown "In the land of the blind, he who has one eye is king" -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

> I was using a 16F628 so everyting was on one code page. ISR was saving > W, STATUS, FSR and PCLATH for good measure. Is there anything else that > could potentially get me? Any other state that is shared between the interrupt and foreground code. > Without the ISR running, the foreground code wouldn't do anything but > loop, as it was waiting for the ISR to fill in a RAM location. And > since the ISR was hit repeatedly so quickly by an external interrupt, it > would have been impossible to simulate with what I have available. The simulator allows you to define how an external pin is wiggled over time in a file. This might be useable to simulate your external interrupt. > I > even thought that since I had two interrupt sources, that maybe somehow > I was receiving another while the first was being serviced, but that > can't happen unless I reenable GIE, right? Right. > It would then print it to an LCD, and then > clear the RAM location, and go back into the tight loop. Was it possible to lose an interrupt by not clearing the RAM location fast enough? ***************************************************************** 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: >> I was using a 16F628 so everyting was on one code page. ISR was >> saving W, STATUS, FSR and PCLATH for good measure. Is there >> anything else that could potentially get me? > > Any other state that is shared between the interrupt and foreground > code. I take that as a no then, in the context of SFR's. >> Without the ISR running, the foreground code wouldn't do anything but >> loop, as it was waiting for the ISR to fill in a RAM location. And >> since the ISR was hit repeatedly so quickly by an external >> interrupt, it would have been impossible to simulate with what I >> have available. > > The simulator allows you to define how an external pin is wiggled over > time in a file. This might be useable to simulate your external > interrupt. I'll look into that. {Quote hidden}>> I >> even thought that since I had two interrupt sources, that maybe >> somehow I was receiving another while the first was being serviced, >> but that can't happen unless I reenable GIE, right? > > Right. > >> It would then print it to an LCD, and then >> clear the RAM location, and go back into the tight loop. > > Was it possible to lose an interrupt by not clearing the RAM location > fast enough? AFAIK, no. If another pulse stream came in while I was writing to the LCD (which happens with the Sony type protocol of sending three bursts of the same data in rapid succession), it would simply overlay the RAM location once the entire burst was processed. The timer interrupt was there to tell me that no data had arrived for a while, and for me to re-init my capture field and bits received counter. Give me some time, and I will try to duplicate the issue as you've really got me thinking about this again. I'm highly inclined to believe that I missed something obscure, as I know better than to blame a CPU for odd behavior, no matter how odd. It's just that with knowledge of the prior GIE issue and some of the other documented issues, I was a tad more inclined to chalk it up to some obscure problem with the CPU and int handling when using the capture module and to let it slide. Again, this is not my normal practice. I'm a bit to obsessive/compulsive to brush things like that off. ;-) michael brown "In the land of the blind, he who has one eye is king" -- 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: > > > A (possibly!) good habit for beginners is to force > > locate different chunks of your code on different > > pages by using orgs, > > Yuk! > > I think a much better habit is to define each page as a separate linker > section. If you do that, the linker will automatically fit modules in > pages appropriately while guaranteeing that no module crosses a page > boundary. Ha ha! I knew "Mr Linker" would have a go at that suggestion. Trouble is, whether you or I agree that the linker is the superior way, beginners *will* keep using snippets of code text they got from the internet and just paste it all in a line. My suggestion of forcing code pieces into particular memory at least is a start to getting them to think- where this routine goes, where that table goes, do I have to check PCLATH, hey I can see how much rom is left in each page in the absolute listing etc. -Roman -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

Olin, >It would be helpful if you formatted >your code to use shorter line >lengths, at least when posting it to Point Taken. Will format/modify the pasted code. Do I get points for comments? I have spent much time changing the format of my assembler code. I decided on tab space of 5. So Opcode should be at 10 and operands at 20. I find it difficult to read if the opcodes dont start after the labels finish. When pasted outlook changed it to spaces of 8 for each tab. It prints well when using 80cols per line. Justin -----Original Message----- From: Olin Lathrop [EraseMEolin_piclistspamspamBeGoneEMBEDINC.COM] Sent: Wednesday, 26 February 2003 9:00 PM To: RemoveMEPICLISTKILLspamMITVMA.MIT.EDU Subject: Re: [PIC]: 16f628 BTFSS & BTFSC curiosity Richards, Justin P wrote: > These snippets are located in the first 60 odd bytes of code. > ... <snip> -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

On Thu, 27 Feb 2003, Richards, Justin P wrote: > Olin, > >It would be helpful if you formatted > >your code to use shorter line > >lengths, at least when posting it to > > Point Taken. Will format/modify the pasted code. Do I get points for > comments? Yes, as you will also for turning on line wrap at something short of column 80 in your email messages. 8-) >I have spent much time changing the format of my assembler > code. I decided on tab space of 5. One word of advice: When sending code from Point A to Point B, don't use tab characters. Most editors have the ability to fill tabs with spaces, and since lots of people will NOT be using 5 character tabs (I use 4, some people use more, some less) your code will line up properly. With tabs it's almost guaranteed to look pretty ugly when someone else views it. Dale -- It's a thankless job, but I've got a lot of Karma to burn off. -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

> Point Taken. Will format/modify the pasted code. Do I get points for > comments? Yes, although I can't comment on the quality since it was too much of a mess to read. > I have spent much time changing the format of my assembler > code. I decided on tab space of 5. There's the problem. DON'T USE TABS!! It's fine to use a "tab" key when entering code, as long as all horizontal spacing gets converted to hard spaces in the file. > So Opcode should be at 10 and operands at 20. I went thru this too when I started with PIC assembler. I wanted things spaced to be easy to see th labels, opcodes, operands, and comments in different columns, but still leave room for decent comments without making the lines too wide. I finally settled on labels in column 1 (required by the assembler), opcodes in column 10, operands at 18, and comments at 30. Every last bit of source code at http://www.embedinc.com/pic adheres to this convention. > I find it difficult to read if the opcodes dont start > after the labels finish. Labels should never be followed by an instruction mnemonic on the same line anyway, so long labels overflowing into the opcode field isn't a bit deal. > When pasted outlook changed it to spaces of 8 > for each tab. Again, that's because your file contained tab characters, which leaves the interpretation uncertain. That's why you don't do that. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.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

Olin Lathrop <spamBeGonePICLISTSTOPspamEraseMEmitvma.mit.edu> wrote: > > However how do I do the line wrap thing in MS Outlook 2000 or do I > > just use the <CR> key. > > Don't use CR, that inserts a hard line break. In OE anyway, you go to > TOOLS > OPTIONS > SEND > PLAIN TEXT SETTINGS and set the line length. > You can chose anything you want, although 72-80 are the only correct > choices <g>. Olin: Is there a setting in OE that adds the universally-standard "name <KILLspamuserspamBeGonedomain.com> wrote:" header to text quoted in replies? If so, please turn it on; I can never tell to whom you're replying. -Andy === Andrew Warren -- EraseMEaiwEraseMEcypress.com === Principal Design Engineer === Cypress Semiconductor Corporation === === Opinions expressed above do not === necessarily represent those of === Cypress Semiconductor Corporation -- 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

Andrew Warren wrote: > Is there a setting in OE that adds the universally-standard "name > <@spam@user@spam@spam_OUTdomain.com> wrote:" header to text quoted in replies? If so, > please turn it on; I can never tell to whom you're replying. This line is seeded in the reply window, as above. However, there is enough crap abvoe and below it to make trimming it in a hassle. I usually do it only when it is relevant whom I'm replying to. Most of the time this isn't relevant (like this example, although I included it since you specifically asked. I don't see whom I'm replying to with this message as making any difference to someone reading the reply). I do try to include enough of the original post to provide context, and otherwise trim as much as possible. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.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

At 06:24 PM 2/28/03 +1000, Richards, Justin P wrote: >-----Original Message----- >From: Paul Hutchinson [TakeThisOuTpaulKILLspamspamPAULHUTCH.COM] > >In OL2000, "Tools-Options", "Mail Format" tab, "Settings" button. > >I don't seem to have this setting but under Mail Format I could set it to >plain text rather than Rich Text. So how does this line look. Seems fine. There should be a "wrap line at XX characters" field somewhere - set that number somewhere around 72 characters, less if you plan to engage in long debates with many levels of quoting. I've seen some people recommend as low as 68 chars. dwayne -- Dwayne Reid <.....dwaynerRemoveMEplanet.eon.net> Trinity Electronics Systems Ltd Edmonton, AB, CANADA (780) 489-3199 voice (780) 487-6397 fax Celebrating 19 years of Engineering Innovation (1984 - 2003) .-. .-. .-. .-. .-. .-. .-. .-. .-. .- `-' `-' `-' `-' `-' `-' `-' `-' `-' Do NOT send unsolicited commercial email to this email address. This message neither grants consent to receive unsolicited commercial email nor is intended to solicit commercial email. -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

I just checked another PC in the office and it does not have the "Settings" button in OL2000. The other PC is setup for an Exchange server instead of Internet mail so, I guess the wrap length is another one of the settings that is only available when you setup OL2000 for Internet mail instead of Exchange Server. The Exchange server administrator can probably change the settings for you at the server. Paul > -----Original Message----- > [RemoveMEPICLISTspamBeGoneMITVMA.MIT.EDU]On Behalf Of Richards, Justin P > Sent: Friday, February 28, 2003 3:24 AM > > I don't seem to have this setting but under Mail Format I could > set it to plain text rather than Rich Text. So how does this line look. > > Regards Justin -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.