Arbitrary naming of interrupt vectors for the tinyAVR series 1 (e.g. ATtiny1614) and maybe others.
It appears impossible from the data sheet alone to predict how to name at least some of the interrupt vectors in such a way that these will be accepted by the compiler. I'm using, incidentally, Arduino 1.8.15 and the Dr Azzy megaTinyCore. I've annotated a section of the data sheet for the RTC module with the vector names in red to highlight this.
To get the names, you have to find the file where these mnemonics are defined for a specific board. In this case, the file is called iotn1614.h, then hunt through for likely looking names.
Here using Windows findstr to search
C:\Users\6V6GT>findstr /irc:"rtc.*vect" C:\Users\6V6GT\Documents\ArduinoData\packages\DxCore\tools\avr-gcc\7.3.0-atmel3.6.1-azduino3\avr\include\avr\iotn1614.h
/* RTC interrupt vectors */
#define RTC_CNT_vect_num 6
#define RTC_CNT_vect _VECTOR(6) /* */
#define RTC_PIT_vect_num 7
#define RTC_PIT_vect _VECTOR(7) /* */
This gives the vector names which can then be used in the code:
// do something
// do something
Yes. (iotn1614.h is "per specific CHIP", rather than "board.)
Both the datasheet and the iotn1614.h file are provided by Microchip, and used "as is" by the Arduino stuff. You'd think that they would be more in-sync, but ... apparently not.
Historically, you pretty much need to look at the ioXXX.h files to figure out the vector names.
I guess it's somewhat fortunate that they have a pretty regular location and naming scheme. (XXX/include/avr/io[m|tn|x]NNNN.h, where XXX is the compiler directory, m is for mega, tn is for tiny, x is for xmega, and NNNN is the number part of the chip.
(alas, for Arduino, the "compiler directory" is rather buried in strange places.)
I suppose I was hoping this would have got better with the newer, more systematic naming of values to configure register such as EVSYS_ASYNCCH0_PORTA_PIN3_gc etc. That is, there would be a closer relationship between the names of objects in the data sheet and the names of the same objects at the C++ level.
With the original AVR series which included MCUs like the ATmega328p, the Arduino programmer is not so exposed this problem because, thanks to Nick Gammon et. al. , there are easily searchable, ready made code samples for every possible application, to paste into a sketch. Now with the newer tinyAVR series 1 and the megaAVR series 0 etc., there is not such a huge body of work to draw on so the data sheet becomes more important. This can only get worse because of the increasing variety of MCUs tagged on to the Arduino ecosystem and, correspondingly, the hope of finding ready made code, for anything other than simple applications, diminishes accordingly.
This ain't news. It's a step forward and a step backwards. On the one hand, everything now is laid out in a sane and logical way with way less blindfolds and dartboards in the engineering department. On the other hand, you now need 3 windows open for all programming (datasheet, io header and the file you're editing), not just some of it, because you'll never remember the formulation for the registers and bit fields of a particular peripheral now that 4 words long instead of 4 letters long.
Latest released version of megaTinyCore has all the register names and vector names in keywords.txt though so you at least get syntax highlighting. (DxCore too) - cdredit for that goes to MCUdude - he did it for both my modern cores, and I just went through stripping out a few invalid ones that slipped through, and removed some that were just dumb as hell, like when they give a name for every single bit in an 8-bit field. Nobody cares about the bitmask of the 5th data bit in the USART RXDATA
And the vectors are like they always were, ie, you need the datasheet to figure out what they're named. I guess I should probably add the list of vector names to my core's documentation like I did on ATTinyCore because of the unpredictable naming. I mean, at least here the names are consistent among all modern AVRs.
. . . plus of course the matching iotnXXXXX.h file ( could be +/- 5000 lines) plus some initiative on the part of the programmer to match these up (as you have already pointed out). Of course, it is so that this has not changed with the newer 8 bit architecture variants (although IMHO it would have been a great opportunity to clean that up). The difference is now that individual programmers have to dirty their hands thumbing through all this stuff whereas, with more mature parts, some pioneer would have already been there first and documented all their discoveries, so this would not have been an issue. But anyway, the syntax highlighting will be a great help in alerting the programmer to incorrect names before the compiler does.
Just for some context, this all started with some low power experiments I was doing with the ATtiny1614 chip. You've already published an example with the PIT (programmable interrupt timer) and I wanted to push the RTC into "SLEEP_MODE_STANDBY" which is a bit more flexible. But then I needed to know what the compare/match interrupt vector was called in C++. In the meantime, that has all been solved so I can progress with the project.
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.