LPCXpresso IDEのトピックUnused variables in LPCOpen library

Unused variables in LPCOpen library

hmyoong — Tue, 21 Feb 2017 00:00:43 GMT

lpc_chip_43xx/src/spi_43xx.c

/* Clean all data in RX FIFO of SPI */
void Chip_SPI_Int_FlushData(LPC_SPI_T *pSPI)
{
volatile uint32_t tmp; // <----- Not used
Chip_SPI_GetStatus(pSPI);
tmp = Chip_SPI_ReceiveFrame(pSPI);
Chip_SPI_Int_ClearStatus(pSPI, SPI_INT_SPIF);
}

lpc_chip_43xx/src/uart_18xx_43xx.c

/* Initializes the pUART peripheral */
void Chip_UART_Init(LPC_USART_T *pUART)
{
volatile uint32_t tmp; // <----- Not used
/* Enable UART clocking. UART base clock(s) must already be enabled */
Chip_Clock_EnableOpts(UART_PClock[Chip_UART_GetIndex(pUART)], true, true, 1);
/* Enable FIFOs by default, reset them */
Chip_UART_SetupFIFOS(pUART, (UART_FCR_FIFO_EN | UART_FCR_RX_RS | UART_FCR_TX_RS));
//...
}

Re: Unused variables in LPCOpen library

adamrakam — Wed, 22 Feb 2017 16:49:26 GMT

/* Clean all data in RX FIFO of SPI */
void Chip_SPI_Int_FlushData(LPC_SPI_T *pSPI)
{
volatile uint32_t tmp;
Chip_SPI_GetStatus(pSPI);
tmp = Chip_SPI_ReceiveFrame(pSPI); // <----- used here
Chip_SPI_Int_ClearStatus(pSPI, SPI_INT_SPIF);
}

I would expect it has sth to do with a compiler/an optimization but I might be completely wrong.

Re: Unused variables in LPCOpen library

hmyoong — Thu, 23 Feb 2017 12:50:27 GMT

I did not look down of the lines. You are right, the default optimization removes it. Need to dissambly the code to see the differences.

Re: Unused variables in LPCOpen library

adamrakam — Thu, 23 Feb 2017 15:32:22 GMT

You are right, the default optimization removes it.

Removes what ?

This is how "Chip_SPI_ReceiveFrame()" is defined :

STATIC INLINE uint16_t Chip_SPI_ReceiveFrame(LPC_SPI_T *pSPI)
{
return SPI_DR_DATA(pSPI->DR);
}

I suppose :

The volatile keyword is used to force a compiler to call the function "Chip_SPI_ReceiveFrame()". If the variable tmp was defined without volatile keyword i.e. just "uint32_t tmp", calling of the "Chip_SPI_ReceiveFrame()" would not be guaranteed. In this case a compiler might think: "hm, return value from "Chip_SPI_ReceiveFrame()" is stored in the non-volatile "tmp" variable on the stack and "tmp" is not used till the end of the "Chip_SPI_Int_FlushData()" so i will not call(inline) it and save time/memory."

But the volatile keyword does not give a compiler any chance to be ambiguous about calling "Chip_SPI_ReceiveFrame()" - keyword volatile guarantees that calling "Chip_SPI_ReceiveFrame()" will not be optimized away.