PBP 3.0 really needed?


+ Reply to Thread
Results 1 to 31 of 31
  1. #1
    Join Date
    Jan 2008
    Location
    Selm, Germany
    Posts
    116

    Default PBP 3.0 really needed?

    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

  2. #2
    Join Date
    Oct 2005
    Location
    Sweden
    Posts
    3,204

    Default Re: PBP 3.0 really needed?

    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.

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

    Default Re: PBP 3.0 really needed?

    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

  4. #4
    Join Date
    Feb 2006
    Location
    Gilroy, CA
    Posts
    1,530

    Default Re: PBP 3.0 really needed?

    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)



    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.
    Last edited by ScaleRobotics; - 4th March 2012 at 18:13.
    http://www.scalerobotics.com

  5. #5
    Join Date
    Jan 2008
    Location
    Selm, Germany
    Posts
    116

    Default Re: PBP 3.0 really needed?

    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

  6. #6
    Join Date
    Feb 2006
    Location
    Gilroy, CA
    Posts
    1,530

    Default Re: PBP 3.0 really needed?

    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.
    http://www.scalerobotics.com

  7. #7
    Join Date
    Jan 2008
    Location
    Selm, Germany
    Posts
    116

    Default Re: PBP 3.0 really needed?

    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

  8. #8
    Join Date
    Jan 2005
    Location
    Montreal, Quebec, Canada
    Posts
    2,249

    Default Re: PBP 3.0 really needed?

    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.

    Robert

  9. #9
    Join Date
    Jan 2008
    Location
    Selm, Germany
    Posts
    116

    Default Re: PBP 3.0 really needed?

    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.

  10. #10
    Join Date
    Feb 2006
    Location
    Gilroy, CA
    Posts
    1,530

    Default Re: PBP 3.0 really needed?

    Glad you found it. Contact Melabs.com . They are the ones selling the upgrade.
    http://www.scalerobotics.com

  11. #11
    Join Date
    Feb 2009
    Posts
    6

    Default Re: PBP 3.0 really needed?

    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........

  12. #12
    Join Date
    Nov 2003
    Location
    Wellton, U.S.A.
    Posts
    5,924

    Default Re: PBP 3.0 really needed?

    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
    Dave
    Always wear safety glasses while programming.

  13. #13

    Default Re: PBP 3.0 really needed?

    And if you really do mean 12F1840, look here: http://www.picbasic.co.uk/forum/showthread.php?t=15001

  14. #14

    Default Re: PBP 3.0 really needed?

    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!

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

    Default Re: PBP 3.0 really needed?

    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 ...

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

  16. #16

    Default Re: PBP 3.0 really needed?

    18F97J94, I believe there is another one or two of different series

  17. #17

    Default Re: PBP 3.0 really needed?

    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

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

    Default J94's

    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.
    DT

  19. #19
    Join Date
    Oct 2004
    Posts
    441

    Default Re: J94's

    Quote Originally Posted by Darrel Taylor View Post
    ... 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
    and:
    PIC18F97J94 FAMILY.


    Norm

  20. #20
    Join Date
    Jan 2008
    Location
    Selm, Germany
    Posts
    116

    Default Re: J94's

    4 years are gone and I bought PBP3 Gold. I have the tendence of purchasing an excavator for planting a pansy.

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

    Default Re: J94's

    Yeah, I sorta overengineer stuff as well.
    Not as dumb as yesterday, but stupider than tomorrow!

  22. #22
    Join Date
    Nov 2003
    Location
    Greece
    Posts
    2,750

    Default Re: J94's

    Better be safe, right? But on the other hand an evolution is needed. And I can't see it...

    Ioannis

  23. #23
    Join Date
    Apr 2014
    Location
    Northeast
    Posts
    252

    Default Re: J94's

    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.

  24. #24
    Join Date
    Oct 2005
    Location
    Sweden
    Posts
    3,204

    Default Re: PBP 3.0 really needed?

    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.

  25. #25
    Join Date
    Apr 2014
    Location
    Northeast
    Posts
    252

    Default Re: PBP 3.0 really needed?

    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.

  26. #26
    Join Date
    Oct 2005
    Location
    Sweden
    Posts
    3,204

    Default Re: PBP 3.0 really needed?

    ....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.

  27. #27
    Join Date
    May 2013
    Location
    australia
    Posts
    1,510

    Default Re: PBP 3.0 really needed?

    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


    Code:
    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
    This is more entertaining than Free to Air TV

  28. #28
    Join Date
    May 2013
    Location
    australia
    Posts
    1,510

    Default Re: PBP 3.0 really needed?

    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
    Code:
    ;  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


    Code:
    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
    Code:
    ;  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
    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
       }
    }
    Last edited by richard; - 17th December 2017 at 01:21.
    This is more entertaining than Free to Air TV

  29. #29
    Join Date
    Apr 2014
    Location
    Northeast
    Posts
    252

    Default Re: PBP 3.0 really needed?

    Quote Originally Posted by HenrikOlsson View Post
    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.

  30. #30
    Join Date
    Oct 2005
    Location
    Sweden
    Posts
    3,204

    Default Re: PBP 3.0 really needed?

    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):
    Code:
    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.

  31. #31
    Join Date
    Apr 2014
    Location
    Northeast
    Posts
    252

    Default Re: PBP 3.0 really needed?

    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.

Members who have read this thread : 30

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