KOZOSのブートローダー、のソースコードの検証 [プログラミング]
って言っても、大した事はやらないです。下のページを見て納得するだけです。
http://monoist.atmarkit.co.jp/mn/articles/1106/14/news001_2.html#tbl75c
ここからの続き。
それまでの状況ですが、動作確認は終わりました。電気がコネクタのせいで来なかったり、そもそもMac自体のUSBシリアルコンバータの認識が上手くいってなかったり、なぜかそのシリアルUSBが、VirtualBoxから見えず使えないで、両OSとも再起動したり、何となく動かない感じがずっと続いていてやめようかと思った。でも動くのが分かったので、ゆったりとソースを読む気にもなりました。ぷつんと切れる前に成功して良かった。
今回のケースを良く考えると、ちょっとしたネットワークブートみたいな感じですね。シリアルを通じてOSをもらって、ブートローダーだけが離れたボードで動くっていう形になっていました。OSをコンパイルする度にフラッシュメモリに書き込んで、残り書き込み回数を減らす事になりますし、フラッシュメモリに全部載っけただけでは動かず、結局使う時にはRAMに入れなきゃならないので、こういう形はボードを最後まで使い倒そうと思ったら必須のやり方なのかも、と思いました。
他のH8マイコン用の本を買ったのですが、そっちはLinuxをムリヤリ載っけようとしていて、途中で色々面倒くさくなってしまってやめていました。ボードの不具合がどうも出まくったらしいのですが、今回もその片鱗を見せていてちょっと恐いところです。
今回の再挑戦は、イーサネット部分まできっちり使いたいものです。最終的には、ネットワークサーバが出来るそうなので、プアでも何か便利に使えるものを妄想しているところです。TCPのプロトコルスタックさえ使えれば、後は容量の許すまで頑張れそうですね。気合い入れたら、C言語をきちきちになる書き方で、目がつまったバイナリにして動かしたいなぁ。どうせデバッグしないので、頑張って最大容量まで突き詰めたい気持ちでいっぱいです。ってRAMってどのくらいあったんだったっけ。
んでブートローダーだけれども、今まではシリアル通信を全くの生の状態で使って、ボードの方からHello Worldを出力していたけど、今度はXMODEMという簡便なプロトコルを使って、OSを入れ込んでいるようです。他の本ではtftpとかで入れ込んでいたと思ったんですが、それより容量が少なくて済みそうですね。そんでRedBootとか使ってた気がします。
今回はTCP/IPまでフルスクラッチするってことらしいので、ちょっとワクワクしてます。そういうところって、ほとんどが既にライブラリが用意されているので、プロトコルから送信するデータまでを扱うってのは、なかなかないんじゃないだろうか、と思います。上の本は、Linuxを入れるメリットとして、既存のTCPのプロトコルスタックとかが使えてうれしい、ってのが理由の一つになっていたようですが、今回のはプロトコルは全部自分で実装しているのだそうで、あんまり長くないソースでOSの根幹を知る事が出来るのはうれしい限りです。大抵のライブラリはエラー処理とか、他の処理が入って来たりしていて、素直に読めないばかりか、ソースが長過ぎてウンザリする事が多いですしね。
ブートローダーってのは、いわゆるBIOS的な部分じゃないかと思います。普段のOSだと立ち上げの時にちょっとだけ見えるBIOSですが、ブートローダーとBIOSの機能を引き受けている感じがします。どこまでBIOSとか言われると困るけど、OSと切り離すためには良さげな半固定な部分、だと思います。普通のパソコンでもBIOSはフラッシュメモリに書き込めるけど、そんなには変更したりはしない、というところは似ているかなと思うのですが。
http://monoist.atmarkit.co.jp/mn/articles/1106/14/news001_2.html#tbl75c
xmodem.cはまんまXMODEMプロトコルの実装。serial.cのところで、1バイトずつポイポイ拾っていけばいいだけみたい。H8_3069F_SCI_SSR_RDRFっていう終了するデータが来たら受信を終わりにします。どうにもXMODEMのPC側のクライアントソフトの出来が悪いので、XMODEMはあんまり使いたくなくて、どうにかしたいとは思っています。イーサがあるので、TFTPとか使うんかな、やっぱし。
次はELFですか。これをOSと見立てろってことらしいですが、見立て好きの日本人でもなかなか厳しいです。
http://monoist.atmarkit.co.jp/mn/articles/1106/14/news001_3.html
大体、Linuxはバイナリがこの形式みたいですね。ブートローダーはelfから、モトローラな形式に変えていましたけど、OSの方はelfのまんまなのかな? きちんとMakefile読んでないので何とも言えんのですが、stripっていうコマンドで、elf形式のファイルをオブジェクトファイルのシンボルを削るものらしいです。何やってるんだかいまいち分からんけど、シンボルを剥いた分、ファイルが小さくなっているのは分かります。動作のためにはelfほど情報が必要じゃないってことなんでしょうかね。GNUのツールらしいです。今まで知らんかったかも。
あと気になるのが、重複したコードがあること。lib.cとかは仕方ないとはいえ、serial.cとかはどっちも使うのは分かるけど、どっちにもあると冗長っぽい気がしてしまう。ブートローダーに頼むような形式にはしない方がいいんだろうか。そのうちKOZOSのサンプルソースを見ていけばはっきりするとは思うけど、何となく同じ事はしたくないなというだけの話。まぁブートローダーにしてみれば、OSに立ち上げ部分を実行できるようになってもらえば、重複しようが別に関係ないという気もする。それに外から見えるように関数を可視化するのは、恐らくstripで除いてしまっているのでしょうしね。OSのデータをRAMに展開する前の、受け渡し関係が出来れば、何も問題ないのかもしれない。
今回のソースコードは、前回とかぶるところが多かったので、あんまり話す事はないです。ブートローダーってのは、組み込みでは大切なんだなぁという事ぐらいしか分かってません。
http://monoist.atmarkit.co.jp/mn/articles/1106/14/news001_2.html#tbl75c
ここからの続き。
それまでの状況ですが、動作確認は終わりました。電気がコネクタのせいで来なかったり、そもそもMac自体のUSBシリアルコンバータの認識が上手くいってなかったり、なぜかそのシリアルUSBが、VirtualBoxから見えず使えないで、両OSとも再起動したり、何となく動かない感じがずっと続いていてやめようかと思った。でも動くのが分かったので、ゆったりとソースを読む気にもなりました。ぷつんと切れる前に成功して良かった。
今回のケースを良く考えると、ちょっとしたネットワークブートみたいな感じですね。シリアルを通じてOSをもらって、ブートローダーだけが離れたボードで動くっていう形になっていました。OSをコンパイルする度にフラッシュメモリに書き込んで、残り書き込み回数を減らす事になりますし、フラッシュメモリに全部載っけただけでは動かず、結局使う時にはRAMに入れなきゃならないので、こういう形はボードを最後まで使い倒そうと思ったら必須のやり方なのかも、と思いました。
他のH8マイコン用の本を買ったのですが、そっちはLinuxをムリヤリ載っけようとしていて、途中で色々面倒くさくなってしまってやめていました。ボードの不具合がどうも出まくったらしいのですが、今回もその片鱗を見せていてちょっと恐いところです。
今回の再挑戦は、イーサネット部分まできっちり使いたいものです。最終的には、ネットワークサーバが出来るそうなので、プアでも何か便利に使えるものを妄想しているところです。TCPのプロトコルスタックさえ使えれば、後は容量の許すまで頑張れそうですね。気合い入れたら、C言語をきちきちになる書き方で、目がつまったバイナリにして動かしたいなぁ。どうせデバッグしないので、頑張って最大容量まで突き詰めたい気持ちでいっぱいです。ってRAMってどのくらいあったんだったっけ。
んでブートローダーだけれども、今まではシリアル通信を全くの生の状態で使って、ボードの方からHello Worldを出力していたけど、今度はXMODEMという簡便なプロトコルを使って、OSを入れ込んでいるようです。他の本ではtftpとかで入れ込んでいたと思ったんですが、それより容量が少なくて済みそうですね。そんでRedBootとか使ってた気がします。
はじめる組込みLinux H8マイコン×uClinuxで学べるマイコン開発の面白さ
- 作者: 米田 聡
- 出版社/メーカー: ソフトバンク クリエイティブ
- 発売日: 2007/04/14
- メディア: 大型本
今回はTCP/IPまでフルスクラッチするってことらしいので、ちょっとワクワクしてます。そういうところって、ほとんどが既にライブラリが用意されているので、プロトコルから送信するデータまでを扱うってのは、なかなかないんじゃないだろうか、と思います。上の本は、Linuxを入れるメリットとして、既存のTCPのプロトコルスタックとかが使えてうれしい、ってのが理由の一つになっていたようですが、今回のはプロトコルは全部自分で実装しているのだそうで、あんまり長くないソースでOSの根幹を知る事が出来るのはうれしい限りです。大抵のライブラリはエラー処理とか、他の処理が入って来たりしていて、素直に読めないばかりか、ソースが長過ぎてウンザリする事が多いですしね。
ブートローダーってのは、いわゆるBIOS的な部分じゃないかと思います。普段のOSだと立ち上げの時にちょっとだけ見えるBIOSですが、ブートローダーとBIOSの機能を引き受けている感じがします。どこまでBIOSとか言われると困るけど、OSと切り離すためには良さげな半固定な部分、だと思います。普通のパソコンでもBIOSはフラッシュメモリに書き込めるけど、そんなには変更したりはしない、というところは似ているかなと思うのですが。
http://monoist.atmarkit.co.jp/mn/articles/1106/14/news001_2.html#tbl75c
xmodem.cはまんまXMODEMプロトコルの実装。serial.cのところで、1バイトずつポイポイ拾っていけばいいだけみたい。H8_3069F_SCI_SSR_RDRFっていう終了するデータが来たら受信を終わりにします。どうにもXMODEMのPC側のクライアントソフトの出来が悪いので、XMODEMはあんまり使いたくなくて、どうにかしたいとは思っています。イーサがあるので、TFTPとか使うんかな、やっぱし。
次はELFですか。これをOSと見立てろってことらしいですが、見立て好きの日本人でもなかなか厳しいです。
http://monoist.atmarkit.co.jp/mn/articles/1106/14/news001_3.html
大体、Linuxはバイナリがこの形式みたいですね。ブートローダーはelfから、モトローラな形式に変えていましたけど、OSの方はelfのまんまなのかな? きちんとMakefile読んでないので何とも言えんのですが、stripっていうコマンドで、elf形式のファイルをオブジェクトファイルのシンボルを削るものらしいです。何やってるんだかいまいち分からんけど、シンボルを剥いた分、ファイルが小さくなっているのは分かります。動作のためにはelfほど情報が必要じゃないってことなんでしょうかね。GNUのツールらしいです。今まで知らんかったかも。
あと気になるのが、重複したコードがあること。lib.cとかは仕方ないとはいえ、serial.cとかはどっちも使うのは分かるけど、どっちにもあると冗長っぽい気がしてしまう。ブートローダーに頼むような形式にはしない方がいいんだろうか。そのうちKOZOSのサンプルソースを見ていけばはっきりするとは思うけど、何となく同じ事はしたくないなというだけの話。まぁブートローダーにしてみれば、OSに立ち上げ部分を実行できるようになってもらえば、重複しようが別に関係ないという気もする。それに外から見えるように関数を可視化するのは、恐らくstripで除いてしまっているのでしょうしね。OSのデータをRAMに展開する前の、受け渡し関係が出来れば、何も問題ないのかもしれない。
今回のソースコードは、前回とかぶるところが多かったので、あんまり話す事はないです。ブートローダーってのは、組み込みでは大切なんだなぁという事ぐらいしか分かってません。
タグ:組み込み
イーサの使い道、うちではプランターの水やりしたり、ドアの鍵の開け閉めをコントロールしてましたよ。
冗長なコード
最初からスクラッチしてるとなかなかないけど、コピペしてくると結構起きますね。容量が切羽詰ったらそういう箇所を圧縮です!
by 7700 (2011-07-03 22:48)
すげー、そこまで出来るんですね、イーサで。データ的に10baseで足りそうですけど。
そういえば、Panasonicだとリモートカメラで家の防犯カメラを付けられて、それをDIGAで録画できるみたいですね。やれば出来るんだろうけど、面倒なので製品として作らない、ってのはたくさんありそうな気がします。
外出先からGコードの数字送って、DVDレコーダーのWebインターフェイスに突っ込むような妄想をしていたときもありました。外から自宅のSSHサーバにつないだりしていると、普通にそういう発想になっちゃうのが危ないです。でも実施能力がないので、苦労しないで済んでますけど。
C言語は案外切り分けが面倒な気がします。オブジェクト指向の言語は案外、切り分け方の常識がある気がしますね。切り分けによって、デザインパターン的なこともあり、考えを共有しやすいですしね。
by miff (2011-07-04 19:10)