Interrupt names for ATmega4809? [SOLVED]

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

Help, Freaks!

 

I've looked in the device-specific data sheet, I've looked in the Mega-0 data sheet. I've looked in the Microchip AVR LibC documentation. Zilch! Found a vector table but nothing that  looks like proper names!

 

Where does one find the proper names for gcc? I really hope they are not buried in the avr/io file morass! I have no clue about navigating that. Already spent more time than any mortal ought to need to spend!

 

Thanks

Jim

This topic has a solution.

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Tue. Mar 31, 2020 - 04:34 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It is in iom4809.h.
All have "_vect" at the end.

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

This might help?

 

Attached.

 

 

Jim

Attachment(s): 

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
/* ========== Interrupt Vector Definitions ========== */
/* Vector 1 is the reset vector */

/* CRCSCAN interrupt vectors */
#define CRCSCAN_NMI_vect_num  2
#define CRCSCAN_NMI_vect      (2)  /*  */

/* BOD interrupt vectors */
#define BOD_VLM_vect_num  3
#define BOD_VLM_vect      (3)  /*  */

/* RTC interrupt vectors */
#define RTC_CNT_vect_num  4
#define RTC_CNT_vect      (4)  /*  */
#define RTC_PIT_vect_num  5
#define RTC_PIT_vect      (5)  /*  */

/* CCL interrupt vectors */
#define CCL_CCL_vect_num  6
#define CCL_CCL_vect      (6)  /*  */

/* PORTA interrupt vectors */
#define PORTA_PORT_vect_num  7
#define PORTA_PORT_vect      (7)  /*  */

/* TCA0 interrupt vectors */
#define TCA0_LUNF_vect_num  8
#define TCA0_LUNF_vect      (8)  /*  */
#define TCA0_OVF_vect_num  8
#define TCA0_OVF_vect      (8)  /*  */
#define TCA0_HUNF_vect_num  9
#define TCA0_HUNF_vect      (9)  /*  */
#define TCA0_LCMP0_vect_num  10
#define TCA0_LCMP0_vect      (10)  /*  */
#define TCA0_CMP0_vect_num  10
#define TCA0_CMP0_vect      (10)  /*  */
#define TCA0_CMP1_vect_num  11
#define TCA0_CMP1_vect      (11)  /*  */
#define TCA0_LCMP1_vect_num  11
#define TCA0_LCMP1_vect      (11)  /*  */
#define TCA0_CMP2_vect_num  12
#define TCA0_CMP2_vect      (12)  /*  */
#define TCA0_LCMP2_vect_num  12
#define TCA0_LCMP2_vect      (12)  /*  */

/* TCB0 interrupt vectors */
#define TCB0_INT_vect_num  13
#define TCB0_INT_vect      (13)  /*  */

/* TCB1 interrupt vectors */
#define TCB1_INT_vect_num  14
#define TCB1_INT_vect      (14)  /*  */

/* TWI0 interrupt vectors */
#define TWI0_TWIS_vect_num  15
#define TWI0_TWIS_vect      (15)  /*  */
#define TWI0_TWIM_vect_num  16
#define TWI0_TWIM_vect      (16)  /*  */

/* SPI0 interrupt vectors */
#define SPI0_INT_vect_num  17
#define SPI0_INT_vect      (17)  /*  */

/* USART0 interrupt vectors */
#define USART0_RXC_vect_num  18
#define USART0_RXC_vect      (18)  /*  */
#define USART0_DRE_vect_num  19
#define USART0_DRE_vect      (19)  /*  */
#define USART0_TXC_vect_num  20
#define USART0_TXC_vect      (20)  /*  */

/* PORTD interrupt vectors */
#define PORTD_PORT_vect_num  21
#define PORTD_PORT_vect      (21)  /*  */

/* AC0 interrupt vectors */
#define AC0_AC_vect_num  22
#define AC0_AC_vect      (22)  /*  */

/* ADC0 interrupt vectors */
#define ADC0_RESRDY_vect_num  23
#define ADC0_RESRDY_vect      (23)  /*  */
#define ADC0_WCOMP_vect_num  24
#define ADC0_WCOMP_vect      (24)  /*  */

/* PORTC interrupt vectors */
#define PORTC_PORT_vect_num  25
#define PORTC_PORT_vect      (25)  /*  */

/* TCB2 interrupt vectors */
#define TCB2_INT_vect_num  26
#define TCB2_INT_vect      (26)  /*  */

/* USART1 interrupt vectors */
#define USART1_RXC_vect_num  27
#define USART1_RXC_vect      (27)  /*  */
#define USART1_DRE_vect_num  28
#define USART1_DRE_vect      (28)  /*  */
#define USART1_TXC_vect_num  29
#define USART1_TXC_vect      (29)  /*  */

/* PORTF interrupt vectors */
#define PORTF_PORT_vect_num  30
#define PORTF_PORT_vect      (30)  /*  */

/* NVMCTRL interrupt vectors */
#define NVMCTRL_EE_vect_num  31
#define NVMCTRL_EE_vect      (31)  /*  */

/* USART2 interrupt vectors */
#define USART2_RXC_vect_num  32
#define USART2_RXC_vect      (32)  /*  */
#define USART2_DRE_vect_num  33
#define USART2_DRE_vect      (33)  /*  */
#define USART2_TXC_vect_num  34
#define USART2_TXC_vect      (34)  /*  */

/* PORTB interrupt vectors */
#define PORTB_PORT_vect_num  35
#define PORTB_PORT_vect      (35)  /*  */

/* PORTE interrupt vectors */
#define PORTE_PORT_vect_num  36
#define PORTE_PORT_vect      (36)  /*  */

/* TCB3 interrupt vectors */
#define TCB3_INT_vect_num  37
#define TCB3_INT_vect      (37)  /*  */

/* USART3 interrupt vectors */
#define USART3_RXC_vect_num  38
#define USART3_RXC_vect      (38)  /*  */
#define USART3_DRE_vect_num  39
#define USART3_DRE_vect      (39)  /*  */
#define USART3_TXC_vect_num  40
#define USART3_TXC_vect      (40)  /*  */

#define _VECTOR_SIZE 4 /* Size of individual vector. */
#define S_SIZE (40 * _VECTOR_SIZE)

 

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

Many thanks! Now, some day, I need to figure out HOW to find things in there.

 

What is the difference between X_vect_num and x_vect? And how do you construct a proper ISR definition? Again, nothing I can find.

 

Big thanks,

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

These are for the xmega32E5 but I guess it's the same for the 4809 by using the correct names of course'

//  4ms interrupts ticks
ISR (TCC4_CCA_vect)
{
	time_scaler--;
	if (time_scaler == 0)
		{
		time_scaler=25;
		// 100ms tasks done here if any
		PORTD_OUTTGL = (1<<PIN5_bp);	
		one_second_timer--;	
		if (one_second_timer == 0)
			{
			one_second_timer=10;
		// 1s tasks done here if any
			PORTD_OUTTGL = (1<<PIN4_bp);
			}
		}		
}

// 10ms ticks, 50Hz output
ISR (TCC5_CCA_vect)
{
	PORTC_OUTTGL = (1<<PIN0_bp);
}

// 500us ticks, 1KHz output
ISR (TCD5_CCA_vect)
{
	PORTC_OUTTGL = (1<<PIN1_bp);
}

 

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Thanks, John -

 

Will try!

 

Assume the X_vect_bm are bit masks. Where are they used?

 

Jim

 

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Tue. Mar 31, 2020 - 01:09 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is the method using AtmelStudio.

New Project-> GCC C Executable Project-> OK

Select ATmega4809
Build project
Expand Dependencies from Solution Explorer and double-click iom4809.h

Open search window with Ctrl + f and enter "_vect"

_vect_num is the vector number
_vect is a vector address

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

Thanks, kabasan -

 

That makes it almost easy!

 

Jim

 

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

 

I must be a luddite. If I want to know the vector names for a device I simply:

 

 

Of course it does help to know where the file is to look at. For that I did use AS7:

 

 

Oh and if an editable/searchable list helps:

#define CRCSCAN_NMI_vect      _VECTOR(1)  /*  */
#define BOD_VLM_vect      _VECTOR(2)  /*  */
#define RTC_CNT_vect      _VECTOR(3)  /*  */
#define RTC_PIT_vect      _VECTOR(4)  /*  */
#define CCL_CCL_vect      _VECTOR(5)  /*  */
#define PORTA_PORT_vect      _VECTOR(6)  /*  */
#define TCA0_LUNF_vect      _VECTOR(7)  /*  */
#define TCA0_OVF_vect      _VECTOR(7)  /*  */
#define TCA0_HUNF_vect      _VECTOR(8)  /*  */
#define TCA0_CMP0_vect      _VECTOR(9)  /*  */
#define TCA0_LCMP0_vect      _VECTOR(9)  /*  */
#define TCA0_LCMP1_vect      _VECTOR(10)  /*  */
#define TCA0_CMP1_vect      _VECTOR(10)  /*  */
#define TCA0_LCMP2_vect      _VECTOR(11)  /*  */
#define TCA0_CMP2_vect      _VECTOR(11)  /*  */
#define TCB0_INT_vect      _VECTOR(12)  /*  */
#define TCB1_INT_vect      _VECTOR(13)  /*  */
#define TWI0_TWIS_vect      _VECTOR(14)  /*  */
#define TWI0_TWIM_vect      _VECTOR(15)  /*  */
#define SPI0_INT_vect      _VECTOR(16)  /*  */
#define USART0_RXC_vect      _VECTOR(17)  /*  */
#define USART0_DRE_vect      _VECTOR(18)  /*  */
#define USART0_TXC_vect      _VECTOR(19)  /*  */
#define PORTD_PORT_vect      _VECTOR(20)  /*  */
#define AC0_AC_vect      _VECTOR(21)  /*  */
#define ADC0_RESRDY_vect      _VECTOR(22)  /*  */
#define ADC0_WCOMP_vect      _VECTOR(23)  /*  */
#define PORTC_PORT_vect      _VECTOR(24)  /*  */
#define TCB2_INT_vect      _VECTOR(25)  /*  */
#define USART1_RXC_vect      _VECTOR(26)  /*  */
#define USART1_DRE_vect      _VECTOR(27)  /*  */
#define USART1_TXC_vect      _VECTOR(28)  /*  */
#define PORTF_PORT_vect      _VECTOR(29)  /*  */
#define NVMCTRL_EE_vect      _VECTOR(30)  /*  */
#define USART2_RXC_vect      _VECTOR(31)  /*  */
#define USART2_DRE_vect      _VECTOR(32)  /*  */
#define USART2_TXC_vect      _VECTOR(33)  /*  */
#define PORTB_PORT_vect      _VECTOR(34)  /*  */
#define PORTE_PORT_vect      _VECTOR(35)  /*  */
#define TCB3_INT_vect      _VECTOR(36)  /*  */
#define USART3_RXC_vect      _VECTOR(37)  /*  */
#define USART3_DRE_vect      _VECTOR(38)  /*  */
#define USART3_TXC_vect      _VECTOR(39)  /*  */

 

EDIT: forgot your comment:

What is the difference between X_vect_num and x_vect? And how do you construct a proper ISR definition? Again, nothing I can find.

Now I'm not entirely sure which C compiler you are talking about but I kind of assumed GCC in which case the only thing of any importance to you the user are the X_vect names and you use them in the form:

#include  <avr/interrupt.h>

ISR(SOME_vect) {
    // handler code
}

which is all explained (surprise, surprise) in the user manual:

 

https://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html

 

Last Edited: Tue. Mar 31, 2020 - 01:49 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cliff -

 

Thanks for the exposition. Honesty, I've consciously stayed away from the device files. Have always been able to rely on LibC documentation. That said, I immediately discounted the material having to do with interrupt.h because I never found "4809" for any single interrupt in that huge list.

 

From that absence,  I had to conclude that there is something about Mega-0 devices that did not conform to the LibC interrupt structuring (or, possibly, it just wasn't up to date and there was still "something" that just didn't fit). I even looked at Microship's documentation instead of my usual go-to at nongnu.org and there was nothing, there, re-enforcing my earlier conclusion. 

 

THAT was the genesis of my initial posting.

 

Cheers

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

clawson wrote:
Now I'm not entirely sure which C compiler you are talking about but I kind of assumed GCC ...

As apparently nearly all the respondents did, as well as the poster.

 

So, Jim can't find vector names FOR A PARTICULAR TOOLCHAIN spelled out in the datasheet.  Upon reflection, is that really a surprise?  Years ago I was told here that Atmel was compiler-agnostic, despite evidence to the contrary.

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

The problem with device packs and -B etc is that it used to be the case that there was a complete, single build of AVR-LibC and during that there was a Doxygen run that built the user manual. So the manual for a given release was a complete documentation and the description of avr/interrupt.h would contain a complete list of all the vector names from all the ioXXX.h but now, after an initial build/release of AVR-LibC new device support is "drip fed" in the form of device pack updates but there's no clever way for these to insert "new bits" into the documentation so even if the AVR-LibC documentation is on your hard drive it might not cover AVR-0/1 added since the C lib was first built. That's a bit of a shame really.

Last Edited: Tue. Mar 31, 2020 - 08:11 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@Lee,

 

Surely you are being a little pedantic.   Codevision had its own interrupt vector names for Mega and Tiny.    Imagecraft likewise.   GCC likewise.

 

This was all fairly painful.   Which is why the names were standardised for Xmega about thirteen years ago.

It looks as if the AVR8X chips have also got standardised vector names.

 

Yes,   Compilers retain their own syntax extensions e.g. for Interrupt Service Routines

 

Somehow,   I would expect new Codevision users would struggle with writing their own ISR()s from scratch.

But CV has a built-in Help system which makes life much easier than GCC.    And comes with a comprehensive set of Example projects.    (which still need a bit of assistance when porting to other targets)

 

If a CV user has a problem,   she can quote the CV example.   If she does not get help from regular Forum members,   Pavel is always there for licencees.

 

David.

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

david.prentice wrote:
Pavel is always there for licencees.

 

Cough! Just be prepared for a VERY blunt response.

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

david.prentice wrote:
Surely you are being a little pedantic.   Codevision had its own interrupt vector names for Mega and Tiny.    Imagecraft likewise.   GCC likewise.

Exactly.  [not the pedantic part]

 

Now, I don't really see your point with that and the rest of your post.  And my response earlier wasn't a CV rant.  It was questioning the expectation of the vector names in the datasheet.

 

You are saying that after standardization, the vector names to be used in any mainstream compiler ARE in the datasheets?  And that the conform to C-family syntax rules?  That indeed would be new to me as I only deal in legacy AVR models.

jgmdesign wrote:
Cough! Just be prepared for a VERY blunt response.

Now I'll pick up on a CV topic.  (When did that happen, anyway?)  Is there something we should all know?  When, over nearly two decades, I uncovered a situation I've always received a timely response.  If a "fix" was warranted it would appear very soon.

 

 

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

Mea Culpa!

 

I did not think to state "gcc on AS7".

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

@Lee,

 

The datasheet does not specify any vector names.    Personally,   I don't mind how the name is spelled.    Just that it is the same spelling for all the major Compilers.

 

Regarding Compiler-dependent extensions.    It would be traumatic to alter the syntax for legacy code or legacy chips.

You just have to suffer the consequences of historic decisions.

 

Compiler vendors also want you to get locked into their products.    Members of your advanced years can remember the PC Compiler wars,   conflicting syntax, ... of the 1980s.

 

David.

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

clawson wrote:

EDIT: forgot your comment:

What is the difference between X_vect_num and x_vect? And how do you construct a proper ISR definition? Again, nothing I can find.

Now I'm not entirely sure which C compiler you are talking about but I kind of assumed GCC in which case the only thing of any importance to you the user are the X_vect names and you use them in the form:

   

X_vect_num are used with the interrupt priority system (dunno if all the xType devices have this).  On the attiny817 you load the vector number into CPUINT.LVL1VEC for it to take priority over other interrupts.

Letting the smoke out since 1978

 

 

 

 

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

david.prentice wrote:
The datasheet does not specify any vector names. 

AAArgh!  I must be totally inept at making a point.  I totally agree with you, except OP's initial

ka7ehk wrote:
I've looked in the device-specific data sheet, I've looked in the Mega-0 data sheet. I've looked in the Microchip AVR LibC documentation. Zilch! Found a vector table but nothing that  looks like proper names!
seems to expect that.

 

Then all of you help, by pointing out where the names can be found.  But all that help ignored

ka7ehk wrote:
Where does one find the proper names for gcc? I really hope they are not buried in the avr/io file morass! I have no clue about navigating that. Already spent more time than any mortal ought to need to spend!
the OP's stated rules for this hunt.

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. Mar 31, 2020 - 10:05 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Its not a complicated process for gcc-

 

https://godbolt.org/z/kDow96

 

They already have 'weak' __vector_N names in place in the vector table (from crtYourMcu.o), and you are simply overriding the name with your own function. The specific mcu header has a define to source a number to a macro in sfr_defs that produces a __vector_N type name. The ISR macro in interrupt.h uses that name to create a function declaration with the signal attribute (to produce isr prologue/epilogue) and the start of a function definition.

 

If you wanted to bypass the header for some/any reason, you just come up with a __vector_N name by looking up the number in the datasheet, create a declaration with the signal attribute, and create your isr function.

 

For some reason, the Tiny datasheets I have open spell out the vector name and is used in the headers so can use the datasheet to figure out the name (just add _vect). The mega4809 datasheet only gives the peripheral name then provides the 'long name' for the specifics, so you have to look it up in the header.

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


Well in traditional Tiny/Mega the AVR-LibC authors always tried to use the names in the "interrupt vector table" part of the datasheet for the vector names so, where possible, it was always a case of just taking the datasheet name and adding _vect. But some of the datasheets have "odd" entries in that table...

 

 

who on earth thought "SPI, STC" or "USART, TXC" were good names? Sadly you cannot use a comma in a C (or I suspect Asm) label name. Equally some are two words with a space ("TIMER1 CAPT" etc). So the LibC authors interpreted this as:

C:\Program Files (x86)\Atmel\Studio\7.0\packs\atmel\ATmega_DFP\1.4.346\include\avr>grep _vect iom16.h | grep _VECTOR
#define INT0_vect                               _VECTOR(1)
#define INT1_vect                               _VECTOR(2)
#define TIMER2_COMP_vect                _VECTOR(3)
#define TIMER2_OVF_vect                 _VECTOR(4)
#define TIMER1_CAPT_vect                _VECTOR(5)
#define TIMER1_COMPA_vect               _VECTOR(6)
#define TIMER1_COMPB_vect               _VECTOR(7)
#define TIMER1_OVF_vect                 _VECTOR(8)
#define TIMER0_OVF_vect                 _VECTOR(9)
#define SPI_STC_vect                    _VECTOR(10)
#define USART_RXC_vect                  _VECTOR(11)
#define USART_UDRE_vect                 _VECTOR(12)
#define USART_TXC_vect                  _VECTOR(13)
#define ADC_vect                                _VECTOR(14)
#define EE_RDY_vect                             _VECTOR(15)
#define ANA_COMP_vect                   _VECTOR(16)
#define TWI_vect                                _VECTOR(17)
#define INT2_vect                               _VECTOR(18)
#define TIMER0_COMP_vect                _VECTOR(19)
#define SPM_RDY_vect                    _VECTOR(20)

so on the whole you replace "punctuation" with the '_' character and then the _vect names come out of that. 

 

Atmel got better at picking sensible names for the vectors in later AVR so:

 

leads to:

C:\Program Files (x86)\Atmel\Studio\7.0\packs\atmel\ATtiny_DFP\1.4.301\include\avr>grep _vect iotn1634.h | grep _VECTOR
#define INT0_vect            _VECTOR(1)
#define PCINT0_vect            _VECTOR(2)
#define PCINT1_vect            _VECTOR(3)
#define PCINT2_vect            _VECTOR(4)
#define WDT_vect            _VECTOR(5)
#define TIMER1_CAPT_vect            _VECTOR(6)
#define TIM1_CAPT_vect            _VECTOR(6)
#define TIMER1_COMPA_vect            _VECTOR(7)
#define TIM1_COMPA_vect            _VECTOR(7)
#define TIMER1_COMPB_vect            _VECTOR(8)
#define TIM1_COMPB_vect            _VECTOR(8)
#define TIMER1_OVF_vect            _VECTOR(9)
#define TIM1_OVF_vect            _VECTOR(9)
#define TIMER0_COMPA_vect            _VECTOR(10)
#define TIM0_COMPA_vect            _VECTOR(10)
#define TIMER0_COMPB_vect            _VECTOR(11)
#define TIM0_COMPB_vect            _VECTOR(11)
#define TIMER0_OVF_vect            _VECTOR(12)
#define TIM0_OVF_vect            _VECTOR(12)
#define ANA_COMP_vect            _VECTOR(13)
#define ADC_vect            _VECTOR(14)
#define ADC_READY_vect            _VECTOR(14)
#define USART0_START_vect            _VECTOR(15)
#define USART0_RXS_vect            _VECTOR(15)
#define USART0_RX_vect            _VECTOR(16)
#define USART0_RXC_vect            _VECTOR(16)
#define USART0_UDRE_vect            _VECTOR(17)
#define USART0_DRE_vect            _VECTOR(17)
#define USART0_TX_vect            _VECTOR(18)
#define USART0_TXC_vect            _VECTOR(18)
#define USART1_START_vect            _VECTOR(19)
#define USART1_RXS_vect            _VECTOR(19)
#define USART1_RX_vect            _VECTOR(20)
#define USART1_RXC_vect            _VECTOR(20)
#define USART1_UDRE_vect            _VECTOR(21)
#define USART1_DRE_vect            _VECTOR(21)
#define USART1_TX_vect            _VECTOR(22)
#define USART1_TXC_vect            _VECTOR(22)
#define USI_START_vect            _VECTOR(23)
#define USI_STR_vect            _VECTOR(23)
#define USI_OVERFLOW_vect            _VECTOR(24)
#define USI_OVF_vect            _VECTOR(24)
#define TWI_SLAVE_vect            _VECTOR(25)
#define TWI_vect            _VECTOR(25)
#define EE_RDY_vect            _VECTOR(26)
#define QTRIP_vect            _VECTOR(27)

so by these later AVRs it really is a 1-to-1 correspondence between the names in the datasheet table and the _vect's for the ISR()s

 

However you do have to wonder why they bothered with some "duplicates" that don't actually match the datasheet. For tiny1634 here many of (N) appear twice with two different names. One that matches the d/s table and then some with more "human readable" names like USI_STR_vect  (datasheet) versus USI_START_vect (human).

 

Can't help thinking life would be simpler if all _vect had ONE name and it was formed from the entry in the IVT listed in the d/s !

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

clawson wrote:

Can't help thinking life would be simpler if all _vect had ONE name and it was formed from the entry in the IVT listed in the d/s !

 

There are historic reasons.   Once you have documentation "out in the world" you are stuck with it.

 

There were many anomolies with the early Mega SFR_NAMES, BIT_NAMES, ... and the style of header files.

 

The early microprocessors varied a lot.   Microcontrollers made an effort to standardise register bits, names, ...

Perhaps the software designers should have communicated better with the hardware team.    And the documentation writers should have been "supervised".

 

Hey-ho.   AVRs are over twenty years old.    You can't change anything now.   The AVR8X chips look as if there was more thought involved.

 

David.

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

theusch wrote:

jgmdesign wrote:

Cough! Just be prepared for a VERY blunt response.

 

Now I'll pick up on a CV topic.  (When did that happen, anyway?)  Is there something we should all know?  When, over nearly two decades, I uncovered a situation I've always received a timely response.  If a "fix" was warranted it would appear very soon.

 

 

It happened when I started using CV for my xmega projects, and when one uses the Wizard AFTER the initial setup.  I saved the .CWZ file and I opened it when I realised I needed to add a peripheral and opened it to add the peripheral.  I hit generate and it indeed generated the .c file, but not the .h file  I wrote Pavel asking why, and I certainly received a timely response, I was told to write my own .h file in between the insults.    There was another part that I also did not understand in spite of reading Pavels manual, which I will say is rather well written, and explained it and the response was again rather nasty, with him saying he has 50,000 users and no one ever asks questions.  I took the time to research BEFORE asking the question, and again I was met with a nasty response.  %0,000 users and I am the only one that has a question?  Ok.....

 

I will say I wonder if his nastiness towards me has anything to do with his revenge on someone, and I privately had an email exchange about it.  Either way, I still use the product and I would recommend it.

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

Pavel has always seemed very polite.    Perhaps you got him on a bad day(s).

 

As far as I know,   you have always had an active licence.    So would get active support.

 

I can understand irritation when a licence has expired.    Or annoyance when a licence has never been bought.

 

Incidentally,   you get a fresh set of H and C files when you create a CV project from the Wizard.

A subsequent re-run of the Wizard means that you have to paste specific re-generated C files.    The H files are probably unchanged.

 

I probably never use the Wizard for Mega and Tiny.    But the Wizard is very useful for AVR8X and Xmega.

It might be a worthwhile option to save the whole set of re-generated C, H files.

Discuss.

If several users suggest a feature,   Pavel often implements it.

 

David.

Last Edited: Wed. Apr 1, 2020 - 03:04 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgmdesign wrote:
with him saying he has 50,000 users and no one ever asks questions. 

I'll bet anything you care to wager (and I'll deliver the stake in person with a firm handshake and hug) if you can in anyway document that your statement is not some exaggeration and bears any reasonable resemblance to a quote. 

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

david.prentice wrote:
Incidentally,   you get a fresh set of H and C files when you create a CV project from the Wizard.

Yet the claim

jgmdesign wrote:
I hit generate and it indeed generated the .c file, but not the .h file 

So do I need to run a test also, to see why ECJ's result is different from similar across the pond?  Is it that one of you generates a project, and the other just code?  Kind of immaterial, I guess, w.r.t. the conversation during the support event.

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: Wed. Apr 1, 2020 - 10:19 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My apologies.   You don't ever see the H files in the CodeWizard window whether a New project or a re-generated project.

 

A New project has "Generate and Save".   In which case you can view the saved H files.

 

Discuss.   (but in a separate CV related thread)

 

@Lee,

Have you used the Tiny AVR8X or the Mega AVR8X chips yet?   I know that you don't use Xmega.

 

David.

 

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

theusch wrote:

jgmdesign wrote:
with him saying he has 50,000 users and no one ever asks questions. 

I'll bet anything you care to wager (and I'll deliver the stake in person with a firm handshake and hug) if you can in anyway document that your statement is not some exaggeration and bears any reasonable resemblance to a quote. 

 

I would take that bet(something from your smoker as currency) if I cared to look through the hard drives from old machines past for the email exchange.  So I am going to recant that above quote since it's not worth the effort.  You win.

 

david.prentice wrote:
My apologies.   You don't ever see the H files in the CodeWizard window whether a New project or a re-generated project.

In a NEW project it will create the .H files, but not in a re-generated project.  It took several heated emails between Pavel and I when he FINALLY replied with this:

The supplied "CLEAR" instructions specified that you must copy/paste PORTIONS of code from the preview window as NEEDED.

PORTIONS of code = timer initialization function DEFINITIONS The timers_init.h header file just contain the DECLARATIONS for the functions generated in timers_init.c files, nothing more.

If you chose to copy mechanically ALL the contents of the preview window, then you can easily create this header file YOURSELF using your OWN BRAIN and a little knowledge of C.

@Lee, I would be more than happy to send you a copy of this one as it was from January this year.

 

So, on a brand new project, provided you enable"GEnerate code for unused peripherals", the Wizard will not generate .c or .h files.  Fair enough, but if you are opening a wizard config file and adding a peripheral then why does the wizard NOT generate the associated .h file?  Which is what I was trying to get an answer to when the above response was given.

 

My work around is to simply make a dummy new project and configure the peripheral I need and then generate it and copy the .h and .c file to my working project and add the lines in the main file accordingly.  It's kludge-ee but it works.

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

jgmdesign wrote:
So I am going to recant that above quote since it's not worth the effort.  You win.

[snark] Kind of what I figured.  The last time I had a number from HPInfoTech it wasn't near the number you claimed.  I suppose there could have been multi-thousand university contracts in the meantime, but I was willing to put some lipstick on a pork butt.  [just did one Monday; no pictures tho]

jgmdesign wrote:
@Lee, I would be more than happy to send you a copy of this one as it was from January this year.

Yet another snark, eh?  We'll call it a draw and meet halfway -- Cleveland?  But remember, given your 50000 number,

Fifty-million Frenchmen can't be wrong

which goes on in the origin article

The number of Frenchmen seems to vary whenever the phrase reappears. From what I've been able to look up, the population of France was only 40 million in 1927, and only a minority of those would have been men, but that's artistic license for you.

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

david.prentice wrote:

@Lee,

Have you used the Tiny AVR8X or the Mega AVR8X chips yet?

No, I retired about the same time that they became commonplace.  The only AVR work I do now is tweaking my smoker controller and remote-control holiday lights.

 

lht

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'll deliver the stake in person with a firm handshake and hug

But NY is the epicenter of CV19 ....(not the one from Pavel) you may not make it back to Wisconsin.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly