シリアル通信 (Serial.print) は RAM を大量に消費する (Arduino)
Arduinoについて気付いた話です。前回のPROGMEMに続き、今回はシリアル通信でおなじみの Serial.print です。
Serial.print は使い方が簡単なので便利です。でもこれ、すごい量のRAMを消費します。ミニオシロ作りではRAMが足りなくて、対策としてPROGMEMを使ったり、無駄な変数を使わないようにして出来るだけRAMを節約しています。ところが、シリアルを使うとそんな苦労をしているのがアホらしくなるくらい大量のRAMが使われます。
ということで、そのあたりの様子を詳しく見てみます。
▼シリアルのRAM使用量のテスト
RAMの残りのサイズは、コンパイル後にIDEの画面下に表示されるので、この値を見て行きます。
ところで話は脱線しますが、画面のスクリーンショットは違法なんて話がありますが、こういうのやっちゃいけなくなるんでしょうか？ 違法と知らなくてもダメらしいのですが、「画面内のその書き方は、だれそれの著作権を犯しているぞ」なんて因縁つけることだって出来る気がします。スクショがダメなら、「hogeというプログラムのバージョンaaaを画面サイズcc X ddで開いた時の、画面座標(x1,y1)-(x2,y2)の範囲に、」なんて書くしかないので、web文化は終わっちゃいます。
話を戻しましょう。
以下はSerial.print を使った時のRAMの使用量を調べた結果です。
順番に数値を追ってみます。
１．setupとloopしか無い状態で、これがArduinoのミニマムの状態です。RAMの物理的な容量は2048バイトありますが、ここでは2039バイトとなっていて9バイト少なくなっています。この9バイトは Arduinoとして動かすために必要な量なんでしょうが、思ってたより少ないです。
２．無限ループを作っているwhileだけ追加した状態です。RAMは使わないので、残りRAMの量に変化はありません。なお、フラッシュメモリの量はもちろん変化しています。
３．Serial.begin(115200); を追加しただけですが、ここで一気に173バイトもRAMが減っています。これあんまりじゃないの、と思ったのがこの記事を書いている動機なのですが、とりあえず話を先に進めます。
４．Serial.println(F("Hellow world!")); を追加して実際に文字の出力を行っています。13文字出力していますが、引数をF( )でくくって、PROGMEM として扱っているので、RAM は4バイトしか減っていません。
５．文字列をStringクラスで扱っているので、RAMの消費量が36バイト増えています。まあ便利さの代償としてこれくらいは仕方がない感じです。ちなみにString はメモリの消費が多いと言われていますが、実際にどれくらいなのか調べたことがありませんでした。この例では、さほどでもない感じです。
◆まとめ
シリアルを使うと予想外にRAMが減って、Serial.begin( )で宣言しただけで173バイトも持って行かれます。PROGMEMなどを使ってちびちびと節約しているのに、その横でこんな大盤振る舞いをされたら、たまったもんじゃありません。
調べてみたら、Serial では受信と送信バッファに各々64バイト、合計で128バイトのRAMを使うので、こんなRAMの消費量になるようです。シリアルのバッファはハードのFIFOでやっているのだと思っていたのですが、CPUのRAMだったんですね。あと、シリアルの受信なんて、私はコマンド文字を1文字受信するくらいがせいぜいの使い方なので、受信バッファは64バイトもいりません。でもArduinoはいろんな人が使うので、多めに確保しておいた方が良いという判断なんでしょうね。
ちなみにシリアルのバッファサイズをユーザーのスケッチから再定義出来るといいのですが、そういうことは出来ないようです。どうしてもやりたいなら、元のデバイスの定義を修正するしか無いようですが、それをやると、思わぬ問題の種を蒔くことになります。
そんなことで、RAMが足らなくなったら、Serial を使わないようにするのが特効薬になりそうです。但し、Serial.printを使ったデバッグは出来なくなるので、液晶などの画面があればそこに変数の内容を表示させる、などの工夫が必要になります。
Serial.print は使い方が簡単なので便利です。でもこれ、すごい量のRAMを消費します。ミニオシロ作りではRAMが足りなくて、対策としてPROGMEMを使ったり、無駄な変数を使わないようにして出来るだけRAMを節約しています。ところが、シリアルを使うとそんな苦労をしているのがアホらしくなるくらい大量のRAMが使われます。
ということで、そのあたりの様子を詳しく見てみます。
▼シリアルのRAM使用量のテスト
RAMの残りのサイズは、コンパイル後にIDEの画面下に表示されるので、この値を見て行きます。
ところで話は脱線しますが、画面のスクリーンショットは違法なんて話がありますが、こういうのやっちゃいけなくなるんでしょうか？ 違法と知らなくてもダメらしいのですが、「画面内のその書き方は、だれそれの著作権を犯しているぞ」なんて因縁つけることだって出来る気がします。スクショがダメなら、「hogeというプログラムのバージョンaaaを画面サイズcc X ddで開いた時の、画面座標(x1,y1)-(x2,y2)の範囲に、」なんて書くしかないので、web文化は終わっちゃいます。
話を戻しましょう。
以下はSerial.print を使った時のRAMの使用量を調べた結果です。
// RAM使用量のテストプログラム自体の説明は不要と思います。コメントのAからFまでの行を追加して行った時のRAMの量を、末尾のコメント欄に記入しています。
String a = "Hellow "; // A
String b = "world!"; // B
void setup() {
Serial.begin(115200); // C
}
void loop() {
Serial.println(a + b); // D
// Serial.println(F("Hellow world!")); // E
while (1) {} // F
}
/* 条件別の残りRAMの量
1. (全部無し) ：ローカル変数で2039バイト使うことができます。
2. F ：ローカル変数で2039バイト使うことができます。-0
3. C +F ：ローカル変数で1866バイト使うことができます。-173
4. C +E+F ：ローカル変数で1862バイト使うことができます。-4
5. A+B+C+D +F ：ローカル変数で1826バイト使うことができます。-36
*/
順番に数値を追ってみます。
１．setupとloopしか無い状態で、これがArduinoのミニマムの状態です。RAMの物理的な容量は2048バイトありますが、ここでは2039バイトとなっていて9バイト少なくなっています。この9バイトは Arduinoとして動かすために必要な量なんでしょうが、思ってたより少ないです。
２．無限ループを作っているwhileだけ追加した状態です。RAMは使わないので、残りRAMの量に変化はありません。なお、フラッシュメモリの量はもちろん変化しています。
３．Serial.begin(115200); を追加しただけですが、ここで一気に173バイトもRAMが減っています。これあんまりじゃないの、と思ったのがこの記事を書いている動機なのですが、とりあえず話を先に進めます。
４．Serial.println(F("Hellow world!")); を追加して実際に文字の出力を行っています。13文字出力していますが、引数をF( )でくくって、PROGMEM として扱っているので、RAM は4バイトしか減っていません。
５．文字列をStringクラスで扱っているので、RAMの消費量が36バイト増えています。まあ便利さの代償としてこれくらいは仕方がない感じです。ちなみにString はメモリの消費が多いと言われていますが、実際にどれくらいなのか調べたことがありませんでした。この例では、さほどでもない感じです。
◆まとめ
シリアルを使うと予想外にRAMが減って、Serial.begin( )で宣言しただけで173バイトも持って行かれます。PROGMEMなどを使ってちびちびと節約しているのに、その横でこんな大盤振る舞いをされたら、たまったもんじゃありません。
調べてみたら、Serial では受信と送信バッファに各々64バイト、合計で128バイトのRAMを使うので、こんなRAMの消費量になるようです。シリアルのバッファはハードのFIFOでやっているのだと思っていたのですが、CPUのRAMだったんですね。あと、シリアルの受信なんて、私はコマンド文字を1文字受信するくらいがせいぜいの使い方なので、受信バッファは64バイトもいりません。でもArduinoはいろんな人が使うので、多めに確保しておいた方が良いという判断なんでしょうね。
ちなみにシリアルのバッファサイズをユーザーのスケッチから再定義出来るといいのですが、そういうことは出来ないようです。どうしてもやりたいなら、元のデバイスの定義を修正するしか無いようですが、それをやると、思わぬ問題の種を蒔くことになります。
そんなことで、RAMが足らなくなったら、Serial を使わないようにするのが特効薬になりそうです。但し、Serial.printを使ったデバッグは出来なくなるので、液晶などの画面があればそこに変数の内容を表示させる、などの工夫が必要になります。
