H8/3069F再入門 - KOZOSの中身を見ていく。 [プログラミング]
前回、H8/3069F再入門をしてみました。いわゆるマイコンのボードです。組み込みの入門には最適みたいで、無理やりLinuxを乗せることもできるけど、今度はもうちっと軽いものでやってみたいと思っていました。
前回は、KOZOSというOSを載せたみたいですが、作業をしている時にはあんまり気にしてませんでした。正直KOZOSのコンパイルをするよりも、H8用のコンパイラを作って環境を整える事がかなり面倒で、その上USBのケーブルからシリアルポートの入出力をするので、なかなか自分としてはハードルが高かったです。
とはいえ、前にむりやりLinuxを載っけたときの物理環境（シリアルポートとH8ボードなど）が残っていたので、そこいらは面倒がなくて済みました。通販でお取り寄せって言うのが一番簡単で、確実性があると思うので、つまらない所でつまずいてもいいように、準備で楽できる所は楽しましょう。シリアル系の含めて、全部揃えても5000円程度ですし。
始めは、仮想サーバのゲストOSには、コンソールでいいじゃないかと思っていたのですが、やっぱり自分が腑抜けていて、デスクトップ環境がないとすごく作業効率が下がります。Ubuntu Serverで作業中の時に、64bitじゃダメなんじゃないのと書かれているのを見て、すぐさま32bitのUbuntu Desktopに切り替えたのですが、Desktop環境がやりやす過ぎて、おなじgccのコンパイルエラーが出ていても、geditでソースを改変してコンパイルをサクッと通して終わっちゃいました。やはりコマンドラインはいちいち考えたり、調べたりしないといけないので面倒ですわ。CUIにもいいところはあるので、否定はしませんけど、やっぱりGUIでやれるならそっちの方がいいです。太っているのでやせ我慢はしない。
おいらは玄箱でかなり鍛えたとはいえども、結局、全部コンソールのマシンで作業をするには、かなりスキルが足りてないみたい。出来るは出来るんだけど、確証が持てないことが多過ぎて、いちいちググるから時間がかかってしまう。ブラウザもelinksとかを使えばそれなりに、サクッとダウンロード出来るのだけれど、やっぱりデスクトップ環境でFirefoxでやった方が気持ちよくできる。解凍もtarで.bz2を解凍するパラメーターは何だっけ？（xjf）とか、CUIではあるけれども、GUIでやれば、ダブルクリックにコピペで終わりですもんね。負抜けたと言われても仕方ないけど、負抜けられるなら負抜けましょうよってことで。そうじゃなかったら、Ubuntuなんて使わないで、DebianのCUIをずっと使っていれば良いのですから。
いつだったか、緑色かなんかの、OSを作る本をちょっと欲しかったりしたのですが、OS作る前に既存のを使いこなせた方が先だ、と思い、購入を思いとどまりました（高いし）。でも、このくらいの量だったら、本に頼らずとも、自分で読みこなせるだろう、と思ったのでした。
動いたから、はいバイバイ、じゃ何をしたか分からないので、実際にコンパイルしたソースコードをこの記事に従って見ていきます。
http://monoist.atmarkit.co.jp/mn/articles/1105/10/news001.html
ここ↑に書かれているように、確かにHello Worldを表示するごときで、200行ってのは多い気がしますし、OSの機能を200行程度で一応実現できるってのもすごいと思います。OSって言っても、どうせこのコードではHelloWorld以上の事は出来ないってのも真なりな訳で。とはいえ、OSの構造を曲がりなりにも学べるのは、既存のやたら長いソースを見るよりかは現実的だと思います。Linuxでもカーネルに含まれているドライバ一つ読むのだって大変な事でしょうからね。
んで、読んでいきます。割り込みベクターってのも、組み込み的でパソコン的ではないですね。x86でも割り込みベクターってのはあるんだろうけど、あんまり使ってないってことなのかな。割り込みのための表みたいな存在で、該当する場所に飛ぶと、更に処理されるアドレスがそこに書いてあるから、その割り込みハンドラに更に飛ぶ、みたいな感じらしい。
リセット割り込みってのがあるけど、結局、通電したときと一緒らしい。ということは、そうじゃないCPUもあるって事なんでしょうな。でも0x000000のアドレスから始まるってのは普通な感じではある。0x000000は内蔵フラッシュROM上にあるので、自分で書き込んだ処理を動かせるようになってるって書いてあるね。いきなりフラッシュロムの領域になるってのも、それはそれですごいと思うけど。
あ、携帯を作っている時に、やたらアドレス関係に腐心していたのを思い出した。.textとか.bssとかデータによって領域があって、デバッグオプションを付けると、やたらでかくなって困ってました。組み込みをよく知っている人が少なくて、僕もその一味だったんだけど、コンパイルオプションのやり方を知ってない人が多かった。その時でさえ、Makefileを何も見ずに手で書けるぐらいの人ってあんまりいなさそうだったしなぁ。
次のページ
http://monoist.atmarkit.co.jp/mn/articles/1105/10/news001_2.html
リンカスクリプトはリンクしてelf形式にファイルを作る時にメモリ配置をするものらしい。使ってるコンパイラがelf何とかって書いてあったので、適当に想像。今時のOSだと、アプリケーションから見えるアドレスは独立しているらしく、普通は考えなくてもいいところ。でも、組み込みは自分でやらなきゃ行かないので面倒ですね。ld.scrって所にはメモリの位置の設定が書かれていて、多分この順番でデータがフラッシュメモリに書かれるようになるのだと思う。
vector.cを見てみるとstart()と、vectors[]()という関数が書かれていますが、「関数の配列のポインタ」って普段ではあまり見かけない、嫌な感じの記述法ですね。でも、簡略に書いたり使ったりするにはこういう書き方の方が簡素であるのでしょう。システムとか速さを気にするプログラムだとよく見かけるかも。その中身を見ると、start()を先頭に、全体が8x8の64個の配列になっています。ここに並べる順番で、適宜処理を飛ばしたりする事になるんでしょう。にしても64個ってのは、割り込みベクターが制限されていてこの数なのかな？
start()っていうのを発動するだけじゃなくて、スタック・レジスタの初期化とか、スタートアップを呼ばれる始めにやっとかなきゃいけないことがあるのですか。スタートアップはアセンブラで嫌だなぁ。startup.sは短いけど、アセンブラは何やってるか分からないので、読みたくないなぁ。結局、多くの部分が機種依存だからねぇ。main.cには普通のC言語ライクにmain()がありますが、組み込みってあんまりmainとか考えてない気がして、スタートアップした後は各タスクが別途動いているというような状態になっていると思っていた。main()って考えでは、パソコンのアプリケーション方面すぎると思います。つっても、組み込みの中身を見たのはitronしかないんだけどね。
最後のページ
http://monoist.atmarkit.co.jp/mn/articles/1105/10/news001_3.html
標準ライブラリを入れるのも場所がもったいないので、printf()は当然の如く使えず、puts()のような低水準の関数しか使えないんですね。まぁputsが使えれば問題ないっす。
シリアルドライバってのもシリアル通信するので、当然の如くあって、
sciというのは「serial controller interface」ってことか。まぁ変数の名前なんてどうでもいいんだけど。
メモリマップドI/Oってのは、組み込み的に分かりやすいですね。同じアドレスの延長で扱えるのは、いろいろリソースが少ないシステムでは別個にしない方がいいのかもしれません。ポインタ経由のメモリアクセスが、シリアルコントローラのレジスタ操作になっている、って書いてありますが、それ以上の拡張がない世界としては、物事が単純になるので、アドレスの決め打ちでやった方が色々面倒が少ないってこともありますしね。アドレスをマクロで宣言してあげれば、使う時にはそれで済むのですから楽でしょう。
あ、さっきのputs()も自作の関数だったんですね。シリアルに出力するために、表示したい文字を一文字ずつ特定のアドレスに書き込んでいました。たぶん、C言語の組み込みの低水準の関数、read(), write()すらも実装されてないかも。元々、ファイルという概念も、ファイルシステムがない時点では、無くても当然な気がします。itronのときも当然の如くなかったので、ここでもないんでしょうね。
細かく見ていくつもりでしたが、特に私が突っ込む所はありませんでしたね。わりと親切丁寧に説明されていたので、自分の感想ぐらいしか書けませんでした。
前回は、KOZOSというOSを載せたみたいですが、作業をしている時にはあんまり気にしてませんでした。正直KOZOSのコンパイルをするよりも、H8用のコンパイラを作って環境を整える事がかなり面倒で、その上USBのケーブルからシリアルポートの入出力をするので、なかなか自分としてはハードルが高かったです。
とはいえ、前にむりやりLinuxを載っけたときの物理環境（シリアルポートとH8ボードなど）が残っていたので、そこいらは面倒がなくて済みました。通販でお取り寄せって言うのが一番簡単で、確実性があると思うので、つまらない所でつまずいてもいいように、準備で楽できる所は楽しましょう。シリアル系の含めて、全部揃えても5000円程度ですし。
始めは、仮想サーバのゲストOSには、コンソールでいいじゃないかと思っていたのですが、やっぱり自分が腑抜けていて、デスクトップ環境がないとすごく作業効率が下がります。Ubuntu Serverで作業中の時に、64bitじゃダメなんじゃないのと書かれているのを見て、すぐさま32bitのUbuntu Desktopに切り替えたのですが、Desktop環境がやりやす過ぎて、おなじgccのコンパイルエラーが出ていても、geditでソースを改変してコンパイルをサクッと通して終わっちゃいました。やはりコマンドラインはいちいち考えたり、調べたりしないといけないので面倒ですわ。CUIにもいいところはあるので、否定はしませんけど、やっぱりGUIでやれるならそっちの方がいいです。太っているのでやせ我慢はしない。
おいらは玄箱でかなり鍛えたとはいえども、結局、全部コンソールのマシンで作業をするには、かなりスキルが足りてないみたい。出来るは出来るんだけど、確証が持てないことが多過ぎて、いちいちググるから時間がかかってしまう。ブラウザもelinksとかを使えばそれなりに、サクッとダウンロード出来るのだけれど、やっぱりデスクトップ環境でFirefoxでやった方が気持ちよくできる。解凍もtarで.bz2を解凍するパラメーターは何だっけ？（xjf）とか、CUIではあるけれども、GUIでやれば、ダブルクリックにコピペで終わりですもんね。負抜けたと言われても仕方ないけど、負抜けられるなら負抜けましょうよってことで。そうじゃなかったら、Ubuntuなんて使わないで、DebianのCUIをずっと使っていれば良いのですから。
いつだったか、緑色かなんかの、OSを作る本をちょっと欲しかったりしたのですが、OS作る前に既存のを使いこなせた方が先だ、と思い、購入を思いとどまりました（高いし）。でも、このくらいの量だったら、本に頼らずとも、自分で読みこなせるだろう、と思ったのでした。
- 作者: 川合 秀実
- 出版社/メーカー: 毎日コミュニケーションズ
- 発売日: 2006/03
- メディア: 単行本
動いたから、はいバイバイ、じゃ何をしたか分からないので、実際にコンパイルしたソースコードをこの記事に従って見ていきます。
http://monoist.atmarkit.co.jp/mn/articles/1105/10/news001.html
ここ↑に書かれているように、確かにHello Worldを表示するごときで、200行ってのは多い気がしますし、OSの機能を200行程度で一応実現できるってのもすごいと思います。OSって言っても、どうせこのコードではHelloWorld以上の事は出来ないってのも真なりな訳で。とはいえ、OSの構造を曲がりなりにも学べるのは、既存のやたら長いソースを見るよりかは現実的だと思います。Linuxでもカーネルに含まれているドライバ一つ読むのだって大変な事でしょうからね。
んで、読んでいきます。割り込みベクターってのも、組み込み的でパソコン的ではないですね。x86でも割り込みベクターってのはあるんだろうけど、あんまり使ってないってことなのかな。割り込みのための表みたいな存在で、該当する場所に飛ぶと、更に処理されるアドレスがそこに書いてあるから、その割り込みハンドラに更に飛ぶ、みたいな感じらしい。
リセット割り込みってのがあるけど、結局、通電したときと一緒らしい。ということは、そうじゃないCPUもあるって事なんでしょうな。でも0x000000のアドレスから始まるってのは普通な感じではある。0x000000は内蔵フラッシュROM上にあるので、自分で書き込んだ処理を動かせるようになってるって書いてあるね。いきなりフラッシュロムの領域になるってのも、それはそれですごいと思うけど。
あ、携帯を作っている時に、やたらアドレス関係に腐心していたのを思い出した。.textとか.bssとかデータによって領域があって、デバッグオプションを付けると、やたらでかくなって困ってました。組み込みをよく知っている人が少なくて、僕もその一味だったんだけど、コンパイルオプションのやり方を知ってない人が多かった。その時でさえ、Makefileを何も見ずに手で書けるぐらいの人ってあんまりいなさそうだったしなぁ。
次のページ
http://monoist.atmarkit.co.jp/mn/articles/1105/10/news001_2.html
リンカスクリプトはリンクしてelf形式にファイルを作る時にメモリ配置をするものらしい。使ってるコンパイラがelf何とかって書いてあったので、適当に想像。今時のOSだと、アプリケーションから見えるアドレスは独立しているらしく、普通は考えなくてもいいところ。でも、組み込みは自分でやらなきゃ行かないので面倒ですね。ld.scrって所にはメモリの位置の設定が書かれていて、多分この順番でデータがフラッシュメモリに書かれるようになるのだと思う。
vector.cを見てみるとstart()と、vectors[]()という関数が書かれていますが、「関数の配列のポインタ」って普段ではあまり見かけない、嫌な感じの記述法ですね。でも、簡略に書いたり使ったりするにはこういう書き方の方が簡素であるのでしょう。システムとか速さを気にするプログラムだとよく見かけるかも。その中身を見ると、start()を先頭に、全体が8x8の64個の配列になっています。ここに並べる順番で、適宜処理を飛ばしたりする事になるんでしょう。にしても64個ってのは、割り込みベクターが制限されていてこの数なのかな？
start()っていうのを発動するだけじゃなくて、スタック・レジスタの初期化とか、スタートアップを呼ばれる始めにやっとかなきゃいけないことがあるのですか。スタートアップはアセンブラで嫌だなぁ。startup.sは短いけど、アセンブラは何やってるか分からないので、読みたくないなぁ。結局、多くの部分が機種依存だからねぇ。main.cには普通のC言語ライクにmain()がありますが、組み込みってあんまりmainとか考えてない気がして、スタートアップした後は各タスクが別途動いているというような状態になっていると思っていた。main()って考えでは、パソコンのアプリケーション方面すぎると思います。つっても、組み込みの中身を見たのはitronしかないんだけどね。
最後のページ
http://monoist.atmarkit.co.jp/mn/articles/1105/10/news001_3.html
標準ライブラリを入れるのも場所がもったいないので、printf()は当然の如く使えず、puts()のような低水準の関数しか使えないんですね。まぁputsが使えれば問題ないっす。
シリアルドライバってのもシリアル通信するので、当然の如くあって、
sciというのは「serial controller interface」ってことか。まぁ変数の名前なんてどうでもいいんだけど。
メモリマップドI/Oってのは、組み込み的に分かりやすいですね。同じアドレスの延長で扱えるのは、いろいろリソースが少ないシステムでは別個にしない方がいいのかもしれません。ポインタ経由のメモリアクセスが、シリアルコントローラのレジスタ操作になっている、って書いてありますが、それ以上の拡張がない世界としては、物事が単純になるので、アドレスの決め打ちでやった方が色々面倒が少ないってこともありますしね。アドレスをマクロで宣言してあげれば、使う時にはそれで済むのですから楽でしょう。
あ、さっきのputs()も自作の関数だったんですね。シリアルに出力するために、表示したい文字を一文字ずつ特定のアドレスに書き込んでいました。たぶん、C言語の組み込みの低水準の関数、read(), write()すらも実装されてないかも。元々、ファイルという概念も、ファイルシステムがない時点では、無くても当然な気がします。itronのときも当然の如くなかったので、ここでもないんでしょうね。
細かく見ていくつもりでしたが、特に私が突っ込む所はありませんでしたね。わりと親切丁寧に説明されていたので、自分の感想ぐらいしか書けませんでした。
タグ：組み込み
まだ今日の話ぐらいはハード屋の私でもわかるな。
H8だったと思いますけど、コンパイラ付属のライブラリにSCIx_printf()なんてのが準備されてて、なかなかセンスを感じたことがあります。
ファイルシステムはワンチップマイコンの鬼門ですねー。
昔、MP3プレイヤーつくった際、FAT32がわかんなくてwebでソース探してコピペした屈辱の記憶があります。未だによくわかってないし。
by 7700 (2011-06-28 22:35)
まだファイルシステムうんぬんのところまでは行ってないですが、マイコンで扱うには少々大袈裟な仕組みなのかも知れませんね。でも、FAT32を読み書きするのをスクラッチする意味はあんまりないかもしれません。あるものを借りて来て使うってのは普通だと思いますしね。まともに動かなかったら、ハックして使えるようにするぐらいが今時のOSSなプログラミングだと思います（自己憐憫入ってます）。
FAT32ってのも、最近ではフラッシュメモリの大容量化で、それなりに拡張されているみたいです。というか、NTFSとかはかなり長い間書き込みとか出来なかったので、無理矢理FAT32を使ってたのではないのでしょうか。
Linuxでもずっと前から読み書きできてましたし、そこのところはみんなそういう実績のあるソースを使っているんじゃないですかね。MSがきちんと仕様を出している（CIFSとかは大例外？）わけじゃないと思うので、ソースから読み取るぐらいの事しか出来ないんじゃないですかね。いちからスクラッチしてもバグ出しが面倒だし、車輪の再発明と言われても仕方ないですしね。
どちらにしてもファイルシステムをソースレベルで考えるのは難しいと思います。
by miff (2011-06-29 19:17)
しかし、それをやるのがまたホビーなのです。
by 7700 (2011-07-01 00:20)
おぉー志が高いですね。ホビーが仕事を上回っちゃうことも多いのが、この趣味の醍醐味ではありますね。
NFSを数年前まで、普通のファイルシステムだと思っていたぐらいなので、ファイルシステムうんぬんは全然分かりません。ext4がSSD対応をしているとか、早いところBtrFSがものになればいいな、ぐらいの私見しかないですね。
by miff (2011-07-03 20:57)