WiPort入手しました。

Arduinoハッキングとは別の話で、WiFiシリアルコンバータ+XBeeを使って、汎用外部機器コントローラを作りたいと思っています。
きっかけは、iPhoneラジコンでjailbreakしないと動作しないのが不満だったので、WiFi経由でコントロールしたいなぁ、というところから来ています。
WiFiなら、iPhoneで制御出来ますので、XBeeブリッジを作れば、ラジコンだけじゃなく色々な応用が出来そうです。

WiPortは正にそう言う用途にうってつけです。本当はSparkFunのWiFiシリアルコンバータを入手したのですが、ピンピッチが2mmという特殊なサイズで、Breakoutボードもなく、基板を興さないといけないのがいやで、乗り換えちゃいました。でも、コストはSparkFunの方が安いので、将来はこっちに行くと思います。

これでモバイルエンターテイメントを追求したいと思っています。
これも進捗をアップしていきたいと思います。

AVRマイコン復活基板完成

すごーく時間が経過してしまいましたが、やっと自分の時間をちょっと作れたので、AVRマイコン復活基板をデバッグしました。普及したい側のRESET電圧がとても変だったのではまりましたが、どうやらトランジスタが壊れていたようです。
とりあえず、交換して動くようになったみたいです。(でもH側FUSEビット書き込みエラー表示は消えない・・・。ま、復活しているからいいか。)

で、AVR DRAGONもいるし、再度Arduinoハッキングを開始したいと思います。(ほとんど時間を取れないので、亀のような進捗になりそうですが。)

AVRマイコンでハマってます。

新しくAVR Dragonが来ました。
これで快適なデバッグが出来る！と思ったら大間違い。
debugWireモードでロックしてしまってISPモードに戻せないAVRがすでに3個。
こりゃどうすればいいの？と悩んでいると、高電圧パラレルプログラミングモードで書けば良さそうだとわかりました。
が、あまり情報がないんですね。
でも、一ついいのを見つけました。
「SatE-O　マイコンによるビギナー電子工作」
ドンぴしゃ！感謝です。
これを作ろうと思います。これでゴミ箱行きの予定だったAVR君は復活できることでしょう。
しかし、どこにこのやり方の技術資料が落ちているんだろう？見つからない。
それにしても、簡単にこのモードに陥ってしまう設計に疑問を感じるのは私だけでしょうか？

my Arduino OS計画 #4

AVR mkII Liteというデバッガですが、こいつがハングするとAVRマイコンもISPモードに出来なくなって、使い物にならなくなってしまいます。もう２つも潰しました・・・。
これではあまりにひどいので、ATMEL純正のAVR dragonというのをDigiKeyに発注しました。
これがくるまでは、ちょっと開発はストップしておこうと思います。
ついでにATmega168も発注してしまいました。

my Arduino OS計画 #3

#2で解説したイメージをビジュアル化しました。



あ、そうだ、OSの名前はとりあえず、"laos"(Lightweight AVR OS)としました。これじゃ、ミャンマーって意味になっちゃいますねぇ。あんまり自分的にはしっくりこないのですが、何か名前が欲しかったので、これで行きます。

このOSのキモは、メッセージドリブン+メッセージFIFOです。
ある意味、OSとすら言えないほどシンプルです。

実装について記そうと思ったのですが、ちょっと面倒くさいので、次回に回します。
どうもすみません。

my Arduino OS計画 #2

今、手に入れているAVRマイコンはArduinoと同じATmega168ではなく、ROM容量が半分の8kByteになったATmega88というマイコンです。メモリ容量以外はほぼコンパチですので、これに入れられればATmega168にもスムーズに入ることになります。
なぜ、ATmega88なのかというと、秋月電子で購入できたのがこれだけだったから、というそれだけの理由です。ちなみにクロックは20MHzにしてしまっていますが、Arduinoは16MHzでした。これはチェックし忘れたからです。CPUクロックの違いは主にタイマやUARTなどに影響が出ますが、これは#defineでクリアしようと思っています。

さて、今回はArduinoに入れるOSの基本設計思想(アーキテクチャ)を記したいと思います。このAVRマイコンのメモリリソースはとても十分とは言えないので、ある程度機能を割り切った設計が必要だと考えました。
Overviewは以下の感じです。
・タスク優先度のない疑似マルチタスク(ノンプリエンプティブ)
・多重割込はしない
・リアルタイム性は若干損なわれるが、事象発生順は保たれる
・タスク間のやりとりはメッセージによって通知する(メッセージドリブン)

擬似マルチタスク(ノンプリエンプティブ)とは、複数のタスクを定義することは出来るが、実行中のタスクからOSがタスク優先度的に（あるいは定期的に）CPUリソースを剥奪することはせずに、実行中のタスクが自発的にCPUを解放する、という方式です。
また、タスク優先度という概念も省いて、シンプルな設計にします。

多重割込とは、ある割込ハンドラの実行中に他の優先度の高い割込ハンドラの動作を許可する機能ですが、これも省いて、ある割込ハンドラは最後まで実行させてしまいます。基本的に割込ハンドラの処理はなるべく早く終わらせ、タスク側に複雑な処理を実行させるようにすれば、意外に狙い通りに動作するものです。また、多重割込にしなければ、割込ハンドラが使用するスタック容量も少なくなり、見積もりもし易くなるメリットがあります。さらに、事象発生順も保証することが出来ます。

リアルタイム性とは、ある処理イベントが発生してから、十分許容出来る時間内に必要な処理を実行できる、というものです。例えば、車のアンチロックブレーキシステムの場合は、タイヤがロックしてから数十msecでポンピングブレーキングを実行できなければ、重大な事故に繋がることになります。この許容時間内に処理を実行できる保証がリアルタイム性です。今回は擬似マルチタスクであることからも、タスクがCPUを解放するまで次のタスクには回ってきませんので、実装次第では、全然リアルタイム性が損なわれる可能性がありますが、そこはそれを意識して実装すれば、そこそこのリアルタイム性は保持できます。また、事象(イベント)発生順を保持する仕組みとしては、イベント(タイマ、AD変換、端子状態変化などの外部イベントや、あるタスクが他タスクに通知する内部イベント)をタスクに通知する際、共用のFIFOにその通知を入れていく仕組みにすることで、発生順番が保証されるようにします。

メッセージドリブンとは、タスク間の通知の方式としてメッセージという一意に決まった形をとることにより、タスク処理を起動する方式です。マルチタスクではタスク間通知の方式は、イベントフラグやセマフォ、メッセージプールなどを使うことが通例です。今回のOSではメッセージプールをFIFOで制御することにします。このようなアーキテクチャによって、タスクの構造は次のようになるはずです。

　1.メッセージを待つ。
　2.メッセージを処理する。必要なら他タスクにメッセージを発行する。
　3.上記1.に戻る。

このデザインパターンにより、タスク設計が見た目にもわかりやすく、バグが発生する可能性を下げるメリットがあります。
タスク優先度のない擬似マルチタスクを採用するので、タスク切り替えはタスクが次のメッセージを待つ時に発生します。

μitronなどのプリエンプティブなOSを利用する場合は、シンプルとは言え、それなりのメモリリソースが必要となりますが、今回のOSのようなアーキテクチャにすることで、メモリリソースはそんなに心配しなくて済みます。実際、基本的なメッセージFIFOによるタスク切替の実装は、ROMが8kByteの内5%程度、RAMが1kByteの内10数%で済む(FIFOの段数に依存)ことになりそうです。また、タスクスイッチの時間も、シンプルな設計なので、μitronに比べてかなり高速になります。

次回は、このアーキテクチャの実装を具体的に記したいと思います。

ジャジャ馬 AVR mkII Liteデバッガ

今回購入したAVR mkII Liteデバッガはかなりのジャジャ馬(それとも駄馬?)であることがわかりました。
無邪気に動かしても、AVRマイコンと接続できないでハマってしまいます。
これは備忘録に残しておかないと、しばらくすると忘れちゃうでしょうから、ちょっと記録しておきます。

まず、Mac上のWindows(Parallels Desktop for mac)から動かせるか？ですが、動かせます。
ていうか、私が動かした限り、ピュアWindowsマシンと振る舞いは変わらなく見えます。
つまり、Windowsマシンでもハマるということです。

では、動作させてみます。
まず、初めての書き込みは説明書通りに行えば、意外にあっさり行くと思います。
まぁ、説明書のPDFは、Ver4.14のAVRStudioの画面ではなく、もっと前のバージョンの画面で説明しているので(さすが安物、こんなところにも質の低さが露呈しています。)、なんとなく想像するしかありません。
ネットで調べてみると、このAVR mkII Liteの筐体が全然違うので、最近モデルチェンジしたのでしょう。なので、それらとは振る舞いが違う可能性があります。$45→$39にコストダウンしたからかもしれません。
書き込みは、"STK500 or AVRISP"を選択しないと動きません。間違っても、"JTAG mkII"を選択しないことです。まずはここでハマることでしょう。

さて、1度書き込みが終わると、デバッグモードにしたくなります。
ここで、キーポイントは、ターゲットの電源OFF/ONです。これをやらないと一生うまく繋がらないと思います。
まず、"Start Debugging"をアイコンからクリックします。
1回目はいきなり以下のダイアログが出ます。

これはマニュアルにはない、ダイアログです。ここではキャンセルを押します。OKを押してもFirmwareアップデートに失敗した、と言われるだけで終わってしまいます。
で、このダイアログをキャンセルすると、右下のステータスバーで以下の表示が6回ほどトグルするので、灰色の表示になるまで放っておきます(15秒くらいかな)。


で、もう1回"Start Debugging"を選択します。
次は、以下のようなダイアログが出ます。"JTAG mkII"と、使うAVRマイコンを選択し、"Finish"を選択します。

この後、1回目で出たダイアログをキャンセルすれば、うまくいけば、これでデバッグモード状態になるはずです。
ここでうまくいかないときは、一旦ターゲット電源をOFF/ONして、同じ操作を繰り返します。

途中で、以下のダイアログが出ることがあります。

この時は、"Use SPI to enable debugWire interface"を選択します。すると、次のダイアログが出ると思うので、再試行ボタンを押す前に、ターゲット電源をOFF/ONします。

これで、たぶん接続できます。あー、面倒くさい！
デバッグでソースを修正したときは、上記操作を繰り返すことになります。

再び書き込みモード(ISPモード)にするときは、メニューの"Debug"から、"JTAG mkII Options"を選んで、出てきたダイアログで"disable debugWire"を選びましょう。これを忘れるとISPモードで通信エラーとなって、書き込みが出来ないです。当然、接続すら出来ません。
その次に、ターゲット電源を必ずOFF/ONしてください。


どうですか?使いこなせますか?
ちなみに私はここまで押さえるのに丸一日かかりました。トホホ。
こんなに使いづらいデバッガは初めてです。
このデバッガを使う人は覚悟した方がいいです。
一応、お断りしておきますが、このやり方は私の環境で、ということですので、他の人はもっとスムーズに動くかも知れないし、もっと動かないかも知れません。

これからこんなデバッガを使うのかと思うと、気が重いです。orz