DTs instant Interrupts

[Mugelpower]

maybe its like poking around in the holy grale of software marketing and the lawyers are ready for takeoff after this and me finding myself full of tar and feathers and dunno why.... but:

is it possible to integrate DTs instant interrupts into PBP?

or a subroutine in PBP that automatically inserts cool superfast ASM routines for interrupts?

I´m on the run....

[skimask]

Is it possible to integrate DTs instant interrupts into PBP?

You're kidding me right?
Run a search on the instant interrupts, read the thread...AGAIN if need be!
And tell us all what you think after reading the multitude of threads posted on these forums concerning that particular subject.

[tenaja]

...
is it possible to integrate DTs instant interrupts into PBP?

or a subroutine in PBP that automatically inserts cool superfast ASM routines for interrupts?

I´m on the run....

I agree with SKI for your first answer.

For the second question, I will offer this:
If you are using basic commands that compile into short asm code, the fastest interrupt is the built in software interrupts. This is because you don't have to save any variables.

If you are using basic commands that consume a lot of code, and take a lot of time to run, then you may add some code to provide a "Reduced-Delay" asm routine for interrupts. I said it this way because there is no way to get a "superfast" interrupt in Basic, unless you exercise great care and knowledge with the code--but certainly not as a plugin.

[skimask]

I said it this way because there is no way to get a "superfast" interrupt in Basic, unless you exercise great care and knowledge with the code--but certainly not as a plugin.

I don't know about that....those DT's Instant Int's are pretty fast, like Instant, like as in practically zero latency...and the Instant Int's package qualifies as a 'plug-in' in my book, 'cause you just plug in a few lines in the PBP code, and you're set.
But, yes, obviously you're right about what goes inside the interrupt code. Too easy to screw one's self trying to do too much between the INT and the RETFIE...

[tenaja]

If you are saving all of the variables every time, in my book, it is not "superfast." That's a lot of unnecessary saving. The latency of saving every variable can throw a PIC RTC off by one count every interrupt. If you have a 32kHz watch crystal, you have to account for that or accept the loss in time.

But, that is what Basic is all about... not the fastest or most efficient code, but the simplest.

[edit adds this...]
For "superfast" interrupts, eliminate all "system" variables in the interrupt so you don't have to save them. If you must use basic commands that require system variables, you can do this by duplicating the subroutines using unique variable names. Then, your only concern is if you have multi-byte variables that are read and/or modified within both the interrupt and the non-interrupt code.

...and even then, you can use a byte variable to set a flag, so you don't have the multi-byte reads and/or modifications...

[skimask]

If you are saving all of the variables every time, in my book, it is not "superfast." That's a lot of unnecessary saving. The latency of saving every variable can throw a PIC RTC off by one count every interrupt. If you have a 32kHz watch crystal, you have to account for that or accept the loss in time.

But, that is what Basic is all about... not the fastest or most efficient code, but the simplest.

I smell what you cookin'...I'm picking up what you're laying down...I'm diggin' what you're burying...
But who's saving all of the variables everytime an interrupt kicks out? Certainly not me! At most, it's W, STATUS, FSR, maybe a couple others, that's about it.

My watch doesn't have a 32kHz crystal...in fact it doesn't even have a crystal...in fact, I don't even have a watch...never mind... I just lost some time And I accept that...