Atmel Studio for SAMD21G18, how to supress warning.

Go To Last Post
7 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
volatile uINT8 RXBuf[1];
void usart_rx_callback(struct usart_module *const module)
{
	#pragma warning(disable:3380)
	usart_read_buffer_job(&usart_module_edbg, RXBuf, 1);
	//usart_read_buffer_wait(&usart_module_edbg, RXBuf, 1);
	#pragma warning(enable:3380) 

When I tried to suppress the warning in Atmel Studio 7, I get this (snipped unneeded statement for clarity) 

 

Severity    Code    Description    Project    File    Line
Warning        ignoring #pragma warning  [-Wunknown-pragmas]    
Warning        passing argument 2 of 'usart_read_buffer_job' discards 'volatile' qualifier from pointer target type [-Wdiscarded-qualifiers]   
Warning        [N] 3380 : passing 'volatile uINT8 [1]' to parameter of type 'uint8_t *' (aka 'unsigned char *') discards qualifiers    
Warning        ignoring #pragma warning  [-Wunknown-pragmas]    
 

What is the right method to suppress the warning?

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

Have your tried casting away the problem?  Since the call is inside a callback from an interrupt, dropping the volatile qualifier via the function call is not a problem.  Different story if done from the application level.

 

usart_read_buffer_job(&usart_module_edbg, (uint8_t *)RXBuf, 1);

 

 

Last Edited: Fri. Dec 28, 2018 - 04:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is not an answer I'm seeking.

I seeking to suppress the warning in the context of how for this specific case. So far the answer is what but no clue how.

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

Out of this context......

I wondered why volatile is not used in ASF library, especially callback function or ISR function required it as part of golden rules.

When I created the local uINT8 inside the ISR or callback function, it did not works and unreliable to use.

When I placed uINT8 outside the ISR/callback function with (global) it worked fine. I inserted volatile since it golden rule when dealing with ISR/callback.

 

Again out of context.....

The 2nd issue that after powering up the board and the device, the 1st char that goes in is alway read 0 rather than ASCII. I could not find it the problem. I use SERCOM USART in ASF 3 (most recent). I check output from  

usart_read_buffer_job(&usart_module_edbg, (uint8_t *)RXBuf, 1);

and found no error. I flushed the RX buffer by reading and it did not solve this problem. I could not figure out how to flush this 1st char before following ASCII command via UART via ASF framework. 

 

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

riscy00 wrote:
What is the right method to suppress the warning?

The only right way to suppress a warning is to find out what caused it and to fix it - warnings can also be important. In this case the program will interpret the byte value as a pointer, which will point to somewhere you didn't expect. 

Try the declaration volatile char RXbuf[1]; and cast the second argument as (char *)

A simple adaptation of your program would be:

 

#include "sam.h"
#include <stdio.h>

/* Copy buflen bytes from RXbuf to RXout */
void usart_read_buffer_job(char *RXout, char *RXbuf, int buflen)
{
  for (int i = 0; i < buflen; i++)
    *RXout++ = *RXbuf++;
} // usart_read_buffer_job()

int main(void)
{ volatile char RXbuf[1];
  char RXout[10];

  usart_read_buffer_job(RXout, (char *) RXbuf, 1);
  return 0;
}

Jerry, an ASF non-believer

Last Edited: Fri. Dec 28, 2018 - 09:26 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think it's useless/wrong to declare RXBuf volatile. It's just a memory buffer, right ?

Simplified: volatile means that the contents of a variable might change without notice of the compiler.

The only truly valid use case of volatile is properly declaring hardware/peripheral addresses/pointers volatile, because the contents of the pointed-to variable is changed by external hardware and the compiler must use a full load instruction from that address to get its actual contents. Same applies for write to hardware registers.

See e.g. the CMSIS headers where all the peripheral pointers are declared.