Mac OS X用BELKINシリアルアダプタドライバ開発メモ
sourceforgeのプロジェクトのページ
シリアル接続の機器がいくつかあり、OS Xで使えないため BELKIN社のUSBシリアル アダプターをOS Xで使えるようにできないか試している。Appleのサンプルコード を見てみると、 AppleUSBCDCSampleDriverというコミュニケーションクラスのドライバの があるようなので、これをベースにしてみる。このデバイスで使うためには、クラ スではなく、ベンダーIDやデバイスIDによりロードされる必要があり、この設定を ビルドの設定のバンドルの中で変更を行なう。これによりどうにかモジュールは kextloadコマンドでロードされるようになったが、デバイスをopenしたりすると カーネルが落ちてしまう。
FreeBSD(NetBSD)のUSBドライバの中にubsaというドライバがあり、BELKIN社の USBシリアルアダプタをサポートしているようなので、このドライバのコードも 参考にする予定。
ドライバのデバッグでログを吐き出すためには、IOLogとEvLogという関数があるよ うだ。IOLogの方がお手軽で、EvLogはより制約がないと書いているようだが、あま りちゃんと理解できず。 アップルのページの説明
EvLogの使い方がわからないので、IOLogを使うように.hファイルを変更したところ 動作が少し安定したように思える。(気のせいかも)
IOSerialDriverSyncで使われるacquirePort()まで処理が進むようになりこの関数で kIOReturnExclusiveAccessを返すとプロセスからオープンした時に正常にエラーが 返り、動作上は問題がない。kIOReturnSuccessを返すとカーネルが落ちる。おそら く他の関数が呼ばれ処理で問題をお越し落ちるのではないだろうか。まずは acquirePort()で正常に処理ができるようにすることが良いのではないかと思ってい る。
USBデバイスにはインターフェース・パイプ・エンドポイントという仕組みがあっ て1つのデバイスは1つ以上のインターフェースを持ち、1つのインターフェースは 番号0のパイプを必ず持ち、それ以外にもデータ転送用のパイプを持っていること もある。エンドポイントとはこのパイプに結び付けられたバッファを示すようだ。
コミュニケーションクラスの場合、インターフェースは2つあり、1つのインター フェースにはインターラプト転送用のパイプがあり、もう1つのインターフェース にはバルク転送用のパイプが2つ(送信+受信)あるようだ。
BELKINのモジュールでは、インターフェースが1つに上記の3つのパイプが含まれ るようである。
acquirePort()で落ちていたのは、正しく設定されていないインターフェースを openしていたためであった。
インターフェースを1つで処理するようにしたところなんとなく動き始めた。テ ストプログラムでモデムに"AT\r"と送ると同じ文字列がreadできる。 （本当に読めているのかは微妙）ただ本当は"OK"の文字列も読めるはずだが、 これは読み込めていない。
IOKitのドライバのメソッドは、start,stop,messageの三つしかない。OS 9 以前のコードフラグメントのドライバもエントリーポイントは三つだったよう な気がするので、Appleの伝統であろうか。68Kのころはさすがに思い出せない。
なんとなく動くようになったが、接続した状態でkextをロードするとちゃんと 動かなかったり、デバッグライトを抜くと動かなかったりする。かなり怪しい。
sourceforgeに プロジェクトを登録してみた。ある程度まとまったところで、cvs にソースはアップする予定。
ちなみにF5U103はATMEL社のAT90S4414というチップにプログラムを放り込んだも ののようです。
PI ZaurusのIR(ASK)のアダプタをつないで昔作ったzauaskでデータが取り込みが できるようになったが、ハンドシェイクでの受信はできていない。送信も今のと ころ不可。
昨日帰宅後と、今朝早くからデバッグしてみたがやっぱり変わらず。いくつか不 思議な点としては、デバッグがオンのそこそこ動いているバイナリでもモジュー ルが勝手にunloadされたりする。あとデバッグがオンのモジュールだと、アプリ ケーションプログラムからアクセスすると落ちるのだが、アクセスしなくても、 一度抜いて指し直すと認識されなし。？？？
一応書いておくと、開発環境はiBook DualUSB 500MHz, MacOS X 10.1.5で10.1に 付属のProjectBuilderを使って開発しています。カーネルが落ちたところでリモ ートデバッグするためにもう一台あるとうれしいのだが。
帰宅後酒を飲みながらのデバッグなので、牛歩のごとくの進捗である。DEBUGを抜 いた時にカーネルがパニックするのはreleasePort()でデバイスをclose()すると ころのようである。DEBUGとは直接は関係が無いように思われるのでやはり、タイ ミングの問題であろうか？
サンプルコードを見る限りではアプリケーション側からのシリアルデバイスへの APIセットがUNIX由来のtermiosのようである。IOKit独自のAPIセットも用意する のだろうか？
releasePort()->releaseResources()中でパイプのメモリディスクリプタをrelease() している所があるのだがこの結果、commReadComplete()とdataReadComplete()が kIOReturnAbortedで呼び出されてしまうようだ。このタイミングが関係してデバッグ を外すとカーネルが落ちているのではないだろうか。
週末もいろいろ試したが、やはり安定しない。debugのフラグを落としてコンパイル すると顕著なのだが、フラグをたてても稀に落ちるので、たまたま動いているだけ なのかもしれない。手詰まりな感じである。
releaseResources()で何も処理しなければ一度は必ず動く。しかし次のアクセスで エラーになり、もう一度アクセスするとカーネルが落ちる。
怪しいながらもシリアルからの入力は動いている、出力についてほとんどは動いて いないように見受けられるので、こちらを少し調べるのを先に行った方が良いのか もしれない。
releaseResources()で落ちているのでインターフェースをclose()せずに再利用する 事で回避できるのかもしれない。全うな方法としては、なぜインターフェースのclose() で落ちてしまうのかを突き止めるのが良いのだろうが、、、
BSDのドライバでもclose時にインターフェースはcloseしていないようである。機器 固有の動作があるのだろうか？
朝猫に起こされて、やむなく修正の作業を行なってみた。アプリケーション側が closeした時にインターフェースのクローズなとを行わずリソースを再利用するよう にしたところ動作が安定した。このソースをsourceforgeのcvsにアップしてみが、 なかなかviewcvsで表示されるようにならない。
週末にバイナリもアップを行なった。viewcvsでもファイルが見えるようになった。 かなり怪しいながらどうにか動作して、OSが落ちることも無くなった。
cvsにimportした時に.で始まるMacOS Xの属性ファイルを一緒に入れてしまったので cvsのkextのモジュールがが汚くなっている。またなかなかviewcvsに反映されなか ったの、誤ってビルドした状態でimportを繰り返してしまったので、ビルドされた ファイルまで混じってしまった。アカウントでのcheckoutはできていたので、 もう少し待つべきであった。（反省）
kextフォルダを/System/Library/Extensionsの下にコピーしてrootにchownして再起 動すると、ドライバはロードされるだが、USBケーブルをつないだままで再起動すると、 ドライバ機能しない。/devの下にはエントリーはできている。
週末は台風で雨がずっと降っていたことと、ドライバがぼちぼち動いていたので、 zauaskにUIをつけたアプリケーションをProject Builderで作っていた。UI部分は Interface Builderで作るのだが、このツールのUIが非常にわかりづらい。 またCで書かれた、シリアルインターフェースを拾い出すサンプルコードを追加 POPUPメニューに表示するようにしたのだが、最初はCコードの中でCFMutableArray をアロケートしてObjective Cに引き渡していたのだがうまくいかなかった。 Objective CでNSMutableArrayをアロケートしたあとにCコードに CFMutableArrayRefとして渡し、操作するとうまくいった。
個人的な推測だが、Appleは現在のtemiosでのAPIは初期のMacOSのシリアルへの ドライバーコールレベルの位置付けで、コミニュケーションツールボックス(CTB) のようなAPIをオーバラップしようとしているのでは無いだろうか？いくら高速の メディアが登場してもシリアル通信は残ると思われ、このままではないですよね？ >Appleさん
アプリケーションでデータ通信中にNSProgressIndicatorのNSProgressIndicatorSpinningStyle を使おうと思ったのだが、10.1.5上のInterface Builderではこれが設定できない。 コード上で設定を試みたがこれもundefineでコンパイル時にエラーになる。たしかに ドキュメントを見るとこの機能は10.2以降となっているがCodeWarriorのPowerPlantで LChasingArrowsというクラスは10.1.5(carbon)でもこの機能を提供している。OS X 10.1 のデベロッパーキットのサンプルに含まれるAppearanceSampleというアプリケーション でもこの機能は使われている。:-(
PowerPlantのLChasingArrowsは10.1系では矢印が丸く回っているようなアニメーション になり10.2系ではOS起動時にも使われている円形で放射状の棒が回るアニメーションに なる。
MacOS X 10.1の開発環境はOS 10.1のアップデータに同梱されたCDのDeveloper Toolsと (Sep 2001)、そのアップデータ(Dec 2001)があり、それとgcc3が含まれた物(Apr 2002) がある。
| September 2001 | December 2001 | April 2002 | |
| Project Builder | 1.1 (v73.3) | ? | 2.0 |
| Interface Builder | 2.1(v219) | ? | 2.2.1(v263.2) |
| gcc v2 | gcc-932.1(2.95.2) | ? | gcc-937.2(2.95.2) |
| gcc v3 | NA | NA | 1041(3.1 20020105) |
このモジュールを利用しているユーザからメールをもらったのだが、10.2.6などで ロードすると下記のようなエラーが表示され、同じ内容の日本語のダイアログも出 てきてしまう。何が原因なんだろうか？(2003/10/22)
% sudo kextload BelkinF5U103Driver.kext
2003-10-20 21:14:30.748 kextload[417] CFLog (20): The program you are using need
s to use a system file that may reduce the security of your computer.: <CFArray
0x2e85e0 [0xa01303fc]>{type = mutable-small, count = 3, values = (
0 : <CFString 0x7274 [0xa01303fc]>{contents = 'The file ''}
1 : <CFString 0x4f390 [0xa01303fc]>{contents = 'BelkinF5U103Driver.kext'
}
2 : <CFString 0x7284 [0xa01303fc]>{contents = '' has problems that may r
educe the security of your computer. You should contact the manufacturer of the
product you are using for a new version. If you are sure the file is OK, you can
allow the application to use it, or fix it and then use it. If you click Don't
Use, any other files that depend on this file will not be used.'}
)}
kextload: BelkinF5U103Driver.kext loaded successfully
上記の問題は元にしたAppleのサンプルコード(AppleUSBCDCSampleDriver)でも発生 するようである。どうしたらよいのだろうか？
xcodeでビルドできないという連絡をもらったが、まだ10.3を購入していないので 環境が作れない。
| TD | RD | RTS | CTS | DSR | DCD | QM | RTS | DTR | |
| 送信前(CE-IR2 OFF) | 1 | - | 1 | 1 | 1 | - | - | - | 1 |
| 送信前(CE-IR2 ON) | 1 | 1 | 1 | 1 | 1 | - | - | - | 1 |
| 送信中(CE-IR2 ON) | 0,1 | 0,1 | - | 0 | 0 | - | - | - | 0 |
Mac開発者のメーリングリストで、上記のシステムからの警告の件を質問した ところ、持ち主がroot:wheelで権限が0644でないといけないことを教えても らった。感謝です。
最近インストールなどについての問い合わせが何件かあったのでインストーラ をPackageMagerで作ってみた。残念なことに10.2の開発環境で作ったパッケー ジは10.1では使えないようだ。
Tigerで試された方から、上記のパーミッションなどが間違っていると、警告が出て まったくロードされないようになったと連絡をもらった。やはりちゃんとパッケージ を作った方が良いのかもである。
ひょんなことでいまさらPalm(WorkPad c3)を手に入れ、palmのページからPalm Desktop のソフトウエアをダウンロードしてインストールした。インストーラの出来が悪く、 rootでログインしてインストールしないとうまくできないようであった。
どうにかインストールできて、「HotSync マネージャ」を起動すると、BELKIN のポートは認識されるが、モデムとして誤認識されてしまうようである。この プログラムのの処理は「/ライブラリ/Application Support/Palm HotSync/トランスポート」 の下のプラグインで処理されているようだ。この中の「シリアル」というプラ グインが誤認識しているようだ。
いろいろ試したのだが、とりあえずは下記の方法でBELKINのユニットを使って、 シリアルのクレードルでの接続を認識できるようになるようだ。
一度「HotSync マネージャ」を起動させ終了すると 「~/ライブラリ/Preferences/ByHost」の下にcom.palm.HS.T.S.で始まるファ イルが作成される。このファイルにはシリアル系のポートの設定が含まれて いて、「HotSync マネージャ」で正常に認識されていればBELKINのモジュー ルの設定も含まれる。このファイルをxcodeに含まれる、「Property List Editor」 で開き「Port Mappings」で指定された項目の中の中の「Port Type」 が「Modem」となってしまっているので、で「Serial-Serial」に書き換えてしまう。
これでBELKINのモジュールが「HotSync マネージャ」でシリアルポートとして 認識されるようになるようだ。
おそらく「シリアル」プラグインは通常のシリアルポートとして処理するデバイス 名の一覧をどこかに持っているはずなので、そこにBELKINのデバイス名を追加でき るのであればそうするのが良いのだろうが、今のところその在処が見つけられない。
なんとも久しぶりだがOS X 10.5のXcode 3.1.3でビルドしてみて、svnにソースを つっこんでみた。もはやまともに確認できる環境はないのだがとりあずISDNのTAで ATにOKが帰るので使えるのではないかと思う。
IrDAモジュールのドライバーを書くために思い出して いたのだが、USBRequest()がボーレートなどを設定する機種依存部のコードのようだ。
5年ほど前に壊れて不安定なクロッサム2を修理しているのだが、RSIF-2010で接続し て/vしたところ以下が帰ってきた。
sh-3.2$ cu -l /dev/cu.F5U1030000111D Connected. Multi Remote Controler HMR-2000(CROSSAM2) Ver 1.00 Copyright (C) 1990 by HAL Laboratory,inc. Created by Y.Shinohara and S.Iwata Special thanks to M.Fujishita and T.Saito, etc.
ということで10年越しの構想のクロッサムのページ を作ってみた。
10.5からcuコマンドが入ってデバッグが楽になったが、10.6では/var/spool/uucp/ のパーミッションが無くなって、ユーザー権限でcuが使えなくなった。デバイス のアクセス権限があるので、セキュリティー的な問題ではなく、単純なミスのよう に思える。
今更だが分解写真を撮ってみた。
AppleUSBCDCSampleDriverは開発を始めた当時Appleのデベロッパーサイトの サンプルコードにあったが今はないようだ。一緒にサイトにあった同じくDTS作成の USBCDCEthernetはオープンソースのIOUSBFamilyのExamplesの下に入っていたりする のだが。。。
CDC ECMをいじっていてちょっと思い出していたのだが、標準のCDCなデバイスは インターフェースが二つあって、コントロール用とデータ用になっている。 Belkinのデバイスはインターフェースが一つで、コントロールはデバイスへの リクエストで処理しているようだ。私のコードは見直してみると、もう少し奇麗に かけたような気もするが、もはや手を入れるつもりはない。
USBの最初の頃はCDCなデバイスはあまりなくて、Belkinの様に独自仕様のものが 多かった気がするが、最近はCDCなデバイスもいろいろあったりする。 昔はCDC仕様で作っても、OS側のドライバが信用できなかったりしたので、独自仕様を 採用していたケースもあったのではないだろうか。最近はOS側のドライバもほぼ 枯れているので、CDC仕様を採用することが多くなったのではないかと思われる。 FTDIみたいな特殊な用途を目指しているところは、独自仕様なわけだが。
FAXを送信する必要があって、久しぶりにこのkextを使ってみた。モデムはもう10年 も使っていなかったOMRONのモデムをつないでMac OS Xの標準のドライバで送信する 事が出来た。