Something wrong with PBP?


Closed Thread
Results 1 to 21 of 21
  1. #1
    Join Date
    Aug 2005
    Location
    Michigan, USA
    Posts
    224

    Default Something wrong with PBP?

    Is there a problem with the way PBP handles interrupts? Why would you need to add something like DT-Interrupts to a program?

    Also, what's the deal with inserting assembly language into PBP programs? It doesn't look anything like the PIC assembly language I'm familiar with. Why does it look so strange?

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


    Did you find this post helpful? Yes | No

    Default Re: Something wrong with PBP?

    Quote Originally Posted by Mike, K8LH View Post
    Is there a problem with the way PBP handles interrupts? Why would you need to add something like DT-Interrupts to a program?
    No need to use DT's stuff. Just makes things easier.
    Also, what's the deal with inserting assembly language into PBP programs? It doesn't look anything like the PIC assembly language I'm familiar with. Why does it look so strange?
    All assembly looks strange to me
    Dave
    Always wear safety glasses while programming.

  3. #3
    Join Date
    Oct 2005
    Location
    Sweden
    Posts
    3,518


    Did you find this post helpful? Yes | No

    Default Re: Something wrong with PBP?

    Hi,
    To elaborate a bit on Dave's reply:
    PBP uses a bunch of working/temporary variables "behind the scenes". For example, when you do a HSEROUT["This is a test"] PBP must keep track of which character in the string to send next just like you'd do with a WHILE-WEND or FOR-NEXT loop etc. These temporary/working variables are shared between several PBP commands. This means that if you are in the middle of a HSEROUT when an interrupt fires and the code in the interrupt handler happens to use the SAME temporary/working variables that the HSEROUT is using you're pretty much screwed.

    What DT-INTS does is saving these temporary/working variables when entering the interrupt routine and restores them when exiting in order to not mess anything up in the main program.

    All this COULD have been built in, you woudn't know about it and there wouldn't be anything "wrong" with the way PBP handles interrupts. It's just that now we have the OPTION to select the best aproach to interrupt for the particullar application at hand. If you don't care much about code space or latency use ON INTERRUPT, if you want "hard" interrupts but still want to write the interrupt code in PBP use DT-INTS, if you need the absolute best performance use "true" ASM interrupts.


    What do you mean inserting asm looks strange?
    If you insert it then you wrote it so must look the way you wrote it....? Or do you mean the assembly code created by PBP?

    /Henrik.

  4. #4
    Join Date
    Aug 2011
    Posts
    408


    Did you find this post helpful? Yes | No

    Default Re: Something wrong with PBP?

    Unless things have changed in recent versions, the real issue is that PBP doesn't use interrupts in the conventional sense. To get around some of the issues Henrik pointed out, PBP uses a polled method which can drastically effect the latency, or interrupt response time.

    Some snippets from the manual:
    When an interrupt occurs, it is flagged. As soon as the current PICBASIC PRO statement’s execution is complete, the program jumps to the BASIC interrupt handler at Label.

    Since PICBASIC PRO statements are not re-entrant (i.e. you cannot execute another PICBASIC PRO statement while one is being executed), there can be considerable latency before the interrupt routine is entered.

    PBP will not enter the BASIC interrupt handler until it has finished executing the current statement. If the statement is a PAUSE or SERIN, it could be quite a while before the interrupt is acknowledged.
    So, basically if you're using the ON INTERRUPT method, PBP polls the IF between PICBASIC statements, not at the uC instruction level. Depending on what you're doing, this can make them useless.

  5. #5
    Join Date
    May 2007
    Posts
    604


    Did you find this post helpful? Yes | No

    Default Re: Something wrong with PBP?

    Quote Originally Posted by HenrikOlsson View Post
    Hi,
    All this COULD have been built in, you woudn't know about it and there wouldn't be anything "wrong" with the way PBP handles interrupts. It's just that now we have the OPTION to select the best aproach to interrupt for the particullar application at hand. If you don't care much about code space or latency use ON INTERRUPT, if you want "hard" interrupts but still want to write the interrupt code in PBP use DT-INTS, if you need the absolute best performance use "true" ASM interrupts.

    /Henrik.
    From the viewpoint of a PIC (or any processor for that matter), an interrupt is an interrupt. It really doesn't know (or care) whether it is an ASM, BASIC, C or Super-Dooper interrupt. As far as the OP's question is concerned, its about how the compiler handles the interrupt request.
    Why pay for overpriced toys when you can have
    professional grade tools for FREE!!!

  6. #6
    Join Date
    Oct 2005
    Location
    Sweden
    Posts
    3,518


    Did you find this post helpful? Yes | No

    Default Re: Something wrong with PBP?

    Right, and since we're talking about the compiler and not the PIC itself what I ment with built in was obviously built into the compiler - not the chip. I thought that was pretty obvious but apparently it wasn't.

    /Henrik.

  7. #7
    Join Date
    Jan 2009
    Location
    Miami, Florida USA
    Posts
    637


    Did you find this post helpful? Yes | No

    Default Re: Something wrong with PBP?

    Quote Originally Posted by Mike, K8LH View Post
    Also, what's the deal with inserting assembly language into PBP programs?
    Mike,

    I agree with you on this one. Unless you are designing a time sensitive application, where you need to have control of the clock cycles, I don't see why you need assembly lines in your code. A friend of mine, who is a computer programmer, told me one time that the assembly language is something trivial. Does anybody else agree with this point of view?

    Robert
    "No one is completely worthless. They can always serve as a bad example."

    Anonymous

  8. #8
    Join Date
    Aug 2005
    Location
    Michigan, USA
    Posts
    224


    Did you find this post helpful? Yes | No

    Default Re: Something wrong with PBP?

    Thank you Gentlemen. I downloaded the PBP3 Reference Manual and it looks like much of the information is in there.

    I suspect if I keep looking I might find an explanation for strange assembly language like that below...

    Cheerful regards, Mike

    Code:
          MOVE?BB  FDutyVar, BuffAddr#v(FDutyVar)

  9. #9
    Join Date
    Oct 2009
    Location
    Utah, USA
    Posts
    427


    Did you find this post helpful? Yes | No

    Default Re: Something wrong with PBP?

    A friend of mine, who is a computer programmer, told me one time that the assembly language is something trivial. Does anybody else agree with this point of view?
    Depends on what the meaning of the word "is" is.
    sorry... I digress.

    Assembly is, I believe, the lowest level of language that can be used to program a PIC. In order to code in assembly one must have an intimate working knowledge of the inner workings of the PIC. Must know about the various registers, the stack, addressing, flags, memory banks, etc, etc.

    If you are good at assembly your code will be the most compact (fewest number of bytes). PICbasic for example makes writing and understanding a program MUCH easier, BUT at the expense of compactness. It is considered a Higher Level Language.

    I am not a "C" programer, but I believe, it is somewhat closer to assembly than Basic.

    If your friend meant by "trivial" that it is easy and there is "nothing to it" then I do not agree... but that is probably because I am not familiar with the inner workings of the PIC micro. If he meant that it is the most basic form of language that one can code in... he/she was probably correct.

    If you look through a PIC data sheet there are numerous examples of coding in assembly... for example in the 16F690 datasheet here is how to initialize PORTA
    BCF STATUS,RP0 ;Bank 0
    BCF STATUS,RP1 ;
    CLRF PORTA ;Init PORTA
    BSF STATUS,RP1 ;Bank 2
    CLRF ANSEL ;digital I/O
    BSF STATUS,RP0 ;Bank 1
    BCF STATUS,RP1 ;
    MOVLW 0Ch ;Set RA<3:2> as inputs
    MOVWF TRISA ;and set RA<5:4,1:0>
    ;as outputs
    BCF STATUS,RP0 ;Bank 0
    I would prefer to work at a higher level and not have to worry about the finer details of the inner "guts" of the PIC.

    Sometimes, though, the only way to get a job done is to use assembly. Especially when TIME/SPEED is critical.

    my .02

    ============================
    @ Mike,K8LH
    If you are hoping to learn about assembly by reading the PICbasic manual... I do not think you will find much. It details how to use the BASIC language (specifically PICbasic written by MELabs) since there are several versions of BASIC one must pay close attention to syntax and command structure for the version of BASIC they are using. If you were using PROTON BASIC... the PICbasic manual would do you no good. (except for general learning and comparison)

    I often look over on the Parallax Basic Stamp forum for coding examples as PICbasic and the basic stamp are quite similar.

    I am not sure where to go to learn about assembly... I do know there are some VERY GOOD assembly programers that hang around here that might be able to steer you.
    Last edited by Heckler; - 7th November 2011 at 02:56.
    Dwight
    These PIC's are like intricate puzzles just waiting for one to discover their secrets and MASTER their capabilities.

  10. #10
    Join Date
    Aug 2005
    Location
    Michigan, USA
    Posts
    224


    Did you find this post helpful? Yes | No

    Default Re: Something wrong with PBP?

    Thanks for the additional info' Dwight. FYI, I'm a reasonably accomplished assembly language programmer and I also use C. I also enjoyed using the free/lite version of the Swordfish BASIC compiler a couple years ago.

    I agree that high level languages are faster, more readable, and more intuitive when compared to assembly language and I often include C code comments in my assembly language programs to help convey concepts.

    Regards, Mike

  11. #11
    Join Date
    Sep 2004
    Location
    montreal, canada
    Posts
    6,898


    Did you find this post helpful? Yes | No

    Default Re: Something wrong with PBP?

    Quote Originally Posted by Mike, K8LH View Post
    I suspect if I keep looking I might find an explanation for strange assembly language like that below...

    Cheerful regards, Mike

    Code:
          MOVE?BB  FDutyVar, BuffAddr#v(FDutyVar)
    MOVE?BB is a PBP macro. It move the value of a Byte var into another BYTE var.

    Buffaddr#v(FDutyVar)
    #v is a MPASM text substitution.

    How it works: assume the value of FDutyVar =1, MPASM replace the text at compile time like so
    Buffaddr1. At compile time MOVE?BB FDutyVar, BuffAddr#v(FDutyVar) will compile MOVE?BB FDutyVar, BuffAddr1

    slick huh?

    Seems this MPASM feature is far to be well documented ... the last time I checked
    Steve

    It's not a bug, it's a random feature.
    There's no problem, only learning opportunities.

  12. #12
    Join Date
    Jan 2009
    Location
    Miami, Florida USA
    Posts
    637


    Did you find this post helpful? Yes | No

    Default Re: Something wrong with PBP?

    Quote Originally Posted by Heckler View Post
    If your friend meant by "trivial" that it is easy and there is "nothing to it" then I do not agree... but that is probably because I am not familiar with the inner workings of the PIC micro. If he meant that it is the most basic form of language that one can code in... he/she was probably correct.
    I can only guess what he meant by "trivial". But, remember I said he is a computer programmer, so he was referring to assembly language for computers. I think that he meant that assembly was "trivial" or "of no importance" to him since he can do with computers anything he wants with higher level languages like C and Java. I thought that the same could be said about PICs.

    Robert
    "No one is completely worthless. They can always serve as a bad example."

    Anonymous

  13. #13
    Join Date
    Aug 2005
    Location
    Michigan, USA
    Posts
    224


    Did you find this post helpful? Yes | No

    Default Re: Something wrong with PBP?

    Quote Originally Posted by mister_e View Post
    MOVE?BB is a PBP macro.
    A search on "move?bb" or "macro" within the PBP3 Ref' Manual doesn't turn up anything but I'll keep looking...

    Thanks...

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


    Did you find this post helpful? Yes | No

    Default Re: Something wrong with PBP?

    Hi Mike,
    I'm a bit out on the deep end here but I'll make a try....
    MOVE?BB is not a PBP command which is why it's not in the PBP manual, it's an assembly macro used by the compiler to "build" the compiled version of your source code.

    When you compile your PBP source code it's compiled into the type of ASM that you are referreing to. It's a series of assembler macros and you need to check the MPASM documentation (not the PBP manual) to find more details on macros in general.

    Basically MOVE?BB is then "replaced" with the "real" assembly code of the MOVE?BB macro "call" (it's not a the same as a subroutine though) which in this case is stored in the PBPPIC18.LIB (if you're compiling for an PIC18 device). If you open that file you'll find a boatload of macros and the code for the MOVE?BB macro looks like this:
    Code:
    ;****************************************************************
    ;* MOVE?BB    : Macro - Move BYTE variable into BYTE variable   *
    ;*                                                              *
    ;* Input      : Bin    = BYTE variable                          *
    ;* Output     : Bout   = BYTE variable                          *
    ;*                                                              *
    ;* Notes      :                                                 *
    ;****************************************************************
    
    MOVE?BB macro Bin, Bout
            movff   Bin, Bout
        endm
    I suspect the actual code of the macro is more in the line of what you're familiar with.

    But really, if you want to include assembly (single lines or blocks of code) in your program you don't need to worry about these macros (but you CAN use them if you want to) just write your ASM the way you're used to with movff, btfsc, bsf and so on.

    Other compilers hides this stuff completely for you, having their libraries closed, but with PBP everything is there for you to investigate if you want to - but there's generally no need to worry about them. Again, if you want to inline assembly just code away in the same way you're used to.

    Hopefully someone will jump in correct me if I'm way off.

    /Henrik.

  15. #15
    Join Date
    Aug 2010
    Location
    Maryland, USA
    Posts
    869


    Did you find this post helpful? Yes | No

    Default Re: Something wrong with PBP?

    Assembly is, I believe, the lowest level of language that can be used to program a PIC.
    Assembler is still a higher level, albiet not very high. Hex is the only actual language the PIC understands. I had to code in hex WAAYYY back in collage for 8085's. Man it was crap! basically write the code in mnumonics, then convert it all to hex. Then input it on a development do-hicky that had a 16 key keypad and (6) 7 segment displays. We did really cool stuff like hard code 2 plus 3 and display it.

    But it had it's place in my learning, I still remember how to multiplex the display to make all of them look on at once.
    -Bert

    The glass is not half full or half empty, Its twice as big as needed for the job!

    http://foamcasualty.com/ - Warbird R/C scratch building with foam!

  16. #16
    Join Date
    May 2007
    Posts
    604


    Did you find this post helpful? Yes | No

    Default Re: Something wrong with PBP?

    Quote Originally Posted by cncmachineguy View Post
    Hex is the only actual language the PIC understands.
    Actually, binary is the only language that the PIC (and every MCU) understands.
    Why pay for overpriced toys when you can have
    professional grade tools for FREE!!!

  17. #17
    Join Date
    Sep 2004
    Location
    montreal, canada
    Posts
    6,898


    Did you find this post helpful? Yes | No

    Default Re: Something wrong with PBP?

    Actually, they don't understand anything... they're just lambs... they do what your compiled code ask them... and sometimes... not what YOU want
    Steve

    It's not a bug, it's a random feature.
    There's no problem, only learning opportunities.

  18. #18
    Join Date
    Sep 2004
    Location
    montreal, canada
    Posts
    6,898


    Did you find this post helpful? Yes | No

    Default Re: Something wrong with PBP?

    PBP aren't documented, but like Henrik said, dig the .LIB files.
    Quote Originally Posted by HenrikOlsson View Post
    But really, if you want to include assembly (single lines or blocks of code) in your program you don't need to worry about these macros (but you CAN use them if you want to) just write your ASM the way you're used to with movff, btfsc, bsf and so on.
    The advantage of knowing the internal macro is you don't always need to worry about bank/page switching, WDT reset... and writing additional code for common tasks... and it's a little bit easier to read... and if you switch from PIC family to another, you don't need to worry about the different asm instructions. But yes, it's not a must, just handy tool.
    Steve

    It's not a bug, it's a random feature.
    There's no problem, only learning opportunities.

  19. #19
    Join Date
    May 2007
    Posts
    604


    Did you find this post helpful? Yes | No

    Default Re: Something wrong with PBP?

    Quote Originally Posted by mister_e View Post
    Actually, they don't understand anything... they're just lambs... they do what your compiled code ask them... and sometimes... not what YOU want
    How are they able to do what your compiled code asks them to if they do not understand anything?
    Why pay for overpriced toys when you can have
    professional grade tools for FREE!!!

  20. #20
    Join Date
    Jan 2009
    Posts
    78


    Did you find this post helpful? Yes | No

    Default Re: Something wrong with PBP?

    How are they able to do what your compiled code asks them to if they do not understand anything?
    make sense for me, and Yes ... this is my case

  21. #21
    Join Date
    Sep 2004
    Location
    montreal, canada
    Posts
    6,898


    Did you find this post helpful? Yes | No

    Default Re: Something wrong with PBP?

    Quote Originally Posted by rmteo View Post
    How are they able to do what your compiled code asks them to if they do not understand anything?
    For two reasons, the first being exactly for the same reason why children hate cauliflower the really first time they see some in their plate.

    Second one being the answer to the following question:
    Why when I buy soft cookie they become hard, but when I buy hard one they become soft?
    Steve

    It's not a bug, it's a random feature.
    There's no problem, only learning opportunities.

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