atmega328 SIG_INTERRUPT0 vs int0

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

I'm working with v-usb and there is this tidbit.

/* The following configurations have working defaults in usbdrv.h. You
 * usually don't need to set them explicitly. Only if you want to run
 * the driver on a device which is not yet supported or with a compiler
 * which is not fully supported (such as IAR C) or if you use a differnt
 * interrupt than INT0, you may have to define some of these.
 */
/* #define USB_INTR_CFG            MCUCR */
/* #define USB_INTR_CFG_SET        ((1 << ISC00) | (1 << ISC01)) */
/* #define USB_INTR_CFG_CLR        0 */
/* #define USB_INTR_ENABLE         GIMSK */
/* #define USB_INTR_ENABLE_BIT     INT0 */
/* #define USB_INTR_PENDING        GIFR */
/* #define USB_INTR_PENDING_BIT    INTF0 */
/* #define USB_INTR_VECTOR         INT0_vect */

also

#   ifndef USB_INTR_VECTOR /* default to hardware interrupt INT0 */
#       ifdef INT0_vect
#           define USB_INTR_VECTOR  INT0_vect       // this is the "new" define for the vector
#       else
#           define USB_INTR_VECTOR  SIG_INTERRUPT0  // this is the "old" vector
#       endif
#   endif

 

I'm having a hard time understanding what the SIG_INTERRUPT0  is opposed to the int0 with respect to the atmegaq328. Was there a name change in one of the ATmega chips and/or is this backward compatible thus no advantage over one or the other.

This topic has a solution.
Last Edited: Tue. Aug 21, 2018 - 01:28 PM
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

S_K_U_N_X wrote:
Was there a name change in one of the ATmega chips

???  What would the chip have to do with the name(s) that >>your chosen toolchain<< cares to use?

 

What does the documentation for >>your chosen toolchain<< say about the issue?

https://www.nongnu.org/avr-libc/...

Choosing the vector: Interrupt vector names

The interrupt is chosen by supplying one of the symbols in following table.

There are currently two different styles present for naming the vectors. ...

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Last Edited: Tue. Aug 21, 2018 - 01:20 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That is for backward compat with an older version of GCC.

 

These are not the droids your looking for, move along!

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274

 

 

 

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

I didn't realize this was tool chain naming that makes more sense now. All understood.

Last Edited: Tue. Aug 21, 2018 - 01:29 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
D:\atmel_avr\avr8-gnu-toolchain\avr\include\avr>grep -i poison iomx8*.h
#pragma GCC poison SIG_INTERRUPT0
#pragma GCC poison SIG_INTERRUPT1
#pragma GCC poison SIG_PIN_CHANGE0
#pragma GCC poison SIG_PIN_CHANGE1
#pragma GCC poison SIG_PIN_CHANGE2
#pragma GCC poison SIG_WATCHDOG_TIMEOUT
#pragma GCC poison SIG_OUTPUT_COMPARE2A
#pragma GCC poison SIG_OUTPUT_COMPARE2B
#pragma GCC poison SIG_OVERFLOW2
#pragma GCC poison SIG_INPUT_CAPTURE1
#pragma GCC poison SIG_OUTPUT_COMPARE1A
#pragma GCC poison SIG_OUTPUT_COMPARE1B
#pragma GCC poison SIG_OVERFLOW1
#pragma GCC poison SIG_OUTPUT_COMPARE0A
#pragma GCC poison SIG_OUTPUT_COMPARE0B
#pragma GCC poison SIG_OVERFLOW0
#pragma GCC poison SIG_SPI
#pragma GCC poison SIG_USART_RECV
#pragma GCC poison SIG_USART_DATA
#pragma GCC poison SIG_USART_TRANS
#pragma GCC poison SIG_ADC
#pragma GCC poison SIG_EEPROM_READY
#pragma GCC poison SIG_COMPARATOR
#pragma GCC poison SIG_TWI
#pragma GCC poison SIG_2WIRE_SERIAL
#pragma GCC poison SIG_SPM_READY

SIG_* is poisoned and has been for a decade or more.

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

clawson wrote:
SIG_* is poisoned and has been for a decade or more.
theusch wrote:
What does the documentation for >>your chosen toolchain<< say about the issue?

Starting with avr-libc version 1.4.0, a second style of interrupt vector names has been added, where a short phrase for the vector description is followed by _vect. The short phrase matches the vector name as described in the datasheet of the respective device (and in Atmel's XML files), with spaces replaced by an underscore and other non-alphanumeric characters dropped. Using the suffix _vect is intented to improve portability to other C compilers available for the AVR that use a similar naming convention.

The historical naming style might become deprecated in a future release, so it is not recommended for new projects.

 Cliff, you knew how to do the grep and what the "poison" means.  I tried to promote RTFM.  IMO, OP's initial queries are more than sufficiently addressed in the text, of which I gave tantalizing tidbits to try to encourage the imbibing of a full meal.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

I didn't read your reply - only the thread title. I was responding to that.