日記帳だ! with Tux on Libserver

ふと気になったことがあって、マイコンのデバッグで使うUART通信、

評価ボードだとUSB-UARTブリッジICが搭載されていて接続できたり、

あるいはRS-232Cに変換してPCと接続したり……

このときよく使われる通信速度として115200bpsというのがあるが、なんでこのスピードなんでしょうね?

そもそもUARTというのは調歩同期式シリアル通信の代表的なもので、

調歩同期式というのは信号線1本で通信を完結できる仕組みである。

一般的には送信・受信を分けて全二重にすることが多いが、それでも2本である。

SPI通信だとクロック・チップセレクト信号も伝達することが通常だが、

UARTではスタートビットの送信で通信開始を示し、

それを合図に取り決めたボーレートで順番にデータをやりとりして、

最後にストップビットをやりとりしたら1byte送信完了となっている。

UART通信を正しくやる上で肝心なのが時間精度である。

例えば9600bpsで通信する場合、104.2us周期で送信側は信号を切替、受信側はサンプリングしなければならない。

スタートビットからストップビットまでの間に1bitズレると通信に失敗する。

高速になるほど、これがシビアになるので難しい?

とはいえ、その上限が115200bpsとも思えないところはある。

確かにあるシステムでは同じ基板の上に乗ったマイコン同士が1MbpsのUART通信をしている。

なぜUARTなのかというと、この間に絶縁素子があるからである。

信号線1本(往復で2本)で伝達できるというのは絶縁という点でも有利である。

UARTというのはシンプルな方式なので、それ自体に上限はなさそうで、

問題は経路とインターフェースということになろうかと思う。

さっきの例だと絶縁素子のスピードで決まる部分が多いかと思う。

あるいはマイコンのUART機能はクロック周波数の8分周が最速とか決められてるので、

そういうところで最高速度が決まるということである。

通信相手がPCの場合に問題となりそうなのは、RS-232Cという伝送経路と、

USB-UARTブリッジICの性能というところが問題ではないかと思う。

今どきPC自体にRS-232Cが搭載されているということはそうそうなくて、

一般的にはUSB接続のRS-232Cインターフェースと組み合わせて使うが、

その内部にはUSB-UARTブリッジICが搭載されているのが通常である。

それをRS-232Cで引き出した先におくか、評価ボード上に置くかの違いである。

まず、RS-232Cの最高速度だが、規定上は20kbpsとなっているらしい。

この範囲内に入るボーレートでよく使われるのが9600bpsと19200bpsだが……

明らかにこれは実態に合っていなくてRS-232Cはもっと高速な通信で使われることは多い。

無難な数字として9600bpsとか19200bpsが使われることはあるが。

現実的な上限は150～250kbpsぐらいの範囲にあることが多いようだ。

ある基板に搭載されていたRS-232Cのドライバ/レシーバICではMaximum Data Rateは150kbps(min.)となっていた。

このICを介して行うRS-232Cの通信は150kbpsが上限になるということで、

冒頭に書いた115200bpsはその上限に近い数字である。

というか115200bpsの通信は通せる仕様ということでこうしたんじゃないか。

もう1つの要素としてはUSB-UARTブリッジICの対応速度がある。

1Mbpsぐらいは対応しているものが多いようである。

もう少し速くて2Mbpsとか3Mbpsとか対応したものもあるようだけど。

基板上で完結する通信ならば少なくとも1Mbpsぐらいは対応できるとみられるので、

USB-UARTブリッジICを基板上に置けばそのあたりが現実的な上限なのだろう。

というわけで115200bpsというのは現代的なシステムではほぼ対応できるボーレートで比較的速いものとして選ばれたのではないかと思う。

RS-232Cを通すとなると、さらに倍速の230400bpsが通るか通らないかというところ。

堅いのは115200bpsまでということなんだろう。

ただ、UARTという通信方式そのものは1Mbps程度までは対応可能で、

インターフェースや通信経路をよくよく精査すればより高速化は可能かもしれないと。

なんでこんな話を書いたかというと10MbyteぐらいあるデータをROMに書くのに、

マイコンにUARTで送って書き込んでもらうことを考えたのだが、

10Mbyteのデータを115200bpsで送ることを考えると、

UARTで1byte送るにはスタートビット+8bit+ストップビット=10bit送る必要があるので、

所要時間は 10×10⁶×10/115200=868sと求まる。

868秒と言われてもピンとこないが、60で割ると14.5分である。

データ送信プロトコル(例えばYMODEM)のオーバーヘッドなど加味せずにこれだけかかるのである。

で、速くする余地はあるのかと考えたのだが、

まず最初に考えたのはデータ圧縮、ただ、すでに圧縮されているのか効果が見いだせなかった。

効果があればzlibとか組み込んでDeflateしたデータを送るとか考えたけど。

となると、通信速度自体を上げたいと調べたがRS-232Cを介する場合はこれが現実的な上限であると。

1Mbpsまで速くできれば100sだから、2分ぐらいで送信できる計算で、

これだとそんなに悪くない気がするが、さすがに15分は遅いなと。

というわけでシリアル通信で送る作戦は手軽でよいと思ったのだが、

こうも遅いとあまりよい方法ではないと思った。

他の手段がなければ15分かかっても仕方ないですけど。

結論から言えば、以前紹介したICEからプログラムでは無いものを書く方式が速かった。

ICEからプログラムでは無いものを書く

書き込み先のROMはマイコンのプログラムを格納するROMではなかったが、

マイコンには接続されているので、同じような書き込み方をすることはできた。

マイコンのデバッグインターフェースの速度次第だとは思うのだが、

一般的に考えればUARTよりは速いわけで、データ転送だけ考えれば速い。

あとはオーバーヘッドなど総合的に見てどうかという話ではあるけど、

数分で書き込み完了できたので、この方法がよいと思った。

ただ、ICEで接続できる場合に限られるので、やはりシリアル通信で書き込みたい話もあるかもしれない。

コンパイラのバージョンを変えたら正しく動かないという話があり、

なんのこっちゃと調べていたらレジスタやスタックの使い方が変わったことで、

既存のバグ(かそれに近いもの)が露呈した形である。

1つはスタックに確保した配列の範囲外を操作したことによるもので、

なぜこれが見逃されてきたかというのは気になるところだが、

配列サイズを適切に設定すれば解消する問題なので、これはこれでよい。

問題は残り2つで、元々スタックの使用方法に依存する処理と、

どうしてもレジスタ上で処理してほしい処理である。

スタックの使用方法に依存する処理はコンパイル結果に依存することは口伝されていたので、

新しいコンパイル結果に見合った調整を行えば回避できる。

が、そもそもスタックの使用方法に依存する処理というのが問題じゃないかという話で、

そこに依存しないように作っておくべきだったのではというのは……

この問題への僕の考える答えは後で書く。

もう1つのどうしてもレジスタ上で処理したい処理の話だが、

端的に言えばコーディングの問題である。

Cのコーディングでこの変数はレジスタ上に配置することを保証することはできない。

変数宣言時にregisterキーワードを付けるとレジスタ上に配置するよう努めるが、

必ずしもレジスタ上に配置しなくてもよいとされている。

それでコンパイラの独自拡張で変数の配置場所をレジスタに指定することができて、

これを使うことでCでコーディングしながらレジスタ上での処理が保証できるようになっていたが、

問題はこのレジスタ上に配置される変数がグローバル変数扱いだったことである。

グローバル変数といっても当該Cファイルを超えて、extern宣言でアクセスできるわけではないはずだが。

もう1つの問題が使用していたレジスタがスクラッチレジスタではなかったことである。

各アーキテクチャではABI(Application Binary Interface)の取り決めによりレジスタの使い方が決まっている。

32bit版のARMの場合、r0～r3は引数・返り値の受け渡しに使い、r14(lr)は復帰先のアドレスを格納するなど。

で、呼びされた関数で破壊してもよいスクラッチレジスタの規定があり、

r0～r3, r12の5つのレジスタは各関数で退避せず破壊してもよいことになっている。

これ以外のr4～r11, r13(sp), r14(lr)は使用する場合は各関数でスタックなどに退避する必要がある。

どうしてもレジスタ上でやりたい処理をスクラッチレジスタを使ってやっていればよかったのだが、

上を見てもわかるように32bit版のARMの場合、スクラッチレジスタの大半は引数・返り値の受け渡し用でもあり、

そういうレジスタをグローバル変数に割りあてるというのは到底認められないわけである。

そこでこれ以外のレジスタを使っていたのだが、退避させる処理が抜けていたと。

unsigned int reg4; //コンパイラ独自拡張でr4に配置
void something(void){
   unsigned int reg4_keep;
   reg4_keep = reg4;
   //reg4を使った処理
   reg4 = reg4_keep
}

こう書いていればよかったのだが、そうなっていなかったのである。

というわけでこういう記述に修正してとりあえず回避できた。

なんでこれで従来問題になってなかったのかが不思議だが。

なお、コンパイル結果を確認するとスクラッチレジスタに退避させているようだった。

最大の失敗はこの処理をアセンブラで書かなかったことではないかと思う。

アセンブラで書いていれば、スクラッチレジスタを使って素直に書けたはずなので。

そもそもスクラッチレジスタとそうでないレジスタについて知識がなかったのでは? というのも気になるけど。

そんな処理があることは以前から知っていた(詳しくコードは見てなかったが)

ただ、ローカル変数をレジスタに割りあてる機能だと勘違いしてて退避処理も入れてくれると思っていたが、

そうではなく自分で退避させる必要があったというのも勘違いなのかもしれないが。

冒頭に書いたスタックの使用方法に依存する処理も、

スタックを使わないようにアセンブラで工夫して書くことはできるわけで、

そうしておけばコンパイル結果に依存しないコードになってたのになと。

もちろんアセンブラで書くことでコーディングのミスを起こしやすいとか、

長期的に見れば移植性の問題などあるにはあるけど、

結局コンパイラのバージョン違いで移植性の問題が起きてるじゃないかと。

最近別の仕事でアセンブラでコーディングせざるを得ないところをいろいろやって、

もうそれアセンブラで書けばと言ってしまいがちなのはある。

難しいことをアセンブラで書いちゃダメですけどね。

デバッグ用にシリアル通信でプログラムをロードして実行できるようにしたいという話があった。

以前のシステムではそのための特別なプログラムをマイコンに書き込んで、

そういうことをできるようにしていたのだが、今回はそれを通常のプログラムに入れた方がいいねと。

話によればU-Bootのようなブートローダーの機能を参考に作ったのだという。

今回のシステムでも当初はU-Bootが必要なのでは?

という話があったのだが、結局は不要となった経緯がある。

U-Bootにはシリアル通信でプログラムをロードするコマンドがあって、

当初の実験時に loadyコマンドでYMODEMで転送した覚えがあるような。

確かそのときはメモリ上に転送した後、mmc writeコマンドでSDカード(MMC)に書き込んだっただったか。

プログラムを保存する機能は持っていないけど、転送機能はほぼそれで、

あとはU-Bootで言うところの bootmコマンド、単純に指定アドレスにジャンプするだけだけど、

それを実装しておけばテスト用のプログラムをシリアル通信で転送して実行できるわけ。

元々マイコンに焼いていたコードを流用して作り始めたのだが、

かなり改変が大きく、跡形もないぐらいに変わってしまったかも。

アルゴリズム的にはあまり変わってないんですけどね。

内部的にはprintfもどきの関数を自作して持っていたりする。

他のデバッグでも表示にはこれを使うかと付替をしたりなんとか。

あとはそこにロードするプログラムのひな形も作ってみて、

実運用上、こういう使い方ができるといいなというのを多少加えた。

できたものを動かしてみると、確かにけっこう便利かもしれない。

最初はデバッグ用のプログラムをROMに書いて動かせばよいと思ってたが、

いろいろ特殊な事情もあるので、単純にROMに書いても動かない問題があった。

なのでデバッグ機能を作り込んだ方がよいねとなったのだけど、

それ以外のメリットとしてはROM書換用にICEなど用意する必要が無いこと。

ロードするプログラムを変えればいろいろな評価に活用できること。

(現在もそういう使い方をしているらしい)

従来よりこの機能の使い道も増えたので、新しい使い方もあるかもねとは言っているが果たしてどうか。

そこはわからんけど当初の機能の代替としては十分でしょう。