bugAVR C Runtime Library - Bugs: bug #31267, misleading header iom128rfa1.h

 
 

bug #31267: misleading header iom128rfa1.h

Submitted by:  Ilya <ibagrak>
Submitted on:  Thu 07 Oct 2010 06:48:52 AM UTC  
 
Category: HeaderSeverity: 3 - Normal
Priority: 9 - ImmediateItem Group: libc code
Status: FixedPercent Complete: 0%
Assigned to: Joerg Wunsch <joerg_wunsch>Open/Closed: Closed
Release: UnknownFixed Release: 1.8.1

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Wed 28 Dec 2011 09:48:52 PM UTC, comment #3:

I opened an Atmel bug report for this, requesting the removal
of these vectors from the respective XML file (which is the
base of the header file).

This still leaves the question how to handle IRQ vector slots
that are not implemented in a particular device. Just not
mention them in the header file? To the best of my knowledge,
this is the first time we run into that situation.

Joerg Wunsch <joerg_wunsch>
Project AdministratorIn charge of this item.
Mon 21 Feb 2011 11:34:21 PM UTC, comment #2:

Joerg,

Don't you (or the group you're in) have some control over this XML file anyway?

Can't we go ahead and make these changes?

Eric Weddington <arcanum>
Project Administrator
Thu 07 Oct 2010 06:54:48 AM UTC, comment #1:

Well, our policy is that the header file matches the device XML file,
so Atmel would have to change the XML file first.

However, this case is particularly difficult. As I understand it, the
vector is physically there, so we cannot just omit it from the table,
even though this vector is fairly pointless as it could never trigger.
I suggest to not use any of the interrupt vectors as the decision base
in your case but the control registers: the control registers for
USARTs that cannot be used have been removed, apparently.

Joerg Wunsch <joerg_wunsch>
Project AdministratorIn charge of this item.
Thu 07 Oct 2010 06:48:52 AM UTC, original submission:

I am referring to the file "iom128rfa1.h"

starting at line 5227

/* USART2, Rx Complete */
#define USART2_RX_vect _VECTOR(51)
#define USART2_RX_vect_num 51

and at line 5240

/* USART3, Rx Complete */
#define USART3_RX_vect _VECTOR(54)
#define USART3_RX_vect_num 54

According to the documentation "doc8266.pdf" page 212 and 213

"3. Not usefull in ATmega128RFA1 due to limited pin count."

Therefore this chip does NOT have uart2 and uart3

When writing code to work on multiple CPUs, many people use #if defined() to determine if a feature is available or not.

I had in my code

#if defined(USART3_RX_vect)
...
#endif

to determine if USART3 is present. Therefore my code tried to use USART3 but it was not present.

Therefore the .h file contradicts the documentation. In this case the documentation is correct and the .h file is misleading

Ilya <ibagrak>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by arcanum (Posted a comment)
  • -unavailable- added by joerg_wunsch (Posted a comment)
  • -unavailable- added by ibagrak (Submitted the item)
  • -unavailable- added by ibagrak
  •  

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 7 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri 03 May 2013 04:12:08 PM UTCjoerg_wunschFixed ReleaseNone=>1.8.1
    Fri 03 May 2013 03:46:30 PM UTCjoerg_wunschStatusIn Progress=>Fixed
      Open/ClosedOpen=>Closed
    Fri 16 Nov 2012 06:57:52 PM UTCarcanumPriority5 - Normal=>9 - Immediate
    Wed 28 Dec 2011 09:48:52 PM UTCjoerg_wunschStatusNone=>In Progress
    Mon 21 Feb 2011 11:34:21 PM UTCarcanumAssigned toNone=>joerg_wunsch
    Thu 07 Oct 2010 06:48:52 AM UTCibagrakCarbon-Copy-=>Added -unavailable-

    Back to the top


    Powered by Savane 3.1-cleanup