attempt to use poisoned "SIG_UART0_RECV" on atmega

Go To Last Post
14 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Nowadays, you should use and ISR(SOME_INTERRUPT_vect) style.

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

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
/* 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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

why is it giving me

attempt to use poisoned "SIG_UART0_RECV"


Read ALL of that file:

#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!!).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

is it ok if I disable it ?

#pragma GCC poison SIG_USART0_RECV
#pragma GCC poison SIG_UART0_RECV 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What is wrong with using the preferred ISR names?

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bianchi77 wrote:
is it ok if I disable it ?

#pragma GCC poison SIG_USART0_RECV
#pragma GCC poison SIG_UART0_RECV 

No, it is not ok to disable it. They were disabled for a reason. Do what everyone is telling you, use the preferred ISR names.

Why are you trying to use this old code in the first place? What does it do that you need to use it?

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

No, it is not ok to disable it.

Apart from anything else you must NEVER edit any .h file that comes with the compiler (when you upgrade next week all your edits will be lost anyway!). If something in a supplied .h causes problems in your code then fix that problem IN YOUR CODE.

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Isnt the difference between signal and interrupt is that one reenables interrupts in the handler?

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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 ;-)