Post by thread:[PIC] 16F684 & Interrupt Problems

Exact match. Not showing close matches.
PICList Thread
'[PIC] 16F684 & Interrupt Problems'
2005\09\13@065004 by Sean Schouten

part 1 794 bytes content-type:text/plain; charset=WINDOWS-1252 (decoded base64) Hey guys, I can't seem to get interrupts working on my 16F684. This would be the first time that I try to use interrupts, and I have compiled a small and simple piece of code to get started with them. I have attached the ASM-file to this e-mail. I think that the problem is down to me doing something absurdly wrong in my assembler code, although I have no clue to as what it possibly could be. I first suspected it having something to do with me trying to have a button connected to RA3 trigger an interrupt whilst utilizing other RA-ports to flash a couple of LEDs. I proceeded to only flash LEDs on PORTA in the Interrupt Service Routine; but they just never flashed� I don't think that me pushing the button generated an interrupt! HELP! part 2 5256 bytes content-type:application/octet-stream; name="test.asm" (decode) part 3 35 bytes content-type:text/plain; charset="us-ascii" (decoded 7bit)

2005\09\13@070858 by Jan-Erik Soderholm

Sean Schouten wrote : > I think that the problem is down to me doing something > absurdly wrong in my assembler code,... I think so to. >From "START" You *CALL* a sub called INITIALIZE, but you use GOTO instead of RETURN to get back from the sub... And from MAIN you *CALL* another sub called "FLASHLED", but you never RETURN from it, so your code will just run on into "START" from the sub... And from another point in your code you GOTO FLASHLED. There I stopped reading... :-) For some reason, your DELAY1S sub uses RETURN, so you seems to at least know about it... Jan-Erik.

2005\09\13@073256 by Jinx

> > I think that the problem is down to me doing something > > absurdly wrong in my assembler code,... What Jan-Erik said and..... Do you use tabs ? The alignment is all over the place, not reader-friendly with Notepad BCF STATUS, RP0 ; Return to BANK 0 probably works 99.9999% of the time but better to use BANKSEL

2005\09\13@074738 by Michael Rigby-Jones

{Quote hidden}>-----Original Message----- >From: spam_OUTpiclist-bouncesTakeThisOuTmit.edu [.....piclist-bouncesKILLspam@spam@mit.edu] >Sent: 13 September 2005 12:09 >To: piclistKILLspammit.edu >Subject: RE: [PIC] 16F684 & Interrupt Problems > > >Sean Schouten wrote : > >> I think that the problem is down to me doing something >> absurdly wrong in my assembler code,... > >I think so to. > >>From "START" You *CALL* a sub called INITIALIZE, but you >use GOTO instead of RETURN to get back from the sub... > >And from MAIN you *CALL* another sub called "FLASHLED", >but you never RETURN from it, so your code will >just run on into "START" from the sub... > >And from another point in your code you GOTO FLASHLED. > >There I stopped reading... :-) OK, a few more things to add to the list. Firtsly, there is absolutely no bank switching in the code, so the device is clearly not being initialised correctly. You need to understand how to use the banking architecture before moving onto more advanced functions such as interrupts. Secondly to enable the PORTA interrupt on change, the IOCA register firstly needs to be configured. At power up, all port change interrupts are disabled. Thirdly, the interrupt handler does not have a very functional context save/restore. The datasheet shows exactly how this should be done in the "Conext saving during interrupts" section (12.5). Also why are you saving/restoring TMR0 and PORTA and PORTC in the interrupt handler? There appears to be no reason to do this. Regards Mike ======================================================================= This e-mail is intended for the person it is addressed to only. The information contained in it may be confidential and/or protected by law. If you are not the intended recipient of this message, you must not make any use of this information, or copy or show it to any person. Please contact us immediately to tell us that you have received this e-mail, and return the original to us. Any use, forwarding, printing or copying of this message is strictly prohibited. No part of this message can be considered a request for goods or services. =======================================================================

2005\09\13@084134 by Howard Winter

Sean, On Tue, 13 Sep 2005 12:50:03 +0200, Sean Schouten wrote: >...< > I think that the problem is down to me doing something absurdly wrong in my > assembler code Indeed - several "somethings" ! :-) > although I have no clue to as what it possibly could be. Well the flow of your program has so many errors that it's too early to debug the Interrupt part. You need to look at the whole program flow (perhaps draw it out in some sort of diagram) and get that sorted out first, for example: CALLed routines with a GOTO at the end (eg. INITIALIZE) CALLed routines with nothing at the end (eg. FLASHLED) Orphaned routines (eg. FLASHLEDLOOP - far from being a "permanent loop", it can never be executed) And the thing that still puzzles me: you seem to be using the Timer 0 special function register (TMR0) as if it was an ordinary memory location, doing your own count-down timer in a loop. This can't be right - either use the hardware timer, or if you are going to do it yourself, use a general purpose register to do the counting-down. You are also saving and reloading TMR0 in your ISR, which seems a strange thing to do, since normally it would be a free-running counter, and what you are doing would confuse things terribly if you were actually using Timer 0. In the ISR your save and restore code needs looking with regard to status changes resulting from saving/restoring other registers (clue: look at the way others do it, using SWAPF) > I first suspected it having something to do with me trying to have a button > connected to RA3 trigger an interrupt whilst utilizing other RA-ports to > flash a couple of LEDs. (Terminology point: "Port" is a collection of pins associated with a data and a control register - you mean "other RA-pins" above, I think). > I proceeded to only flash LEDs on PORTA in the > Interrupt Service Routine; but they just never flashedà I don't think that > me pushing the button generated an interrupt! You aren't flashing the LED in the ISR in the version you posted. It's not obvious to me what you are doing to get an interrupt triggered - it looks like you're expecting an "interrupt on change", but you are changing the port yourself by flashing the LED - I don't know if this would work, but it sounds really dodgy! You are also setting one pin to analog mode - you don't say why, and I'm not sure what effect that will have on "interrupt on change" but it looks an odd thing to do. Incidentally, your "BANK 0:" definition was appended to the comment line before it, but that may have happened in transit - but check it anyway! Your commenting shows all the hallmarks of someone who is new to programming: You start out well, with plenty of headings and descriptions of what the language itself is doing (nothing wrong with that) but you don't explain the meaning of what *you* are doing, for example: ; Supress the inferior 302-error! would be much better if you said what the 302 error was, rather than you and anyone reading it having to look it up! Your comments sometimes don't match what the code is doing (which should be a hanging offence :-) for example: ; Make RC0 & RC 3 inputs. MOVLW 0x09 MOVWF TRISA A no-comment example later on, your delay routine: DELAY1S CLRF TMR0 LOOPY MOVF TMR0, W SUBLW 0x0F BTFSS STATUS, Z GOTO LOOPY RETURN I had to work out what repeatedly subtracting 0x0F starting from zero would do - it turns out it gives 3840 loops before giving a zero result - you should explain that (because nobody else knows that and you won't remember it in future either). BUT! You aren't actually doing that at all - you are reloading the same value on each loop, so 0x00 - 0x0F will give the same result every time which will never be zero... you're stuck there! Cheers, Howard Winter St.Albans, England

2005\09\13@121147 by Thomas C. Sefranek

You seem to be calling Initialize and not returning from it, The end seems to be a GOTO not a return. Your code is not well commented or threaded. Tom * | __O Thomas C. Sefranek .....tcsKILLspam.....cmcorp.com |_-\<,_ Amateur Radio Operator: WA1RHP (*)/ (*) Bicycle mobile on 145.41MHz PL74.4 ARRL Instructor, Technical Specialist, VE Contact. hamradio.cmcorp.com/inventory/Inventory.html http://www.harvardrepeater.org {Original Message removed}

2005\09\13@160434 by Sean Schouten

On 9/13/05, Jan-Erik Soderholm <EraseMEjan-erik.soderholmspam_OUTTakeThisOuTtelia.com> wrote: >From "START" You *CALL* a sub called INITIALIZE, but you > use GOTO instead of RETURN to get back from the sub... That should not matter. And the goto is pointing at the main program loop; I don't see my self calling an initialization sub every time the main loop loops... And from MAIN you *CALL* another sub called "FLASHLED", > but you never RETURN from it, so your code will > just run on into "START" from the sub... That was a mistake; I missed that entirely.... Fixing it still doesn't help me, because the interrupts didn't work even before that sub was in place. And from another point in your code you GOTO FLASHLED. > > There I stopped reading... :-) Ah, that is because the "FLASHLEDLOOP" used to be called "FLASHLED" and it was an endless loop. That's why I decided to rename it. I was still in the process of cleaning that all up, and it was sloppy of me to send in that source file; I should of sent in something a little cleaner. Sorry about that.

2005\09\13@162250 by Sean Schouten

On 9/13/05, Michael Rigby-Jones <Michael.Rigby-Jonesspam_OUTbookham.com> wrote: > > > > Firtstly, there is absolutely no bank switching in the code, so the device > is clearly not being initialised correctly. You need to understand how to > use the banking architecture before moving onto more advanced functions such > as interrupts. Ehm, there is definately some bank selecting going on in there... Check my INITIALIZE routine! Secondly to enable the PORTA interrupt on change, the IOCA register firstly > needs to be configured. At power up, all port change interrupts are > disabled. IOCA register? You might just be a life saver. Let me try this and see if it works. I think you might just of hit the nail on the head! :-) Thirdly, the interrupt handler does not have a very functional context > save/restore. The datasheet shows exactly how this should be done in the > "Conext saving during interrupts" section (12.5). Also why are you > saving/restoring TMR0 and PORTA and PORTC in the interrupt handler? There > appears to be no reason to do this. To tell you the truth: there is no reason to do so. I was doing so because I figured that if an interrupt would come and disturb some routine functioning, when the interrupt drops me back into that routine at the place we left it, I would be able to restore the original port state as well. The more I think about doing the same with TMR0, the less sence it makes to me. That is going for sure! Thanks... :-) Sean.

2005\09\13@164647 by Jan-Erik Soderholm

Sean Schouten wrote : > On 9/13/05, Jan-Erik Soderholm <@spam@jan-erik.soderholmKILLspamtelia.com> wrote: > > >From "START" You *CALL* a sub called INITIALIZE, but you > > use GOTO instead of RETURN to get back from the sub... > > > That should not matter. And the goto is pointing at the main > program loop; I don't see my self calling an initialization > sub every time the main loop loops... I must be missing someting here... I just can't figure out if you're joking or not... Best Regards, Jan-Erik.

2005\09\13@170432 by Sean Schouten

On 9/13/05, Howard Winter <KILLspamHDRWKILLspamh2org.demon.co.uk> wrote: > > Sean, > > On Tue, 13 Sep 2005 12:50:03 +0200, Sean Schouten wrote: > > >...< > > I think that the problem is down to me doing something absurdly wrong in > my > > assembler code > > Indeed - several "somethings" ! :-) Nooooooo! Don't blame the newbie for having to learn the ropes! > although I have no clue to as what it possibly could be. > > Well the flow of your program has so many errors that it's too early to > debug the Interrupt part. You need to > look at the whole program flow (perhaps draw it out in some sort of > diagram) and get that sorted out first I shall re-submit a "clean-er" version, taking in concideration all the comments made in conjuction with the messy sandwich I submitted earlyer today! > CALLed routines with a GOTO at the end (eg. INITIALIZE) Why is that such a bad thing other than it screwing the mind of whomever is trying to read through what they think is a "normal" program flow? And the thing that still puzzles me: you seem to be using the Timer 0 {Quote hidden}> special function register (TMR0) as if > it was an ordinary memory location, doing your own count-down timer in a > loop. This can't be right - either > use the hardware timer, or if you are going to do it yourself, use a > general purpose register to do the > counting-down. You are also saving and reloading TMR0 in your ISR, which > seems a strange thing to do, since > normally it would be a free-running counter, and what you are doing would > confuse things terribly if you were > actually using Timer 0. Believe it or not; I copied that 1 on 1 out of a pic-programming book called "PIC in practice", which I might note is regarded quite highly by whomever write reviews about it on Amazon.com <http://Amazon.com>, which would also explain the reason I bought it in the first place. By the way (about the countdownloop with TMR0); Don't I need to be able to use interrupts if I want to use TMR0 like it is supposed to be used (overflow...)??? In the ISR your save and restore code needs looking with regard to status > changes resulting from > saving/restoring other registers (clue: look at the way others do it, > using SWAPF) I shall do so! > I first suspected it having something to do with me trying to have a > button > > connected to RA3 trigger an interrupt whilst utilizing other RA-ports to > > flash a couple of LEDs. > > (Terminology point: "Port" is a collection of pins associated with a data > and a control register - you mean > "other RA-pins" above, I think). sorry! I was thinking network 'ports' eg port 80 ... My bad. > I proceeded to only flash LEDs on PORTA in the > > Interrupt Service Routine; but they just never flashedà I don't think > that > > me pushing the button generated an interrupt! > > You aren't flashing the LED in the ISR in the version you posted. Yeah, I was kind of in the middle of trying something else when I posted this code. I must admit that it's funny to read some of the remarks I get about this sloppy code of mine. Oh well... it's all in the name of improvement! And if I ever feel down, remind me to post more sloppy code because this is just fantastic! :-D It's not obvious to me what you are doing to get an interrupt triggered - it > looks like you're expecting an > "interrupt on change", but you are changing the port yourself by flashing > the LED - I don't know if this would > work, but it sounds really dodgy! You are also setting one pin to analog > mode - you don't say why, and I'm > not sure what effect that will have on "interrupt on change" but it looks > an odd thing to do. Ah, that is because there is a potmeter connected to that port and I was planning to work with that and the A/D converter after I manage to get interrupts going.The Pic is on my PicKit1. Oh, I wasn't too sure about changing the port by flashing the led with the "interrupt on change" thingy. But I figured that there is a way around that... I suspect IOCA? Incidentally, your "BANK 0:" definition was appended to the comment line > before it, but that may have happened > in transit - but check it anyway! > > Your commenting shows all the hallmarks of someone who is new to > programming: Your reading me like a book. Oh, that 302 error was bugging the hell out of me; I only felt satisfied after I called it inferrior. Your comments sometimes don't match what the code is doing (which should be {Quote hidden}> a hanging offence :-) for example: > ; Make RC0 & RC 3 inputs. > MOVLW 0x09 > MOVWF TRISA > > A no-comment example later on, your delay routine: > > DELAY1S > CLRF TMR0 > LOOPY > MOVF TMR0, W > SUBLW 0x0F > BTFSS STATUS, Z > GOTO LOOPY > RETURN > > I had to work out what repeatedly subtracting 0x0F starting from zero > would do - it turns out it gives 3840 > loops before giving a zero result - you should explain that (because > nobody else knows that and you won't > remember it in future either). BUT! You aren't actually doing that at all > - you are reloading the same value > on each loop, so 0x00 - 0x0F will give the same result every time which > will never be zero... you're stuck > there! > Okay, commenting either needs some working on. I think that I changed that value in the first example without 'updating' the commenting. Again real sloppy. The second example (delay) does not get stuck in the loop because of me reloading the same value into the timer over and over again. I am guessing that the propper way would be to write a value to TMR0 and wait for it to overflow? How would I go about sensing the overflow without using interrupts? Thanks, Sean.

2005\09\13@170652 by Sean Schouten

On 9/13/05, Jan-Erik Soderholm <RemoveMEjan-erik.soderholmTakeThisOuTtelia.com> wrote: > > > I must be missing someting here... > > I just can't figure out if you're joking or not... No, I am dead serious. Why should it matter? Maybe because whomever is reading through the code would expect to find a some what 'normal' program flow and finds snake-like code? Sean.

2005\09\13@171002 by Jinx

>From "START" You *CALL* a sub called INITIALIZE, but you > use GOTO instead of RETURN to get back from the sub... That should not matter You have code that doesn't work as expected. Everything matters

2005\09\13@171557 by Jan-Erik Soderholm

Sean Schouten wrote : > On 9/13/05, Jan-Erik Soderholm <spamBeGonejan-erik.soderholmspamBeGonetelia.com> wrote: > > > > > > I must be missing someting here... > > > > I just can't figure out if you're joking or not... > > > No, I am dead serious... OK, then you have problems with programming in general, not only with PIC-programming... > Why should it matter? Why ask when you have the right anser yourself ? : > Well, Maybe because whomever is reading through the > code would expect to find a some what 'normal' program > flow and finds snake-like code? Yes, absolutely correct ! Jan-Erik.

2005\09\13@172649 by Jinx

> > CALLed routines with a GOTO at the end (eg. INITIALIZE) > Why is that such a bad thing other than it screwing the mind of > whomever is trying to read through what they think is a "normal" > program flow? For one thing, it unnecessarily leaves a return address on the stack. Why not just GOTO the routine and return with a GOTO ? What is "abnormal" about a RETURN resolving a CALL ? If you know what you're doing you can play around with the stack on some micros > Don't I need to be able to use interrupts if I want to use TMR0 > like it is supposed to be used (overflow...) ??? Interrupts are not essential, but it really depends on your application. When any timer rolls over, its IF gets set, which you can poll for, eg BTFSS INTCON,T0IF. Only if T0IE (and GIE) is set will an IRQ be generated. Consider an interrupt as a forced CALL to the ISR. If you don't need to respond immediately to an event, polling is quite acceptable. You have to understand the environment your code is expected to work in though to make that choice

2005\09\13@173845 by Paul James E.

In looking over your code, I believe I hear you say you are trying to use RA3 as the interrupt source (Interrupt-on-change). Is this correct? If it is, you'll never get an interrupt because PORTA doesn't have interrupt on change. PORTB does. PORTA does have the input for the TMR0, and that will cause an interrupt when the counter rolls over from FF to 00, but PORTA will not generate an interrupt on change. If I'm wrong about this, someone correct me. I haven't used this part. I'm just going on experience with other parts, and what's in the datasheet. Let us know when you figure it out. Good luck. Regards, Jim {Quote hidden}> Hey guys, > > I can't seem to get interrupts working on my 16F684. This would be the > > first time that I try to use interrupts, and I have compiled a small > and simple piece of code to get started with them. I have attached the > ASM-file to this e-mail. > > I think that the problem is down to me doing something absurdly wrong > in my > assembler code, although I have no clue to as what it possibly could > be. I first suspected it having something to do with me trying to have > a button connected to RA3 trigger an interrupt whilst utilizing other > RA-ports to flash a couple of LEDs. I proceeded to only flash LEDs on > PORTA in the Interrupt Service Routine; but they just never flashed… I > don't think that me pushing the button generated an interrupt! > > HELP!

2005\09\13@174447 by olin piclist

Jinx wrote: >> Why is that such a bad thing other than it screwing the mind of >> whomever is trying to read through what they think is a "normal" >> program flow? I never saw your original code, but documentation is important. Don't use cutesy unusual constructs unless there is a good reason for them, and if you do they need to be documented extra carefully. > For one thing, it unnecessarily leaves a return address on the stack. > Why not just GOTO the routine and return with a GOTO ? Why not just put the routine in line? If he's jumping to a specific spot, then jumping back to a fixed spot, he might as well put the code there in the first place. > If you know what you're doing you can play around with the stack > on some micros Jinx is right. There are rare times when you might want to perform unnatural acts on the stack, but you have to know what you're doing. You've got a long way to go before that. In the mean time you should make it as easy as possible for those you are asking a favor of to help you. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com

2005\09\13@174805 by olin piclist

Paul James E. wrote: > In looking over your code, I believe I hear you say you are trying > to use RA3 as the interrupt source (Interrupt-on-change). Is this > correct? If it is, you'll never get an interrupt because PORTA > doesn't have interrupt on change. Yes it does. See page 33 of DS41202C. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com

2005\09\13@180958 by Paul James E.

Never mind. I was looking at the 16F648. Not the 684. Sorry. Regards, Jim {Quote hidden}> Paul James E. wrote: >> In looking over your code, I believe I hear you say you are trying to >> use RA3 as the interrupt source (Interrupt-on-change). Is this >> correct? If it is, you'll never get an interrupt because PORTA >> doesn't have interrupt on change. > > Yes it does. See page 33 of DS41202C. > > ***************************************************************** > Embed Inc, embedded system specialists in Littleton Massachusetts > (978) 742-9014, http://www.embedinc.com > --

2005\09\13@184805 by Sean Schouten

part 1 1133 bytes content-type:text/plain; charset=ISO-8859-1 (decoded quoted-printable) ...And I'm back. I did some cleaning and re-touching her and there. I my self think that it looks much cleaner and the comments are plentyfull. I still have to find the optimal commenting style for my self; no worries though... Okay; My main loop now boasts a NOP (whoa!), basically doing nothing (oooooooh!)... In my INITIALIZE routine I have done the following: [code] ; Interrupt Configuration BSF INTCON, GIE ; Set the General Interrupt Enable bit to 1. BCF INTCON, RAIF ; Clear the PORTA interrupt flag. BSF INTCON, RAIE ; Enable PORTA change interrupt. BSF IOCA, IOCA3 ; Enable interrupt-on-change on RA3. [/code] Now, does this mean that when I hit the button attached to RA3, the pic should jump right to mem-location 0x04 and from there run my Interrupt Service Routine? I once again attached my ASM-file to this mail -this time a clean(er) version-. If any-one has any other tips, comments or whatever; I'm ready for em (I think)! Thanks once again, Sean. P.S. Start cheering, my INITIALIZE now boasts a RETURN! If you don't believe me, feel free to take a look! part 2 6029 bytes content-type:application/octet-stream; name="test_piclist.asm" (decode) part 3 35 bytes content-type:text/plain; charset="us-ascii" (decoded 7bit)

2005\09\13@192347 by olin piclist

Sean Schouten wrote: > TEMP_W EQU H'0020' ;Place to dump W-Register in case of interrupt. > TEMP_STATUS EQU H'0021' ;Place to dump STATUS-Register data in case of interrupt. Bad idea to put variables at hard coded addresses. This will get you into trouble when moving code from PIC to PIC. Also if TEMP_W is supposed to be where W gets saved on interrupt, this will not work on PICs that have more than one bank. > ORG 0x00 Absolute mode is for bacwards compatibility with old crufty code. It should not be used for new code. Now is the right time to learn to use the linker and relocatable code, before you accumulate an existing code base. And no, I don't want to hear how you want to do just this one example in absolute mode, then you'll switch. What will happen is there will be a minor tweak on this one, then a little more, then a new project you want to get into and not spend the time, etc, etc. It's like drugs. When it comes to absolute mode, JUST SAY NO! > GOTO START ;Standard Operation This may work on your particular PIC, but will fail on a PIC with more than one code page where START ended up not on page 0. Get in the habit of thinking about PCLATH now. > ORG 0x04 > GOTO ISR ;The Interrupt Service Routine (Called in case of an Interrupt) First, this won't work on PICs with more than one code page. Second, it's silly to put the ISR elsewhere anyway. Something will end up here, and it might as well be the interrupt service routine. > INITIALIZE > BSF STATUS, RP0 ;Go to BANK 1 Only on PICs with two banks. Otherwise this goes to bank 1 or bank 3. Manual bank setting is a bad idea, especially when the state of some bank bits is assumed. You insert new code above here and something below breaks. Beginners can use BANKSEL. Once you're comfortable with that, I can show you more sophisticated ways of setting the bank. > ; Set OSC to 31kHz > MOVLW 0x03 > MOVWF OSCCON Doesn't this do more than just select the oscillator frequency? > ; Set prescaler to devide clock by 256 > MOVLW 0x07 > MOVWF OPTION_REG Same here. I'm pretty sure the option register controls more than just a prescaler. > BSF INTCON, GIE ;Set the General Interrupt Enable bit to 1. > BCF INTCON, RAIF ;Clear the PORTA interrupt flag. This is out of order. Turning on GIE is the last thing you should do in the interrupt setup. > ISR > ; First things first (I have my reason) That is a totally useless and unprofessional comment. > BCF STATUS, RP0 ;Go to BANK 0 Very bad. You just trashed the bank setting on the foreground code. > ; Backup the STATUS-Register But you already trashed it above. > ;### Begin ISR code: ### > ; Turn LED on and keep it in that state for 5 whole seconds. > BSF PORTA, 1 ;Turn LED on. > CALL DELAY1S ;Delay for 1 second. > CALL DELAY1S ;Delay for 1 second. > CALL DELAY1S ;Delay for 1 second. > CALL DELAY1S ;Delay for 1 second. > CALL DELAY1S ;Delay for 1 second. This will take the processor completely out to lunch for the whole 5 seconds. It's a bad idea to put delays, especially long ones, in the interrupt routine. There may be some specialized structures where this makes sense, but that is something you should only do after being completely familiar with the machine and the reasons for doing so. Also, you don't turn off the LED after waiting the 5 seconds. There's undoubtedly more below, but I've had enough for now. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com

2005\09\13@193607 by Jinx

> Now, does this mean that when I hit the button attached to RA3, the pic > should jump right to mem-location 0x04 and from there run my Interrupt > Service Routine? Is the button changing the level on RA3 ? IOW, is the button connecting RA3 to Vdd or, what is implied next, grounding a pull-up ? The /RAPU bit is cleared, which enables internal RA pull-ups ; Set prescaler to devide clock by 256 MOVLW 0x07 MOVWF OPTION_REG movlw b'00000111' ; 0 enable RA pull-ups ; 111 PS2,1,0 TMR0 pre-scaler = 256 movwf option_reg You could also use Boolean bit-setting by name I still suggest you use BANKSEL to change bank eg BANKSEL CMCON0 CLRF CMCON0 ; Clear CMCON0 The instruction obviously does clear CMCON0. A more useful comment would explain why it is cleared

2005\09\13@195416 by Peter van Hoof

> SUBLW 0x0F ; Subtract 0x0F from the value of TMR0 Actually this does subtract the value of tmr0 from 0x0f , does not seem logical but it's true. Peter van Hoof

2005\09\13@201658 by Jinx

> > SUBLW 0x0F ; Subtract 0x0F from the value of TMR0 > > Actually this does subtract the value of tmr0 from 0x0f , does not > seem logical but it's true You have a keen eye Peter movlw 0x0f subwf tmr0,w

2005\09\13@201834 by Dmitriy Kiryashov

Hi Peter. Still makes sense. <sublw k> value is {less or equal || greater} than k <addlw -k> value is {greater or equal || less} than k What command you think pic16 micros are missing and better be implemented insetad of sublw ? :) WBR Dmitry. Peter van Hoof wrote: > > > SUBLW 0x0F ; Subtract 0x0F from the value of TMR0 > > Actually this does subtract the value of tmr0 from 0x0f , > does not seem logical but it's true.

2005\09\13@205721 by Dmitriy Kiryashov

> Your comments sometimes don't match what the code is doing (which should be > > a hanging offence :-) for example: > > ; Make RC0 & RC 3 inputs. > > MOVLW 0x09 > > MOVWF TRISA > > > > A no-comment example later on, your delay routine: > > > > DELAY1S > > CLRF TMR0 > > LOOPY > > MOVF TMR0, W > > SUBLW 0x0F > > BTFSS STATUS, Z > > GOTO LOOPY > > RETURN Jinx wrote: > > movlw 0x0f > subwf tmr0,w Even with this fix still no good... What is going to happen if for some reason ( interrupts ? temporary malfunction etc.. TMR0 will change from 0x0E right to 0x10 ? Loop would not stop until next TMR0 iteration. I would rewrite it with using carry ( which is still not reliable because of 0xFF to 0x00 crossing went undetected ) as decision or better with T0IF flag. ; general initializing ; initializing TMR0 pre-scaler ; disabling TMR0 interrupt ; ..... DELAY1S movlw -const movwf TMR0 bcf INTCON,T0IF btfss INTCON,T0IF goto $-1 ; .....

2005\09\13@212207 by Peter van Hoof

Sean, I think I have found it, {Quote hidden}> BCF STATUS, RP0 ; Return to BANK 0 > > ; Turn off comparators > CLRF CMCON0 ; Clear CMCON0 > > ; Clear Ports 'n Timers > CLRF PORTA > CLRF PORTC > CLRF TMR0 > > ; Interrupt Configuration > BSF INTCON, GIE ; Set the General Interrupt Enable bit to 1>. > > BCF INTCON, RAIF ; Clear the PORTA interrupt flag. > BSF INTCON, RAIE ; Enable PORTA change interrupt. > BSF IOCA, IOCA3 ; Enable interrupt-on-change on RA3. IOCA is in bank 1 not bank 0 we are tinkering with now! There might be other problems but this is likely to cause grief Peter van Hoof

2005\09\13@212806 by Jinx

> 0x00 crossing went undetected ) as decision or better with T0IF flag. > > DELAY1S > movlw -const > movwf TMR0 > bcf INTCON,T0IF > > btfss INTCON,T0IF > goto $-1 That would be my preferred way too Dmitriy. I did mention to Sean that T0IF could be polled. It has the advantage of the rollover being recorded if the code is busy elsewhere at the time of the rollover. In Sean's case he has such a slow Fosc, very long TMR0 period and s/w that is doing nothing else that there is ample time and opportunity to poll T0IF. As you say, in this example it's simpler to load a "-ve" count-up-to-00 value into TMR0 and then examine T0IF

2005\09\14@030049 by Sean Schouten

On 9/14/05, Olin Lathrop <TakeThisOuTolin_piclistEraseMEspam_OUTembedinc.com> wrote: > > Sean Schouten wrote: > > TEMP_W EQU H'0020' ;Place to dump W-Register in case of > interrupt. > > TEMP_STATUS EQU H'0021' ;Place to dump STATUS-Register data in case > of interrupt. > > Bad idea to put variables at hard coded addresses. This will get you into > trouble when moving code from PIC to PIC. There is another way; other than hard-coded memory addressing? You would make me happy by pointing me to an example. Also if TEMP_W is supposed to be > where W gets saved on interrupt, this will not work on PICs that have more > than one bank. Ah, why is that? {Quote hidden}> ORG 0x00 > > Absolute mode is for bacwards compatibility with old crufty code. It > should > not be used for new code. Now is the right time to learn to use the linker > and relocatable code, before you accumulate an existing code base. > > And no, I don't want to hear how you want to do just this one example in > absolute mode, then you'll switch. What will happen is there will be a > minor tweak on this one, then a little more, then a new project you want > to > get into and not spend the time, etc, etc. It's like drugs. When it comes > to absolute mode, JUST SAY NO! How do I not use 'absolute-mode' in this case? I am more than willing to say no... My code might not be the best of code, but if every one keeps on commenting like this, it will one day be supperb code! :*-) Oh, I should mention that I got that out of my PIC book too! (PIC in Practice) > GOTO START ;Standard Operation > > This may work on your particular PIC, but will fail on a PIC with more > than > one code page where START ended up not on page 0. Get in the habit of > thinking about PCLATH now. I shall look into PCLATH! > ORG 0x04 > > GOTO ISR ;The Interrupt Service Routine (Called in > case of an Interrupt) > > First, this won't work on PICs with more than one code page. Second, it's > silly to put the ISR elsewhere anyway. Something will end up here, and it > might as well be the interrupt service routine. Consider it done! {Quote hidden}> INITIALIZE > > BSF STATUS, RP0 ;Go to BANK 1 > > Only on PICs with two banks. Otherwise this goes to bank 1 or bank 3. > > Manual bank setting is a bad idea, especially when the state of some bank > bits is assumed. You insert new code above here and something below > breaks. > Beginners can use BANKSEL. Once you're comfortable with that, I can show > you more sophisticated ways of setting the bank. BANKSEL it is. I will get back to you on that more sophisticated way though! > ; Set OSC to 31kHz > > MOVLW 0x03 > > MOVWF OSCCON > > Doesn't this do more than just select the oscillator frequency? No. > ; Set prescaler to devide clock by 256 > > MOVLW 0x07 > > MOVWF OPTION_REG > > Same here. I'm pretty sure the option register controls more than just a > prescaler. Well, that's all I needed it to do. Are you implying that I must change the way I comment it? > BSF INTCON, GIE ;Set the General Interrupt Enable bit to 1. > > BCF INTCON, RAIF ;Clear the PORTA interrupt flag. > > This is out of order. Turning on GIE is the last thing you should do in > the > interrupt setup. I thought that GIE had to be turned on in order to enable interrupts in general. If that is not the case, then the datasheet doesn't make too much sense to me. "PIC in Practice" also enables the GIE in their example, although they do not state anything about IOCA. /Me is confused. > ISR > > ; First things first (I have my reason) > > That is a totally useless and unprofessional comment. I know and my excuse is that I wanted to explicitly store everything in bank1 because all the "hard-coded" memory locations where thought up withthe idea of them all being in bank1 in the back of my head. > BCF STATUS, RP0 ;Go to BANK 0 > > Very bad. You just trashed the bank setting on the foreground code. > > > ; Backup the STATUS-Register > > But you already trashed it above. I figured that! {Quote hidden}> ;### Begin ISR code: ### > > ; Turn LED on and keep it in that state for 5 whole seconds. > > BSF PORTA, 1 ;Turn LED on. > > CALL DELAY1S ;Delay for 1 second. > > CALL DELAY1S ;Delay for 1 second. > > CALL DELAY1S ;Delay for 1 second. > > CALL DELAY1S ;Delay for 1 second. > > CALL DELAY1S ;Delay for 1 second. > > This will take the processor completely out to lunch for the whole 5 > seconds. It's a bad idea to put delays, especially long ones, in the > interrupt routine. There may be some specialized structures where this > makes sense, but that is something you should only do after being > completely > familiar with the machine and the reasons for doing so. > > Also, you don't turn off the LED after waiting the 5 seconds. I know I do take the CPU out of the whole 5 seconds, and I also know that I have to find another way so the CPU stays kind of available. I just dont quite know how to go about it yet other than my suspicion of it involving interrupts? There's undoubtedly more below, but I've had enough for now. Thanks anyway, I shall see what I can do about getting it all fixed before we continue this dialog. Sean.

2005\09\14@030519 by Sean Schouten

On 9/14/05, Jinx <RemoveMEjoecolquittTakeThisOuTclear.net.nz> wrote: {Quote hidden}> > > Now, does this mean that when I hit the button attached to RA3, the pic > > should jump right to mem-location 0x04 and from there run my Interrupt > > Service Routine? > > Is the button changing the level on RA3 ? IOW, is the button connecting > RA3 to Vdd or, what is implied next, grounding a pull-up ? > > The /RAPU bit is cleared, which enables internal RA pull-ups > > ; Set prescaler to devide clock by 256 > MOVLW 0x07 > MOVWF OPTION_REG > > movlw b'00000111' > ; 0 enable RA pull-ups > ; 111 PS2,1,0 TMR0 pre-scaler = 256 > movwf option_reg > > You could also use Boolean bit-setting by name There is an external pull-up in the switch circuit. I am sure that it changes the port-state; I have used it before by polling RA3. The scematic is in the PicKit1 manual. Sean.

2005\09\14@031004 by Sean Schouten

On 9/14/05, Peter van Hoof <peterEraseME.....whacky-scientist.com> wrote: {Quote hidden}> > Sean, > > I think I have found it, > > > > BCF STATUS, RP0 ; Return to BANK 0 > > > > ; Turn off comparators > > CLRF CMCON0 ; Clear CMCON0 > > > > ; Clear Ports 'n Timers > > CLRF PORTA > > CLRF PORTC > > CLRF TMR0 > > > > ; Interrupt Configuration > > BSF INTCON, GIE ; Set the General Interrupt Enable bit to 1>. > > > > BCF INTCON, RAIF ; Clear the PORTA interrupt flag. > > BSF INTCON, RAIE ; Enable PORTA change interrupt. > > BSF IOCA, IOCA3 ; Enable interrupt-on-change on RA3. > > IOCA is in bank 1 not bank 0 we are tinkering with now! > There might be other problems but this is likely to cause grief > > Ahhh, nasty. I saw that it was in bank1 in the datasheet last night. So much for placing it next to the other Interrupt settings. Thanks.

2005\09\14@031429 by Sean Schouten

On 9/14/05, Jinx <EraseMEjoecolquittclear.net.nz> wrote: > > > 0x00 crossing went undetected ) as decision or better with T0IF flag. > > > > DELAY1S > > movlw -const > > movwf TMR0 > > bcf INTCON,T0IF > > > > btfss INTCON,T0IF > > goto $-1 > > That would be my preferred way too Dmitriy. I did mention to > Sean that T0IF could be polled. It has the advantage of the > rollover being recorded if the code is busy elsewhere at the > time of the rollover. In Sean's case he has such a slow Fosc, > very long TMR0 period and s/w that is doing nothing else that > there is ample time and opportunity to poll T0IF. As you say, > in this example it's simpler to load a "-ve" count-up-to-00 value > into TMR0 and then examine T0IF > Wouldn't it take multiple overflows to count to a second if I switch my OSC up to 8Mhz? Wouldn't that involve me using some memory location as a place to count the number of overflows? Actually, the only reason my OSC is set so low, is because this is the easy'est way for me to count seconds. I welcome any alternative that works at 8Mhz OSC setting with a 1x prescaler setting. Sean.

2005\09\14@033128 by Chen Xiao Fan

Some examples of re-loacatable code. http://gputils.sourceforge.net/reloc_howto.html http://www.embedinc.com/pic C:\Program Files\Microchip\MPASM Suite\Template\Object Chapter 6 of Microchip's "MPASM User's Guide with MPLINK and MPLIB". Olin's PIC programming environment may be the best tools to get all the banking and paging right. Regards, Xiaofan {Original Message removed}

2005\09\14@053406 by Jan-Erik Soderholm

Sean Schouten wrote : > > There is another way; other than hard-coded memory > addressing? You would make me happy by pointing > me to an example. You could simply use the docs. Look up the RES assembler directiv in the MPASM manual (or in the help file). > > Also if TEMP_W is supposed to be > > where W gets saved on interrupt, this will not work > > on PICs that have more than one bank. > > Ah, why is that? Because you want to save W *without* making any changes to STATUS (since that one will be save next, as-is). And since you can not know which bank you're in when the INT fired, you have to use un-banked memory. In the case of the F684, that is h'70' - h'7F'. See the "data memory map" in the data sheet. > How do I not use 'absolute-mode' in this case?... In short : - Add a "linker script" to your MPLAB project. - Make the needed changes to the source to convert it from asb mode to reloc mode. Not that you code of course will *work* in either mode, but relocatable is the *prefered* way of writing code today. > > ; Set OSC to 31kHz > > > MOVLW 0x03 > > > MOVWF OSCCON > > > > Doesn't this do more than just select the oscillator frequency? > > No. Yes, it also select the source if the "system clock". You are also writing a "1" to the LTS bit, which is read-only... > > BSF INTCON, GIE ;Set the General Interrupt Enable bit to 1. > > > BCF INTCON, RAIF ;Clear the PORTA interrupt flag. > > > > This is out of order. Turning on GIE is the last thing you > > should do in the interrupt setup. > > > I thought that GIE had to be turned on in order to enable > interrupts in general. It is. Just do it last in your INIT routine. > Wouldn't it take multiple overflows to count to > a second if I switch my OSC up to 8Mhz? Of course, that's the normal way to handle it, not to lower the system clock as you do. Jan-Erik.

2005\09\14@053816 by Jan-Erik Soderholm

Jinx wrote : > In Sean's case he has such a slow Fosc, > very long TMR0 period and s/w that is doing nothing else that > there is ample time and opportunity to poll T0IF... Now, having a slow Fosc doesn't give you more "time" realy, since everything have been slowed down. You still have exactly the same number of processor *cycles* (with is the only kind of "time" the processor knows about) between two TMR0 rollovers... Giving the same prescaler and all, of course. Jan-Erik.

2005\09\14@054433 by Jinx

> > ; Set prescaler to devide clock by 256 > > MOVLW 0x07 > > MOVWF OPTION_REG > > > Same here. I'm pretty sure the option register controls more than > > just a prescaler. > Well, that's all I needed it to do. Are you implying that I must change > the way I comment it ? What you need it to do and what it actually does can be be two different things. Writing 0 to a bit doesn't necessarily disable the function that bit controls (eg RAPU is active low). If you had been using RA2 as the input then INTEDG would have been important too. The button would activate code with the push on or the release according to how INTEDG is set One other reason to account for all bits is that maybe some time in the future unforeseen or improbable circumstances may happen that causes code to behave very strangely (or even dangerously). For example, leaving a RETURN address on the stack. It may seem harmless now, but it's lurking there forever, just waiting to be set free You have to be clear in your mind and your code what you want to happen and document it, for clarity now and later. If you ever re-visit code that isn't commented properly, working out what you did and why just makes more work. It's better to comment it now, while it's fresh, even if you think, well, duh, I'll remember that {Quote hidden}> > BSF INTCON, GIE ;Set the General Interrupt Enable bit to 1. > > BCF INTCON, RAIF ;Clear the PORTA interrupt flag. > > > > This is out of order. Turning on GIE is the last thing you should do in > > the interrupt setup > I thought that GIE had to be turned on in order to enable interrupts > in general. If that is not the case, then the datasheet doesn't make > too much sense to me. "PIC in Practice" also enables the GIE in > their example, although they do not state anything about IOCA > /Me is confused. If RAIF is already set and you turn GIE on, code will immediately jump to the ISR - that's why you have to make sure any unwanted pending interrupt sources are clear before setting GIE. If you want to have a good clear-out before turning on GIE CLRF INTCON CLRF PIR1 BANKSEL PIE1 CLRF PIE1 BANKSEL INTCON BSF INTCON,GIE

2005\09\14@054722 by Jinx

> > very long TMR0 period and s/w that is doing nothing else that > > there is ample time and opportunity to poll T0IF... > > Now, having a slow Fosc doesn't give you more "time" really, > since everything have been slowed down. You still have > exactly the same number of processor *cycles* (with is the > only kind of "time" the processor knows about) between two > TMR0 rollovers... Yes, I did mean to say that it was "real" time, not cycle times. I meant a long time compared with the sub-second button time

2005\09\14@061009 by Jinx

> Wouldn't it take multiple overflows to count to a second if I switch > my OSC up to 8Mhz ? > Wouldn't that involve me using some memory location as a place to > count the number of overflows ? Yes > Actually, the only reason my OSC is set so low, is because this is > the easy'est way for me to count seconds. I welcome any > alternative that works at 8Mhz OSC setting with a 1x prescaler > setting OK, you can switch to Timer1, which is 16-bit + 3-bit pre-scaler. That gives you a division of up to 524,288 between rollovers. At 8MHz (2MHz instruction cycles) = 2,000,000 / 524,288, or roughly 4 interrupts / second without re-loading TMR1. If that's too rough (if you want it exactly 1 second), then you have at least three options 1) re-loading. See http://www.piclist.com/techref/microchip/time.htm You'll have seen Dmitriy's example DELAY1S movlw -const movwf TMR0 bcf INTCON,T0IF 2) use a 32kHz crystal on T1OSC. The binary division will output TMR1 rollovers that neatly divide into 1 second 3) change to a hex value for the main oscillator. This will output TMRx rollovers that divide neatly into 1 second The problem is that 8MHz is a decimal value, and internally the PIC is binary/hexadecimal. When you divide 2000000 by, for example, 256 you'll get 7812.5. Not an impossible number to work with but a hex value crystal will divide evenly by 256. I keep a stock of 9.3804MHz, 18.432MHz, and 19.6608MHz for that reason (and also RS232) as well as 10s and 20s - sometimes you need a decimal result. Depends what in the code has priority

2005\09\14@073257 by Sean Schouten

part 1 1212 bytes content-type:text/plain; charset=ISO-8859-1 (decoded quoted-printable) Dear colleagues, teachers and friends, I have been hard at work during my school break today, patching together some of the information that I have been given by you guys. This is what I have done so far: * Implemented the BANKSELECT pre-processor. * Implemented dynamic memory allocation. * Got rid of "GOTO ISR" and placed the ISR itself at the definition "ORG 0x04". * Did a little cleaning and some re-commenting. * Fixed the value being written to a read-only bit on the OSCCON0-Register (0x03 becomes 0x01) * Made sure that "BSF INTCON, GIE" is the last thing done in the initialization sub and that INTCON / PIE1 / PIR1 are cleared before setting the GIE. --> See the attached ASM. Ah, since the bank-incident was cleared with IOCA, the interrupts seem to finally be working on PORTA!!! I still have some things to like crank the OSC up to it's full power and devise a devious and perhaps efficient way of going about my delays by making use of a Timer-overflow. Might do that either this afternoon or evening. If there is anything else, please let me know!!! Don't be too shy to scrutinize it all! :-) Thanks, Sean. part 2 7316 bytes content-type:application/octet-stream; name="test_piclist.asm" (decode) part 3 35 bytes content-type:text/plain; charset="us-ascii" (decoded 7bit)

2005\09\14@074301 by Jinx

> > This is out of order. Turning on GIE is the last thing you should do > > in the interrupt setup > I thought that GIE had to be turned on in order to enable interrupts.. > ... doesn't make too much sense You've misunderstood. By "last" Olin meant "final"

2005\09\14@075829 by Sean Schouten

On 9/14/05, Jinx <RemoveMEjoecolquittEraseMEEraseMEclear.net.nz> wrote: > > > > This is out of order. Turning on GIE is the last thing you should do > > > in the interrupt setup > > > I thought that GIE had to be turned on in order to enable interrupts.. > > ... doesn't make too much sense > > You've misunderstood. By "last" Olin meant "final" As in: GIE is the last bit to be set out of all of the things that have to do with the Interrupts? Sean.

2005\09\14@080116 by Howard Winter

On Wed, 14 Sep 2005 23:42:54 +1200, Jinx wrote: > > > This is out of order. Turning on GIE is the last thing you should do > > > in the interrupt setup > > > I thought that GIE had to be turned on in order to enable interrupts.. > > ... doesn't make too much sense > > You've misunderstood. By "last" Olin meant "final" That may be true, but don't forget that RETFIE does it for you anyway (that being its /raison d'etre/ - otherwise it's the same as RETURN) :-) Cheers, Howard Winter St.Albans, England

2005\09\14@080220 by Jinx

Looking a lot more organised Sean - that's good progress for a day Just a couple of things. As you get to know the registers better you could cut down on the BANKSELs. For example PortA, PortC and TMR0 are all in bank0 so BANKSEL PORTA CLRF PORTA CLRF PORTC CLRF TMR0 is sufficient instead of BANKSEL PORTA CLRF PORTA BANKSEL PORTC CLRF PORTC BANKSEL TMR0 CLRF TMR0 ================== You can define a name for a bit in a register (such as a pin) #define led porta,1 would allow you to use the expression BCF LED instead of BCF PORTA,1

2005\09\14@081801 by Jinx

> As in: GIE is the last bit to be set out of all of the things that have > to do with the Interrupts? Uh-huh. There are times when you might want to turn interrupts off and on, and that may mean NOT clearing pending IFs. Say you have code that has both a clock and comms. The comms have priority and you don't want them to be interrupted by, er, an interrupt that isn't vital. So, on comms detection or commence- ment, you turn GIE off while you deal with the foreground task of making sure the comms are done properly. Meanwhile, in the background, the clock (eg a TMR) is still running. When the comms are finished, you turn GIE back on. If a clock event happened whilst you were comming, there will be an IF set in hardware, which will direct program flow to the ISR as soon as GIE is re-set

2005\09\14@082329 by Peter Onion

On Wed, 2005-09-14 at 13:01 +0100, Howard Winter wrote: > That may be true, but don't forget that RETFIE does it for you anyway (that being its /raison d'etre/ - > otherwise it's the same as RETURN) :-) But your code is never going to get into an ISR to execute the RETFIE if GIE isn't set in the first place ! Chicken and Egg I think :-) Peter

2005\09\14@083125 by Jinx

> That may be true, but don't forget that RETFIE does it for > you anyway (that being its /raison d'etre/ - otherwise it's the > same as RETURN) :-) At that point in Sean's code the interrupts hadn't yet been enabled Mr W, so reaching the RETFIE would be a tad on the difficult side ;-) I've made occassional use of the difference between RETURN and RETFIE. GIE is turned off by the interrupt process and if you end the ISR with RETURN, it stays off. This prevents any subsequent event entering the ISR until code turns GIE back on

2005\09\14@085216 by Howard Winter

Peter, On Wed, 14 Sep 2005 13:23:28 +0100, Peter Onion wrote: > On Wed, 2005-09-14 at 13:01 +0100, Howard Winter wrote: > > > That may be true, but don't forget that RETFIE does it for you anyway (that being its /raison d'etre/ - > > otherwise it's the same as RETURN) :-) > > But your code is never going to get into an ISR to execute the RETFIE if > GIE isn't set in the first place ! Chicken and Egg I think :-) Well yes, but we were talking specifically about re-enabling it at the end of an Interrupt Service Routine - you obviously have to set it initially. Cheers, Howard Winter St.Albans, England

2005\09\14@085601 by Howard Winter

Jinx, On Thu, 15 Sep 2005 00:30:41 +1200, Jinx wrote: > > That may be true, but don't forget that RETFIE does it for > > you anyway (that being its /raison d'etre/ - otherwise it's the > > same as RETURN) :-) > > At that point in Sean's code the interrupts hadn't yet been > enabled Mr W, so reaching the RETFIE would be a tad on > the difficult side ;-) But we were talking about re-enabling it at the end of the ISR (where setting it explicitly, as Sean was doing, is unneeded if you're using RETFIE). The fact that you can't get into the ISR unless it's enabled initially is equally (ir)relevant whether you set it or the RETFIE does! > I've made occassional use of the difference between RETURN > and RETFIE. GIE is turned off by the interrupt process and if > you end the ISR with RETURN, it stays off. This prevents any > subsequent event entering the ISR until code turns GIE back on Oh yes, but *usually* you want it set back on at the end of the ISR(s). Cheers, Howard Winter St.Albans, England

2005\09\14@095415 by Paul James E.

You sure do put your comments way out in right field. Makes it difficult to print out on a standard page and still be able to read the comments. Jim {Quote hidden}> ...And I'm back. > > I did some cleaning and re-touching her and there. I my self think that > it looks much cleaner and the comments are plentyfull. I still have to > find the optimal commenting style for my self; no worries though... > > Okay; > > My main loop now boasts a NOP (whoa!), basically doing nothing > (oooooooh!)... In my INITIALIZE routine I have done the following: > > [code] > > ; Interrupt Configuration > BSF INTCON, GIE ; Set the General Interrupt Enable bit to 1. > > BCF INTCON, RAIF ; Clear the PORTA interrupt flag. > BSF INTCON, RAIE ; Enable PORTA change interrupt. > BSF IOCA, IOCA3 ; Enable interrupt-on-change on RA3. > > [/code] > > Now, does this mean that when I hit the button attached to RA3, the pic > should jump right to mem-location 0x04 and from there run my Interrupt > Service Routine? > > I once again attached my ASM-file to this mail -this time a clean(er) > version-. If any-one has any other tips, comments or whatever; I'm > ready for em (I think)! > > Thanks once again, > > Sean. > > P.S. Start cheering, my INITIALIZE now boasts a RETURN! If you don't > believe me, feel free to take a look!

2005\09\14@112328 by olin piclist

Sean Schouten wrote: >> Bad idea to put variables at hard coded addresses. This will get you >> into trouble when moving code from PIC to PIC. > > There is another way; other than hard-coded memory addressing? You would > make me happy by pointing me to an example. Read up on the RES directive. >> Also if TEMP_W is supposed to be >> where W gets saved on interrupt, this will not work on PICs that have >> more than one bank. > > Ah, why is that? Because the bank is unknown on entry to the interrupt. You either have to reserve the same offset in each bank or put TEMP_W in the global area mapped to all banks on some PICs. > How do I not use 'absolute-mode' in this case? You use the linker. Other will have to tell you how to set up a relocatable project. I use external build scripts. My PIC development environment is at http://www.embedinc.com/pic, although that will be a bit overwhelming to you at this stage. > Oh, I should mention that I got that out of my PIC book too! (PIC in > Practice) So screw the book and stick to common sense and the data sheet. >> ; Set prescaler to devide clock by 256 >>> MOVLW 0x07 >>> MOVWF OPTION_REG >> >> Same here. I'm pretty sure the option register controls more than just >> a prescaler. > > Well, that's all I needed it to do. Are you implying that I must change > the way I comment it? Yes. >> This is out of order. Turning on GIE is the last thing you should do in >> the interrupt setup. > > I thought that GIE had to be turned on in order to enable interrupts in > general. If that is not the case, then the datasheet doesn't make too > much sense to me. "PIC in Practice" also enables the GIE in their > example, although they do not state anything about IOCA. /Me is > confused. I didn't say not to enable GIE, only to do it last. You cleared some interrupt conditions after enabling GIE. If those interrupt coditions were previously set, you would have gotten an interrupt right there. That's why its best to make sure the whole interrupt system is set exactly the way you want it and all interrupt conditions initialized to off, THEN set GIE. >> That is a totally useless and unprofessional comment. > > I know and my excuse is <blah, blah, blah> There is no exuse. > I know I do take the CPU out of the whole 5 seconds, and I also know > that I have to find another way so the CPU stays kind of available. I > just dont quite know how to go about it yet other than my suspicion of > it involving interrupts? Why not a simple polling loop with not interrupts at all? That should be less to chew off initially too while you get familiar with PICs. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com

2005\09\14@113113 by Sean Schouten

On 9/14/05, Paul James E. <RemoveMEjamespspam_OUTKILLspamintertex.net> wrote: > > > You sure do put your comments way out in right field. Makes it difficult > to print out on a standard page and still be able to read the comments. > > I work with 1280 x 1024 and don't print things out often... :-) Sean.

2005\09\14@113723 by olin piclist

Howard Winter wrote: > That may be true, but don't forget that RETFIE does it for you anyway > (that being its /raison d'etre/ - otherwise it's the same as RETURN) > :-) Yes, but that applies to returning from the interrupt service routine. We were discussing how to enable interrupts during system initialization. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com

2005\09\14@114452 by olin piclist

Jinx wrote: > Just a couple of things. As you get to know the registers better > you could cut down on the BANKSELs. For example PortA, > PortC and TMR0 are all in bank0 so > > BANKSEL PORTA > CLRF PORTA > CLRF PORTC > CLRF TMR0 Hmm. I'm not sure I like that. I think it's better for a newbie to use BANKSEL in front of every SFR access, except for the ones specifically documented to be mapped to all banks (INTCON, STATUS, etc). Implicit assumptions in the source code about what bank things are in is a bad idea in my opinion. Using BANKSEL isn't a good way to write prodution code because it inserts a lot of needless diddling of RP0 and RP1, but it's a reliable way to get started. Once a newbie has a general comfort with the PIC and understands the memory architecture better, it's time to re-examine banking. At that point they're ready for DBANKIF and related facilities in STD.INS.ASPIC at http://www.embedinc.com. > You can define a name for a bit in a register (such as a pin) > > #define led porta,1 > > would allow you to use the expression > > BCF LED > > instead of BCF PORTA,1 Yes, this is a good point. Once past the initial learning stage, the next step is to use the /INBIT and /OUTBIT directive of my preprocessor which do this but also define a bunch of other constants related to an I/O bit, and the standard PORT module then automatically initializes everything as you specified. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com

2005\09\14@120346 by olin piclist

part 1 557 bytes content-type:text/plain; (decoded 7bit) Paul James E. wrote: > You sure do put your comments way out in right field. Makes it > difficult to print out on a standard page and still be able to read the > comments. I noticed that too. There's a lot of bad code formatting out there. That's why I wrote my ASPIC_FIX program, which is part of my PIC development environment at http://www.embedinc.com/pic. I ran Sean's code thru that before even attempting to make sense of it. As an example, I've attached his latest code as cleaned up by ASPIC_FIX. part 2 7579 bytes content-type:application/octet-stream; (decode) part 3 35 bytes content-type:text/plain; charset="us-ascii" (decoded 7bit)

2005\09\14@124440 by Paul James E.

Oh yea, much easier to read. I'll have to keep your utility in mind. Thanks, Jim {Quote hidden}> Paul James E. wrote: >> You sure do put your comments way out in right field. Makes it >> difficult to print out on a standard page and still be able to read >> the comments. > > I noticed that too. There's a lot of bad code formatting out there. > That's why I wrote my ASPIC_FIX program, which is part of my PIC > development environment at http://www.embedinc.com/pic. I ran Sean's > code thru that before even attempting to make sense of it. As an > example, I've attached his latest code as cleaned up by ASPIC_FIX.

2005\09\14@154740 by Sean Schouten

I just found out what it looks like when you guys open my ASM with whatever you use; I used a text-viewer. It looks a whole lot different then when I open it in my MPLAB IDE. Real weird.

2005\09\14@174351 by Jinx

> I just found out what it looks like when you guys open my ASM > with whatever you use; I used a text-viewer. It looks a whole lot > different then when I open it in my MPLAB IDE. Real weird That's why I asked if you were using tabs (rather than spaces). My default .txt viewer is Notepad and the line length was too long for my screen (1024 x 768). I could have looked at it with something else but, y'know....... Not every viewer copes with tabs the same way and a print-out can be real formatting mess, totally different from what you'd see on the screen. Which is why I never use tabs

2005\09\14@180837 by Sean Schouten

On 9/14/05, Jinx <RemoveMEjoecolquittTakeThisOuTspamclear.net.nz> wrote: > > > I just found out what it looks like when you guys open my ASM > > with whatever you use; I used a text-viewer. It looks a whole lot > > different then when I open it in my MPLAB IDE. Real weird > > That's why I asked if you were using tabs (rather than spaces). My > default .txt viewer is Notepad and the line length was too long for > my screen (1024 x 768). I could have looked at it with something > else but, y'know....... > > Not every viewer copes with tabs the same way and a print-out can > be real formatting mess, totally different from what you'd see on the > screen. Which is why I never use tabs > > > Hmmm, I do use tabs. There should be a setting somewhere where you can specify a TAB being 4 spaces (real space chars), or so I hope. I know that that's the case in N++ and DEV-C++. I will see what I can find, because this sucks! Sean

2005\09\14@182339 by Sean Schouten

On 9/14/05, Jinx <EraseMEjoecolquittspamspamBeGoneclear.net.nz> wrote: > > Looking a lot more organised Sean - that's good progress for > a day Thank you! Just a couple of things. As you get to know the registers better {Quote hidden}> you could cut down on the BANKSELs. For example PortA, > PortC and TMR0 are all in bank0 so > > BANKSEL PORTA > CLRF PORTA > CLRF PORTC > CLRF TMR0 > > is sufficient instead of > > BANKSEL PORTA > CLRF PORTA > > BANKSEL PORTC > CLRF PORTC > > BANKSEL TMR0 > CLRF TMR0 > Doesn't the latter cater for complete portability? It probably caters for twice as much overhead; or does the assembler take care of that all upon code assembly?

2005\09\14@182752 by Sean Schouten

On 9/15/05, Sean Schouten <RemoveMEdev.seantechKILLspamgmail.com> wrote: {Quote hidden}> > > > On 9/14/05, Jinx <joecolquittSTOPspamspam_OUTclear.net.nz> wrote: > > > > > I just found out what it looks like when you guys open my ASM > > > with whatever you use; I used a text-viewer. It looks a whole lot > > > different then when I open it in my MPLAB IDE. Real weird > > > > That's why I asked if you were using tabs (rather than spaces). My > > default .txt viewer is Notepad and the line length was too long for > > my screen (1024 x 768). I could have looked at it with something > > else but, y'know....... > > > > Not every viewer copes with tabs the same way and a print-out can > > be real formatting mess, totally different from what you'd see on the > > screen. Which is why I never use tabs > > > > > > > Hmmm, I do use tabs. There should be a setting somewhere where you can > specify a TAB being 4 spaces (real space chars), or so I hope. I know that > that's the case in N++ and DEV-C++. I will see what I can find, because this > sucks! I found it! For those of you that don't know where to change the -tabs- into -spaces- in your MPLAB IDE. In the MPLAB menu: [EDIT] > [Properties..]. > [Sizes]. It should be set to "Keep Tabs". Let's make that "Insert Spaces" shall we? Have fun, Sean.

2005\09\14@184338 by Jinx

> Hmmm, I do use tabs. There should be a setting somewhere In MPLAB, Edit/Properties/Tabs

2005\09\14@184342 by Jinx

> Doesn't the latter cater for complete portability? It probably > caters for twice as much overhead; or does the assembler take > care of that all upon code assembly ? It's a bit swings and roundabouts. I think without exception registers like PORTA/GPIO on 12/16 PICs are always in bank0, TRIS/TRISIO are in bank1. 18s are not banked so BANKSEL is unnecessary. If 12/16 code might one day be ported to an 18 or whatever comes in the future then it would be best to use a universally compatible style. I suggested grouping registers with a common bank together to cut down on clutter - I have a slight leaning towards that, but not at the cost of code screwing up. I did say that you might rationalise when you get to know the PIC better, but you should take note of Olin's comments

2005\09\14@190648 by Sean Schouten

On 9/15/05, Jinx <spamBeGonejoecolquittSTOPspamEraseMEclear.net.nz> wrote: > > > Doesn't the latter cater for complete portability? It probably > > caters for twice as much overhead; or does the assembler take > > care of that all upon code assembly ? > > It's a bit swings and roundabouts. I think without exception > registers like PORTA/GPIO on 12/16 PICs are always in > bank0, TRIS/TRISIO are in bank1. 18s are not banked so > BANKSEL is unnecessary. If 12/16 code might one day be > ported to an 18 or whatever comes in the future then it would > be best to use a universally compatible style. I suggested > grouping registers with a common bank together to cut down > on clutter - I have a slight leaning towards that, but not at the > cost of code screwing up. I did say that you might rationalise > when you get to know the PIC better, but you should take > note of Olin's comments > > Once I have soaked up all of this new programming 'style' that I have adapted in the past day or two, I shall ask Olin to teach me his advanced bank selection techniques. He told me that he would do so, once I am comfortable with what I now know. I also still have to look into using the linker so I don't use have to use "absolute-mode" any more... I can't decide what is more important! Anyhow, time for bed! I am sure that I will be found tinkering around with my source at school tomorrow. Till then I will probably be visualizing what I have learnt on the back of my eyelids. Sean.

2005\09\14@200059 by olin piclist

Jinx wrote: > 18s are not banked so > BANKSEL is unnecessary. Not completely. The basic 18s have all the SFRs in the access bank, but some have so many that there wouldn't have been any user RAM left in the access bank. I think these are the USB and/or CAN variants. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com

2005\09\14@200402 by olin piclist

Sean Schouten wrote: > Once I have soaked up all of this new programming 'style' that I have > adapted in the past day or two, I shall ask Olin to teach me his > advanced bank selection techniques. He told me that he would do so, > once I am comfortable with what I now know. I also still have to look > into using the linker so I don't use have to use "absolute-mode" any > more... I can't decide what is more important! Definitely the linker. Keep using BANKSEL for now. It will always work, and you don't currently care about a few extra instructions or cycles. The fancy bank and page handling can wait until after you get more comfortable with the general architecture and tools. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com

2005\09\14@202515 by William Chops Westfield

On Sep 14, 2005, at 3:08 PM, Sean Schouten wrote: > There should be a setting somewhere where you can > specify a TAB being 4 spaces Tabs come every 8 spaces as "standard." Please fix your configuration. (which, of course, is the problem with using tabs. I LIKE tabs, but I can't be bothered to change my environment to look at your code, and I don't expect you to change your environment to look at my code, either.) (but tabs every 8 spaces really is a long-standing defacto standard.) BillW

2005\09\15@045941 by Sean Schouten

On 9/15/05, William Chops Westfield <KILLspamwestfwspamBeGonemac.com> wrote: > > On Sep 14, 2005, at 3:08 PM, Sean Schouten wrote: > > > There should be a setting somewhere where you can > > specify a TAB being 4 spaces > > Tabs come every 8 spaces as "standard." Please fix your configuration. > > (which, of course, is the problem with using tabs. I LIKE tabs, but > I can't be bothered to change my environment to look at your code, and > I don't expect you to change your environment to look at my code, > either.) > > (but tabs every 8 spaces really is a long-standing defacto standard.) > > BillW >

2005\09\15@072007 by olin piclist

William Chops Westfield wrote: > Tabs come every 8 spaces as "standard." Some Unixes seem to think that's a standard, but at best this is common usage for a segment of computing. Lot's of code would be annoying to look at or leave too little room for comments if it used 8 spaces for each indentation level. When it comes to tabs, there is no standard. The only right answer is to not put tabs in the files, especially if other are supposed to view them. Most editors have an option so that you can use the TAB key to advance to the next tab stop column, but the editor inserts spaces into the file to get there. > Please fix your configuration. Yes, but by getting rid of tabs altogether. Other people here, including me, will find your code annoying if it contains tabs that assume tab stops are every 8 spaces. You might also consider running your code thru my ASPIC_FIX program. The result is guaranteed not to contain tabs. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com

2005\09\15@075630 by Xiaofan Chen

I use Ultraedit on Windows and it can convert between TABS and spaces. of course it also has lots of other features. Still I always set tab to 4 spaces since I think it looks better. MPLAB 5.x was a pain to use for code editing and I chose Ultraedit. After MPLAB 6 came out, I use MPLAB more and more often but seting tabs to 4 at both MPLAB and Ultraedit make my life easier. Notepad defults to use 8 spaces though. I like TABs but posting code with TABs can be a problem for others. Regards, Xiaofan

2005\09\15@101923 by olin piclist

Xiaofan Chen wrote: > I use Ultraedit on Windows and it can convert between TABS and > spaces. Yes, the FORMAT > TABS TO SPACES command does that. But how do you set it up so that you can hit TAB but have it insert spaces to get to *arbitrary* tab stops? Under ADVANCED > CONFIGURATION > EDIT you can check USE SPACES IN PLACE OF TABS, but for some unfathomable reason when you do that it uses the single INDENT SPACES value for the pitch between tabs stops instead of the arbitrary list you can enter for TAB STOP VALUE when not converting tabs to spaces. This seems really dumb, but it's documented that way and works that way. What I want is to be able to set a list of arbitrary tab stops that are not necessarily at regular intervals, but still have the TAB key insert spaces to get to the next tab stop. This seems like a really obvious thing to do, but I can't see how to set it up that way. What I end up doing is let it write tabs in the file, then do Alt-T S to convert them to spaces before saving. That's a hassle to remember, and it also has the annoying side effect of positioning the window back to the start of the file. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com

2005\09\15@114607 by William Chops Westfield

On Sep 15, 2005, at 4:20 AM, Olin Lathrop wrote: >> Tabs come every 8 spaces as "standard." > > Some Unixes seem to think that's a standard, but at best this is common > usage for a segment of computing. Lot's of code would be annoying to > look > at or leave too little room for comments if it used 8 spaces for each > indentation level. Actually, I think it's a DEC thing, perhaps based on ForTran. DEC fortran used to let you use a tab to skip over the statementnumber/etc field that normally ran column 1 through whatever. And the assemblers had 6char label:<tab>opcode<tab>arg,arg<tab><tab>;comment DEC operating systems would expand tabs to multiple-of-8 column during echo, and DEC terminals default to tabstops every 8 columns if they supported tabs at all. > > Lot's of code would be annoying to look at or leave too little room for > comments if it used 8 spaces for each indentation level. The "standard" predates languages with lots of indentation levels, but having tabstops at 8 spaces doesn't mean that the indentation level has to be 8 spaces too. Most modern editors will happily divorce the action of the tab key from the width of a tab character. >> Please fix your configuration. > Yes, but by getting rid of tabs altogether. Un-tabifying code is certainly preferred for publication, and my toungue was firmly in cheek with my suggestion to switch from 4 to 8 space tabs. Alas, with many modern mail agents deciding to send or display messages in proportional fonts, code indented with spaces isn't guaranteed to look right, either... BillW

2005\09\15@142734 by Howard Winter

Olin, On Thu, 15 Sep 2005 10:19:58 -0400, Olin Lathrop wrote: > What I want is to be able to set a list of arbitrary tab stops that are not > necessarily at regular intervals, but still have the TAB key insert spaces > to get to the next tab stop. Me too! If you find an editor (preferably cross-platform) that will do this, please let me know! > This seems like a really obvious thing to do, Perhaps not obvious to editor-writers, apparently. :-( I'm a bit amazed that considering the maturity of programming as a function, that there aren't better editors around designed for it. I have yet to find any that do everything you'd want in one program. Cheers, Howard Winter St.Albans, England

2005\09\15@152118 by olin piclist

Howard Winter wrote: >> What I want is to be able to set a list of arbitrary tab stops that >> are not necessarily at regular intervals, but still have the TAB key >> insert spaces to get to the next tab stop. > > Me too! If you find an editor (preferably cross-platform) that will do > this, please let me know! The editor built into the Apollo display manager did this. I really like that editor, but of course it only runs on old apollos. I still have one in my office just to edit on, but unfortunately I have to be at other places sometimes where only PCs are available. I got UltraEdit and have been slowly getting used to it. It think it has a lot of power that I haven't tapped yet, and I can make it eventually do what I want, but it's still not the Apollo editor. The interface is too much clickety click and everything is done with temporary popups. And there are some parts of replace operations with regular expressions I can't get to work even after the 20th time carefully reading the description. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com

2005\09\15@155337 by Marcel Duchamp

Howard Winter wrote: > Olin, > > On Thu, 15 Sep 2005 10:19:58 -0400, Olin Lathrop wrote: > > >>What I want is to be able to set a list of arbitrary tab stops that are not >>necessarily at regular intervals, but still have the TAB key insert spaces >>to get to the next tab stop. Funny how things change. My old 1954 Royal manual desktop typewriter does that perfectly.

2005\09\15@165647 by John Nall

Marcel Duchamp wrote: > > Funny how things change. My old 1954 Royal manual desktop > typewriter does that perfectly. Yes, I was thinking much along the same lines, of my old manual typewriter. :-) I also believe, although I could be mistaken, that the Joe text editor under Unix (and most likely still available under Linux -- no tool in that environment ever completely gets trash-canned) provided variable tab stops. But it has been a long, long time since I used that and I might be wrong. John

2005\09\15@201633 by William Chops Westfield

>> What I want is to be able to set a list of arbitrary tab stops that >> are not necessarily at regular intervals, but still have the TAB >> key insert spaces to get to the next tab stop. >> EMACS certainly can do this. As far as I know, the variable "indent-tabs-mode" controls whether tabs or spaces are used for indentation completely orthogonally to which sort of tabbing is currently in effect. But "tab-to-tab-stop" certainly obeys it, as well as the more complex context and language dependent functions normally bound to "tab" for the language modes. And if you don't like how it behaves, you can always change it :-) BillW

2005\09\15@203108 by William Chops Westfield

On Sep 15, 2005, at 11:27 AM, Howard Winter wrote: > Perhaps not obvious to editor-writers, apparently. :-( > > I'm a bit amazed that considering the maturity of programming as a > function, that there aren't better editors around designed for it. The market is too small. > I have yet to find any that do everything you'd want in one program. > EMACS does everything. It's a fine example of why that isn't as good an idea as you might think. Likewise, it's a fine example of many of the good AND bad aspects of open source development projects. (Someone mentioned 'joe'; isn't that "Joe's Own Emacs" or something like that. Put it in the bin with MINCE, FINE, and the other emacs clones of more or less functionality...) BillW

2005\09\15@204036 by John Nall

William Chops Westfield wrote: > EMACS does everything. It's a fine example of why that isn't as good > an idea as you might think. Likewise, it's a fine example of many of > the good AND bad aspects of open source development projects. I THINK that you are saying what I am fixing to say. :-) EMACS is not for the faint of heart. It does everything anyone could possibly want to do in a text editor (if one would want to call it by such a humble name). But it is indeed a sterling example of open source development projects. Plus, for those who follow the history of these things, look at who the primary authors are. I say that in a completely humble manner -- they are far beyond what I could every hope to be -- but trying to use something which was developed by such Greatness can be a royal pain in the rear end. So yeah, it will do everything. But beware. John

2005\09\15@210241 by William Chops Westfield

On Sep 15, 2005, at 5:39 PM, John Nall wrote: [EMACS] > So yeah, it will do everything. But beware. > It's rather a lot like linux (or vis-versa, given the history.) You spend as much time trying to track down the documentations and proper settings to make something work, as you would writing a similar function from scratch... But to be fair, a lot of the right stuff happens pretty much "out of the box." BillW

2005\09\15@225444 by Lee Jones

>>> Tabs come every 8 spaces as "standard." >> Some Unixes seem to think that's a standard, but at best this is >> common usage for a segment of computing. Lot's of code would be >> annoying to look at or leave too little room for comments if it >> used 8 spaces for each indentation level. Tab stops every 8 spaces predates block structured languages. And, anyway, comments had to be on a line seperate from code. :-) > Actually, I think it's a DEC thing, perhaps based on ForTran. As I recall, the Teletype printing terminals, such as the models 33, 35, & 37 (both ASR & KSR variants) all had fixed hardware tab stops every 8 characters. And you _really_ wanted 1 tab character (not 8 space characters) when you were receiving your program listing at 10 chars/sec (110 baud). Bonus history question: What do tha accronyms ASR & KSR mean and what hardware differed between those variants? Lee Jones

2005\09\16@084403 by William Couture

On 9/15/05, Lee Jones <EraseMEleeEraseMEfrumble.claremont.edu> wrote: > Bonus history question: What do tha accronyms ASR & KSR mean and > what hardware differed between those variants? ASR -- Asynchronous Send Receive KSR -- Keyboard Send Receive The ASR was a "receive only" teletype, used for such things as newsfeeds. The KSR included a keyboard. Bill -- Psst... Hey, you... Buddy... Want a kitten? straycatblues.petfinder.org

2005\09\16@090913 by olin piclist

William Couture wrote: > The ASR was a "receive only" teletype, used for such things as > newsfeeds. Really? We had lots of teletypes with the integrated keyboards and referred to them a ASR-35. Maybe that was a common incorrectness, but it was certainly common. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com

2005\09\16@091137 by Wouter van Ooijen

> > Bonus history question: What do tha accronyms ASR & KSR mean and > > what hardware differed between those variants? > > ASR -- Asynchronous Send Receive > > KSR -- Keyboard Send Receive > > The ASR was a "receive only" teletype, used for such things > as newsfeeds. > > The KSR included a keyboard. AFAIK I had an *A*SR 33 *with* a keyboard. IIRC the A was for automatic. My parents did not allow me to use the beast in my little room for fear of ear damage. It ended up next to my sisters room. I used it to print address labels.I used narrow paper (much cheaper than telex paper), which had to fit in the centre because that is were the feed mechanism was. Hence the beast had to do a lot of spaces before it reached the printing zone. IIRC it took an hour or so to print 200 labels, but that was much better than writing the labels by hand :) The computer was an Exidy Sorcerer, 48K RAM and a modified casette interface. Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: http://www.voti.nl/hvu

2005\09\16@091653 by Alan B. Pearce

2005\09\16@105047 by William Chops Westfield

On Sep 16, 2005, at 6:11 AM, Wouter van Ooijen wrote: >> ASR -- Asynchronous Send Receive >> The ASR was a "receive only" teletype, used for such things >> as newsfeeds. > AFAIK I had an *A*SR 33 *with* a keyboard. IIRC the A was for > automatic. > > I remember "automatic" too; The ASR had the paper-tape punch/reader. BillW

2005\09\16@133647 by Howard Winter

Lee, On Thu, 15 Sep 2005 20:02:45 -0700, Lee Jones wrote: >...< > As I recall, the Teletype printing terminals, such as the models > 33, 35, & 37 (both ASR & KSR variants) all had fixed hardware tab > stops every 8 characters. And you _really_ wanted 1 tab character > (not 8 space characters) when you were receiving your program listing > at 10 chars/sec (110 baud). Or, indeed, sending it to the computer in the first place :-) > Bonus history question: What do tha accronyms ASR & KSR mean and > what hardware differed between those variants? Stone me, I was a teenager the last time I touched one, and a gigabyte of storage took up a decent sized room, rather than being carried on my keyring as it is now... Automatic Send / Receive Keyboard Send / Receive ...if I remember rightly. The ASRs had a paper tape reader/punch (all of ours at college did because we weren't allowed to work "live" - had to punch the tape offline and hand it over to be sent when the lab.tech had time :-) What's the prize, a roll of paper tape with my name punched along it? :-) Cheers, Howard Winter St.Albans, England

2005\09\16@140149 by Wouter van Ooijen

> What's the prize, a roll of paper tape with my name punched > along it? :-) I think I have a few rolls left somewhere, but no name on it. I still refer to paper tape when I explain the meaning of ASCII 0x7F. Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: http://www.voti.nl/hvu

2005\09\16@140740 by Peter

On Thu, 15 Sep 2005, Howard Winter wrote: > I'm a bit amazed that considering the maturity of programming as a > function, that there aren't better editors around designed for it. I > have yet to find any that do everything you'd want in one program. Try emacs Peter (vi user)

2005\09\16@142312 by Jan-Erik Soderholm

One thing with the teletypes, IRCC, was that there wasn't any flowcontrol on the 110 baud line. So a full carrriage return from right to left was done in 1/10 of a second at the full 10 char/sec speed... Jan-Erik.

2005\09\16@144411 by Wouter van Ooijen

> One thing with the teletypes, IRCC, was that there wasn't any > flowcontrol on the 110 baud line. > So a full carrriage return from right to left was done in > 1/10 of a second at the full 10 char/sec speed... No. After a CR and/or LF (those were two realy separate things!) you had to wait the appropriate time before the beast would accept a next character. IIRC 3 characters for a CR. Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: http://www.voti.nl/hvu

2005\09\16@145450 by olin piclist

Jan-Erik Soderholm wrote: > One thing with the teletypes, IRCC, was that there wasn't any > flowcontrol on the 110 baud line. > So a full carrriage return from right to left was done in > 1/10 of a second at the full 10 char/sec speed... Oh no it wasn't! One of the issues of driving a teletype back then was that you had to insert NULLs after a carriage return so that the next character didn't get printed until after the carriage had finished moving back. We have CRLF not LFCR today because line feed was much quicker and therefore could be overlapped with carriage return by starting it second. One time I even wrote a teletype driver that took into account where the carriage was when a CR was issued and inserted the appropriate number of NULLs. You could notice it going faster on short lines. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com

2005\09\16@163529 by Lee Jones

>>> Bonus history question: What do tha accronyms ASR & KSR mean and >>> what hardware differed between those variants? Bill Couture wrote:: >> ASR -- Asynchronous Send Receive [...] a "receive only" teletype, >> used for such things as newsfeeds. >> KSR -- Keyboard Send Receive [... with] a keyboard Wouter wrote: > AFAIK I had an *A*SR 33 *with* a keyboard. IIRC the A was for automatic. Alan B Pearse wrote: > I believe you have KSR correct, but I believe the ASR is "Auto Send > Receive" because it had a paper tape reader and punch, which could be > remotely controlled without operator intervention. BillW wrote: > I remember "automatic" too; The ASR had the paper-tape punch/reader. ASR is indeed Automatic Send Receive because it had a paper tape reader & punch. You could also punch a tape locally (keyboard to tape punch) then minimize your on-line time by quickly sending the pre-punched tape (tape reader to serial interface). I believe paper tape is why the ASCII delete character is 0x7F (all holes punched). Great fun to make chaff by punching a tape of all delete chars. Receiving a delete caused the head to cycle but the latch magnets did not engage. Reading a tape of all deletes caused the ASR-33 to sit there and vibrate but not print anything. Lee Jones

2005\09\16@211738 by Carey Fisher - NCS

> You could also punch a tape locally (keyboard to tape punch) then > minimize your on-line time by quickly sending the pre-punched tape > (tape reader to serial interface). > > I believe paper tape is why the ASCII delete character is 0x7F (all > holes punched). Great fun to make chaff by punching a tape of all > delete chars. Receiving a delete caused the head to cycle but the > latch magnets did not engage. Reading a tape of all deletes caused > the ASR-33 to sit there and vibrate but not print anything. > > Lee Jones My first teletype machine was a Model 19 - 45.45 baud, Baudot code (6 bits?). It did not have a synchronous motor, just a little lever on the motor you adjusted while watching the strobe pattern on the motor with a tuning fork that had a built in viewing window. When the lines stood still, you were right on speed - for a short period of time. The machine worked great on 20M RTTY with a homemade (vacuum) tube "modem" - they were called Terminal Units (TU) back then. When it was receiving, the whole house shook. If it ever hit resonance with the framing, it would have brought the house down. Carey , K8VZ

2005\09\17@011706 by Matthew Miller

On Fri, Sep 16, 2005 at 09:07:36PM +0300, Peter wrote: > > On Thu, 15 Sep 2005, Howard Winter wrote: > > >I'm a bit amazed that considering the maturity of programming as a > >function, that there aren't better editors around designed for it. I > >have yet to find any that do everything you'd want in one program. > > Try emacs Yes, see this page: http://www.cs.utah.edu/dept/old/texinfo/emacs18/emacs_23.html Matthew -- Whatever you do will be insignificant, but it is very important that you do it. -- Gandhi

2005\09\17@093230 by michael brown

----- Original Message ----- From: "Lee Jones" <@spam@lee@spam@spam_OUTfrumble.claremont.edu> > As I recall, the Teletype printing terminals, such as the models > 33, 35, & 37 (both ASR & KSR variants) all had fixed hardware tab > stops every 8 characters. And you _really_ wanted 1 tab character > (not 8 space characters) when you were receiving your program listing > at 10 chars/sec (110 baud). IIRC, you could punch up a control card that defined tab stops wherever you wanted, auto skip zones and even numeric only areas. As I remember it many of the machines would often stop one space to the right of the defined tab because they never got properly adjusted. That service was reserved for actual keypunch professionals. ;-) > Bonus history question: What do tha accronyms ASR & KSR mean and > what hardware differed between those variants? How bout the RO models, did you forget about them? ;-) Unfortunately I had to suffer thru those days too. Rolls of yellow paper, how convenient and oh so easy on the eyes. Did you ever see a TWX machine?

2005\09\17@101838 by olin piclist

michael brown wrote: > IIRC, you could punch up a control card that defined tab stops > wherever you wanted, auto skip zones and even numeric only areas. As > I remember it many of the machines would often stop one space to the > right of the defined tab because they never got properly adjusted. > That service was reserved for actual keypunch professionals. ;-) I think you are remembering keypunch machines, not teletypes. These did indeed have a drum you could put a special card on that defined tab stops and other stuff. Teletypes like the ASR-33 and ASR-35 weren't that smart. One annoyance of the model 041(?) keypunch machine is that although it had a duplicate card function, it wasn't actually capable of duplicating an arbitrary binary card. Certain bit combinations that couldn't result from keystrokes caused the machine to jam. You could only create those cards in the manual "multi-punch" mode where you specified exactly which bits to punch out. That was also the way to clear a jam. Put it in multi-punch mode and bang on the keyboard like a monkey until all the punches got released and it could continue feeding the card thru. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com

2005\09\17@112029 by Howard Winter

Olin, On Sat, 17 Sep 2005 10:18:35 -0400, Olin Lathrop wrote: {Quote hidden}> michael brown wrote: > > IIRC, you could punch up a control card that defined tab stops > > wherever you wanted, auto skip zones and even numeric only areas. As > > I remember it many of the machines would often stop one space to the > > right of the defined tab because they never got properly adjusted. > > That service was reserved for actual keypunch professionals. ;-) > > I think you are remembering keypunch machines, not teletypes. These did > indeed have a drum you could put a special card on that defined tab stops > and other stuff. Teletypes like the ASR-33 and ASR-35 weren't that smart. > > One annoyance of the model 041(?) keypunch machine is that although it had a > duplicate card function, it wasn't actually capable of duplicating an > arbitrary binary card. I only remember the 029 cardpunch - but it sounds like what you're talking about. There was quite an art to using the program-card drum, and a lot of people didn't bother but did it all by hand - but it could save an awful lot of time once you'd cracked it. > Certain bit combinations that couldn't result from > keystrokes caused the machine to jam. You could only create those cards in > the manual "multi-punch" mode where you specified exactly which bits to > punch out. That was also the way to clear a jam. Put it in multi-punch > mode and bang on the keyboard like a monkey until all the punches got > released and it could continue feeding the card thru. I don't remember that problem, but I don't think I ever tried to duplicate binary cards. I do remember the special hook-ended knife used for getting bits of jammed card out from under the punch-head, though! :-) Cheers, Howard Winter St.Albans, England

2005\09\17@114616 by michael brown

----- Original Message ----- From: "Olin Lathrop" <spamBeGoneolin_piclistKILLspamembedinc.com> To: "Microcontroller discussion list - Public." <.....piclistspam_OUTmit.edu> Sent: Saturday, September 17, 2005 9:18 AM Subject: Re: [PIC] 16F684 & Interrupt Problems > michael brown wrote: > > IIRC, you could punch up a control card that defined tab stops > > wherever you wanted, auto skip zones and even numeric only areas. As > > I remember it many of the machines would often stop one space to the > > right of the defined tab because they never got properly adjusted. > > That service was reserved for actual keypunch professionals. ;-) > > I think you are remembering keypunch machines, not teletypes. These did > indeed have a drum you could put a special card on that defined tab stops > and other stuff. Teletypes like the ASR-33 and ASR-35 weren't that smart. Yes you are quite right, I don't know what I was thinking. I must have had a preliminary senior moment. ;-) > One annoyance of the model 041(?) keypunch machine is that although it had a > duplicate card function, it wasn't actually capable of duplicating an > arbitrary binary card. Certain bit combinations that couldn't result from > keystrokes caused the machine to jam. You could only create those cards in > the manual "multi-punch" mode where you specified exactly which bits to > punch out. That was also the way to clear a jam. Put it in multi-punch > mode and bang on the keyboard like a monkey until all the punches got > released and it could continue feeding the card thru.

2005\09\17@115403 by michael brown

From: "Howard Winter" > I don't remember that problem, but I don't think I ever tried to duplicate binary cards. I do remember the > special hook-ended knife used for getting bits of jammed card out from under the punch-head, though! :-) When I was in Air Force tech school, they warned us right off that it would be an automatic Article 15 for tossing the contents of a chad box in the air. I was always impressed at how well a card reader could fan fold a punch card. It also sounded neat when it happened.

2005\09\17@155032 by olin piclist

Howard Winter wrote: > I only remember the 029 cardpunch - but it sounds like what you're > talking about. Yeah, that's the one. I don't know where I got 041 from. > I don't remember that problem, but I don't think I ever tried to > duplicate binary cards. Then you must not have messed with an IBM 1130. The cold start card (or something like that) was one of those cards that would jam a 029 if you tried to duplicate the card. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com

2005\09\17@163943 by Lee Jones

>>> IIRC, you could punch up a control card that defined tab stops >> I think you are remembering keypunch machines, not teletypes. >> One annoyance of the model 041(?) keypunch machine > I only remember the 029 cardpunch - but it sounds like what you're > talking about. There was quite an art to using the program-card drum, The 80 column Hollerith cards were hand punched on the IBM 026 and later 029 models. I just noticed, that even after all these years, everybody calls it an 0xx (_with_ the leading zero). I don't remember the IBM model numbers for the computer peripheral card punches. There was also the smaller System 3 card with 96 columns (3 rows of 32 characters). I never hand punched those and don't recall the machine's model number. I did do an embedded controller for a System 3 multi-function card read/punch/print device once. Goal was data transfer between CP/M systems and the System 3. It worked too. A fascinating contract. Not lucrative, since I underestimated the work involved... >> caused the [keypunch] to jam. > I do remember the special hook-ended knife used for getting bits > of jammed card out from under the punch-head, though! :-) Wow, I haven't thought of that in a while. [pause] Just checked; I've still got one. Mine has saw teeth on the back side, opposite the hook-end. Cards were sometimes really jammed in there. Lee Jones

2005\09\19@042105 by Alan B. Pearce

>One thing with the teletypes, IRCC, was that there >wasn't any flowcontrol on the 110 baud line. Correct, only for the tape reader, I don't think the punch had control. >So a full carrriage return from right to left was >done in 1/10 of a second at the full 10 char/sec speed... I think it was longer than that - it required 2 full character times, which is why they used CR/LF at the end of lines. If you streamed the data out at the full 110B and used LF/CR on full length lines the first character on the next line got printed about half way across the page as the carriage was still returning. I remember seeing this happen as we had a machine that was used to make tapes for an NC machine, and for some reason these required LF/CR instead of CR/LF.

2005\09\20@122628 by Herbert Graf

On Thu, 2005-09-15 at 20:39 -0400, John Nall wrote: > I THINK that you are saying what I am fixing to say. :-) EMACS is not > for the faint of heart. It does everything anyone could possibly want > to do in a text editor (if one would want to call it by such a humble > name). Not quite everything. I regularly at work edit 500+MB text files, and for files that big vi (or specifically vile) is the best way (IMHO) to go. TTYL ----------------------------- Herbert's PIC Stuff: http://repatch.dyndns.org:8383/pic_stuff/

2005\09\20@155719 by Barry Gershenfeld

>I think it was longer than that - it required 2 full character times, which >is why they used CR/LF at the end of lines. If you streamed the data out at >the full 110B and used LF/CR on full length lines the first character on the >next line got printed about half way across the page as the carriage was >still returning. And if you had to add extra NULs beyond the LF, then your mechanism was in need of cleaning. At school there were about 30 of these machines, and a repair department that was constantly working on them. I got to see a lot of the insides, and hear about what broke and how to fix it. When you punched a row of Deletes you could hear it, with all the punches going. BTW 0x7F is only 7 bits; weren't there 8 bits on the tape? You rarely could control the upper bits, though, being dictated by the computer or the inteface. Delete was also called "rubout" because of what it did. I don't recall a hardware tab on any model Teletype. There was a "vertical tab" on some 33's which I think you set by configuring hardware inside the machine. The accidental ^K would spew paper. I think this was only on the pin-feed models. My second machine was a model 19. Any hams know what a "chicken shift" is? My first machine was loaned by a neighbor, a Model 2. Printed on a strip of paper. I found out why the telegrams all looked like that. Remarkably easy to drive. I started with an envelope detector and a power transistor, about 4 parts, and I could receive RTTY. OK, the "chicken shift": You pull the oscillator tube out, wrap a wire around the appropriate pin, then plug the tube back in. Now you can couple into the wire with a capacitor and a varactor, to get your frequency shift. No modifications to the radio. And if you think I used a real varactor to do this, you're not an experimenter... Barry Karen's law states that any technical discussion that runs long enough will inevitably degenerate into a techno-nostalgia session.

2005\09\20@162701 by Wouter van Ooijen

> When you punched a row of Deletes you could hear it, with all > the punches > going. BTW 0x7F is only 7 bits; weren't there 8 bits on the > tape? IIRC my ASR33 had only 7 bits on the tape. Or maybe an 8th don't-care bit. Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: http://www.voti.nl/hvu

2005\09\22@123610 by Howard Winter

On Tue, 20 Sep 2005 12:57:11 -0700, Barry Gershenfeld wrote: > When you punched a row of Deletes you could hear it, with all the punches > going. BTW 0x7F is only 7 bits; weren't there 8 bits on the tape? Yes, 3 on one side of the sprocket-hole, five on the other, so you couldn't mount it reversed by accident. You could feed it through backwards, though, so the tear-off tongue produced a "V" shaped end to the tape, so you could see which end was which (you fed it in the direction the "V" pointed). > You > rarely could control the upper bits, though, being dictated by the computer > or the inteface. On our ASR 33s the eighth was the parity bit. They used even parity, so NUL (no holes) and Rubout (8 holes) gave correct parity. > Delete was also called "rubout" because of what it did. Indeed, and thet key that punched it was marked as such. Cheers, Howard Winter St.Albans, England

More... (looser matching)
- Last day of these posts
- In 2005 , 2006 only
- Today
- New search...