Migration of xmega64a3u project AmtelStudio=>Linux

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

Hello there,

 

I am currently migrating a kind of complex xmega64a3u project from AmtelStudio to Linux. I am a professional C++ developer usually working in a Linux environment trying to help a friend with basic rules of professional software development (Revision Control, automated tests, bla bla bla). So I do know C/C++ but I know little about microcontrollers.
 

I managed to install the avr8-gnu-toolchain-3.5.4.1709-linux.any.x86_64.tar.gz and my IDE (Code::Blocks, will do cmake|vim later ;) ) is compiling up to a couple of lines like these:
 

TCD0.CTRLB = TC_TC0_WGMODE_SINGLESLOPE_gc|TC0_<...>;

The compiler complains about

error: 'TC_TC0_WGMODE_SINGLESLOPE_gc' undeclared (first use in this function)

From reading the  Atmel-8465-8-and-16-bit-AVR-Microcontrollers-XMEGA-C_Manual.pdf I do understand every single part of this word. But I don't find any enum|define or anything with the TC_TC0_ prefix in the whole toolchain's includes nor in the project itself (using grep). I see a lot of TC_WGMODE_SINGLESLOPE_gc though. There are a couple of other TC_TC0_ prefixed defines in other errors as well.

Now my Question:

What am I missing? Where do I find *good* documentation about this? 

Thx in advance

Amie

AVR Newbee

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

amie wrote:
What am I missing?
Device descriptor files; these are a fairly recent addition to AVR GCC.

amie wrote:
Where do I find *good* documentation about this?

http://distribute.atmel.no/tools/opensource/Atmel-AVR-GNU-Toolchain/3.5.4/

...

Use Atmel Device Family Packs (DFP) for new devices support. You can download Atmel DFPs from here.

How to use Atmel DFPs with Standalone toolchain?

...

why :

GCC Wiki

avr-gcc

Using avr-gcc

Supporting "unsupported" Devices

https://gcc.gnu.org/wiki/avr-gcc#Supporting_.22unsupported.22_Devices

 

Edit : why

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Wed. Jun 7, 2017 - 08:50 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So I finally have a kind of a clue whats going on here:
My friend sent me the Windows' tool chain version of iox64a3u.h.
when I compare, for instance the  /* Waveform Generation Mode */ part, I end up like this:

 

my, linux, 2017 version:

/* Waveform Generation Mode */                                                                                
typedef enum TC_WGMODE_enum                                                                                   
{                                                                                                             
    TC_WGMODE_NORMAL_gc = (0x00<<0),  /* Normal Mode */                                                       
    TC_WGMODE_FRQ_gc = (0x01<<0),  /* Frequency Generation Mode */                                            
    TC_WGMODE_SINGLESLOPE_gc = (0x03<<0),  /* Single Slope */                                                 
    TC_WGMODE_SS_gc = (0x03<<0),  /* Single Slope */                                                          
    TC_WGMODE_DSTOP_gc = (0x05<<0),  /* Dual Slope, Update on TOP */                                          
    TC_WGMODE_DS_T_gc = (0x05<<0),  /* Dual Slope, Update on TOP */                                           
    TC_WGMODE_DSBOTH_gc = (0x06<<0),  /* Dual Slope, Update on both TOP and BOTTOM */                         
    TC_WGMODE_DS_TB_gc = (0x06<<0),  /* Dual Slope, Update on both TOP and BOTTOM */                          
    TC_WGMODE_DSBOTTOM_gc = (0x07<<0),  /* Dual Slope, Update on BOTTOM */                                    
    TC_WGMODE_DS_B_gc = (0x07<<0),  /* Dual Slope, Update on BOTTOM */                                        
} TC_WGMODE_t;                 

Windows, 2016 Version:
 

/* Waveform Generation Mode */                                                                                
typedef enum TC_TC0_WGMODE_enum                                                                               
{                                                                                                             
    TC_TC0_WGMODE_NORMAL_gc = (0x00<<0),  /* Normal Mode */                                                   
    TC_TC0_WGMODE_FRQ_gc = (0x01<<0),  /* Frequency Generation Mode */                                        
    TC_TC0_WGMODE_SINGLESLOPE_gc = (0x03<<0),  /* Single Slope */                                             
    TC_TC0_WGMODE_SS_gc = (0x03<<0),  /* Single Slope */                                                      
    TC_TC0_WGMODE_DSTOP_gc = (0x05<<0),  /* Dual Slope, Update on TOP */                                      
    TC_TC0_WGMODE_DS_T_gc = (0x05<<0),  /* Dual Slope, Update on TOP */                                       
    TC_TC0_WGMODE_DSBOTH_gc = (0x06<<0),  /* Dual Slope, Update on both TOP and BOTTOM */                     
    TC_TC0_WGMODE_DS_TB_gc = (0x06<<0),  /* Dual Slope, Update on both TOP and BOTTOM */                      
    TC_TC0_WGMODE_DSBOTTOM_gc = (0x07<<0),  /* Dual Slope, Update on BOTTOM */                                
    TC_TC0_WGMODE_DS_B_gc = (0x07<<0),  /* Dual Slope, Update on BOTTOM */                                    
} TC_TC0_WGMODE_t;           

so they are simply incompatible.
Imho, the Linux Version makes much more sense, as this is configuration of a timer, that might be applied to any timer, not only TC0.

Anyone has a clue about the back grounds here?

Cheers
Amie

AVR Newbee

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

But the only difference, surely, is the presence of TC0_ in the name prefix - so a simple text search & replace would fix that.

 

The "background" is probably simply that they are of different generations, and Atmel have just changed their naming conventions at some point

 

EDIT: so what happens if you compare "Linux" and "Windows" versions with matching dates ... ?

 

might be applied to any timer, not only TC0

It isn't necessarily the case that all timers have the same structure ...

 

Last Edited: Thu. Jul 13, 2017 - 10:05 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You have to be aware that there are two developments of avr-gcc in the world. There is the generic GNU FSF one (which is almost certainly what the Linux repo builders will use) and there is Atmel's "private" one. The Atmel one is "ahead" of the generic one in the sense that it's always something like 20..50 new AVRs ahead but there are other subtle differences. Slowly but surely Atmel push back their changes to the GNU master but this takes time.

 

Looking at the "generic" open sources the header file is:

 

http://svn.savannah.gnu.org/view...

 

Looking for SINGLESLOPE leads to line 2164

 

So that version does not include "TC0" in the names (which makes sense - suppose there were 13 TC's then would you really have the same stuff repeated 13 times as TC0..., TC1... TC2... etc?)

 

Interestingly the last change to the file was made 2 years ago and the person who made the change was actually one of the Atmel engineers.

 

If you want the latest  "Atmel version" on Linux then go to :

 

http://www.atmel.com/tools/atmel...

 

I would be very surprised if the names contain "TC0". Having said that Atmel recently changed their mechanism for auto-generating these headers from device XML files and I could well believe that a bug in that process may have inadvertently added "TCO_" to the names.

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

amie wrote:

Windows, 2016 Version:

/* Waveform Generation Mode */                                                                                
typedef enum TC_TC0_WGMODE_enum                                                                               
{                                                                                                             
    TC_TC0_WGMODE_NORMAL_gc = (0x00<<0),  /* Normal Mode */                                                   
    TC_TC0_WGMODE_FRQ_gc = (0x01<<0),  /* Frequency Generation Mode */                                        
    TC_TC0_WGMODE_SINGLESLOPE_gc = (0x03<<0),  /* Single Slope */                                             
    TC_TC0_WGMODE_SS_gc = (0x03<<0),  /* Single Slope */                                                      
    TC_TC0_WGMODE_DSTOP_gc = (0x05<<0),  /* Dual Slope, Update on TOP */                                      
    TC_TC0_WGMODE_DS_T_gc = (0x05<<0),  /* Dual Slope, Update on TOP */                                       
    TC_TC0_WGMODE_DSBOTH_gc = (0x06<<0),  /* Dual Slope, Update on both TOP and BOTTOM */                     
    TC_TC0_WGMODE_DS_TB_gc = (0x06<<0),  /* Dual Slope, Update on both TOP and BOTTOM */                      
    TC_TC0_WGMODE_DSBOTTOM_gc = (0x07<<0),  /* Dual Slope, Update on BOTTOM */                                
    TC_TC0_WGMODE_DS_B_gc = (0x07<<0),  /* Dual Slope, Update on BOTTOM */                                    
} TC_TC0_WGMODE_t;           

 

That is weird. My Windows version (Atmel Studio 7.0.1188) from 2016 has this:

/* Waveform Generation Mode */
typedef enum TC_WGMODE_enum
{
    TC_WGMODE_NORMAL_gc = (0x00<<0),  /* Normal Mode */
    TC_WGMODE_FRQ_gc = (0x01<<0),  /* Frequency Generation Mode */
    TC_WGMODE_SINGLESLOPE_gc = (0x03<<0),  /* Single Slope */
    TC_WGMODE_SS_gc = (0x03<<0),  /* Single Slope */
    TC_WGMODE_DSTOP_gc = (0x05<<0),  /* Dual Slope, Update on TOP */
    TC_WGMODE_DS_T_gc = (0x05<<0),  /* Dual Slope, Update on TOP */
    TC_WGMODE_DSBOTH_gc = (0x06<<0),  /* Dual Slope, Update on both TOP and BOTTOM */
    TC_WGMODE_DS_TB_gc = (0x06<<0),  /* Dual Slope, Update on both TOP and BOTTOM */
    TC_WGMODE_DSBOTTOM_gc = (0x07<<0),  /* Dual Slope, Update on BOTTOM */
    TC_WGMODE_DS_B_gc = (0x07<<0),  /* Dual Slope, Update on BOTTOM */
} TC_WGMODE_t;

And that matches your Linux version just fine.

I wonder how old your friends version really is.

 

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

I imagine there was more than 1 release in 2016 ... ?

 

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

awneil wrote:

I imagine there was more than 1 release in 2016 ... ?

Exactly. It would be nice to know exactly where the file with TC0_ came from, other than just "Windows, 2016 Version".

 

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

I have the same issue on a fresh Atmel Studio install on Windows. The problem surfaced when I was trying to migrate an existing project from an XMEGA16D4 to an XMEGA128D4; the ASF-generated header file tc.h is the same for both devices, but their iox*.h-files differ. The one for the XMEGA128D4 has the "TC0_" string added, the one for the XMEGA16D4 doesn't.

 

As mentioned by others, this could be fixed by a simple search and replace. But I hate changing auto-generated files, because then you always have to make sure it doesn't get re-generated and your changes are overwritten.

 

So what would be the proper, upgrade-safe way to fix this?

 

Greetings,

Sean

 

P.S.: I just noticed that there is an update for ASF available. I'll try switching to that, maybe the issue is fixed there.

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

The io*.h are in a "device pack". Atmel have recently modified the compiler to use such "device packs" so it's easy to add new devices without a whole new compiler. The same technology would also allow them to fix errors in device headers without a whole new rebuild of the compiler too. So search "Atmel device packs" and see if there's an update for your device that would fix the issue here.

 

EDIT: if I read this right you may be in luck....

Last Edited: Tue. Aug 29, 2017 - 02:49 PM