#271 macro compatibility with Keil

[Kharitonov Dmitry]

During work I ran into some incompatibility with Cale. I offer macros to correct this.

[Maarten Brock]

# define ISR(vector,bank)       void vector ## _isr(void) __interrupt(vector) __using bank __reentrant

How is this supposed to be used? If vector is a number you get an illegal identifier, if vector is an identifier you get an illegal interrupt number.

And why do you want to force the isr reentrant?

[Kharitonov Dmitry]

For example:

ISR(ADC0_EOC_VECTOR,0) {
    res_adc=ADC0;
    adc_done=1;
    AD0INT = 0;
}

extract to:

void ADC0_EOC_VECTOR_isr(void) __interrupt(10) __using 0 __reentrant {
    res_adc=ADC0;
    adc_done=1;
    AD0INT = 0;
}

Interrupt vectors should always be reentrant. This ensures the preservation of all the registers.

[Kharitonov Dmitry]

You can do so that you can use a number of interrupt vectors.

# define ISR(vector,bank)       void _ ## vector ## _isr(void) __interrupt(vector) __using bank __reentrant

For example:

#define ADC0_EOC_VECTOR      10     /* ADC0 End Of Conversion */

ISR(ADC0_EOC_VECTOR,0) {
    res_adc=ADC0;
    adc_done=1;
    AD0INT = 0;
}

ISR(1,0) {
    res_adc=ADC0;
    adc_done=1;
    AD0INT = 0;
}

extract to:

void _ADC0_EOC_VECTOR_isr(void) __interrupt(10) __using 0 __reentrant {
    res_adc=ADC0;
    adc_done=1;
    AD0INT = 0;
}

void _1_isr(void) __interrupt(1) __using 0 __reentrant {
    res_adc=ADC0;
    adc_done=1;
    AD0INT = 0;
}

[Maarten Brock]

The preservation of registers is already handled for an __interrupt function. Besides, with SDCC using caller-save to preserve registers, __reentrant doesn't help a bit.

I understand now that you assume that vector is a macro itself as well. There was nothing pointing in that direction and it's not necessary either if you fix the macro.

[Kharitonov Dmitry]

Yes. I always try instead of numeric constants use a macro, all the more that the macro is already defined in the header at MCU.

I once used to interrupt the complex function in which the code generated is not correct. And I wanted to write it in assembly language, but read the guide SDCC, which saw __reentrant. And then everything happened. Perhaps this was due to a call from the interrupt other functions.

[Maarten Brock]

There need not always be a macro for every interrupt number. And a user may choose to ignore it. Remember you want to give this to all users, not just to yourself.

But since it doesn't seem to come across, if you change the macro like this the problem goes away:

# define ISR(vector,bank)   void isr_ ## vector (void) __interrupt(vector) __using(bank)

All functions that are called from both an interrupt service routine (isr) and the main loop should be reentrant. The isr itself need not be, unless you call it for several interrupt sources with different priorities.

Btw. What is Cale?

[Kharitonov Dmitry]

That's right, the user has the option to use macros or not. A user can write all himself, or to use a convenient macro.

My managers require that the project was compiled on Keil. Keil gives a very poor error diagnostics. So I debug at the SDCC, and the final compilation do on Keil. For me, it's weird. SDCC generate code at approximately 15% shorter.

Your offer is very good. But the programmer is more convenient to look for the label when its name begins as have programmer.

When I had problems with reentrant, I did not know that this is a bug. I thought that was such a feature or dialect SDCC. I'll try to find that project and check again.

My English is very bad, so I use the translation program. This is so the translator has translated the word Keil. I'm sorry, I did not notice before posted.

[Maarten Brock]

I've decided to fix the incompatibility with the macros that SiLabs already used for years. instead of using your version. Still, this patch triggered me into doing this, so it was not all for nothing.