2023-09-09 03:16 AM
I am porting ILI9341 code from Keil to Cube MX.
The original code contains:
void LCD_WR_REG(vu16 regval)
{
regval=regval; //ʹÓÃ-O2ÓÅ»¯µÄʱºò,±ØÐë²åÈëµÄÑÓʱ
LCD->LCD_REG=regval;//дÈëҪдµÄ¼Ä´æÆ÷ÐòºÅ
}
vu16 seems to be __IO uint16_t i.e. volatile uint16_t
my question: regval=regval; seems obsolete code, but as the driver code seems to be written by somebody that knows what he or she is doing, I wonder what the reason behind this statement would be?
Solved! Go to Solution.
2023-09-12 09:10 AM - edited 2023-09-12 09:11 AM
Accesses (reads and writes) to volatile variables cannot be optimized out. They must be performed on every read and write access--that is the effect of the "volatile" qualifier.
But yes, without the "volatile" qualifier they could be optimized out.
2023-09-12 06:58 AM
It adds a small delay but is otherwise useless. The variable is stored on the stack. Reading/writing shouldn't have an effect outside of the delay due to the additional read/write.
2023-09-12 08:53 AM
Thank you for the answer, it is in line with my expectations.
Can I assume that an optimizing compiler would remove this statement unless the variable is declared as volatile blocking the previously mentioned optimisation?
2023-09-12 09:10 AM - edited 2023-09-12 09:11 AM
Accesses (reads and writes) to volatile variables cannot be optimized out. They must be performed on every read and write access--that is the effect of the "volatile" qualifier.
But yes, without the "volatile" qualifier they could be optimized out.