Something wrong with PBP?

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