volatile

volatile 告訴編譯器，變量的值可能會在編譯器不知道的情況下發生變化。因此，編譯器不能僅僅因為C程序似乎沒有更改值就不能假定值沒有更改。

另一方面，這意味著可能需要在編譯器不知道的其他地方讀取（讀取）變量的值，因此必須確保對變量的每個賦值實際上都是作為寫操作執行的。 / p>

用例

volatile

• 將硬件寄存器（或內存映射的I / O）表示為變量-即使永遠不會讀取寄存器，編譯器也不能只是跳過寫操作，認為“愚蠢的程序員。試圖將值存儲在變量中，他/她將永遠不會回讀。他/她甚至不會注意到我們是否忽略了文字。”相反，即使程序從不向變量寫入值，硬件也可能會更改其值。
• 在執行上下文之間共享變量（例如ISR /主程序）（請參閱@kkramo的答案）

volatile

在將變量聲明為 volatile 時，編譯器必須確保在程序代碼中對其進行的每個賦值均反映在實際的寫操作中，並且每次在程序代碼中進行的讀取均從（映射） ）的內存。

對於非易失性變量，編譯器假定它知道是否/何時改變了變量的值，並可以以不同的方式優化代碼。

其中之一是，編譯器可以通過將值保留在CPU寄存器中來減少對內存的讀取/寫入次數。

示例：

  void uint8_t計算（uint8_t輸入）{
  uint8_t結果=輸入+ 2;
  結果=結果* 2;
  如果（結果> 100）{
    結果-= 100;
  }
  返回結果；
}
 

在這裡，編譯器可能甚至不會為 result 變量分配RAM，並且永遠不會將中間值存儲在任何位置，而是存儲在CPU寄存器中。

如果 result 是易失性的，則C代碼中每次出現 result 都將要求編譯器執行對RAM（或I / O端口）的訪問，從而導致降低性能。

第二，編譯器可能會針對性能和/或代碼大小對非易失性變量進行重新排序。簡單的例子：

  int a = 99;
int b = 1;
整數c = 99;
 

可以重新排序為

  int a = 99;
整數c = 99;
int b = 1;
 

這可以節省彙編程序指令，因為值 99 不必兩次加載。

如果 a ， b 和 c 易失，則編譯器將必鬚髮出指令，以正確的順序分配值在程序中給出。

另一個經典示例如下：

  volatile uint8_t信號；

void waitForSignal（）{
  而（信號== 0）{
    // 沒做什麼。
  }
}
 

如果在這種情況下 signal 不是 volatile ，則編譯器會“認為” while（signal == 0）可能是一個無限循環（因為 signal 永遠不會在循環內被代碼更改），並且可能會生成等價於

  void waitForSignal（）{
  如果（信號！= 0）{
    返回;
  }其他{
    while（true）{// <--無止境的循環！
      // 沒做什麼。
    }
  }
}
 

考慮處理 volatile 值

如上所述，當 volatile 變量被訪問的次數比實際需要的次數多時，可能會導致性能下降。為緩解此問題，您可以通過分配給非易失性變量（如

  volatile uint32_t sysTickCount;

void doSysTick（）{
uint32_t ticks = sysTickCount; //對sysTickCount的單次讀取訪問

  刻度=刻度+ 1;

  setLEDState（打勾< 500000L）;

  if（tick > = 1000000L）{
    刻度= 0;
  }
  sysTickCount =滴答聲; //對易失sysTickCount的單個寫訪問
}
 

這可能在ISR中特別有用，在ISR中，您希望盡可能快地在您知道不需要使用相同的硬件或內存時不會多次訪問同一硬件或內存，因為在您運行ISR正在運行。當ISR是變量值的“生產者”時，例如在上例中的 sysTickCount 中，這是很常見的。在AVR上，讓函數 doSysTick（）訪問內存中相同的四個字節（四個指令=每次訪問 sysTickCount 的8個CPU週期）會特別痛苦。六次而不是兩次，因為程序員確實知道在他/她的 doSysTick（）運行時，其他代碼不會更改該值。

使用此技巧，您基本上可以對非易失性變量執行與編譯器相同的操作，即僅在必須時才從內存中讀取它們，將值保留在寄存器中一段時間，然後僅在發生時才寫回內存它必須但是這一次，您比（如果）讀/寫必須的時候要了解編譯器，因此您可以使編譯器從此優化任務中解脫出來，自己動手。

volatile

非原子訪問

volatile 是否not提供對多字變量的原子訪問。對於這些情況，除了使用 volatile 之外，您還需要通過 其他方式提供互斥。在AVR上，您可以使用 <util / atomic.h> 或簡單的 cli（）;中的 ATOMIC_BLOCK 。 ... sei（）; 調用。各個宏也充當內存屏障，這對於訪問順序很重要：

執行順序

volatile 僅對其他volatile變量施加嚴格的執行順序。這意味著，例如

  volatile int i;
volatile int j;
詮釋

...

i = 1；
a = 99;
j = 2;
 

首先 將1分配給 i ，然後然後將2分配給 j 。但是，不能保證在它們之間分配 a ；編譯器可以在代碼段之前或之後進行分配，基本上可以在任何時候進行，直到 a 的第一次（可見）讀取。

如果不是為了上述宏的存儲障礙，則允許編譯器進行翻譯

  uint32_t x;

cli（）;
x = volatileVar;
sei（）;
 

到

  x = volatileVar;
cli（）;
sei（）;
 

或

  cli（）;
sei（）;
x = volatileVar;
 

（為了完整起見，我必須說，像sei / cli宏所隱含的那樣，內存障礙實際上可以消除對 volatile 的使用，如果 all 這些障礙被括在括號中。）

volatile關鍵字告訴編譯器對變量的訪問具有明顯的效果。這意味著每次您的源代碼使用變量時，編譯器必須創建對變量的訪問。是讀或寫訪問權限。

這樣做的效果是，代碼也會觀察到正常代碼流之外的變量的任何更改。例如。如果中斷處理程序更改了該值。或者，如果變量實際上是一些硬件寄存器，它會自行更改。

這個巨大的好處也是它的缺點。每次對變量的訪問都會遍歷該變量，並且該值永遠不會保存在寄存器中，以便在任何時間段內都能更快地進行訪問。這意味著一個可變變量將很慢。幅度較慢。因此，僅在實際需要的地方使用volatile。

就您而言，就您顯示的代碼而言，僅當您通過 adcValue = readADC（）; 自己更新全局變量時，才會更改全局變量。編譯器知道何時會發生這種情況，並且永遠不會在可能調用 readFromADC（）函數的東西上將adcValue的值保存在寄存器中。或任何它不知道的功能。或會操縱可能指向 adcValue 等的指針的任何內容。確實不需要volatile，因為變量永遠不會以不可預測的方式改變。

在兩種情況下，必須在嵌入式系統中使用 volatile 。

• 從硬件寄存器讀取時。

  這意味著內存映射寄存器本身是MCU內部硬件外圍設備的一部分。它可能會具有一些神秘的名稱，例如“ ADC0DR”。必須使用工具供應商或您自己提供的某些寄存器映射，使用C代碼定義此寄存器。要自己做，您可以做（假設16位寄存器）：

    #define ADC0DR（*（易失性uint16_t *）0x1234）
   

  其中0x1234是MCU映射寄存器的地址。由於 volatile 已經是上述宏的一部分，因此對其的任何訪問都將是volatile限定的。所以這段代碼很好：

    uint16_t adc_data;
  adc_data = ADC0DR;
   

• 使用ISR的結果在ISR和相關代碼之間共享變量時。

  如果您有這樣的事情：

    uint16_t adc_data = 0;
  
  無效的adc_stuff（無效）
  {
    if（adc_data > 0）
    {
      do_stuff（adc_data）;
    }
  }
  
  中斷void ADC0_interrupt（void）
  {
    adc_data = ADC0DR;
  }
   

  然後，編譯器可能會認為：“ adc_data始終為0，因為它不會在任何地方更新。並且永遠不會調用ADC0_interrupt（）函數，因此無法更改該變量”。編譯器通常不會意識到中斷是由硬件而不是軟件調用的。因此，編譯器將刪除代碼 if（adc_data > 0）{do_stuff（adc_data）; } ，因為它認為它永遠不可能是真實的，從而導致了一個非常奇怪且難以調試的錯誤。

  通過聲明 adc_data volatile ，不允許編譯器做出任何此類假設，也不允許優化對變量的訪問。

重要說明：

• ISR必須始終在硬件驅動程序中聲明。在這種情況下，ADC ISR應該位於ADC驅動器內部。除了驅動程序外，其他任何操作都不應與ISR進行通信-其他所有操作都是意大利麵條式編程。

• 編寫C時，必須保護ISR與後台程序 之間的所有通信免受競爭條件的影響。 總是，每次都沒有例外。 MCU數據總線的大小無關緊要，因為即使您用C語言執行一個8位拷貝，該語言也不能保證操作的原子性。除非您使用C11功能 _Atomic 。如果此功能不可用，則必須使用某種信號量或在讀取等過程中禁用中斷。內聯彙編程序是另一種選擇。 volatile 不保證原子性。

  這會發生什麼：
  -將值從堆棧加載到寄存器中
  -發生中斷
  -使用寄存器中的值

  然後，“使用值”部分本身是否為單條指令也沒關係。可悲的是，所有嵌入式系統程序員中有很大一部分人對此一無所知，這可能使其成為有史以來最常見的嵌入式系統錯誤。總是斷斷續續，難以挑釁，很難找到。

正確編寫ADC驅動程序的示例如下所示（假設C11 _Atomic 不可用）：

adc.h

  // adc.h
#ifndef ADC_H
＃定義ADC_H

/ *此處的其他初始化例程* /

uint16_t adc_get_val（void）;

＃萬一
 

adc.c

  // adc.c
#include“ adc.h”

＃定義ADC0DR（*（易失性uint16_t *）0x1234）

靜態揮發性布爾信號量= false;
靜態易失性uint16_t adc_val = 0;

uint16_t adc_get_val（無效）
{
  uint16_t結果;
  信號量= true;
    結果= adc_val;
  信號量= false;
  返回結果；
}

中斷void ADC0_interrupt（void）
{
  if（！信號量）
  {
    adc_val = ADC0DR;
  }
}
 

• 此代碼假定中斷本身無法被中斷。在這樣的系統上，一個簡單的布爾值可以充當信號量，並且不必是原子的，因為如果在設置布爾值之前發生中斷，則不會造成任何危害。上述簡化方法的缺點是，在發生競爭情況時，它將使用先前的值代替ADC讀取。也可以避免這種情況，但是隨後代碼變得更加複雜。

• 此處 volatile 可防止優化錯誤。它與硬件寄存器中的數據無關，只是與ISR共享數據。

• static 通過將變量設置為驅動程序本地變量來防止意大利麵條編程和名稱空間污染。（這在單核，單線程應用程序中很好，但在多線程應用程序中則沒有。）

在嵌入式C應用程序中volatile關鍵字的主要用途是標記在中斷處理程序中寫入的全局變量。在這種情況下，它當然不是可選的。

沒有它，編譯器將無法證明在初始化之後就已經寫入了該值，因為它無法證明曾經調用過中斷處理程序。因此，它認為可以優化不存在的變量。

在問題中提出的代碼段中，尚無使用volatile的理由。 adcValue 的值來自ADC無關緊要。並且 adcValue 處於全局狀態應該使您懷疑 adcValue 是否應該具有可變性，但這不是其本身的原因。

具有全局性是一個線索，因為它打開了從多個程序上下文訪問 adcValue 的可能性。程序上下文包括中斷處理程序和RTOS任務。如果全局變量被一個上下文更改，則其他程序上下文無法假定它們知道先前訪問的值。每個上下文每次使用變量值時都必須重新讀取該變量值，因為該值可能已在其他程序上下文中更改。程序上下文不知道何時發生中斷或任務切換，因此它必須假定由於可能的上下文切換，多個上下文使用的任何全局變量可能在變量的任何訪問之間改變。這就是volatile聲明的用途。它告訴編譯器該變量可以在您的上下文之外更改，因此每次訪問都讀取該變量，並且不要假設您已經知道該值。

如果該變量被內存映射到硬件地址，則硬件所做的更改實際上是程序上下文之外的另一個上下文。因此，內存映射也是一個線索。例如，如果您的 readADC（）函數訪問一個內存映射的值以獲取ADC值，則該內存映射的變量可能應該是易失的。

所以回到您的問題，如果您的代碼還有更多內容，並且 adcValue 被在不同上下文中運行的其他代碼訪問，那麼， adcValue 應該易揮發。

volatile 參數的行為在很大程度上取決於您的代碼，編譯器和完成的優化。

我個人使用 volatile 有兩種用例：

• 如果我想用調試器查看一個變量，但是編譯器已經對其進行了優化（意味著它已經刪除了它，因為它發現沒有必要使用該變量），添加了 volatile 將強制編譯器保留它，因此可以在調試時看到。

• 如果變量可能在“代碼外”更改，通常是在您有一些硬件訪問它，或者將變量直接映射到地址時。

在嵌入式系統中，有時編譯器中也會出現許多錯誤，無法進行優化，有時候 volatile 可以解決問題。

鑑於您的變量是全局聲明的，因此只要在代碼上使用該變量（至少已讀寫），就可能不會對其進行優化。

示例：

  void test（）
{
    整數a = 1;
    printf（“％i”，a）;
}
 

在這種情況下，變量可能會被優化為printf（“％i”，1）;

  void test（）
{
    volatile int a = 1;
    printf（“％i”，a）;
}
 

不會被優化

另一個：

  void delay1Ms（）
{
    無符號整數i;
    對於（i = 0; i<10; i ++）
    {
        delay10us（10）;
    }
}
 

在這種情況下，編譯器可能會優化（如果您針對速度進行了優化），從而丟棄了變量

  void delay1Ms（）
{
       delay10us（10）;
       delay10us（10）;
       delay10us（10）;
       delay10us（10）;
       delay10us（10）;
       delay10us（10）;
       delay10us（10）;
       delay10us（10）;
       delay10us（10）;
       delay10us（10）;
}
 

對於您的用例，“它可能取決於”其餘代碼，在其他地方使用 adcValue 的方式以及您使用的編譯器版本/優化設置。

有時候，沒有優化但無法優化的代碼會很煩人。

  uint16_t adcValue;
void readFromADC（void）
{
  adcValue = readADC（）;
  printf（“％i”，adcValue）;
}
 

這可能已優化為printf（“％i”，readADC（））;

  uint16_t adcValue;
void readFromADC（void）
{
  adcValue = readADC（）;
  printf（“％i”，adcValue）;
  callAnotherFunction（adcValue）;
}
 

-

  uint16_t adcValue;
void readFromADC（void）
{
  adcValue = readADC（）;
  printf（“％i”，adcValue）;
}

無效anotherFunction（）
{
   //用adcValue做某事
}
 

這些可能不會進行優化，但是您永遠不會知道“編譯器有多好”，並且可能會隨編譯器參數而變化。通常，具有良好優化的編譯器均已獲得許可。

“直接從硬件更改的全局變量”

僅僅因為該值來自某個硬件ADC寄存器，並不意味著它被硬件“直接”更改。

在您的示例中，您僅調用readADC（），它將返回一些ADC寄存器值。對於編譯器而言，這很好，因為知道此時已為adcValue分配了新值。

如果您使用ADC中斷例程來分配新值（在準備好新ADC值時調用），則情況會有所不同。在這種情況下，編譯器不會知道何時調用相應的ISR，可能會決定不會以這種方式訪問adcValue。這是易揮發的地方。

很多技術說明，但我想專注於實際應用。

volatile 關鍵字強制編譯器每次使用時從內存中讀取或寫入變量的值。通常，編譯器會嘗試優化而不進行不必要的讀取和寫入，例如通過將該值保存在CPU寄存器中，而不是每次都訪問內存。

這在嵌入式代碼中有兩個主要用途。首先，它用於硬件寄存器。硬件寄存器可以更改，例如ADC結果寄存器可由ADC外設寫入。硬件寄存器在訪問時也可以執行操作。一個常見的例子是UART的數據寄存器，該寄存器通常在讀取時清除中斷標誌。

編譯器通常會假設值永遠不會改變，因此無需重複訪問，通常會嘗試優化寄存器的重複讀寫，但是 volatile 關鍵字將強制執行每次執行一次讀取操作。

第二種常見用法是用於中斷代碼和非中斷代碼所使用的變量。不會直接調用中斷，因此編譯器無法確定何時執行，因此假定中斷內的任何訪問都不會發生。由於 volatile 關鍵字會強制編譯器每次訪問變量，因此將刪除此假設。

請務必注意， volatile 關鍵字不能完全解決這些問題，因此必須小心避免。例如，在8位系統上，一個16位變量需要兩次內存訪問才能進行讀取或寫入，因此，即使編譯器被迫進行這些訪問，它們也依序發生，並且硬件有可能對第一次訪問或兩者之間會發生中斷。

在沒有 volatile 限定符的情況下，在代碼的某些部分中，對象的值可能存儲在多個位置。例如，考慮以下內容：

  int foo;
int someArray [64];
無效測試（無效）
{
  我
  foo = 0;
  對於（i = 0; i<64; i ++）
    如果（someArray [i] > 0）
      foo ++;
}
 

在C語言的早期，編譯器會處理該語​​句

  foo ++;
 

通過步驟：

 將foo加載到寄存器中
遞增該寄存器
將寄存器存儲回foo
 

但是，更複雜的編譯器將認識到，如果“ foo”的值在循環期間保存在寄存器中，則只需要在循環之前加載一次，然後再存儲一次即可。但是，在循環期間，這意味著“ foo”的值將保存在兩個位置-全局存儲內和寄存器內。如果編譯器可以看到循環中可能會訪問“ foo”的所有方式，那麼這將不是問題，但是如果以某種編譯器不知道的機制訪問“ foo”的值，則可能會造成麻煩。例如中斷處理程序。

該標準的作者可能有可能添加一個新的限定詞，該限定詞將明確邀請編譯器進行此類優化，並說老式的語義將在不存在該語義的情況下適用，但在某些情況下，這些優化是有用的代碼大大超過了有問題的代碼，因此標准允許編譯器假定在沒有證據表明這樣的優化是安全的情況下，它們是安全的。 volatile 關鍵字的目的是提供此類證據。

在某些情況下，某些編譯器作者和程序員之間會發生一些爭論：

  unsigned short volatile * volatile output_ptr;
unsigned volatile output_count;

無效interrupt_handler（無效）
{
  如果（output_count）
  {
*（（（unsigned short *）0xC0001230）= * output_ptr;//硬件I / O寄存器
    *（（（無符號短*）0xC0001234）= 1;//硬件I / O寄存器
    *（（（無符號短*）0xC0001234）= 0;//硬件I / O寄存器
    output_ptr ++;
    output_count--;
  }
}

void output_data_via_interrupt（unsigned short * dat，unsigned count）
{
  output_ptr = dat;
  output_count =計數；
  while（輸出計數）
     ;//等待中斷以輸出數據
}

無符號的短output_buffer [10];

無效測試（無效）
{
  output_buffer [0] = 0x1234;
  output_data_via_interrupt（output_buffer，1）;
  output_buffer [0] = 0x2345;
  output_buffer [1] = 0x6789;
  output_data_via_interrupt（output_buffer，2）;
}
 

從歷史上看，大多數編譯器要么允許編寫 volatile 存儲位置可能觸發任意副作用，而且避免在此類存儲中將任何值緩存在寄存器中，否則它們將避免這種可能性從對調用不合格的“內聯”函數的寄存器中的值進行緩存，從而將0x1234寫入 output_buffer [0] ，設置內容以輸出數據，等待數據完成，然後將0x2345寫入 output_buffer [0] ，然後從那裡繼續。該標準不需要 require 實現，以將將 output_buffer 的地址存儲到 volatile 限定的指針中的行為視為可能發生錯誤的標誌。但這是通過編譯器無法理解的方式實現的，因為作者認為編譯器是針對各種平台和目的的編譯器的作者，他們會認識到這樣做的目的是在那些平台上滿足這些目的，而無需告知。因此，某些“靈巧”的編譯器（例如gcc和clang）將假定即使將 output_buffer 的地址寫入兩個存儲在 output_buffer [0] code之間的volatile限定的指針中>，這沒有理由假設任何東西都可能關心那個對象當時持有的價值。

此外，雖然直接從整數強制轉換的指針很少用於除編譯器不太可能理解的方式之外的其他用途，但標準再次不需要編譯器將此類訪問視為易失性。因此，像gcc和clang之類的“聰明”編譯器可能會省略對 *（（unsigned short *）0xC0001234）的首次寫入，因為此類編譯器的維護者寧願聲明忽略了限定條件的代碼諸如 volatile 之類的東西被“破壞”，而不是意識到這種代碼很有用。許多供應商提供的頭文件都省略了 volatile 限定詞，並且與供應商提供的頭文件兼容的編譯器比沒有供應商的頭文件有用。