Got a couple problems going on here ...
First the funky Config lines...
I came up with that quite some time ago as a way to shorten the __CONFIG lines in the editor.
It's been passed around a bit, and Hank had it right(almost) in the first post.
With the exception that _MCLRE_ON was duplicated(not a problem) it was perfect.
After time moves on, I tend to do it more like this now ... (16F690)The second problem here is Indentation.Code:ASM cfg= _XT_OSC ; Oscillator Selection cfg=cfg& _FCMEN_OFF ; Fail-Safe Clock Monitor cfg=cfg& _IESO_OFF ; Internal External Switchover cfg=cfg& _BOR_OFF ; Brown-out Reset cfg=cfg& _CPD_OFF ; Data Code Protection cfg=cfg& _CP_OFF ; Code Protection cfg=cfg& _MCLRE_ON ; Master Clear Reset cfg=cfg& _PWRTE_ON ; Power-up Timer cfg=cfg& _WDT_OFF ; Watchdog Timer __CONFIG cfg ENDASM
The forum tends to scrunch everything up to the left side if you don't use a [code][/code] block.
Copying snippets from the forum often leads to problems if you forget about the indentation. Especially when it's ASM code.
Take a look at the original examples for DT_INTS and you can see the proper indentation for the ASM statements.
Indentation applies to the @ operator too.
Removing the space between the @ and INT_ENABLE etc, does not do what you want it to do. That space must be there.
<br>
DT
Wow...from the man himself! cool.
I figured it was something to do with formatting (the errors I was seeing alluded to it... hence me experimenting the space after the @ !!)
Anyway, in the light of your info ...it all compiles fine! (*many* thanks!)
My problem now is a simple one, why is my 'if' condition not being met when the 1 key is being pressed on my PC keyboard...
(hey, I can do boxes now too! tks Ioannis)Code:loop: if mybyte="1" then hserout ["got it!"] endif if mybyte<>"1" then hserout ["DIDN'T GET IT!",13,10] hserout [mybyte,13,10] ' (tried to add in this line to see onscreen what the content of mybyte is - nothing output!) PAUSE 499 mybyte=0 endif goto loop
All I see on my ASCII terminal when the program is running is "DIDN'T GET IT!" scrolling down - which suggests that when I press the "1" key, the content of variable mybyte is not 00000001 (but possibly an ASCII interpretation of the number 1 (the ASCII for 1 is 49 tried that but it errored!).
I normally spontaneously combust as I try to work out what I should be 'matching' against, so could someone save the fire brigade a visit here - it makes a terrible mess of the carpet!
Many thanks!
Last edited by HankMcSpank; - 17th June 2009 at 13:00.
Sorry, the only water I have is used Beer.
Hope it's a small fire.
So where is mybyte getting read?
I assume there's an HSERIN [mybyte] somewhere? (In the loop?)
<br>
DT
And where do you read the serial in port???
Ioannis
Last edited by Ioannis; - 17th June 2009 at 13:06. Reason: Darrel got me...!
Sorry, I was just stripping out the interupt bits (since they are compiling fine now), but yes, I can see how that's confused you all!
Anyway, to show off my new found "box" skills, here you go...
My (noob) take here is that, when a key is pressed, the interrupt routine jumps to the Get_char - this keyboard 'keyed' "data" is then stored in the variable mybyte - but what will the actual contents of mbyte be ? For example if I press a "1" key on the keyboard will it be 00000001 (unlikely!), or 00110001 (binary for 49 - the ASCII code for the number "1"). Once I can figure out this bit, then I can make sure my "if" takes account of it. (that'll be my next question!) Also, the line I bolded...I was trying to see onscreen what the content of the variable mybyte was - but nothing was output?Code:@MyConfig = _XT_OSC & _WDT_ON & _MCLRE_ON & _CP_OFF @MyConfig = MyConfig & _BOR_OFF @ __config MyConfig INCLUDE "DT_INTS-14.bas" ; Base Interrupt System INCLUDE "ReEnterPBP.bas" ; Include if using PBP interrupts DEFINE OSC 4 DEFINE HSER_SPBRG 25 DEFINE HSER_TXSTA 24h DEFINE HSER_CLROERR 1 ANSELH=0 ANSEL=0 CM1CON0 =0 CM2CON0 =0 CM2CON1 =0 adcon1=0 TRISB.6 = 1 TRISB.7 = 0 TRISC=%00000000 ; set all Port C pins as outputs rcsta.7=1 'SPEN serial port enable bit low portc.0 low portc.1 low portc.2 low portc.3 mybyte var byte '::::::::::::::::::::::::::::::::::::::::::::::::: :::::::::::::::::::::::::: ASM INT_LIST macro ; IntSource, Label, Type, ResetFlag? INT_Handler RX_INT, _Get_char, PBP, yes endm INT_CREATE ; Creates the interrupt processor ENDASM '::::::::::::::::::::::::::::::::::::::::::::::::: :::::::::::::::::::::::::: @ INT_ENABLE RX_INT ; enable external (INT) interrupts loop: if mybyte="1" then hserout ["got it!"] endif if mybyte=!"1" then hserout ["DIDN'T GET IT!",13,10] hserout [mybyte,13,10] ' (tried to add in this line to see onscreen what the content of mybyte is - nothing output!) PAUSE 499 mybyte=0 endif goto loop '---[USART RX - interrupt handler]--------------------------------------------------- Get_char: hserin 100,noreceived,[mybyte] 'Get byte noreceived: 'or if timeout return @ INT_RETURN
BTW The low portc.0 low portc.1 are in there because I have a Microchip low pin count demo board & my (eventual) target for today is to get some LEDs to light up when certain keys on my PC keyboard are pressed - I'm a simple kind of easy to please chap, who marvels at this kind of thing & insists all around me marvel too! (though it irks my two year old something rotten when I interrupt his Thomas The Tank Engine viewing)
Last edited by HankMcSpank; - 17th June 2009 at 13:38.
My guess is that ... 99.99% of the time is spent in the PAUSE 499 statement.
So if anything does come in via the USART in the interrupt during that time, the byte received will be immediately discarded with the mybyte=0 statement that follows.
<br>
DT
Ok, so I stripped that bit out - only this bit remains...
yet when I press the "1" key on my PC keyboard...nothing happens (ie I don't see "Got it!" on my terminal, which seems very apt as I really don't get it!)Code:loop: if mybyte="1" then hserout ["got it!"] mybyte = 0 endif goto loop
??
Last edited by HankMcSpank; - 17th June 2009 at 14:05.
Bookmarks