PDA

View Full Version : Pbp3.1.1



mpgmike
- 2nd January 2018, 19:39
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 "

mpgmike
- 5th January 2018, 10:49
Got it downloaded. Will be playing with a K42 for the next day or 3!

mpgmike
- 5th January 2018, 12:14
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.

mpgmike
- 5th January 2018, 22:54
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/picbasic-pro-compiler-3-0-and-later/bug-report-pbp3/7036-pbp3-1-1-04-missing-files

mpgmike
- 6th January 2018, 03:51
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.

mpgmike
- 7th January 2018, 19:13
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.

HenrikOlsson
- 8th January 2018, 07:01
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.

mpgmike
- 8th January 2018, 18:15
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.

tumbleweed
- 8th January 2018, 19:13
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

Ioannis
- 8th January 2018, 21:52
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

mpgmike
- 8th January 2018, 23:27
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.

tumbleweed
- 8th January 2018, 23:42
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.

mpgmike
- 11th January 2018, 21:48
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.

HenrikOlsson
- 11th January 2018, 22:07
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.

Ioannis
- 11th January 2018, 22:14
Great! this is very good.

Keep us updated please!

Ioannis

richard
- 11th January 2018, 22:57
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

mpgmike
- 11th January 2018, 23:52
8578

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.

richard
- 12th January 2018, 00:09
thanks for that
out of curiosity in your lst file where does the pbp code start at ?
pbp 3.0
starts 000c

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

richard
- 12th January 2018, 00:29
you might simplify the init seq to this, using labels to point to the isr vectors would be safer in the long term



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

richard
- 12th January 2018, 00:38
using labels

isr

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



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

tumbleweed
- 12th January 2018, 12:08
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.

mpgmike
- 12th January 2018, 19:43
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.

richard
- 13th January 2018, 11:47
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

tumbleweed
- 13th January 2018, 16:21
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).

mpgmike
- 13th January 2018, 17:40
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.