Something wrong with PBP?

[Mike, K8LH]

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?

[mackrackit]

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

[HenrikOlsson]

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.

[tumbleweed]

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.

[rmteo]

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.

[HenrikOlsson]

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.

[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. :biggrin-new:
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

[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

[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

[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. :devilish:

[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 :)

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

[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? :highly_amused:

[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? :highly_amused:
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?