Something wrong with PBP?

[HenrikOlsson]

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:

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

[cncmachineguy]

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.

[rmteo]

Hex is the only actual language the PIC understands.

Actually, binary is the only language that the PIC (and every MCU) understands.

[mister_e]

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

[rmteo]

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?

[bogdan]

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

[mister_e]

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?

[mister_e]

PBP aren't documented, but like Henrik said, dig the .LIB files.

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.