Still HSEROUT woes

[mister_e]

well let's see it in the simplest way... an Interrupt flag have been set, it jump to the ISR but he's not clear before going out... what happen? it return back to the ISR as soon as possible.

As it's just a single character.. HSERIN can be changed to

x=RCREG
While RCREG : Discard=RCREG : Wend

or few lines of assembler...

OUF, at least i wasn't too far.. that's good for my own self esteem

[Charles Linquis]

I can deal with the requirement to read the RCREG from within the ISR, but having to shut off the interrupts while running HSEROUT is more problematic. I have to run full-duplex in my application. That is why I needed it interrupt-driven in the first place!

[Charles Linquis]

SteveB:

Confirming - I took your code and loaded it into my 8720. It works as expected, except that it doesn't handle USART interrupts (as you mentioned). I'm thinking that your routine works better because you saved/restored BSR, while I was was saving/restoring FSR0L and FSR0H.

I have an email to MELABS. Maybe they can shed some light on this.

When we are done, I think we will have a good framework for how to deal with interrupts in the 18F series!

[Charles Linquis]

PROBLEM SOLVED!

I have been conversing with Tim Box. Although he no longer writes in PBP, he had some great insights.

I'll be able to write a short tutorial on using interrupts with 18F parts and PBP tonight.

Many thanks to all who contributed!

[BigWumpus]

...I'm using interrupts with the 18Fxxxx and...

the WSAVE...etc-part in front of a interrupt-handler is ONLY neccessary for PICs with up to 2048 words ? (PIC16F872). Bigger PICs don't need the code in the beginning, it is placed by PBP. The restore-code before the retfie is only used for PICs <PIC18, because they know the "retfie 1"-solution to restore all this silly registers, saved by an interrupt... (PBP doesn't support high/low-priority-Ints, so no other interrupt is used!)

But don't try to use PBP inside a interrupt-service-routine !

[mister_e]

Once all PBP variable saved.. you can use PBP statement inside the ISR
<img src="http://www.picbasic.co.uk/forum/attachment.php?attachmentid=960&stc=1&d=1152565276 ">

18Fs are different right, but how... i can't say, as now the regular method work for my requirement... as now. So i guess i should look deeper in that one in case i need something like this.

In this case, there's no big stuff to do in the ISR... so, my question is... is this longer to do only a pure assembler routine... or messing 'round with the known 'once the PBP variables are saved...' stuff. mmm

I miss something in that one anyways... i'll go deeper on my side too. Maybe i could help.

[SteveB]

OK, I've been using an 18F4620 with multiple, prioritized interrupts for a while without any problems. So here a couple of things I know for sure regarding assembly interrupts.

1. PBP does not save context for the 18F4620 (and presumably all the PIC18s), which has >2K program space (The PIC18F2620 and PIC18F4620 each have 64 Kbytes of Flash memory and can store up to 32,768 single-word instructions.). Here are some snippets from the .lst file with some explanatory comments. It clearly shows that PBP does not enter any additional code into Assembly Interrupts.
   
   

   Here are the Defines
   
                         00008 ; Define statements.
                         00009 ; C:\PIC_CODE\MICROC~1\PIC18F~1\CUR\MAIN.BAS    00013   DEFINE  OSC 40 'Oscillator speed in MHz: 3(3.58)
                                4 8 10 12 16 20 24 25 32 33 40 
                         00010 #define         OSC              40 
                         00011 ; C:\PIC_CODE\MICROC~1\PIC18F~1\CUR\INTERRUPT_HANDLER.BAS       00009   DEFINE  INTHAND  HP_INT_ENTRY
                         00012 #define         INTHAND           HP_INT_ENTRY
                         00013 ; C:\PIC_CODE\MICROC~1\PIC18F~1\CUR\INTERRUPT_HANDLER.BAS       00010   DEFINE  INTLHAND  LP_INT_ENTRY
                         00014 #define         INTLHAND                  LP_INT_ENTRY
   
   Here is the beginning of the program (000000) with the interrupt vectors making an immediate jump to the interrupt routines
   
                         00125 ; Oscillator is 40MHz
   000000                01132     ORG RESET_ORG               ; Reset vector at 0
   000000 6A18           01137         clrf    FLAGS           ; Clear all flags on reset
   000002 EFC1 F001      01142         goto    INIT            ; Finish initialization
   000008                01153     ORG RESET_ORG + 8           ; High priority interrupt vector at 8
   000008 EFCF F001      01154         goto    INTHAND         ; Goto high priority user interrupt handler
   000018                01167     ORG RESET_ORG + 18h         ; Low priority interrupt vector at 18h
   000018 EFDC F001      01168         goto    INTLHAND        ; Goto low priority user interrupt handler
   
   
   Here is the beginning of the Interrupt handlers.  The code you see is all generated from my original code, no PBP code has been inserted to save context
   
                         00394 ;---[This creates the Hight Priority Interrupt Service Routine (HPISR)]---------
   00039E                00395 HP_INT_ENTRY  
   00039E 6E49           00396     movwf   _W_HP_Save                 ; 1 copy W to W_HP_Save register
   0003A0 CFD8 F042      00397     movff   STATUS, _STATUS_HP_Save    ; 2 copy status reg to STATUS_HP_Save
   0003A4 CFE0 F028      00398     movff   BSR, _BSR_HP_Save          ; 3 copy BSR to BSR_HP_Save
                         00399     ;Interrupt Code
   0003A8 EFF2 F001      00400     goto    CountTicks
   0003AC                00401 ReturnFromHP
   0003AC C028 FFE0      00402     movff   _BSR_HP_Save, BSR          ; Restore the BSR reg
   0003B0 5049           00403     movf    _W_HP_Save, W              ; Restore W
   0003B2 C042 FFD8      00404     movff   _STATUS_HP_Save, STATUS    ; Restore the STATUS reg
   0003B6 0010           00405     Retfie                             ; Exit the interrupt routine
                         00406 ;-------------------------------------------------------------------------------    
                         00407 
                         00408 
                         00409         ENDASM?
                         00410 
                         00411 
                         00412 ; C:\PIC_CODE\MICROC~1\PIC18F~1\CUR\INTERRUPT_HANDLER.BAS       00040   ASM
                         00413 
                         00414         ASM?
                             M         RST?RP
                             M     if (PREV_BANK != 0)
                             M         movlb   0
                             M PREV_BANK = 0
                             M     endif
                         00415 
                         00416 ;---[This creates the Low Priority Interrupt Service Routine (LPISR)]-----------
   0003B8                00417 LP_INT_ENTRY
   0003B8 6E4A           00418     movwf   _W_LP_Save                 ; 1 copy W to W_LP_Save register
   0003BA CFD8 F043      00419     movff   STATUS, _STATUS_LP_Save    ; 2 copy status reg to STATUS_LP_Save
   0003BE CFE0 F029      00420     movff   BSR, _BSR_LP_Save          ; 3 copy BSR to BSR_LP_Save
   0003C2 EF3C F002      00421     goto    StartSerialBuffer
   0003C6                00422 ReturnFromLP
   0003C6 C029 FFE0      00423     movff   _BSR_LP_Save, BSR          ; Restore the BSR reg
   0003CA 504A           00424     movf    _W_LP_Save, W              ; Restore W
   0003CC C043 FFD8      00425     movff   _STATUS_LP_Save, STATUS    ; Restore the STATUS reg
   0003D0 0010           00426     Retfie                             ; Exit the interrupt routine
                         00427 ;-------------------------------------------------------------------------------

2. W, and STATUS must be saved and restored, along with any other variable/register you may change inside your ISR. Why? There is normally no way to know exactly when an interrupt will occur (hence the name). So, there is no way for the ISR to really know what the current code is doing with items like W, STATUS, FSRs, BSR (or PCLATH for PIC16), etc. Without saving and restoring these items, when the ISR gets done, the state of these things may be different than when it began, and the program will behave unpredictably
   
3. With PIC18s, if High/Low priority interrupts are used, you need to save the context separately for both. See above, but with the addition that the low priority ISR can be interrupted by the high priority ISR. (See the bottom of the above code snippet)
   
4. What makes PIC18s interrupts different than PIC16s? A couple of items (though not exhaustive by any means):
   1. Interrupts can be prioritized into high and low. If not using low priority interrupts, then it is very similar to how PIC16s handle interrupts
   2. Memory Organization: The way the Banks and SFR are organized in the PIC18s is fundamentally different than PIC16s. If you don't understand the difference you are bound to have some problems.
5. Unless the PBP command has a critical timing issue (like with the software comm items), interrupts should not create any problems with the commands if the context is saved properly. Now, if the command does not rely on critical timing, but is used in a time critical manner, interrupts could create some problems related with delays (In this case, you could use INTCON to disable interrupts until the time critical bit of code was done, then re-enable). I would venture to say that most delays, if the ISR is kept as short as possible, will be completely transparent, especially if running at a fast clock rate.
   
6. If PBP code is used inside the ISR, the special PBP variables should be saved for the save reasons stated above for W, STATUS, etc. The way I have done this is to start with the items listed in PBPPIC18.RAM, then once the code has been compiled, look at the .lst file and see if I've missed any. It's a bit tedious, but I end up pretty sure I got them all.

I will be curious to see what Charles posts from his conversations with Tim Box. As I said earlier, I've been using assembly interrupts in my project with no issues on the PIC18F4620. I've got a Timer using high priority interrupts and a serial buffer using low priority interrupts. It runs at 40MHz, and the serial baud is 115200. Apart from the interrupts, some of the other items include the ubiquitous LCD (actually a salvaged VFD), an I2C RTC and EEPROM, button matrix, and some ADC inputs. So, I would have figured if the interrupts were causing problems, they would have showed up by now.


Steve