Something wrong with PBP?

[rsocor01]

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

[Mike, K8LH]

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

      MOVE?BB  FDutyVar, BuffAddr#v(FDutyVar)

[Heckler]

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.

[Mike, K8LH]

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

[rsocor01]

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

[mister_e]

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

Cheerful regards, Mike

      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

[Mike, K8LH]

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

[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]

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.