CuBeatSystems

UOS-LPC800

UOS-LPC800を公開してから早くも一年が経ちました。

KOZOS

"BlacKOZOS" - KOZOS for Blackfin

まとめ

「茶室で楽しむKOZOS拡張基板」企画の開催報告です。

2012年09月30日追記：
@kanpapaさんが別途レポートをまとめてくれました。
雰囲気がよく出ているのでそちらもお楽しみ下さい。
ウェブサイトきょうのかんぱぱの「茶室で楽しむKOZOS拡張基板に参加してきました」のページです。

茶室の横を流れる水の音を楽しみながらの開発は、今までに味わったことのない楽しさを提供してくれました。

[フレーム]

NT-Basic on KOZOS(NT-Basicの改良)

SWEST14での刺激を受けた結果、インタプリタの実装に興味が出てきてNT-Basicなるものを出力しました。

それではという事でKOZOSと組み合わせて使おうと思ったのですが、実際にあまり使い勝手が良くなかったのでNT-Basicの改良から行うことにしました。

エディタが必要だ

KOZOS上で実際に動作させる場合、単にファイルシステムからコードを読み込んで動作させるだけでは面白くありません。ターミナルエミュレータから実際にコードを入力して実行するようなインタラクティブな動作を実現したいのです。

この時に必要になるのが実用的なエディタです。入力を間違えても再編集できて、昔ながらのBasicシステムに似たような動作を提供できるのが理想です。viのように本格的なエディタを設計する気分にはなれなかったので、以下のような戦略をとることにしました。

1. 行編集機能はNT-Shellを用いて機能提供する。
2. プログラムは新たに作るtexteditモジュールが保持する。
3. ターミナルにrunコマンドを与えた時点でイタンプリタを動作させる。

こうする事でtexteditモジュールのみを設計実装すれば済みます。
texteditモジュールのインターフェースは以下のようにしました。

int textedit_init(textedit_t *p);
int textedit_clear(textedit_t *p);
int textedit_insert(textedit_t *p, const int line_number, const char *text);
int textedit_delete(textedit_t *p, const int line_number);
int textedit_fetch(textedit_t *p, const int line_number, char *text, const int maxsize);

NT-Basicはプログラムを文字列として受け取ります。
エディタを設計するならば、内部データは双方向リンクリストで構成する行データの集合として表現したいのですが、NT-Basic側の都合に合わせて単純な一つの文字列で複数の行編集が可能なtexteditモジュールとして設計しました。

これでプログラムの編集は実現できます。

プログラムエラー発生時の挙動修正

初版のNT-Basicでは、プログラムエラーが発生した時に最終的にハードウェア抽象化層のhal_halt関数を呼び出していました。この関数は無限に処理を返さない関数として実装する事を想定しており、「プログラムエラー＝処理を永遠に返さない」というあんまりな挙動を提供する結果を生んでいました。

「それはないだろう」という事で、エラーを検出した時点で、そこから最終的にntbasic_executeまでエラーを伝搬させるようにしました。HAL層にhaltがあると意味がわからないので、hal_haltは削除しました。ちなみに、c89で上位にエラーを伝搬させるのは丁寧に実装するしかない、みたいな感じの実装になっています。

上位でエラー発生時の行番号の取得も可能です。

NT-Basicの実行方法

初版の実装でもう一つ致命的に使いにくいのが、実行方法でした。ntbasic_executeは、実行したらプログラム終了まで処理を返さないという仕様だったのです。が、これではベアメタルシステムで使いにくくて仕方ありません。NT-Basicでチョコチョコ処理をしながら、別の作業をさせたい事もあるわけです。

実際に使ってみると、先ほどのエラー時の挙動と合わせて組み込みシステムで実質使えないような挙動になっていました。

そこで、改良したNT-Basicでは、ntbasic_executeを呼ぶ度に1ステートメントのみ処理するように仕様を変更しました。こうする事でベアメタルシステムでもNT-Basicを導入しやすくなります。

 ntbasic_t ntbasic;
 ntbasic_error_t error;
 /*
 * Setup and execute.
 */
 error = ntbasic_setup(&ntbasic, program);
 while (error == NoError) {
 error = ntbasic_execute(&ntbasic);
 }
 /*
 * Check the termination code.
 */
 if (error != EndOfTheProgram) {
 core_error_message(&ntbasic, error);
 }

上記のような簡単なコードを上位に加えれば従来のような使い方もできます。

辛かった変数名の制限

最初の実装では変数名はAからZまでの26文字という小さなBasicではありがちの制限を持っていました。

実際にプログラムを組んでみるとわかるのですが、これがかなり辛い制限です。
「あれ？この変数は何を入れてるんだっけ？」みたいにすぐに迷子になれます。
「えーと、Rはアレの略にしたから・・・、で、Aは・・・何だっけ？」みたいに脳内記号表を使う羽目になるわけです。本来、これは機械にやらせるべき作業内容です。

そこで、自由に変数名を付けられるような仕様変更を行いました。


内部設計と実装は至ってシンプルです。
小さな記号表モジュールを作って対応しました。

記号表の考え方は非常に面白いものです。
ここでハッシュ法を使った動作を簡単なモデルで紹介しましょう。

ハッシュ法を用いた記号表の実現

記号表は、変数名や型、長さやその他属性を管理するテーブルです。
NT-Basicの場合、変数は内部的にintしか持たないので型や長さは存在しません。
記号表における一番シンプルな例という事になります。

で、与えられた変数名から実際の値を取りだす場合、テーブルを探索する事になります。
線形探索した場合、最悪の場合テーブルのサイズ分の文字列比較作業が必要になります。


上記の図でGHIという変数を探索した場合、先頭から3番目で探索完了になりますが、実際にテーブルの最後に存在した場合、テーブルサイズ分の探索作業を行なう事になります。

これでは変数にアクセスする度に膨大な時間が必要になるので効率的とは言えません。
そこで考えられたのがハッシュ法です。

基本的な考えは非常にシンプルです。

まず、与えられた文字列から導出可能なハッシュ値を得ます。
このハッシュ値は文字列から得られる値で、同じ文字列からは毎回同じ値が得られます。


次に、この得られたハッシュ値を元にテーブルの参照先インデックスを決定します。
例えば、参照先インデックスとして28という数値が得られたら、記号表のインデックス28を参照するという仕組みです。

有限長のテーブルの場合、「参照先インデックス % テーブルサイズ」などとして参照先インデックスを決定します。


整理すると「文字列からハッシュ値」、「ハッシュ値からテーブル参照先インデックス」という過程で、変数名を与えるだけで一意に決まる(ように見える)インデックス番号が求まりました。

さて、ここで疑問が沸いてきます。
仮にテーブルのサイズが16だったとして、ハッシュ値0と16の結果はどうなるでしょうか？

先ほどの例では「参照先インデックス % テーブルサイズ」なのでテーブルの参照先がどちらも0になってしまいます。

変数名として与えられた文字列が異なるものなので、理想的には得られたハッシュ値は異なる結果となります。それにも関わらずテーブルの参照先が同じになってしまいました。

安直な実装の場合、参照先インデックスに格納されている変数名と照合して、合致すれば期待する変数が格納されているものとして処理します。

そして、期待する変数名でなければ近い位置のテーブルを探します。
これにより、線形探索よりも遥に少ない処理で期待する変数値を得ることができます。

実際には、ハッシュ値自身の衝突も考える必要があります。
ハッシュ値自身の衝突の場合も、上記のように期待する変数でなければ近い位置のテーブルを探索するという方法を取ります。

ちなみに、流石に上限なしで対応させるとメモリが幾らあっても足りないので、デフォルトの定義では変数名8文字、変数32個までにしてあります。これはヘッダファイルを書き換えるだけで大きくする事ができます。組み込むシステムに合わせて定義を修正すれば良いでしょう。

この改良によって、以下のようなプログラムが見違えるように判りやすく書けるようになります。
以下はアリスとボブとキャロルの年齢を総計として出力する例です。（ちょっと無理矢理な例）

改良前

INPUT "A=",A
INPUT "B=",B
INPUT "C=",C
T = A + B + C
PRINT "T=",T

改良後

INPUT "Alice=",Alice
INPUT "Bob=",Bob
INPUT "Carol=",Carol
Total = Alice + Bob + Carol
PRINT "Total=",Total

まとめ

今回は小規模組み込みシステムで楽しむためのNT-Basicの改良として、実行方法、エラー時の挙動、変数名の制限について改良した内容について示しました。

ちなみに、NT-Basicは総行数が約2000行とコンパクト。
1人で簡単に読み切れるサイズです。

--------------------
LinesFile
--------------------
438core.c
281expression.c
109hal.c
106main.c
157ntbasic.c
269ntlibc.c
443statement.c
111tinyrand.c
135variable.c
--------------------
2049Total

最新のリリースは以下からダウンロードできます。
http://shinta.main.jp/firmware/ntbasic/ntbasic_ja.html

いよいよ2012年9月29日に「茶室で楽しむKOZOS拡張基板」を開催します。

例えばどんな事ができる拡張基板なのかイメージが掴んで頂く為に、応用例としてミュージック・プレイヤーを仕立ててみました。

[フレーム]

アプリケーションはブートローダ経由でDRAM上に展開してブートしています。
SDカードからブートできるのでパソコンなしでKOZOSの実行が可能！

ブートローダもアプリケーションもソースコードを公開しますので御安心下さい。
どんどん改造して自分好みに仕立て上げる事ができます。

既に定員に達している本企画ですが、見学も大歓迎です。
http://atnd.org/events/30481で見学希望の旨を書いて登録して下さい。

先のツールとの関係

「KOZOSのタスク間通信を可視化するツールを作ってみた (ipcrvt.sh : KOZOS IPC Relationship Visualization Tool)」でも取り上げたように、リアルタイムシステムでは、ある作業単位を設計し、タスクに落とし込んでいく形でシステムを実現するのが通例です。

先の記事では、タスク間通信の関係を実装から簡単に明らかにする方法を紹介しました。
タスク間通信の関係が明らかになることで、システムの中の複数のモジュールの依存関係が明確になり、システムに与える刺激（入力）とシステムから得られる反応（出力）を推測できるようになります。


先のタスク間通信の関係を明らかにするツールは、あくまでもソースコードから得られる静的な情報を基にしたものでした。
実際のリアルタイムシステムの場合、複数のタスクの相互関係性が常に変化するため、ソースコードから得られる静的な情報だけでは、見て取れない動作が膨大に存在します。

そこで、今回は上記の可視化ツールに加えて、実際のシステムの挙動を観察する事のできるロギングツールを設計実装しました。

Natural Tiny Logger (NT-Logger)の特徴

本ツールの特徴を挙げます。

• シリアルポートのある組み込みシステムなら、どんなシステムでも使用可能。
• 組み込みシステム側に巨大なメモリが不要。
• 記録時間はホスト側のストレージの容量に依存。長時間の記録が可能。
• シンプルな設計で移植や改造が容易。
• ホスト側プログラムはWindows, Mac OS, Linuxと3つのプラットフォームに対応。

数年前(2010年前半頃)にTOPPERSプロジェクトのTrace Log Visualizerを使用したのですが、その時からNT-Loggerのプロジェクトがスタートしました。 Trace Log Visualizerは、ターゲット側のメモリにイベント情報を記録し、あるタイミングでホスト側に記録したデータを出力するという仕組みでした。この場合、ターゲット側に巨大なメモリが存在していなくてはならず、TOPPERSのように小規模組み込みシステムで使用したいOSのロギングツールとして魅力をあまり感じませんでした。

Natural Tiny Logger (NT-Logger)の原型は当時にあったのですが、先にNatural Tiny Shell (NT-Shell)の設計実装を開始したのでなかなか手が回りませんでした。

Natural Tiny Logger (NT-Logger)の対象外

NT-Loggerは、上記に記した特徴示すと同時に、幾つかのトレードオフについてユーザに説明する必要があります。

• ターゲットとホスト間の通信経路においてのバッファリング等による遅延などの影響は考えない。
• ターゲットとホスト間の通信経路に存在するであろうバッファリング等による遅延やジッタの影響は、測定対象単位時間に対して十分に小さく無視できるものとして扱う。
• 絶対時間情報を必要とするようなデバッグには使用できないが、メッセージパッシングで駆動するリアルタイムシステムにおいて、通常は因果関係が明らかであるので問題ないものとして扱う。
• 非同期システムのデバッグに使用できない事を意味するが、因果関係のはっきりしないような不確定要素を含むリアルタイムシステムは、そもそも設計してはならないものとして、これを無視する。
• ロギングのためのオーバーヘッドは無視できるほどに小さいものとして扱う。

中には少し過激なトレードオフに見えるものもあるかもしれません。
これはNT-Loggerが「無いより遥かに便利！」、「しかも無償で使える！」というところを念頭に置いているからです。

「そんなロギング意味がない！使い物にならない！」というケースでは、こんな中途半端なツールは使うべきではないでしょう。それは、NT-Loggerがとったトレードオフに含まれる種々の問題を解決したツールを使うべきです。というのが、NT-Loggerの立場です。

どんな組み込みシステムでも使える

組み込みシステムの全体挙動を確認するためのツールは、市販品を中心に星の数ほど存在します。
多く見られる実現形態の一つが、ターゲットとホストの間に専用のハードウェアを介入させて、忠実にイベントをロギングする形態です。
確かに忠実なイベントのロギングには、これが一番信頼性の高い方法でしょう。
中間装置が正確な時刻情報を付与すると共に、データをバッファリングし、ホストコンピュータの処理能力に影響されずに正確にロギングする事ができます。

これらの中間装置を必要とするロギングツールの場合、導入コストがかなりかかる事が多いです。
実際の開発では、システムの全体挙動の概要を確認するだけで、どんな問題があるのかわかる事も多々あります。少し調べたいだけの時に高価なロギングツールを購入できるかどうかは状況によります。


先のトレードオフでも述べたとおり、組み込みシステムの場合はイベント駆動型で設計するのが普通のアプローチです。あるイベントがある動作を引き起こすという因果関係を明らかにするのと同時に、 原因と結果の依存関係を緩い依存関係で留める事ができるわけです。


NT-Loggerは、多くの組み込みシステムに搭載されているシリアルポートを有効に活用し、必要最低限のロギング機能で最大限の効果を挙げることを目的に設計されています。因果関係が明らかになっている組み込みシステムの場合、簡単なロギングメカニズムを追加するだけでも十分な効果が得られるというわけです。

設計と概念など

基本設計と概念

• イベントは、「イベント発生源」から発生する。
• イベントは、イベント情報で表現される。
• イベント情報には、「始まり」と「終わり」を示す「タイプ番号」がある。
• イベント情報には、「イベント発生源」を示す「トラック番号」がある。
• イベント情報には、イベント内容を示す「イベント番号」がある。
• ターゲットから送られるイベント情報には、「トラック番号」と「イベント番号」と「タイプ番号」が含まれる。
• ホストは、ターゲットから送られるイベント情報に時間情報を付与して記録する。
• ホストは、記録されたデータを基にした可視化データを生成する事ができる。

NT-Loggerの使用手順

• ターゲット側プログラムにロギング用APIを埋め込み動作させる。
• ホスト側でキャプチャプログラムを実行する。
• キャプチャされたデータからHTMLを生成するジェネレータを実行する。
• ブラウザで結果を確認する。

仕様

• 最大トラック数は16トラック。
• 1トラックあたり8つのイベントを記録可能。(単純計算で16x8=128事象が扱える事になる。)
• 記録イベントの分解能はマイクロ秒単位。
• RAMが1KBを切るようなシステムでも使用可能。
• ターゲット側は最小限のAPIの実装のみで移植可能。
• データはブラウザで閲覧可能。

今後の計画

現在初版のリリースに向けて作業を開始しています。
暫くこのブログもNT-Loggerまみれにしようと考えています。

一点一点お家で手作り

ATNDで大募集していた「茶室で楽しむKOZOS拡張基板」 の実装を完了させました。
ミスタードーナツさんではないですけど、本当に一点一点お店で、じゃなくてお家で手作りしました。


この基板は、総部品点数が68で、半田付け箇所は300箇所を超えます。
今回は10台製造したので、総部品点数は680個、半田付け箇所は3,000箇所を超えるということになります。これはしんどいわけです。

たった10台、されど10台。
意外に動作確認も大変なのでブートローダ側も機能検証用の機能を盛り込みました。
スタートアップ時の動作を見ると基本機能が動作しているのかわかる仕組みです。

LEDを点灯させ、音声を出力し、SDカードの有無を検出し、SDカードからデータを読み、ディスプレイに表示を行ない、と初期化の後であれこれのデバイスを使うようになっています。

ブートローダの段階で基板の基本機能検証ができますから、わざわざOSをブートさせなくても済むという仕組みです。

後はエイジングと最終機能検証を行って、「茶室で楽しむKOZOS拡張基板」 に挑む事になります。

この基板実装を外注に出した時の試算

これを外注さんに出した時の事を考えて（出す予定はありませんけど）、P板さんの実装サービスで試算してみました。



なるほど。
昨今、思ったほどの驚き価格ではないのですね。

パッケージ

ちょっと余談ですが、半田付けに飽きた時に現実逃避でパッケージも考えました。
皆様にお届けするのに「基板だけぽーん」とか「段ボール箱にボコン」なんてしません。



こんなパッケージに収めて参加者の皆様にお届けします。
お楽しみに！

概要

先週はKOZOS EXPBRDのサンプル・ファームウェアを設計と実装を行なっていました。

サンプル・ファームウェアでは、SDカード上にあるmp3ファイル読み込みながら、mp3デコーダを制御し、赤外線リモコンやユーザ入力を受け付け、ディスプレイの表示をし・・・と沢山の仕事をKOZOSを使ってこなしています。


組み込みシステムでは、システムが提供する機能をある処理単位に分け、複数のタスクに分割した上で所望の機能を実現するために協調動作させるように設計します。
一見複雑な制御も、単純な動作になるまで分けて考えていく事で設計と実装を容易にする事が出来ます。

組み込みシステムの場合、ある出来事（イベント）を中心に動作を実行するイベント駆動型としてファームウェアを設計するのが通例です。タスクは基本的に他のタスクから受けたイベントを起点に動作します。あるタスクが他のタスクにイベントを伝える事を、「タスク間通信(Inter Process Communication)」と言ったり、OSによっては「メッセージ・パッシング」と呼びます。

上記のように設計する事で、タスクとタスクの間の依存関係は非常に緩いものにする事ができる他、新たな機能を付け加えやすくなったり、デバッグが容易になったりします。

しかし、設計文書でいくら図示してあったとしても、実際にコードに落とし込んだ段階でそれらの情報は失われてしまうため、後からコードを見た第三者がファームウェア全体の挙動を把握するのには非常に時間がかかります。

今回は、このような時に便利な方法として内部タスク間コミュニケーションを可視化するツールを作ってみましたのでご紹介します。

今回は茶室で楽しむKOZOS拡張基板の企画もあるので、KOZOSを題材に実装してみました。

実例1

KOZOSの作者である坂井さんがお作りになったTCP/IPアプリケーションを題材にしました。
http://kozos.jp/kozos/h8_2_06.html

まずは下の図をクリックして大きくしてご覧下さい。


KOZOSのタスク間通信は、kz_sendとkz_recvとkx_sendから構成されています。
図を見てわかるように、タスク(及びそれっぽいもの)が丸枠で囲われたもので表現されています。
メッセージ通信の橋渡しとなるメッセージボックスが長方形で表現されています。

それっぽいものと書いたのは、ソースファイル名で抽出しているので必ずしもタスク名とイコールでないこともあるからです。

上記を見てわかるように、ソースコードを眺めて関係性を把握するよりも遥かに直感的です。
実行方法は簡単でシェル・スクリプトをKOZOSアプリケーション・ディレクトリで実行するだけ。

実例2

ちなみにKOZOS EXPBRDのサンプル・ファームウェアにも適用してみました。
こちらは少し改造したシェル・スクリプトですが、だいたい同じものです。


こんな感じでKOZOSで構成した各タスク間のタスク間通信の関係をひと目で把握できます。

実行方法

リソースからサンプル・コンテンツをダウンロードして下さい。
ipcrvt.shをKOZOSアプリケーション・ディレクトリで実行して下さい。
外部依存は幾つかのコマンドとGraphviz/dotのみ。
簡単なシェルで構成されているので改造も容易です。
オプションは取りません。

リソース

ipcrvt.tar.gzをダウンロード

まとめ

現状のipcrvt.shは、まだまだ表示したい情報が欠けいていますし、随分と荒削りな設計と実装です。

しかし、ソースコードを目視で把握するよりも遥かに早いスピードで関係性の概要を把握する事ができるという点で、第1段階のアプローチとしてはまずまずな結果と言えるでしょう。
このツールを使って関係性の概要を把握した上で、ソースコードを読み解いていけば理解が素早く理解を深める事ができる気がします。

また、組み込みシステムで特に意識する必要のあるタスク間通信の学習においても、有用なツールの一つとして役立てることができそうです。

今回はKOZOS向けにシェル・スクリプトを構成していますが、同様の考えを使って他のRTOSでも使用する事ができます。

KOZOS EXPBRD #00のハードウェアデバッグのためにジャンクコードを量産しましたが、
集大成として（←何の？）ニジマス君をロータリーエンコーダーを使って動かすテストをしました。

まぁ、テストというよりもネタです。
すみません。

[フレーム]

SDカードからブートできるようになったので、パソコンいらずでKOZOSを起動させる事ができます。
テストプログラムでは、DRAMを使っていますので巨大なプログラムでも余裕でロード可能。

mp3デコーダチップを使ってスプラッシュサウンドを出力したり、赤外線リモコンを使えます。
ありきたりですがmp3プレイヤーとかを作ってみるのが楽しいかも。

デバッグ用の基板実装にスイッチサイエンスさんから入手したリフローグッズを使おうと思ったのですが、「部品実装のデバッグ」より「基板設計のデバッグ」を優先させたので、結局できませんでした。

何台か作る時には是非試したいなぁ。

今回はチマチマと部品を付けながら暢気にデバッグしたのですが、
最後まで残ったデバイスの動作確認を完了し、大きなバグもなく一安心となりました。


ハードウェアデバッグ用にジャンクコードを量産したので気持ちが悪くなっています。
ハードウェアは問題なさそうなので、今度はファームウェアの設計です。

今回のボードの主な搭載部品をもう一度挙げておきます。

• 122x32ドットのモノクロ・グラフィック・ディスプレイ
• マイクロSDカード・スロット
• 2つのLED
• 2つのスイッチ
• ロータリー・エンコーダー(赤と緑のLEDを内蔵、プッシュスイッチ付き)
• mp3エンコーダー・チップ
• ステレオ・フォン・ジャック
• 赤外線受光素子

合体させる側のボードにはLANも付いているので色んなアプリケーションが考えられます。
こうなると下回りをきちんと整備する事がポイントになってきますね。

「KOZOS EXPBRD #00でKOZOSをしゃぶりつくそう！」みたいな企画も考えています。
どこでどんな風にやろうかなぁ。

あと、どうでも良いのですが・・・。
今度からプロジェクト名に#記号は使わないでおこうと思います。
これは今回の反省点。

Twitterではハッシュタグとして間違えられるし、TracやRedmineではチケット番号として扱われてしまいます。
正しく名前を書こうとして意図していない結果を生むのも考えものです。

KOZOS EXPBRD #00には、SDカードスロットがあります。
設計当初からKOZOSを単独稼働システムとして楽しめるようにしたいなぁと考えていました。

従来はパソコンからブートローダ経由でOSイメージをRAMに転送して実行していたわけです。
この場合、KOZOSを起動するためのパソコンが必ず必要です。
これでは、組み込みシステムとして稼働させるために隣にリッチなパソコンが存在するという矛盾した状況を生んでしまいます。せっかく組み込みの雰囲気を楽しんでいるのに、少し残念な感じがします。

そこで、SDカード系統のハードウェアデバッグも兼ねてSDカードブート機能を実装してみました。
下の動画でSDカードブートの様子を御覧下さい。

[フレーム]


パソコンなしでもリセットスイッチを押すだけでOSイメージをRAMに展開して実行してくれます。
まさにデモする時にボード一つで実行可能。
実際の組み込みシステムの雰囲気に近づくというわけです。

KOZOS EXPBRD #00には、LCDもスイッチもLEDもあるので、複数のブートイメージを用意しておいて、ユーザインターフェースを使って起動モードを選択させたりといった事もできるでしょう。

ちなみに、FATファイルシステムはChaNさんのPetit FAT File System Moduleを使用しています。
うーん。ありがたやありがたや。

先日の記事で取り上げたKOZOS EXPBRD #00ですが、基板も上がってきてユルユルとデバッグしています。

• 122x32ドットのモノクロ・グラフィック・ディスプレイ
• マイクロSDカード・スロット
• 2つのLED
• 2つのスイッチ
• ロータリー・エンコーダー
• mp3エンコーダー・チップ
• ステレオ・フォン・ジャック
• 赤外線受光素子

XMODEM for KOZOS (12ステップで作る 組込みOS自作入門 KOZOS用ユティリティ kz_xmodem)を実装したことで、kz_h8writeとあわせてKOZOS用ユティリティが2つになりました。

ダウンロードはプロジェクトページからどうぞ。
http://sourceforge.jp/projects/kz-h8write/
http://sourceforge.jp/projects/kz-xmodem/

kz_h8writeとkz_xmodemは、Mac OS、Linux、Windowsで動作するように実装してあります。
ただ、あまり積極的にテストしていなかったので、2つのツールが揃ったところでまとめてテストしました。

• それぞれのバイナリは2012年04月29日現在のコードから生成したものを使用しています。
• Mac OSには10.7.3、LinuxにはUbuntu 11.04、WindowsにはWindows 7を使っています。
• 各環境で特別な手順を踏まずに手に入るビルド環境を使っています。

OS	kz_h8write	kz_xmodem
Mac OS
Linux
Windows

2種類のソフトウェアを3つの環境で動作させるわけですから意外に手間がかかります。
クロスプラットフォームともなると自動テストというわけにもいきません。
ターゲットボードにあるスイッチを切り替えなければならないとなればなおさらです。

それでも自分で確認しておくと安心度が違います。
これからもこういった動作確認の報告はしていきたいところです。