Mittwoch, 8. August 2012

[Atmel Studio] [TBLAVR] Strange AVR-Studio 6.0 behaviour

I just experienced heavy troubles when using TBL-Library for AVR in Atmel Studio 6.0

I had a quite simple project set up which was last compiled in Atmel Studio 6.0 beta and includes tbl-Library (-ltbl).

As there came up another bug after a minor -completely unrelated - update with an older Toolchain (WINAVR2007525) from anouther Compnay using the library, I started debugging the library.

Previously compileable projects weren't any more. They showed some very strange error messages, such as

 'DevComSlave_t' has no member named 'SendFrame'  

Editor-Resolvment worked fine, so I took a look into DevComSlave.h (via rightclick on #include<tbl/DevComSlave.h> / Go to implementation and i saw the following:

 // ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  
      // ~~~~~~~~~~~~~~~~~~~~~~~~~~~ DevComSlave-Object ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  
      // ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~            
      typedef struct devComSlaveStruct  
           unsigned char                    Address;                    // Slave Address  
           volatile unsigned char          MCAddress;                    // Multicast Address  
           unsigned short                    ID;                              // Device-ID, configurable by User, could be used to identify device types etc.  
           volatile unsigned char*          Data;                         // Pointer to valid Data            
           volatile unsigned char          DataUpperBound;               // Length-1 (highest index) of acceptable Data Packages. Set 0 if Data of any length up to 256 Bytes should be accepted  
           volatile unsigned char          NewReceived;               // 0 ... no Data available, != 0: New Received (see "New Received Bitmapping" below)  
           // RW-Output (if enabled)  
           volatile uint8_t*               RWPort;                         // Port, where RW-Wire is connected (e.g. for Buscoupler,...)  
           uint8_t                              RW_bp;                         // Bit Position, where RW-Wire is connected (Pn0...Pn7), e.g. PC3  
           unsigned char                    RWPolarity;                    // 0... when writing, RW-Wire is logic 0, 1 when reading    
                                                                            // 1... when writing, RW-Wire is logic 1, 0 when reading  
           DevComSlaveCommandHandler_t CommandHandler;                 
           // A callback-function, that handles all Commands that are NOT handled internally. Feedback Execution State (either DCS_CMDHANDLER_SUCCESS or DCS_CMDHANDLER_ERROR).  
           // parameters:  
           //          pCmd               Pointer to Command (pCmd[0]) and its parameters (pCmd[1]...pCmd[pUpperBound])  
           //          pLastCtrlByte     Controlbyte of the Frame the command was received in  
           //          pUpperBound          UpperBound of pCmd  
           //          pAllowsResponse     Indicates whether the command allows responding (Cmd received via Unicast) or not (Cmd received via Broad-/Multicast)  
           // return:  
           //          DCS_CMDHANDLER_SUCCESS          if Execution of Command was successful  
           //          DCS_CMDHANDLER_ERROR          if Execution of Command was unsuccessful or command is unknown  
           DevComSlaveFrameTransmitter_t SendFrame;  

Well, that is rather strange. For some reason I thought, why not try to open AVR-Studio 6.0 as Administrator and I did so.

Guess what? Compiled smoothly.

To be honest, I have not the slightest idea, why it didn't compile otherwise and even more important, why avr-gcc showed that strange - completely unrelated - error messages.

Any suggestions?

Keine Kommentare:

Kommentar veröffentlichen