Interrupt Latency - ASM vs. Basic

[barkerben]

Hi,

I'm planning on usin serial interruots in PICBasic. I'm keeping the main loop as simple as possible to avod delays in servicing the interrupt, and thus minimizing the chance of buffer overrun. I am aos planning to reduce the serial speed to 300 baud. Hopefully, this will be enough. However, I have noticed some people using ASM service routines, using

DEFINE INTHAND ....

Rather than ON INTERRUPT

I assume that the advantage of embedding an ASM routine in the basic is that it is serviced more quickly. Is this the case, and if so, why ....?


Thanks,

Ben

[mister_e]

Assembly language is still the fastest way to handle interrupt. It use the internal language of the PIC without any other reference/interpretation. I mean, when you're using PICBASIC command, it can refer to hundreds lines of code before finishing one instruction.

The PICBASIC interrupt work well to. It's just another way to use interrupts. BTW if you're planning to use Serial interrupt, choose a PIC that have an internal USART. It will provide you an USART interrupt.

Always keep the main loop instruction as simple as you can. If you must use some delay, do a loop with PAUSEUS or @ NOP. Avoid statement like COUNT, PULSOUT, PULSIN, FREQOUT or so that take time to be finish. There's so many other way to do what they do using the internal TIMER or so. That way, interrupt will be taken faster.

For all my apps, i always use BASIC interrupt. it's just another way of coding. Hope this help you a bit!

[barkerben]

Thanks - basically what I am making is a PC controlled clock output to drive a stepper motor- the PC can set frequency and also a number of control lines on the PIC for controlling the motor.

To keep the main loop quick, I am using TMR1 interrupts to generate the clock - whenever a hardware interrupt occurs, the idea is the service routine checks the flags to see what type of interrupt it is (Timer or Serial) and responds accordingly. All the main loop does is constantly check a series of IF statements to see if one of the interrupt routines has done something which needs responding to (such as changinf clock freq.)

Because of the 2 byte buffer serial, I'm worried about overflow, but at 300 baud, it should take just over 50ms for the buffer to fill up, so hopefully I should be ok. I don't know what kind of latency to expect, but I suspect it will be less than 50ms if I am careful.

Of course, the worst case might be if serial data arrives while a timer interrupt is being serviced, in which case the interruot is missed and we have overlow. Keeping the service routines as short as possible should sort this out I hope.



I've written most of the cde, and will be trying it out next week when I get back to university - I suspect I may make some more posts then :-) thanks for your help,

Ben

[mister_e]

if you're really afraid of the amount of time to get the interrupt, have a HS crystal (20MHZ) or use a PIC that can run up to 40MHZ... But testing in a real world environement will give you the right answer on those delay.

[barkerben]

Thanks - I'm using 4Mhz at the moment, but could up the frequency if I have latency problems. I suspect I will be ok in fact - but I will let uou know hw it goes in the lab. The hardware is all built, so a few days coding and I will know how rthings stand!

I assume the only problem with increasing the crystal frequency is that some of the PICBasic
default commands assume 4Mhz, so care would be needed when implementing them?

One final question:

I realise that, as you say, one command in PICBasic might com pile to many lines of assembler. For this reason, an interrupt service routine written in ASM would prob. be quicker than the same thing written in basic. However, there seems to be a suggestion on various sites that an ASM service routine embedded in a Basic program will be called more quickly - why should this be? Surely the advantages of ASM do not come into play intil the program is already in the service routine...

Cheers, and have a good New Year,


Ben

[mister_e]

I assume the only problem with increasing the crystal frequency is that some of the PICBasic
default commands assume 4Mhz, so care would be needed when implementing them?

you'll void some problem when you'll add DEFINE OSC (value) at the begining of your code. But if you plan to use any kind of PULSIN or else... sure you have to be carefull.

However, there seems to be a suggestion on various sites that an ASM service routine embedded in a Basic program will be called more quickly - why should this be?

for the same reasons as above. But don't be afraid for now. Try it first. BASIC interrupt is not as slow as you can think. Your coding style can slow the interrupt.

BTW, feel free to post any kind of code here if you have problem.

Happy new year to you!