PDA

View Full Version : PBP 3.0 really needed?



Mugelpower
- 4th March 2012, 10:39
Hy Guys & Dolls,

I didnīt pic around for more than a year and some time got by and whoops- here is PBP 3.0.

Got PBP 2.50 C and the question is:

Whats the REALLY advantage of 3.0 ? Are there heavy bugfixes or the ultimate upgrade?

And I read the dsPIC33 or the PIC24F are cheaper than the 8 bit types but canīt be programmed in PBP

As I could tell PBP 3.0 is really more expensive so is it the real McCoy?

Regards

Mugel

HenrikOlsson
- 4th March 2012, 13:30
Hi,
I don't think MELABS is going to add support for new devices in the old version of the compiler but if you're only using devices supported by your current version and you then that's fine.
There are no new BASIC commands added in PBP3 but the REAL advantage (for me) is the conditional compilations feature. On top of that it adds a big improvement to the way the CONFIG bits are handled. No more editing include files etc.

So it's really up to you but for me it wasn't hard to decide.

Demon
- 4th March 2012, 17:34
I'm haven't done the jump to PBP 3 yet, still on 2.60c. I still have a large variety of PICs to chose from and that's fine with me. I don't see myself needing the new feature Henrik spoke of for quite some time.

Robert
:)

ScaleRobotics
- 4th March 2012, 18:11
PBP3 is really nice. It's basically two upgrades past your version 2.50. Looks like they charge $75 for the jump from PBP2.5 to PBP3.0 gold.

Personally, I like using some of the newer chips, like the x7j53, 14K50, enhanced mid range, and some of the other "K" chips. So, it was needed for me :) If those are of interest to you, you will need the upgrade. The jump from pbp 2.5 (in my opinion) to 2.6 was worth way more than $25! And the jump from 2.6 to pbp3.0 was totaly worth the $50, so I wouldn't have to jump back and forth commenting out the configs in all the include files (and previously having to do it all over again with each upgrade!)

Here are the changes from:

PBP3 - 3.0.0.x (Aug 2011) (http://support.melabs.com/content/153-PBP3-3.0.0.x)



New Functionality:


Conditional-compilation with #IF, #IFDEF, and #IFNDEF. Control all PBP code with conditional statements, including DEFINE, Variable and Alias declarations, and Configuration Directives.
Conditional constants can be defined in source code or passed to PBP via command-line options.
#CONFIG block allows configuration directives in source code without modifying system files. Multiple configuration blocks can be selected with conditional compile.
Custom compiler message, warning, and error generation.
Mechanism to create custom PBP commands. (Undocumented at the time of this writing. More information to come.)

Installation and Compatibility:


License protection through online/offline activation.
MPLABX/MPASMX Compatibility with PBP-aware syntax highlighting.
Automatic MPLAB 8.x setup and configuration.
Assembler selection from Start Menu allows specific assembler-version selection, regardless of PATH variable entries. Selection setting accessible as an environment variable.
PATH environment modification no longer required for assembly process.
63-character limit on path\filename removed.
Complete compatibility with 64-bit Windows.

Structural Changes:


Various include files consolidated into one support file per device.
SFR names declared for each individual device.
Device-specific command library capability.
Single executable (PBPX.exe) for both PBPW and PBPL compilation.
PM Assembler no longer supported.

Usability and Accessibility:


Newly revised and expanded, 300+ page reference manual.
Configuration information provided for each supported device.
Multiple editions with different device-support subsets available.
Free major upgrades for one year with every upgrade or full-version purchase.
Minor updates and new-device support distributed frequently through free downloads for all current-version licensed users.
All PBP3 editions and upgrades may be purchased as downloads.

Bug fixes and tweaks:


Limit on LOOKUP2 item list increased to 1024 for Mid-Range and Enhanced Mid-Range architectures.
HPWM changed to accommodate 1:64 prescaler in Enhanced Mid-Range Architecture. (lower minimum frequency limit)
Fixed HPWM compile error for 18FxxK80.
Fixed HPWM compile error for Enhanced Mid-Range parts in which CCPTMRS0 doesn't exist.
Fixed HPWM channel-5 bug for Enhanced Mid-Range parts.
Fixed ERASECODE/WRITECODE/READCODE for 12F617 and similar parts.

Support added for:


Silver and Gold Editions: 12F752, ,12HV752
Gold Edition: 12(L)F1840, 16(L)F1507, 16(L)F1516, 16(L)F1517, 16(L)F1518, 16(L)F1519, 16(L)F1526, 16(L)F1527, 16(L)F1782, 16(L)F1783, 16(L)F1847, 16LF1902, 16LF1903, 16LF1904, 16LF1906, 16LF1907

PBP 2.60c



Fixed ADCIN for parts with 5-bit channel select
Fixed HPWM for parts with CCPTMRSx SFRs
Added support for PIC18F66K80 family
Fixed "Argument out of range" for COUNT in 16F1xxx parts
Fixed errors in PBPL for I2C commands forward-looking labels
Fixed ADCIN GO_DONE error for new PIC18F parts
Fixed LCDOUT for 8-bit mode with 64MHz system clock
Adds support for: PIC16F1824, 16F1825, 16F1828, 16F1829, 16F707, 16F720, 16F721, 18F26J13, 18F26J53, 18F27J13, 18F27J53, 18F46J13, 18F46J53, 18F47J13, 18F47J53, 18F65K22, 18F65K90, 18F66K22, 18F66K90, 18F67K22, 18F67K90, 18F85K22, 18F85K90, 18F86J72, 18F86K22, 18F86K90, 18F87J72, 18F87K22, 18F87K90, 18F25K80, 18F26K80, 18F45K80, 18F46K80, 18F65K80, 18F66K80, 18LF25K80, 18LF40K80, 18LF45K80 18LF26K80, 18LF45K80, 18LF46K80, 18LF65K80, 18LF66K80
Support added for second USART on PIC16F1xxx family.
HPWM frequency calculation fixed for PIC16F1xxx family.


PBP 2.60




Adds support for: PIC12F1822, 12LF1822, 16F1823, 16LF1823, 12F617, 16F722A, 16F723A, 16LF722A, 16LF723A, 18F23K22, 18F24K22, 18F25K22, 18F26K22, 18F43K22, 18F44K22, 18F45K22, 18F46K22, 18LF23K22, 18LF24K22, 18LF25K22, 18LF26K22, 18LF43K22, 18LF44K22, 18LF45K22, 18LF46K22
Fixes WRITE for WORD variables
Fixes assembly errors for 16F1826/16F1827
Fixes baud rate accuracy for SERIN/SEROUT commands
Fixes ADCIN for 18F46J11 family
Fixes WRITECODE for 18F4520 family
Workaround added for enhanced 14-bit devices and MPASM 5.36
Fixes PBPMPLAB.BAT for 64-bit systems


Adds support for Enhanced Mid-range Core PIC16F1826, 1827, 1933, 1934, 1936, 1937, 1938, 1939, 1946, 1947, PIC16LF1826, 1827, 1933, 1934, 1936, 1937, 1938, 1939, 1946 and 1947.
Adds support for PIC18F13K22, 13K50, 14K22, 14K50, 24J11, 24J50, 25J11, 25J50, 26J11, 26J50, 44J11, 44J50, 45J11, 45J50, 46J11, 46J50, 66J90, 66J93, 67J90, 67J93, 86J90, 86J93, 87J90, 87J93, PIC18LF13K22, 13K50, 14K22, 14K50, 24J10, 24J11, 24J50, 25J10, 25J11, 25J50, 26J11, 26J50, 44J10, 44J11, 44J50, 45J10, 45J11, 45J50, 46J11 and 46J50.
Adds new functions ATN (arctangent) and HYP (hypotenuse).
Adds new commands ARRAYREAD, ARRAYWRITE (for enhanced string handling), DO..LOOP, ELSEIF, EXIT, ON GOSUB and ON GOTO.
Adds Word and Long modifiers and allows multiple data for READ and WRITE.
Adds NO_CLEAR_STKPTR Define for more control of stack for RESUME to label.
Adds RESET_ORG Define for 14-bit core.
Adds WRITE_INT Define to disable/enable interrupts for WRITECODE.
Adds COFF debug file support for MPLAB 8.20 and beyond.
Changes plugin for MPLAB 8.20 and beyond.
Changes to new USB framework for support of new USB parts.
Fixes DATA statement for up to 256 values on one line.
Fixes OWIN and OWOUT presence detect for PIC18.
Lengthens default command and data times for LCDOUT.
Adjusts timing for SOUND command for 12-bit core.

Mugelpower
- 4th March 2012, 18:27
If I had only to pay $ 75 or so I would do that. Wasnīt there a thread that told "no more Upgrades from 2.50 possible" ?? And $280 is really a lot if Upgrades are impossible.
And Darrel Taylor had his great DT_INTS-18.bas is that needed in PBP 3.0 or only for the older versions?

regards
Mugel

ScaleRobotics
- 4th March 2012, 18:33
The upgrade appears to still be available here: http://store.melabs.com/cat/PBPUP.html

Just provide proof you own your version.

Darrel's interrupts work on all versions of PBP that we are talking about.

Mugelpower
- 4th March 2012, 18:48
Iīm not aware how to proof . I got the CD but it has no serial number. And I got the green book but it has no serial number either.
Regards
Mugel

Demon
- 5th March 2012, 03:26
Simple, how did you get the CD and manual?


I have yet to setup on my 64-bit PC but that is the plan, so I may end up upgrading to PBP 3 as well. :D

Robert

Mugelpower
- 5th March 2012, 08:59
Found the confirmation of order , it was from Lascar Electronics ( Germany, 72184 Eutlingen) 09/20/2007 order Number 71296 Picbasic Pro Compiler
Version 2.50 and it cost 297,50- Euros (about 392 $ ) at that time.
Thats all I have.

ScaleRobotics
- 5th March 2012, 14:37
Glad you found it. Contact Melabs.com . They are the ones selling the upgrade.

toneman
- 6th June 2013, 15:58
Thanks for the explanation of the versions of PicBasic Pro. I'm interested in the newer 12F1850 8pin chips and thought my version (2.6, I think) would not program them. Still checking........

mackrackit
- 8th June 2013, 08:20
12F1850 is so new it is not listed on Micrchip's web site....
Bit the 12F1840 is and PBP3 supports it.
http://pbp3.com/devicelist.html

Charlie
- 8th June 2013, 10:44
And if you really do mean 12F1840, look here: http://www.picbasic.co.uk/forum/showthread.php?t=15001

fowardbias
- 23rd July 2013, 22:36
Why does the PBP3 device list for the upper end 18F's not include any of the chips that use the V-bat features? The pin count is 64/80/100 for these chips and Melabs is already selling a ZIF adaptor for them. Doesn't jive right to me? 2.6C and happy!

Darrel Taylor
- 24th July 2013, 00:27
Which "upper end 18F's" are you referring to?

The only chips I can find with V-Bat are the PIC24's.

PIC24F Family Ref. Manual, Sect. 57. Power-Saving Features ... (http://ww1.microchip.com/downloads/en/DeviceDoc/30622a.pdf)

--------------------
PBP3, and happier!

fowardbias
- 24th July 2013, 00:47
18F97J94, I believe there is another one or two of different series

fowardbias
- 24th July 2013, 17:44
Follow up on the 94 series: available from Microchip Direct for about $5. Regarding the adapters from Melabs, I would assume they are pinned out for the non V-bat devices, if so maybe the company would spin the board again with a revision to the V-bat devices. Maybe many of the core files of non V's and V's are the same. Anyway, "Whats with all this V stuff anyway?" I'm getting deep sleepy is all I can say. enjoy

Darrel Taylor
- 24th July 2013, 19:11
I hadn't seen those chips yet. But you're right, they have Vbat functions.
Still can't get microchip.com to show them or any other 18F's with a search for Vbat.

I asked about the J94's here, and the response was ...
The J94 series was scheduled to be added in the last update of PBP3, but some issues came up with the device that requires new library routines.
Hopefully, that will be completed by the next update of PBP3.

Normnet
- 25th July 2013, 00:57
... Still can't get microchip.com to show them or any other 18F's with a search for Vbat...
Darrel

A quick search for Vbat turns up:
PIC18F97J94 family is Microchip’s first to offer integrated LCD control, RTCC with Vbat, and USB on a single 8-bit PIC microcontroller (http://www.microchip.com/pagehandler/en-us/press-release/microchip-expands-usb-portfoli.html)
and:
PIC18F97J94 FAMILY. (http://ww1.microchip.com/downloads/en/DeviceDoc/30575A.pdf)


Norm

Mugelpower
- 8th December 2017, 04:08
4 years are gone and I bought PBP3 Gold. I have the tendence of purchasing an excavator for planting a pansy.

Demon
- 12th December 2017, 20:41
Yeah, I sorta overengineer stuff as well. :D

Ioannis
- 13th December 2017, 08:16
Better be safe, right? But on the other hand an evolution is needed. And I can't see it...

Ioannis

mpgmike
- 15th December 2017, 02:13
Some thoughts I had was to integrate new commands based on new Special Functions, like NCO, PPS, etc. That would expand the PBP capability beyond the 20 year old SFs. The PIC16F HEF versus traditional EEPROM poses challenges as well. I agree, PBP is due for a major suspension redesign.

HenrikOlsson
- 15th December 2017, 16:49
This comes up now and then and although I agree that the development of PBP is kind of slow I fail to see how a PBP command to handle something like PPS would even work. I mean setting the output of the MSSP module to RB0 would then require a line of PBP code - exactly the amount of PBP code it takes without a specific command for it. (Not counting the lock/unlock sequence). I personally don't see the benefit of having a dedidated PBP command when all that command would do is set a single register to a specific value.

As far as the NCO goes, that might have some merit but like HPWM a PBP command to run it would likely impose limits/restrictions. That doesn't mean it wouldn't/couldn't be useful though.

It may sound as if I don't want PBP to evelove, I most certainly do, but I'd rather see the apparently limited development resources available spent on keeping up with the current devices instead of adding commands that a couple of lines of PBP code (ie setting a register or two) already does.

What I'd like to see is something like DT-Ints built into PBP but an even clever version that analyses the code in the ISR and determines what system variables it NEEDS to save based on what library routines the compiler acutally used to generate the code in the ISR.

New 8-bit devices are coming out with vectored interrups and DMA, I'd like to see support for th.

With that said, I'm not holding my breath...

/Henrik.

mpgmike
- 15th December 2017, 19:01
I've used DT_INTS for several years and fell madly in love with it. Lately, I'm forcing myself to get a grip on the ASM Interrupts as outlined in the "Advanced" section of the PBP Manual. Got it working on a PIC12F1501 and PIC16F18313. I intend to tackle the Vectored Interrupts with the newer offerings soon. It doesn't seem to be much more difficult than DT-INTS. Plus, I discovered you do an ASM Interrupt, part way through the ISR jump out of ASM, add some PBP, then jump back into ASM to RETFIE. I tried to alter the DT_INTS-18 for the new K42 and someone pointed out that it would require far more than just changing the SFRs to match the MCU, due to memory banks & other registers.

I'm with you, Henrik, I'm chomping at the bit to get playing with the new K42's, even ordered 2 PIC18F26K42s in anticipation.

HenrikOlsson
- 16th December 2017, 15:20
....I discovered you do an ASM Interrupt, part way through the ISR jump out of ASM, add some PBP, then jump back into ASM to RETFIE
In the end your compiled PBP statements are ASM too so yes, in theory, you can do that but remember that the PBP statements you use in that ISR might use the same system variables as your main routine and can therefor corrupt those values for whatever it was your main program was doing when it got interrupted.

DT-Ints, as I'm sure you know, handles this by reserving space for, saving on ISR entry and restoring on ISR exit all these system variables. It's somewhat clever in that it "only" saves/restores system variables that the program uses but it does so no matter if the code in the ISR would affect those variables or not.

What I've done on occasions is to write my ISR in PBP but treat it as an assembly type interrupt and then, by looking at the generated .lst file, figure out which system variables my PBP ISR code is actually affecting and then add save/restore code for those ONLY. It works but you need to be very methodical and follow every library call and it's obviously extremely easy to mess up since adding a single line of code to ISR (or even chaning one) could effectively ruin your day.

I'd like to see it built into the compiler with enough intelligense to analyze the code in the ISR and determine exaclty which variables are actually needed to be saved/restored. I mean, sure the main program might use variable T1,T2,T3 but if the code in the ISR only uses T2 then why waste time and space on saving/restoring all three? Some sort of report would be a nice touch so one can figure out the expected latency - which would then obviously vary depending on code complexity of the ISR.

It would be interesting to know how the compiler(s) from MikroE is handling this, anyone in the know?

/Henrik.

richard
- 17th December 2017, 00:38
USERCOMMAND, seldom mentioned on this forum, can accommodate most new chip features.
although its not much use for NCO module since the compiler can only pass word values to the assembler for pic16's
its possible to use the 64bit math capability of the assembler in asm blocks
eg
create a template like this and adjust nco osc and output freq to suit, the other nco regs could be included also if you like




ASM
NCO_OUT_FREQ = 10000000
NCO_OSC = OSC
NCO_INT = NCO_OUT_FREQ*2096/(NCO_OSC*1000)
MOVE?CB NCO1INCL ,LOW (NCO_INT)
MOVE?CB NCO1INCH ,HIGH (NCO_INT)
MOVE?CB NCO1INCU ,UPPER (NCO_INT)
ENDASM

which if fine if you don't need to change nco settings on the fly too much

* this is untested the formula might not be correct ,I don't have a chip with a nco to test with

richard
- 17th December 2017, 01:10
Henrik

mikroc is not much different , it has various R vars as working registers , I believe it saves/restores only as many of these as the isr requires

microc lst and c snippets
lst


; LST file generated by mikroListExporter - v.2.0
; Date/Time: 5/16/2015 12:02:53 PM
;----------------------------------------------

;Address Opcode ASM
0x0000 0x158A BSF PCLATH, 3
0x0001 0x2800 GOTO 2048
_interrupt:
0x0004 0x00FF MOVWF R15
0x0005 0x0E03 SWAPF STATUS, 0
0x0006 0x0183 CLRF STATUS
0x0007 0x00CD MOVWF ___saveSTATUS
0x0008 0x080A MOVF PCLATH, 0
0x0009 0x00CE MOVWF ___savePCLATH
0x000A 0x018A CLRF PCLATH
0x000B 0x0870 MOVF R0, 0
0x000C 0x00A3 MOVWF 35
0x000D 0x0871 MOVF R1, 0
0x000E 0x00A2 MOVWF 34
0x000F 0x0872 MOVF R2, 0
0x0010 0x00A1 MOVWF 33
0x0011 0x0873 MOVF R3, 0
0x0012 0x00A0 MOVWF 32
0x0013 0x0804 MOVF FSR, 0
0x0014 0x00A4 MOVWF 36
;uv_16f648a_lcd.c,232 :: void interrupt(void)
;uv_16f648a_lcd.c,236 :: if (INTCON.RBIF) { // RbC_INT
0x0015 0x1C0B BTFSS INTCON, 0
0x0016 0x2852 GOTO L_interrupt47
;uv_16f648a_lcd.c,237 :: ev = ev << 2;
0x0017 0x082F MOVF interrupt_ev_L0, 0
0x0018 0x00F3 MOVWF R3
0x0019 0x0DF3 RLF R3, 1
0x001A 0x1073 BCF R3, 0
0x001B 0x0DF3 RLF R3, 1
0x001C 0x1073 BCF R3, 0
0x001D 0x0873 MOVF R3, 0
0x001E 0x00AF MOVWF interrupt_ev_L0
;uv_16f648a_lcd.c,238 :: ev = ev | ((PORTB & 0b00110000) >> 4);
0x001F 0x3030 MOVLW 48
0x0020 0x0506 ANDWF PORTB, 0
0x0021 0x00F2 MOVWF R2
0x0022 0x0872 MOVF R2, 0
0x0023 0x00F0 MOVWF R0
0x0024 0x0CF0 RRF R0, 1
0x0025 0x13F0 BCF R0, 7
0x0026 0x0CF0 RRF R0, 1
0x0027 0x13F0 BCF R0, 7
0x0028 0x0CF0 RRF R0, 1
0x0029 0x13F0 BCF R0, 7
0x002A 0x0CF0 RRF R0, 1
0x002B 0x13F0 BCF R0, 7
0x002C 0x0873 MOVF R3, 0
0x002D 0x04F0 IORWF R0, 1
0x002E 0x0870 MOVF R0, 0
0x002F 0x00AF MOVWF interrupt_ev_L0
;uv_16f648a_lcd.c,239 :: count += lut[ev & 0xf];
0x0030 0x300F MOVLW 15
0x0031 0x05F0 ANDWF R0, 1
0x0032 0x0870 MOVF R0, 0
0x0033 0x3E30 ADDLW interrupt_lut_L0
0x0034 0x0084 MOVWF FSR
0x0035 0x0800 MOVF INDF, 0
0x0036 0x00F0 MOVWF R0
0x0037 0x0870 MOVF R0, 0
0x0038 0x07AC ADDWF _count, 1
0x0039 0x1803 BTFSC STATUS, 0
0x003A 0x0AAD INCF _count+1, 1
0x003B 0x3000 MOVLW 0
0x003C 0x1BF0 BTFSC R0, 7
0x003D 0x30FF MOVLW 255
0x003E 0x07AD ADDWF _count+1, 1
;uv_16f648a_lcd.c,240 :: ccc = count >> 2; // divide 4 for 1 count per detent
0x003F 0x082C MOVF _count, 0
0x0040 0x00F0 MOVWF R0
0x0041 0x082D MOVF _count+1, 0
0x0042 0x00F1 MOVWF R0+1
0x0043 0x0CF1 RRF R0+1, 1
0x0044 0x0CF0 RRF R0, 1
0x0045 0x13F1 BCF R0+1, 7
0x0046 0x1B71 BTFSC R0+1, 6
0x0047 0x17F1 BSF R0+1, 7
0x0048 0x0CF1 RRF R0+1, 1
0x0049 0x0CF0 RRF R0, 1
0x004A 0x13F1 BCF R0+1, 7
0x004B 0x1B71 BTFSC R0+1, 6
0x004C 0x17F1 BSF R0+1, 7
0x004D 0x0870 MOVF R0, 0
0x004E 0x00A5 MOVWF _ccc
0x004F 0x0871 MOVF R0+1, 0
0x0050 0x00A6 MOVWF _ccc+1
;uv_16f648a_lcd.c,241 :: INTCON.RBIF = 0;
0x0051 0x100B BCF INTCON, 0
;uv_16f648a_lcd.c,242 :: }
L_interrupt47:
;uv_16f648a_lcd.c,243 :: if (PIR1.TMR1IF){ // tmr2
0x0052 0x1C0C BTFSS PIR1, 0
0x0053 0x2874 GOTO L_interrupt48
;uv_16f648a_lcd.c,244 :: TMR1H = 63515/256;
0x0054 0x30F8 MOVLW 248
0x0055 0x008F MOVWF TMR1H
;uv_16f648a_lcd.c,245 :: TMR1L= 63515%256;
0x0056 0x301B MOVLW 27
0x0057 0x008E MOVWF TMR1L
;uv_16f648a_lcd.c,246 :: milli += 2;
0x0058 0x3002 MOVLW 2
0x0059 0x00F0 MOVWF R0
0x005A 0x01F1 CLRF R0+1
0x005B 0x01F2 CLRF R0+2
0x005C 0x01F3 CLRF R0+3
0x005D 0x0827 MOVF _milli, 0
0x005E 0x07F0 ADDWF R0, 1
0x005F 0x0828 MOVF _milli+1, 0
0x0060 0x1803 BTFSC STATUS, 0
0x0061 0x0F28 INCFSZ _milli+1, 0
0x0062 0x07F1 ADDWF R0+1, 1
0x0063 0x0829 MOVF _milli+2, 0
0x0064 0x1803 BTFSC STATUS, 0
0x0065 0x0F29 INCFSZ _milli+2, 0
0x0066 0x07F2 ADDWF R0+2, 1
0x0067 0x082A MOVF _milli+3, 0
0x0068 0x1803 BTFSC STATUS, 0
0x0069 0x0F2A INCFSZ _milli+3, 0
0x006A 0x07F3 ADDWF R0+3, 1
0x006B 0x0870 MOVF R0, 0
0x006C 0x00A7 MOVWF _milli
0x006D 0x0871 MOVF R0+1, 0
0x006E 0x00A8 MOVWF _milli+1
0x006F 0x0872 MOVF R0+2, 0
0x0070 0x00A9 MOVWF _milli+2
0x0071 0x0873 MOVF R0+3, 0
0x0072 0x00AA MOVWF _milli+3
;uv_16f648a_lcd.c,247 :: PIR1.TMR1IF = 0;
0x0073 0x100C BCF PIR1, 0
;uv_16f648a_lcd.c,248 :: }
L_interrupt48:
;uv_16f648a_lcd.c,249 :: }
L_end_interrupt:
L__interrupt120:
0x0074 0x0823 MOVF 35, 0
0x0075 0x00F0 MOVWF R0
0x0076 0x0822 MOVF 34, 0
0x0077 0x00F1 MOVWF R1
0x0078 0x0821 MOVF 33, 0
0x0079 0x00F2 MOVWF R2
0x007A 0x0820 MOVF 32, 0
0x007B 0x00F3 MOVWF R3
0x007C 0x0824 MOVF 36, 0
0x007D 0x0084 MOVWF FSR
0x007E 0x084E MOVF ___savePCLATH, 0
0x007F 0x008A MOVWF PCLATH
0x0080 0x0E4D SWAPF ___saveSTATUS, 0
0x0081 0x0083 MOVWF STATUS
0x0082 0x0EFF SWAPF R15, 1
0x0083 0x0E7F SWAPF R15, 0
0x0084 0x0009 RETFIE
; end of _interrupt

c isr



void interrupt(void)
{
static signed char lut[] = {0,-1, 1, 0, 1, 0, 0, -1, -1, 0, 0, 1, 0, 1, -1, 0};
static signed char ev = 0;
if (INTCON.RBIF) { // RbC_INT
ev = ev << 2;
ev = ev | ((PORTB & 0b00110000) >> 4);
count += lut[ev & 0xf];
ccc = count >> 2; // divide 4 for 1 count per detent
INTCON.RBIF = 0;
}
if (PIR1.TMR1IF){ // tmr2
TMR1H = 63515/256;
TMR1L= 63515%256;
milli += 2;
PIR1.TMR1IF = 0;
}
}


and a different one

lst

; LST file generated by mikroListExporter - v.2.0
; Date/Time: 1/4/2015 11:01:07 AM
;----------------------------------------------

;Address Opcode ASM
0x0000 0x2D50 GOTO 1360
_interrupt:
0x0004 0x00FF MOVWF R15
0x0005 0x0E03 SWAPF STATUS, 0
0x0006 0x0183 CLRF STATUS
0x0007 0x00C5 MOVWF ___saveSTATUS
0x0008 0x080A MOVF PCLATH, 0
0x0009 0x00C4 MOVWF ___savePCLATH
0x000A 0x018A CLRF PCLATH
0x000B 0x0870 MOVF R0, 0
0x000C 0x00A1 MOVWF 33
;dr3200-pic16f88.c,111 :: void interrupt(){
;dr3200-pic16f88.c,113 :: if (PIR1.TMR1IF){
0x000D 0x1C0C BTFSS PIR1, 0
0x000E 0x2822 GOTO L_interrupt25
;dr3200-pic16f88.c,115 :: T1CON.TMR1ON = 0; // stop TIMER1
0x000F 0x1010 BCF T1CON, 0
;dr3200-pic16f88.c,116 :: data_in = data_in << 1;// shift data to the left
0x0010 0x0DBF RLF _data_in, 1
0x0011 0x0DC0 RLF _data_in+1, 1
0x0012 0x103F BCF _data_in, 0
;dr3200-pic16f88.c,117 :: porta.ra2=portc.rc5 ;
0x0013 0x1A87 BTFSC PORTC, 5
0x0014 0x2817 GOTO L__interrupt35
0x0015 0x1105 BCF PORTA, 2
0x0016 0x2818 GOTO L__interrupt36
L__interrupt35:
0x0017 0x1505 BSF PORTA, 2
L__interrupt36:
;dr3200-pic16f88.c,118 :: if (PORTC.RC5 == 1) // sample the incoming signal // inverted
0x0018 0x1E87 BTFSS PORTC, 5
0x0019 0x281B GOTO L_interrupt26
;dr3200-pic16f88.c,119 :: data_in = data_in | 1; // no need to ask for zero, since data_in is initially
0x001A 0x143F BSF _data_in, 0
L_interrupt26:
;dr3200-pic16f88.c,120 :: ++data_bit; // increment counter of bits
0x001B 0x0AA6 INCF _data_bit, 1
;dr3200-pic16f88.c,121 :: tmr1h = t3h; // preload TIMER1 with T3 == 0xFFFF-T2
0x001C 0x0828 MOVF _t3h, 0
0x001D 0x008F MOVWF TMR1H
;dr3200-pic16f88.c,122 :: tmr1l = t3l; // preload TIMER1 with T3 == 0xFFFF-T2
0x001E 0x0827 MOVF _t3l, 0
0x001F 0x008E MOVWF TMR1L
;dr3200-pic16f88.c,123 :: T1CON.TMR1ON = 1; // start TIMER1
0x0020 0x1410 BSF T1CON, 0
;dr3200-pic16f88.c,125 :: PIR1.TMR1IF= 0; // clear TMR1IF
0x0021 0x100C BCF PIR1, 0
;dr3200-pic16f88.c,126 :: }
L_interrupt25:
;dr3200-pic16f88.c,127 :: }
L_end_interrupt:
L__interrupt34:
0x0022 0x0821 MOVF 33, 0
0x0023 0x00F0 MOVWF R0
0x0024 0x0844 MOVF ___savePCLATH, 0
0x0025 0x008A MOVWF PCLATH
0x0026 0x0E45 SWAPF ___saveSTATUS, 0
0x0027 0x0083 MOVWF STATUS
0x0028 0x0EFF SWAPF R15, 1
0x0029 0x0E7F SWAPF R15, 0
0x002A 0x0009 RETFIE
; end of _interrupt

c code

void interrupt(){

if (PIR1.TMR1IF){

T1CON.TMR1ON = 0; // stop TIMER1
data_in = data_in << 1;// shift data to the left
porta.ra2=portc.rc5 ;
if (PORTC.RC5 == 1) // sample the incoming signal // inverted
data_in = data_in | 1; // no need to ask for zero, since data_in is initially
++data_bit; // increment counter of bits
tmr1h = t3h; // preload TIMER1 with T3 == 0xFFFF-T2
tmr1l = t3l; // preload TIMER1 with T3 == 0xFFFF-T2
T1CON.TMR1ON = 1; // start TIMER1

PIR1.TMR1IF= 0; // clear TMR1IF
}
}

mpgmike
- 17th December 2017, 17:21
In the end your compiled PBP statements are ASM too so yes, in theory, you can do that but remember that the PBP statements you use in that ISR might use the same system variables as your main routine and can therefor corrupt those values for whatever it was your main program was doing when it got interrupted. /Henrik.

I jumped out of ASM so "cheat" with a PAUSE 300 line, so no variables were modified. Creating a 300 ms pause in ASM is nowhere near as clean as PBP. Everything else I'm using ASM in my ISR.

HenrikOlsson
- 17th December 2017, 18:32
I'm sorry but I'm afraid you're mistaken, variables most certainly WAS modified. I'm not talking about "your" variables, I'm talking about PBPs internal variables.
You say that it's a lot "cleaner" to do a PAUSE with PBP (and I agree) but how do you think PBP does that PAUSE for you "behind the scenes"?

A PAUSE 300 compiles to this (for a 16F628A):

movlw low ((0012Ch) >> 8)
movwf R1 + 1
movlw low (low (0012Ch))
call PAUSEL
Already here we can see that system variable R1 is being used. The code also calls library routine PAUSEL and if you look that one up you'll see that it, on top of R1 also might use R0.

Now, let's take this super simple example of your main program being in the middle of a PAUSE 1000 when the interrupt happens. The PAUSE in the main routine obviously compiles to the same code as the PAUSE in the ISR so it's obviously using the same system variables (R1 and possibly R0). What do you think happens with the timing of the PAUSE statement in the main program when the PAUSE statement in the ISR overwrites system variables R1 and possibly R0?

/Henrik.

mpgmike
- 17th December 2017, 20:19
Henrik, stuff like this gets me thinking inside a much larger box over time. You have a knowledge base different (and in my opinion larger) than mine when it comes to programming. I so appreciate these little jewels. I know it worked in the application I used it for, but it could easily have done unexpected things, based on your post. Thanks again for teaching me.