Instant Interrupts - Revisited - Page 2
+ Reply to Thread
Page 2 of 20 FirstFirst 12345612 ... LastLast
Results 41 to 80 of 791
  1. #41
    Join Date
    Sep 2005
    Location
    Campbell, CA
    Posts
    1,107

    Default

    No chance.
    Charles Linquist

  2. #42
    Join Date
    Jul 2003
    Location
    Colorado Springs
    Posts
    4,959

    Default

    Do you have anything else designated as BANKA.

    PBP uses some of it, and there's only 128 bytes.

    Arrays, eat it up fast too.

    ??
    <br>
    DT

  3. #43
    Join Date
    Jan 2005
    Location
    Montreal, Quebec, Canada
    Posts
    2,253

    Default

    I have a habit of placing INCLUDES at the top of a program. I would assume Darrel's routine would allocate whatever it wants in whatever bank first, then my program would take up what is left.

    If I run out of space I know I have to trim excess fat from my code, or upgrade the mcu.

    Robert
    Not as dumb as yesterday, but stupider than tomorrow!

  4. #44
    Join Date
    Jul 2003
    Location
    Colorado Springs
    Posts
    4,959

    Default

    And a good habit it is.

    I also tend to put initialization code in the Include files that need to run before the main program starts. So the top is the best, and don't jump over them.

    DT

  5. #45
    Join Date
    Sep 2005
    Location
    Campbell, CA
    Posts
    1,107

    Default

    This is what I have. This is before I decare any other variables. I figure I'm not using anything close to 128 bytes. Any other ideas?
    I AM declaring a LOT of variables after this block, however.


    MasterClock VAR WORD bankA system
    FanClock VAR WORD bankA system
    Fan1Counter VAR WORD bankA system
    Fan2Counter VAR WORD bankA system
    Fan3Counter VAR WORD bankA system
    Fan4Counter VAR WORD bankA system
    Fan5Counter VAR WORD bankA system
    Fan6Counter VAR WORD bankA system
    Fan7Counter VAR WORD bankA system
    Fan8Counter VAR WORD bankA system
    Fan9Counter VAR WORD bankA system
    changedB VAR BYTE bankA system
    OldPortB VAR BYTE bankA system
    changedC VAR BYTE bankA system
    Temp VAR BYTE bankA system
    TPE VAR BYTE bankA system
    Charles Linquist

  6. #46
    Join Date
    Jul 2003
    Location
    Colorado Springs
    Posts
    4,959

    Default

    I found that if I select a 16F877A, instead of an 18F part, I get the exact same errors. Could Be?

    DT

  7. #47
    Join Date
    Sep 2005
    Location
    Campbell, CA
    Posts
    1,107

    Default

    18F8720

    If you want to try it yourself, send me your email address to

    Charles.Linquist@Gmail.com
    Charles Linquist

  8. #48
    Join Date
    Jul 2003
    Location
    Colorado Springs
    Posts
    4,959

    Default

    Charles,

    Got the program. It's a monster.

    And, I've learned a couple things today. First, Microchip pulled a fast one on me.

    Chips like the 18F252/452/1220 etc. etc. have 128 bytes designated in the lower half of BANKA, ranging from 00h to 7Fh.

    But, the larger chips such as 18Fxx20's only have 96 bytes, 00h to 5Fh. It's really odd, because they've taken the extra space, and turned it into "Note 1: Unimplemented registers are read as ‘0’.". I guess they're saving it for Future Use.

    That wasn't very nice of them.

    Second, it seems the SYSTEM modifier is doing some things that I didn't expect.
    Sometimes I use the SYSTEM to simply remove the Underscore from variable names in ASM routines. But, it appears that SYSTEM does a little more than that with these chips.

    If a variable is declared as...

    <pre>Avar VAR BYTE SYSTEM ; without specifying the bank</pre>it will be placed in BANKA, even though BANKA wasn't specified.

    This seems to happen because PBP sorts things alphabetically, and with SYSTEM removing the underscore it causes them to be sorted in with the BANKA SYSTEM variables.

    Same thing happens with the PBxx BIT variables too. And, the complex octal formulas have created 12 temp (T) word variables, that also go in BANKA.

    So BANKA is filling up with stuff that wasn't designated as BANKA, and now that there's less BANKA available, it's running out of room.

    This problem also continues out into the other banks too. In ReEnterPBP-18, I have...

    <pre>HP_Vars VAR WORD[22] BANK0</pre>Which you would think will automatically go into BANK0 before it starts allocating other variables, but it doesn't. It only fits in BANK0 if it also happens to line up alphabetically. So all variables from _A... to _H... get assigned first. Then HP_Vars throws an error.

    Adding SYSTEM after it...

    HP_Vars VAR WORD[22] BANK0 SYSTEM

    Removes the underscore, and allows it to "sort" into the list before all the _A.._Z variables, and therefore fits in BANK0 just fine.

    At this point, I'm stopping short of calling it a Bug in PBP, because maybe it's just different than what I'm expecting. However, when you declare a variable in BANK0, you would expect it to be placed there! But that's not necessarily what happens.

    <hr>Now then, what to do about it.

    On my end, I've pulled as much as I could out of BANKA and BANK0, and specified BANKs for all system variables. This should help with the smaller BANKA. Still need a few in there but its only about 6 bytes. I've updated the files on the website. Please download them again.
    http://www.pbpgroup.com/modules/wfse...p?articleid=21

    On your end, since you don't actually use the BANKA modifier in your ASM routines (except for a couple PORTB accesses) all your BANKA variables would be just as happy in BANK0. But I think there's still enough room now if you want to leave them.

    But the biggest thing to do is with the temp vars. This line...

    IF (((OCT [0]-48)*100) + ((OCT [1]-48)*10) + (OCT [2] -48) > 255) OR (((OCT [3]-48)*100) + ((OCT [4]-48)*10) + (OCT [5] -48) > 255) OR (((OCT [6]-48)*100) + ((OCT[7]-48)*10) + (OCT [8] -48) > 255) OR (((OCT [9]-48)*100) + ((OCT [10]-48)*10) + (OCT [11] -48) > 255) THEN

    Is creating 12 temp vars (T1-12). ReEnterPBP-18 is only set up for 7. So you'll either need to cut the formula into smaller pieces, or modify the ReEnterPBP-18 files to be able to handle that many temp vars. I'd recommend cutting it.

    There were some other things missing, but I assume that was from not being able to compile it.

    Thanks for the "HUGE" program example, It's easy to miss that kind of stuff with the little ones.

    Added: Forgot to mention, Don't jump over the INT_LIST and INT_ENABLEs. They have to actually execute, to work properly.

    <br>
    Last edited by Darrel Taylor; - 19th July 2006 at 01:43. Reason: Added
    DT

  9. #49
    Join Date
    Sep 2005
    Location
    Campbell, CA
    Posts
    1,107

    Default

    Darrel,

    Thanks for all the work!

    I keep telling people that I probably have the "world's biggest running PBP program", maybe now I have a witness.

    The reason it wouldn't compile is that I was in the process of working DT_Ints into the program but didn't have everything completed. Sometimes, I know that there are unresolved issues, but I hit "compile" anyway so that the compiler can do some of the work of finding errors for me.

    Now, I'll have to see if I can make it all work at my end. I'll let you know.

    Again, thanks for your help.
    Charles Linquist

  10. #50
    Join Date
    Sep 2005
    Location
    Campbell, CA
    Posts
    1,107

    Default

    Darrel,

    It compiles and assembles "clean". I changed my test for invalid IP addresses.
    T5 is the last temp variable used.

    Now I just have to "wire" in the ISR's to the rest of the program and test.


    YAAAAAAAAAAY !
    Charles Linquist

  11. #51
    Join Date
    Jul 2003
    Location
    Colorado Springs
    Posts
    4,959

    Default

    Sweet!

  12. #52
    Join Date
    Oct 2003
    Location
    Australia
    Posts
    257

    Unhappy

    Hi Darrel,

    This is pretty neat code Pretty amazing really. Hahaha

    Anyway, I have a problem with my PIC hanging up because of an Idle State logic level error see <a href="http://www.picbasic.co.uk/forum/showthread.php?t=4301"> Here</a> on a serial input pin.

    I dont want to over complicate the circuit with extra hardware to get around this so I thought that I could use you interrupts to to side step this problem and do it all in software.

    Unfortunately the TMR1 interrupt stops working as well while waiting for serial data eg

    HSERIN [WAIT ("SOME DATA")]

    I was hoping that these interrupts routines were bullet proof regardless of what the program was doing.

    Any ideas?

    Regards
    Squib

  13. #53
    Join Date
    Jul 2003
    Location
    Colorado Springs
    Posts
    4,959

    Default

    Squib,

    TMR1 interrupts will not stop when using HSERIN. Unless the HSERIN is also in an interrupt handler.

    As for the Hanging, the USART will give a Framing Error (RCSTA.2) if the RX pin is held low. Check for the error before trying to HSERIN.
    <br>
    DT

  14. #54
    Join Date
    Jan 2005
    Location
    Montreal, Quebec, Canada
    Posts
    2,253

    Default

    Darrel,

    Any obvious reason why this program takes over 10 seconds to start up on a PIC 18F4550?

    If I comment out the Interrupt settings at the top (includes and asm) and the ReceiveUSART handler further below, it takes less than 2 seconds.

    Robert
    Attached Files Attached Files
    Not as dumb as yesterday, but stupider than tomorrow!

  15. #55
    Join Date
    Jul 2003
    Location
    Colorado Springs
    Posts
    4,959

    Default

    Not sure about this, but gotta start somewhere.

    The RX_INT is being ENABLEd before the USART registers are set-up. Or, more accurately, since HSERIN/OUT are used in the program, PBP initializes the USART first, then RX_INT is enabled, then the USART registers are changed.

    It may be causing a false interrupt that sends it to the ReceiveUSART: handler, which is expecting to see 2 bytes being received, that were never sent. So it sits there.

    Try using this...
    Code:
    DEFINE HSER_CLROERR 1  ' Hser clear overflow automatically 
    DEFINE HSER_RCSTA 90h  ' Hser receive status init 
    DEFINE HSER_TXSTA 24h  ' Hser transmit status init 
    DEFINE HSER_SPBRG 0    ' Hser spbrg init 
    
    While PIR1.5 = 1     ; clear the buffer
        HSERIN [varByte]
    Wend
    
    @ INT_ENABLE  RX_INT     ; enable RX interrupts
    In place of..
    Code:
    @ INT_ENABLE  RX_INT     ; enable RX interrupts
    
    
    DEFINE  HSER_SPBRG  0               ' 1250 KBAUD @ 20 MHz (CPU)
    
            BAUDCON.3 = 0               ' BRG16 Select 8 bit baud rate generator
    
            TXSTA.5 = 1                 ' TXEN  Enable USART transmitter
            TXSTA.4 = 0                 ' SYNC  Asynchronous communication
            TXSTA.2 = 1                 ' BRGH  High speed baud rate
    
            RCSTA.7 = 1                 ' SPEN  Enable USART receiver
            RCSTA.4 = 1                 ' CREN  Enable continuous receive
    DT

  16. #56
    Join Date
    Jan 2005
    Location
    Montreal, Quebec, Canada
    Posts
    2,253

    Default

    Nope, wasn't it. But as I was putzing around trying other stuff I noticed a few attempts were within 2 seconds, but for no apparent reason. For some reason it appeared to be an unstable setup and I remembered that unset pins can do this. And that's when I remembered this from page 235 of the 18F4550:

    -----------------------------------------------------------------------
    The pins of the Enhanced USART are multiplexed with
    PORTC. In order to configure RC6/TX/CK and
    RC7/RX/DT/SDO as a USART:
    bit SPEN (RCSTA<7>) must be set (= 1)
    bit TRISC<7> must be set (= 1)
    bit TRISC<6> must be cleared (= 0) for
    Asynchronous and Synchronous Master modes
    or set (= 1) for Synchronous Slave mode
    -----------------------------------------------------------------------

    I had ignored this paragraph 'cause I had never seen a need for these resistors, I thought it was only for the Enhanced USART. So I added the 4K7 resistors on TX (pulldown) and RX (pullup) and everything works fine, even with my old code.

    Thanks D!

    Robert
    Not as dumb as yesterday, but stupider than tomorrow!

  17. #57
    Join Date
    Jan 2005
    Location
    Montreal, Quebec, Canada
    Posts
    2,253

    Default

    Well, I misunderstood what I was supposed to do but when I removed the resistors and put in the TRIS statements it took 9 seconds again. So I set the port pins to 0, same thing, I set them to 1, same thing.

    It works properly with just the 4K7 resistors.

    EDIT: I tried pulling both pins down and that works as well.

    Robert
    Last edited by Demon; - 23rd July 2006 at 16:34.
    Not as dumb as yesterday, but stupider than tomorrow!

  18. #58
    Join Date
    Jan 2005
    Location
    Montreal, Quebec, Canada
    Posts
    2,253

    Default

    This is great stuff Darrel. I've added interrupts for USART communication between a master and 2 slaves and it works like a charm.

    Now I need to service the USB line every "once in a while" and read a previous reply of yours:
    http://www.picbasic.co.uk/forum/show...9&postcount=33

    This stuff went WHOOOOSH right over my head, you lost me as soon as you started talking about hertzes. From your post I know I have to adjust the prescaler, as well as possibly manage a counter, but that's about it. I have no idea what values to use as a reasonable starting value (I figure some tweaking will be necessary).

    This is the base I have so far, including relevant oscillator information:

    Robert
    Attached Files Attached Files
    Not as dumb as yesterday, but stupider than tomorrow!

  19. #59
    Join Date
    Jul 2003
    Location
    Colorado Springs
    Posts
    4,959

    Default

    "master and 2 slaves", mmm kinky!

    Well, I can answer part of it.

    Just change ...

    <pre>T1CON = $11 ; Prescaler = 2, TMR1ON</pre> @ 48mhz, that will give an interrupt every 10.9 ms. No need to reload the timers.

    According to the PBP manual, USBservice should be called every 10ms, but it doesn't have to be that precise.

    However,

    I have no idea what will happen when you interrupt another USB routine and try to do a USBservice.
    My guess is that it won't be pretty.

    More than likely, you will need to INT_DISABLE the TMR1_INT, before doing anything else with the USB, then INT_ENABLE it when it's done.
    <br>
    DT

  20. #60
    Join Date
    Jan 2005
    Location
    Montreal, Quebec, Canada
    Posts
    2,253

    Default

    Ok, I added the disable/enable at both assembler USB routines generated from HIDMaker but the device is not recognized. I rummaged through the datasheet for TMR1 and T1CON and found this:

    ================================
    When Timer1 is enabled, the RC1/T1OSI/UOE and
    RC0/T1OSO/T13CKI pins become inputs. This means
    the values of TRISC<1:0> are ignored and the pins are
    read as 0.
    ================================

    Now that sucks, I'm using those pins as output to a LCD. I expected the LCD to spaz out but it's working fine.

    I had started with an 18F4550 QFP but had downgraded to a 18F2550 SOIC, easier to solder. I don't have any output pins to spare either, the only pin I'm not using is A3.

    I hate to have to yank all this off the breadboard to put back the 18F4550, again, but I might not have any choice.

    I think I'm going to comment out all unnecessary code (interrupts/HSERIN/HSEROUT) until I have a working USB program again (sprinkling USBSERVICE everywhere). Then I'll put the USB interrupt back in and go on from there.

    Robert
    Not as dumb as yesterday, but stupider than tomorrow!

  21. #61
    Join Date
    Jan 2005
    Location
    Montreal, Quebec, Canada
    Posts
    2,253

    Default

    D'oh! Enabling the USB interrupt before USBINIT was not one of my better ideas.

    Step 1: I commented out everything except the LCD and sprinkled USBSERVICE everywhere it is recognized.

    Step 2: I comment out all USBSERVICE and restored the TMR1 interrupt for USBSERVICE and it failed to be recognized (enabling it immediately after USBINIT).

    Robert
    Not as dumb as yesterday, but stupider than tomorrow!

  22. #62
    Join Date
    Jan 2005
    Location
    Montreal, Quebec, Canada
    Posts
    2,253

    Default

    Step 3: I skipped over all code relating with the LCD and it still is not recognized.

    So now I've narrowed it down to the TMR1 interrupt not working perfectly. How can I tweak it to interrupt at a faster rate?

    I assume I have to accelerate the prescaler, I just don't know which way is which. And then possibly adding a counter to fine-tune the interval between USBservice.

    Robert
    Not as dumb as yesterday, but stupider than tomorrow!

  23. #63
    Join Date
    Jan 2005
    Location
    Montreal, Quebec, Canada
    Posts
    2,253

    Default

    I had screwed up the disabling/enabling of the interrupt during USB subroutines.

    Step 4: Disabled TMR1 _before_ the assembler loop, manually issue USBSERVICE within the loop and then enabled TMR1 after the loop and the device is recognized.

    Robert
    Not as dumb as yesterday, but stupider than tomorrow!

  24. #64
    Join Date
    Jan 2005
    Location
    Montreal, Quebec, Canada
    Posts
    2,253

    Default

    Step 5: Reactivated LCD logic along with USART and RX interrupt and device is still recognized.

    Go figure, the LCD works properly even if I'm using pins C0 and C1 to output the data and commands to the LCD.

    Robert


    EDIT: I'm thinking the LCD works because I'm not using an external oscillator for the timer.
    ================================
    When Timer1 is enabled, the RC1/T1OSI/UOE and
    RC0/T1OSO/T13CKI pins become inputs. This means
    the values of TRISC<1:0> are ignored and the pins are
    read as ‘0’.
    ================================
    Last edited by Demon; - 25th July 2006 at 13:46.
    Not as dumb as yesterday, but stupider than tomorrow!

  25. #65
    Join Date
    Dec 2005
    Posts
    1,073

    Default

    Can DT_INTS-14.bas be used with 12Fxxx PICs?

  26. #66
    Join Date
    Jul 2003
    Location
    Colorado Springs
    Posts
    4,959

    Default

    YES!

    It's a little tight for RAM and program space. But it should work.

    DT
    DT

  27. #67
    Join Date
    Jan 2005
    Location
    Montreal, Quebec, Canada
    Posts
    2,253

    Default

    One note of interest, I kept hanging at the end of one of the interrupt modules, like it lost an address on the stack or something. I ran ICD and I saw the execution just hang on the ENDIF at the very bottom.

    I have an RX interrupt that would write out to an I2C device 2 bytes received via USART. I removed the I2C command from within the interrupt and instead set a flag. Then I checked the flag from within the main logic and issued the I2C write and everything worked perfectly.

    Darrel, here are some screenshots in case you see something obvious. Sorry, I didn't keep a copy of the code.

    Robert
    Attached Images Attached Images  
    Not as dumb as yesterday, but stupider than tomorrow!

  28. #68
    Join Date
    Jan 2005
    Location
    Montreal, Quebec, Canada
    Posts
    2,253

    Default

    2nd pic:

    The program USB 18F2550 is for the master processor, that is not the one I am debugging. I am running the next program, MCP23016 16F628A.

    Robert
    Attached Images Attached Images  
    Not as dumb as yesterday, but stupider than tomorrow!

  29. #69
    Join Date
    Jul 2003
    Location
    Colorado Springs
    Posts
    4,959

    Default

    Interrupts and the MCSP debugger, don't get along together very well.

    You should use DISABLE DEBUG before any interrupt routines, Including the Handlers.

    Then ENABLE DEBUG after them.

    It is possible to save the debugger variables in the same way as ReEnterPBP, but it's a waste of space when not debugging, so I didn't include them

    HTH,
    &nbsp; DT

  30. #70
    Join Date
    Jan 2005
    Location
    Montreal, Quebec, Canada
    Posts
    2,253

    Default

    The weird part is that the interrupts and the debugger worked nicely as long as the I2C command was outside the interrupt routine.

    I suppose there are probably exceptions, but disabling/enabling debug in and out of interrupts isn't the end of the world. It's not like we need to debug your work.

    Robert
    Not as dumb as yesterday, but stupider than tomorrow!

  31. #71
    Join Date
    Jul 2003
    Location
    Colorado Springs
    Posts
    4,959

    Default

    It's kind of like standing on the white line in the middle of a highway.

    Everythings fine for a while, with cars wizzing past at 90mph.

    But take one step to the left or right and, <img src=http://www.darreltaylor.com/files/splash.jpg height=70 width=70 align=top></img>
    DT

  32. #72
    Join Date
    Jul 2003
    Posts
    2,405

    Default

    Go like splat ehh...;o}
    Regards,

    -Bruce
    tech at rentron.com
    http://www.rentron.com

  33. #73
    Join Date
    Jul 2003
    Location
    Colorado Springs
    Posts
    4,959

    Default

    Oh yeah, goes like big Splat!
    There's a thump thump involved too, but you won't hear that part.

    And, much like the highway, everything comes to a halt until the investigation is completed.

    I'm just affraid I killed off Spock.
    Who else would leave a green Splat?

    Well, the moral of the story is two fold.

    1. Don't stand in the middle of the Highway.

    2. Don't try to Debug your interrupt routines.

    LOL,
    &nbsp; DT

  34. #74
    Join Date
    Dec 2005
    Posts
    1,073

    Default

    Quote Originally Posted by Darrel Taylor
    Can DT_INTS-14.bas be used with 12Fxxx PICs?
    YES!

    It's a little tight for RAM and program space. But it should work.
    With a 12F629 my app gets lots of "beyond ram_end" messages; with a 12F683, only two, so I might be able to pare it down to fit.

  35. #75
    Join Date
    Jul 2003
    Location
    Colorado Springs
    Posts
    4,959

    Default

    If you don't have any complex math formula's in the program, you can reduce the number of T?_Save variables.

    From ReEnterPBP.bas...
    T1_Save VAR WORD
    T2_Save VAR WORD
    T3_Save VAR WORD
    T4_Save VAR WORD


    Start with T4. Comment it out and recompile. If no error, try T3, etc.

    Then try ...
    RS1_Save VAR BYTE
    RS2_Save VAR BYTE


    Might save a few bytes of RAM.

    Just remember to un-comment them if you write a program for another chip.

    DT

  36. #76
    Join Date
    May 2006
    Posts
    36

    Default

    I am trying to use the instant interrupts to add the funnctionality of interrupts to my programs but I am having problems with the example that found on Darryl's site. I was trying to do the example with turning a LED on and off with an external interrupt but I am having some problems. I have downloaded the latest files form Darryl's site and have saved them to same folder. I have copied the code from hiw webpage also.
    I am using PICBASIC Pro vers.2.46
    I am using the PIC16F687.

    I am getting the following errors
    Error TOGGLE~1.ASM 490 : [224] local directive only for use in macros
    Error TOGGLE~1.ASM 490 : [225] undefined symbol 'iflagreg'
    Error TOGGLE~1.ASM 490 : [226] numeric constant or symbol name expected
    Error TOGGLE~1.ASM 490 : [201] ')' expected
    Error TOGGLE~1.ASM 490 : [300] too many errors

    I commented out the Wsave's that were not needed. I have some experiece with writing programs in assembly and working with interrupts. I have looked through the include files to see if I could make sense of what is going on but I am having problems figuring it out.
    Can you direct to anywhere that will give me more information about macros? Any suggestions? Thanks for your time and help.

    Josh

    EDIT
    Looking at the datasheet for the 16F687 there IS an External interrupt on RA2 instead of RB0. There is a Port change interupt on both Port A and B. Do I have to modify the file to include the interrupt on PortA? I would want to place any available interrupt pin that I can.
    Last edited by jblackann; - 31st July 2006 at 16:31.

  37. #77
    Join Date
    Jul 2003
    Posts
    2,405

    Default

    Use the MPASM assembler.
    Regards,

    -Bruce
    tech at rentron.com
    http://www.rentron.com

  38. #78
    Join Date
    Dec 2005
    Posts
    1,073

    Default

    Quote Originally Posted by Darrel Taylor
    If you don't have any complex math formula's in the program, you can reduce the number of T?_Save variables.
    There's no math but it didn't help. I think I'll have to try to learn enough ASM for this application. I just need TMR0 to toggle a pin every 8-10mS and TMR1 to give me a 500S or 1000S interval after each TMR0 rollover.

  39. #79
    Join Date
    Jul 2003
    Location
    Colorado Springs
    Posts
    4,959

    Default

    Hi Josh,

    The INT_INT should work ok, even with it on PORTA.

    For the Interrupt on change with PORTA and PORTB, just add these two lines in the ASM section right before the INT_LIST

    RBIF = RABIF
    RBIE = RABIE
    (no space at the beginning of the line)

    Then use RBC_INT. I'll add RABC_INT, C1_INT and C2_INT names in DT_INTS-14 later, but that should get you going for now.

    HTH,
    &nbsp; Darrel

  40. #80
    Join Date
    Jul 2003
    Location
    Colorado Springs
    Posts
    4,959

    Default

    dhouston,

    For the 12F683...
    Did you comment out the wsave2 and wsave3 variables in DT_INTS-14?

    DT

Similar Threads

  1. Clock using Instant Interrupts
    By PICpocket in forum mel PIC BASIC Pro
    Replies: 3
    Last Post: - 16th February 2009, 22:43
  2. DT instant interrupts with mister_e keypad
    By Tomexx in forum mel PIC BASIC Pro
    Replies: 5
    Last Post: - 26th November 2008, 21:02
  3. DT's Instant Interrupts trouble
    By Tomexx in forum mel PIC BASIC Pro
    Replies: 7
    Last Post: - 24th November 2008, 21:48
  4. Keypad and DT's Instant Interrupts
    By Homerclese in forum General
    Replies: 11
    Last Post: - 27th April 2007, 06:32
  5. Replies: 1
    Last Post: - 1st November 2006, 04:11

Members who have read this thread : 31

You do not have permission to view the list of names.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts