Pbp3.1.1


Closed Thread
Results 1 to 25 of 25

Thread: Pbp3.1.1

  1. #1
    Join Date
    Apr 2014
    Location
    OK
    Posts
    557

    Default Pbp3.1.1

    Just saw this on the ME Labs Forum:

    "
    • Added support for devices: PIC16(L)F19155, PIC16(L)F19156, PIC16(L)F19175, PIC16(L)F19176, PIC16(L)F19185, PIC16(L)F19186, PIC16(L)F19195, PIC16(L)F19196, PIC16(L)F19197, PIC18(L)F24K42, PIC18(L)F25K42, PIC18(L)F26K42, PIC18(L)F27K42, PIC18(L)F45K42, PIC18(L)F46K42, PIC18(L)F47K42, PIC18(L)F55K42, PIC18(L)F56K42, PIC18(L)F57K42, PIC18(L)F25K83, PIC18(L)F26K83
    • Changed default PPS pins for HSER2 commands to avoid accidental ICSP lockout
    • Added method to cancel CCP-PPS defaults in devices so equipped
    • Fixed outdated configuration labels for 16F1782/83
    • Updated SFR lists for 16F183xx family
    • Changed configuration defaults for recent devices based on user feedback "

  2. #2
    Join Date
    Apr 2014
    Location
    OK
    Posts
    557


    Did you find this post helpful? Yes | No

    Default Re: Pbp3.1.1

    Got it downloaded. Will be playing with a K42 for the next day or 3!

  3. #3
    Join Date
    Apr 2014
    Location
    OK
    Posts
    557


    Did you find this post helpful? Yes | No

    Default Re: Pbp3.1.1

    Playing with a PIC18F26K42, when I tried to compile I got a library of errors. The magic one was "Unable to find P18F26K42.INC". I had to go into MPLABX/V4.05 and copy the files for all of the K42s into PBP3.1/Temp. After that it compiled.

  4. #4
    Join Date
    Apr 2014
    Location
    OK
    Posts
    557


    Did you find this post helpful? Yes | No

    Default Re: Pbp3.1.1

    Turns out PBP was using MPASM V.5.71 from MPLABX V.4.01. Once I pointed it to the new folder, it works. Details:

    http://support.melabs.com/forum/picb...-missing-files

  5. #5
    Join Date
    Apr 2014
    Location
    OK
    Posts
    557


    Did you find this post helpful? Yes | No

    Default Re: Pbp3.1.1

    Got the obligatory blinked LED Hello World out of the way. Played with NCO, lit up an LCD, still want to explore the Vectored Interrupts that allegedly make the DT_INTS obsolete.

  6. #6
    Join Date
    Apr 2014
    Location
    OK
    Posts
    557


    Did you find this post helpful? Yes | No

    Default Re: Pbp3.1.1

    Got legacy ADC working in 12-bit mode. Took about a day of trial & error but I got Vectored Interrupts working. I pored over the Data Sheet and TB3162, did a bunch of copy/paste, fixed one thing that didn't work the way the DS claimed, and it works! Don't know what I'm doing, but I can build from here, tweaking for application. Getting stoked!

    In the Data Sheet, it says to Label your ISR, then (in ASM) CODE and an address; "T1INT: CODE 0x08C0". That did not work. What I had to do was on the line before the Label T1INT I had to add (again, in ASM) "ORG 0x08C0" and omit "CODE 0x08C0". That worked. Other than that it was just copying the Vectored Interrupt ASM code from the Data Sheet. Upon request I can upload the example I got working on a PIC18F26K42.

  7. #7
    Join Date
    Oct 2005
    Location
    Sweden
    Posts
    3,517


    Did you find this post helpful? Yes | No

    Default Re: Pbp3.1.1

    Well done! I have not got the update nor any K42's to play with yet.

    Regarding the vectored interrupts, don't forget that STILL can't use PBP inside your interrupt handlers, doing so without extreme care WILL screw you as we've discussed before. So if you want to use PBP inside your ISR then DT Ints is still your best bet (not sure why you've got the feeling it's obsolete) but DT Ints does not support the vectored interrupt system and the K42 would have to be bodged into the DT Ints code - which might prove more or less difficult.

    Charles said something about "bad things happening" if you tried to use the vectored interrupt feature but he didn't go into any details, I wonder if it was a general thing or purely related to using PBP in the ISR (either ON INTERRUPT or DT Ints).

    /Henrik.

  8. #8
    Join Date
    Apr 2014
    Location
    OK
    Posts
    557


    Did you find this post helpful? Yes | No

    Default Re: Pbp3.1.1

    I suppose there is a right way and a wrong way to attempt to implement Vectored Interrupts. The program I was testing really didn't do much of anything useful except display a message on the LCD. I used a Timer 1 interrupt to blink an LED and an INT0 interrupt from a push button to toggle an LED. The Main loop just paused and looped. The fact that 2 interrupts worked as intended, I assume 10 would work just as well. Don't know yet.

    I haven't abandoned DT-INTS at all. In fact, I've spent lots of hours tweaking my version to accommodate newer PICs and their newer SFRs. For just about everything but the K42, DT-INTS is still the way to go. I guess I just enjoy the challenge of tackling something new once in awhile.

  9. #9
    Join Date
    Aug 2011
    Posts
    408


    Did you find this post helpful? Yes | No

    Default Re: Pbp3.1.1

    The K42 has builtin hardware context saving for both the high priority and low priority interrupts, which would make most of what DT-INTS does unnecessary. The list of registers it saves is pretty complete.

    I haven't looked at all the details, but it looks like you might get away with just calling the SavePBP/RestorePBP routines in ReEnterPBP-18.bas/ReEnterPBP-18LP.bas

  10. #10
    Join Date
    Nov 2003
    Location
    Greece
    Posts
    3,795


    Did you find this post helpful? Yes | No

    Default Re: Pbp3.1.1

    Quote Originally Posted by tumbleweed View Post
    The K42 has builtin hardware context saving for both the high priority and low priority interrupts, which would make most of what DT-INTS does unnecessary. The list of registers it saves is pretty complete...
    But not the PBP system variables I suppose, right?

    These have to be saved and restored by the ISR.

    Ioannis

  11. #11
    Join Date
    Apr 2014
    Location
    OK
    Posts
    557


    Did you find this post helpful? Yes | No

    Default Re: Pbp3.1.1

    Quote Originally Posted by Ioannis View Post
    But not the PBP system variables I suppose, right?

    These have to be saved and restored by the ISR.

    Ioannis
    I can do a simple INCF _PBP_VAR in the ISR and then display the result on the LCD in PBP to see if it saved. I'll get to that shortly.

  12. #12
    Join Date
    Aug 2011
    Posts
    408


    Did you find this post helpful? Yes | No

    Default Re: Pbp3.1.1

    These have to be saved and restored by the ISR
    Right, like I said you'd have to call the SavePBP/RestorePBP routines in ReEnterPBP-18.bas/ReEnterPBP-18LP.bas like DT-INTS does to save the PBP system variables.

    The rest of what DT-INTS does (and some of SavePBP) would just be repeating what the hardware has already done.

  13. #13
    Join Date
    Apr 2014
    Location
    OK
    Posts
    557


    Did you find this post helpful? Yes | No

    Default Re: Pbp3.1.1

    I created a couple global variables, incremented in ISR and it worked.

    DispL VAR BYTE BANK0 SYSTEM
    DispH VAR BYTE BANK0 SYSTEM

    ;Vectored ISR for Timer 1
    INFSNZ DispL
    INCF DispH
    RETFIE 1

    In the Main Loop,

    DispVal.HIGHBYTE = DispH
    DispVal.LOWBYTE = DispL
    GOSUB Disp ;Display DispVal on LCD

    Of course, this is just a snippet of the whole code, but it worked. The variable DispL was incremented in the Vectored ISR without any special context saving.

  14. #14
    Join Date
    Oct 2005
    Location
    Sweden
    Posts
    3,517


    Did you find this post helpful? Yes | No

    Default Re: Pbp3.1.1

    Since you're using assembly in the ISR there should be no issues as far as system variables goes. But, again, it's a completely different thing if start writing PBP code in the ISR.

    And just to be clear, it's got nothing to do with the variables YOU declare, it's the variables that the compiler declares and uses internally (you never see those) that's the issue and those are the variables that DT-Ints saves/restores for you when you tell it that you're going to use PBP in the ISR.

    The vectored interrupt system takes away the need to save the hardware registers and the need to "manually" poll each enabled interrupts in order to determine which one it was that tripped. It does however not solve the "problem" with PBP system variable being shared between main code and ISR code.

    /Henrik.

  15. #15
    Join Date
    Nov 2003
    Location
    Greece
    Posts
    3,795


    Did you find this post helpful? Yes | No

    Default Re: Pbp3.1.1

    Great! this is very good.

    Keep us updated please!

    Ioannis

  16. #16
    Join Date
    May 2013
    Location
    australia
    Posts
    2,383


    Did you find this post helpful? Yes | No

    Default Re: Pbp3.1.1

    I would be interested to :-
    see how you set the interrupt vector
    see how you determine the interrupt vector address
    know how you partition the memory
    know if pbp uses an ORG that will preserve all int vectors


    and as henrik observed your example would have worked on any chip with auto context save
    Warning I'm not a teacher

  17. #17
    Join Date
    Apr 2014
    Location
    OK
    Posts
    557


    Did you find this post helpful? Yes | No

    Default Re: Pbp3.1.1

    Vectored_INT.txt

    Here is the code. I use an LCD to debug the values for DispVal. I'm using an external INT0 and TMR1 interrupts. Timer 1 overflows every 1 second. The Vector_Table_Init is mostly copy/paste from the Data Sheet. Labels T1ISR & INT0ISR are the Vectored Interrupts. The format deviates from the Data Sheet in that Address locations are denoted with "ORG 0x08C0" instead of "T1ISR CODE 0x08C0". I still don't understand why it has to use Non-Volitile Memory (NVM) for creating the Vector Addresses, but it works, and it's in the Data Sheet.

  18. #18
    Join Date
    May 2013
    Location
    australia
    Posts
    2,383


    Did you find this post helpful? Yes | No

    Default Re: Pbp3.1.1

    thanks for that
    out of curiosity in your lst file where does the pbp code start at ?
    pbp 3.0
    starts 000c
    Code:
                       00136 ; Oscillator is 64MHz
                          01228   LIST
    000000                01229     ORG RESET_ORG               ; Reset vector at 0
                          01238   LIST
    000000 EF78 F000      01239         goto    INIT            ; Finish initialization
                          01249   LIST
    000008                01250     ORG RESET_ORG + 8           ; High priority interrupt vector at 8
    000008 EF7A F000      01251         goto    INTHAND         ; Goto high priority user interrupt handler
                          01487   LIST
    00000C C00C FFE9      01488 ARRAYWRITE movff R5, FSR0L      ; Put the array pointer into FSR0     
    000010 C00D FFEA      01489         movff   R5 + 1, FSR0H
    000014 6EEE           01490         movwf   POSTINC0        ; Put the char into the array and bump up the address
    Warning I'm not a teacher

  19. #19
    Join Date
    May 2013
    Location
    australia
    Posts
    2,383


    Did you find this post helpful? Yes | No

    Default Re: Pbp3.1.1

    you might simplify the init seq to this, using labels to point to the isr vectors would be safer in the long term


    Code:
    ASM
    Vector_Table_Init:
        MOVLW       0x00                        ;Vector Table Start Address: 00 4008h
        MOVWF       IVTBASEU, ACCESS
        MOVLW       0x40
        MOVWF       IVTBASEH, ACCESS
        MOVLW       0x08
        MOVWF       IVTBASEL, ACCESS
        
        MOVLW       0x00                        ;TMR1_INT = Vector #32
        MOVWF       TBLPTRU, ACCESS             ;4008h + [(32d) 20h * 2] = 4048
        MOVLW       0x40
        MOVWF       TBLPTRH, ACCESS
        MOVLW       0x48
        MOVWF       TBLPTRL, ACCESS
        
        MOVLW       0x30                        ;T1ISR >> 2; 08C0h >> 2 = 0230h
        MOVWF       TABLAT, ACCESS
        TBLWT*+
        MOVLW       0x02
        MOVWF       TABLAT, ACCESS
        TBLWT*+
        MOVLW       0x18
        MOVWF       TBLPTRL, ACCESS
        
        MOVLW       0x38                        ;INT0ISR >> 2; 08E0h >> 2 = 0238h
        MOVWF       TABLAT, ACCESS
        TBLWT*+
        MOVLW       0x02
        MOVWF       TABLAT, ACCESS
        TBLWT*+    
        BANKSEL     NVMCON1
        MOVLW       0x84                        ;Setting to write to PFM
        MOVWF       NVMCON1
        MOVLW       0x55                        ;Required unlock sequence
        MOVWF       NVMCON2
        MOVLW       0xAA
        MOVWF       NVMCON2
        BSF         NVMCON1, WR                 ;Start writing to PFM
        BTFSC       NVMCON1, WR                 ;Wait for write to complete
        GOTO        $-2    
        RETURN      1
    ENDASM
    caveat what is the label size for pbp3.1 ? might limit location to first 64k block
    Last edited by richard; - 12th January 2018 at 00:58. Reason: caveat
    Warning I'm not a teacher

  20. #20
    Join Date
    May 2013
    Location
    australia
    Posts
    2,383


    Did you find this post helpful? Yes | No

    Default Re: Pbp3.1.1

    using labels

    isr
    Code:
    T1ISR:
    ASM                                  ;ISR code  relocateable
        BANKSEL PIR4                        ;BANKSELECT for PIR4
        BCF PIR4,0                          ;Clear TMR1IF
    ;    BANKSEL LATC                        ;BANKSELECT for LATC
    ;    BTG _LED                            ;Bit Toggle LATC.3 (LED)
        MOVLW 086h
        BANKSEL TMR1H                       ;BANKSELECT for TMR1
        MOVWF TMR1H, 1
    ;    TMR1H = $86
        MOVLW 0E7h                          ;34535d = 1 Second Interrupts
        MOVWF TMR1L, 1
    ;    TMR1L = $E7
        BANKSEL T1CON                       ;BANKSELECT for T1CON
        MOVLW 1                             ;T1CON = %00000001
        MOVWF T1CON, 1
    ;    T1CON = %00000001
        MOVLB 0
        BSF Cycle
        INFSNZ DispL
        INCF DispH
        RETFIE FAST                         ;RETURN & Restore
    ENDASM
    in init

    Code:
      
        MOVLW       low (_T1ISR >> 2) ; 08C0h >> 2 = 0230h
        MOVWF       TABLAT, ACCESS
        TBLWT*+
        MOVLW       high (_T1ISR >> 2)
        MOVWF       TABLAT, ACCESS
        TBLWT*+
    caveat what is the label size for pbp3.1 ? might limit location to first 64k block
    Last edited by richard; - 12th January 2018 at 00:59. Reason: caveat
    Warning I'm not a teacher

  21. #21
    Join Date
    Aug 2011
    Posts
    408


    Did you find this post helpful? Yes | No

    Default Re: Pbp3.1.1

    The format deviates from the Data Sheet in that Address locations are denoted with "ORG 0x08C0" instead of "T1ISR CODE 0x08C0". I still don't understand why it has to use Non-Volitile Memory (NVM) for creating the Vector Addresses, but it works
    The difference between ORG and CODE is that you use ORG when working with the assembler in absolute mode, and CODE when using the assembler in relocatable mode (ie using a linker). PBP works in absolute mode, so use ORG.

    The NVM instructions are to set the table of vectors (IVT) into the program flash memory. The IVTBASE registers set where the table starts in memory but you still have to put the address of each interrupt handler into the IVT table.

  22. #22
    Join Date
    Apr 2014
    Location
    OK
    Posts
    557


    Did you find this post helpful? Yes | No

    Default Re: Pbp3.1.1

    Thanks Tumbleweed. As to the other questions & comments, I don't know where to find those answers; "what is the label size for PBP3.1?"

    Richard, you seem to indicate you are using PBP 3.0 (?). I let the linker set the PBP start address. I didn't open the List file to find out. Since I'm just copying from Data Sheets, it would be nice if someone with PBP 3.1 could test some of the mentioned short cuts to see if they work. If they do, I'll try to figure out what was actually done and learn from it.

  23. #23
    Join Date
    May 2013
    Location
    australia
    Posts
    2,383


    Did you find this post helpful? Yes | No

    Default Re: Pbp3.1.1

    I wonder if there is any gain using vectored interrupts , for all the extra effort and the risk in locating the vector table inappropriately {like slap bang in the middle of your pgm space}. I cant see that it will perform significantly better than a normal preemptive isr routine for multiple interrupt sources .
    I asked about the pbp reset org thinking it would be nice to locate the ivt at that point and then use "define RESET ORG" to skip over it .
    you could then load your vectors at compile time with @ dw ...... . heaps easier to manage . still need to Vector Table Start Address regs though.
    I have some chips on order with element14 but the have none in stock , when the arrive I will try with xc8 to see if its worth the effort.
    I wonder why they [microchip] did not just allocate more vector address permanently like an avr chip
    "what is the label size for PBP3.1?" since there are 128k chips in this family I guess they have to at least big enough , still test it first

  24. #24
    Join Date
    Aug 2011
    Posts
    408


    Did you find this post helpful? Yes | No

    Default Re: Pbp3.1.1

    You raise some good points about how/where everything is located.

    I think the gains in using vectored interrupts would depend a lot on how many interrupts your program uses.
    If you use a lot of interrupts then having individual vectors can speed it up quite a bit since you don't have to test the IE and IF flags for each interrupt.
    If you only use one or two then the gain might not be that much, if any.

    I suppose you could have different vectors storing different context data so there's that to consider. You might have to do a lot of that by hand, though.

    Either way you get the fast hardware context saving for both low and high priorities, so that's a boost (assuming you change DT-INTS to remove that duplicate code).

  25. #25
    Join Date
    Apr 2014
    Location
    OK
    Posts
    557


    Did you find this post helpful? Yes | No

    Default Re: Pbp3.1.1

    I've used 7 or 8 interrupts in a single program in the past. I agree that for 1 or 2, it makes more sense to just use the conventional High/Low Priority Interrupts, which the K42 can do as well. Even with High/Low Priority, default addresses are 000008h for High and 000018 for Low. These can be changed with IVTBASE the same as the Vectored Ints. Since it's something new, I had to try to figure it out. The Data Sheet showed how to load the Vector Table Start Address at 004008h. I tried loading it at 0008, but didn't understand what was being done well enough to get it to work. Using the example 4008h, it worked.

Similar Threads

  1. PBP3 Code Does not Compile with PBP3.1
    By RossWaddell in forum PBP3
    Replies: 5
    Last Post: - 2nd July 2017, 09:42
  2. I really need some help with PBP3
    By Ramius in forum mel PIC BASIC Pro
    Replies: 5
    Last Post: - 26th February 2012, 17:05
  3. PBP3 and MPLAB 8.83
    By grahamg in forum mel PIC BASIC Pro
    Replies: 6
    Last Post: - 10th February 2012, 14:04
  4. Pbp3
    By rcbandwidth in forum mel PIC BASIC Pro
    Replies: 21
    Last Post: - 18th September 2011, 15:13
  5. What's with PBP3?
    By BrianT in forum mel PIC BASIC Pro
    Replies: 3
    Last Post: - 10th August 2011, 18:09

Members who have read this thread : 1

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

Posting Permissions

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