bianchi77 
Guys,
I tried to compile :
#define UART0_RECEIVE_INTERRUPT SIG_UART0_RECV
and got :
attempt to use poisoned "SIG_UART0_RECV"
I'm using avr studio 6.1
any ideas on how to rectify it ?
Thanks
david.prentice Nowadays, you should use
I suspect that you are using some 10-year old code.
Just use grep or "Search Files" for the SIG_XXX type of statements. Replace with the modern style.
Note that some header files have typos in the vector names. So I would check the spelling of USART0_RXC_vect in your
David.
bianchi77 where can I find this iomxxxx.h file ? and avr/interrupt.h ?
is this what you mean ?
..\avr-libc-1.8.0\include\avr\iom128.h
thanks
david.prentice If you are using AS6, you can click on the Dependencies node to see iomxxx.h files. e.g. "iom128.h"
By all means read these system files. When done, close the file in the Editor. Otherwise, you risk corrupting the file by mistake.
You can also read interrupt.h but quite honestly, you should read the HTML rather than the H file. e.g. http://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html
David.
bianchi77 I can see on iom128.h
/* USART0, Rx Complete */
#define SIG_UART0_RECV _VECTOR(18)
why is it giving me
attempt to use poisoned "SIG_UART0_RECV"
david.prentice /* USART0, Rx Complete */ #define USART0_RX_vect_num 18 #define USART0_RX_vect _VECTOR(18) #define SIG_USART0_RECV _VECTOR(18) #define SIG_UART0_RECV _VECTOR(18)
I see what you mean!
Most header files have removed the SIG_XXXX macros because they are not supposed to be used any more.
Surely you can just use:
ISR(USART0_RX_vect)
{
...
}
i.e. as God intended.
David.
clawson 
why is it giving meattempt to use poisoned "SIG_UART0_RECV"
#define SIG_USART0_RECV _VECTOR(18) #define SIG_UART0_RECV _VECTOR(18)
but later:
#pragma GCC poison SIG_USART0_RECV #pragma GCC poison SIG_UART0_RECV
The poisoning here is deliberate - it's to try and stop you using it (because you are using something that died about 9 years ago!!).
bianchi77 is it ok if I disable it ?
#pragma GCC poison SIG_USART0_RECV #pragma GCC poison SIG_UART0_RECV
Koshchi What is wrong with using the preferred ISR names?
david.prentice It seems unwise to shoot your own feet.
Hey-ho, you can do whatever you like.
There are various conventions that are often followed. If you are in a team, your company will often dictate some standards.
If you are a hobbyist, what does it matter?
You just have to repeat your 'features' with every new compiler release.
David.
is it ok if I disable it ?#pragma GCC poison SIG_USART0_RECV #pragma GCC poison SIG_UART0_RECV
Why are you trying to use this old code in the first place? What does it do that you need to use it?
clawson
No, it is not ok to disable it.
There are two solutions. A good one and a stupid one. The good one is simply to take this ancient code you are trying to use and bring it into the modern age by ditching any use of SIGNAL() and SIG_whatever and replace this with ISR() and and WHATEVER_vect (or it might be better to just ditch the code all together and find something written in the last ten years!).
The stupid solution is:
#define __AVR_LIBC_DEPRECATED_ENABLE__ #include
That turns off the "poison"s but this is a really really poor solution and should only be used as an act of desperation.
bobgardner Isnt the difference between signal and interrupt is that one reenables interrupts in the handler?
clawson Oh well remembered that man. You are talking of the days (< 2006) of SIGNAL() and INTERRUPT() where the first left I untouched while the second enabled it on entry.
These days it's all done with ISR() alone but ISR() is variadic and can take a number of parameters so you can just use:
ISR(INT0_vect) {
}
and you get a "normal" ISR with I disabled. But you can also use:
ISR(INT0_vect, ISR_NOBLOCK) {
}
and that is one in which the prologue enables I as soon as possible.
BTW this is GCC specific so I'll move it ;-)