部品取りとなっていたRS125整備。リアブレーキは予備部品から拾ってきて装着、
フロントは、ヤフオクで落としてブラストかけたところで中座していたフロン
トキャリパーに新品のシール、ピストン、ピンで組んで装着。ブラストが下手
で、ちょっと残念風味。もっと大容量のコンプレッサがあって、エア圧の調整
ができたらなとは思うものの、思わないように。もうガレージに場所がないん
だ。
マスタシリンダは1/2インチ(12.7mm)がよかったのだけど(CR85で使ってるやつ。 88'NSR250R)、手持ちのはどれも14mmだったので、14mmで。カッツン気味になる けど、大丈夫でしょう。カッツン好きだし。

スピードセンサはリアブレーキロータにつけていて、今迄、CR85とRS125でロガー をつけかえる時にはキャリパーごと交換していたのだけど、それぞれ別に作る ことにしました。使わなくなったApe用のバックステップから切り出し。
ここで問題が。DROの表示ユニットが動かない...。

バラして調べてみたところ、なんと電源のトグルスイッチが接触不良になって いた。トグルをぐりぐりすると電源が入ったりもする。ガレージ用にはもっと 屈強なのがいいということで、もうちょっと大きいスイッチに交換。
机の上でいじっている時と、ガレージに装備されて実際にいじられる時とだと 操作の荒さが違うんだよね。
今見ると、結構このモジュール頑張って作ってる。こういうのそろそろ基板を 作ってみたいとも思いつつ、野望的には、フライスをCNC化して、これで基板を 切削なんだ。

マスタシリンダは1/2インチ(12.7mm)がよかったのだけど(CR85で使ってるやつ。 88'NSR250R)、手持ちのはどれも14mmだったので、14mmで。カッツン気味になる けど、大丈夫でしょう。カッツン好きだし。

スピードセンサはリアブレーキロータにつけていて、今迄、CR85とRS125でロガー をつけかえる時にはキャリパーごと交換していたのだけど、それぞれ別に作る ことにしました。使わなくなったApe用のバックステップから切り出し。
ここで問題が。DROの表示ユニットが動かない...。

バラして調べてみたところ、なんと電源のトグルスイッチが接触不良になって いた。トグルをぐりぐりすると電源が入ったりもする。ガレージ用にはもっと 屈強なのがいいということで、もうちょっと大きいスイッチに交換。
机の上でいじっている時と、ガレージに装備されて実際にいじられる時とだと 操作の荒さが違うんだよね。
今見ると、結構このモジュール頑張って作ってる。こういうのそろそろ基板を 作ってみたいとも思いつつ、野望的には、フライスをCNC化して、これで基板を 切削なんだ。
PWMのテスト → サーボモータを動かす フライスをボールネジ仕様にする。 サーボモータを取りつけ。 モータ制御のアプリケーションこれもいつになるかは予測もつかないプロジェクト。ここずっとサーボモータ 買ったところで進んでない。

Adding Scheduler Activations to Mach 3.0 Paul Barton-Davis, Dylan McNamee, Raj Vaswani, and Edward D.Lazowska University of Washington Technical Report 92-08-03 Reversed March 1993続き。スケジューラアクティベーションの概念がわかってないので、ちょっと 訳がつらい。このあたり一度マイOSで思うがままに実装してみると状況がわかると思う のだけど、ユーザランドまで実装するまでの時間もなく。
1.4 枠組の設計 スケジューラアクティベーションのモデルにおいて、それぞれのジョブのユー ザ層スレッドシステムは、それに割当てられたプロセッサの制御をし、この割 当てが変更されたら、通知される。カーネルは、ジョブに割当てられたプロセッ サ毎にスケジューラアクティベーション(実行コンテキスト)を提供し、関連す るイベントがあれば、通知する責任を負う。 Machのカーネルスレッドの振舞いを変更することでスケジューラアクティベー ションを実装した。我々の実装の構造に影響する、一つの重要な設計上の決定 はプロセッサ割当てモジュールの導入で、これは、ある意味Machの既存のカー ネルスレッドのスケジューラを置き換えるものである。Machカーネルのスケー ジューリング方針はスレッド基底で、"quantum-driven"である。この方針は伝 統的な仕事量に対しては適切だが、スケジューラアクティベーションのアプリ ケーションと、カーネルの間で伝達される情報を活用するという方針において は、荷が重い。ただし、Machの「プロセッサセット[Bla90]」によって、標準の スレッド基底の方針(これは我々の目的には不適)を回避でき、それを我々のタ スク基底のものに置き換えることができる。プロセッサセットは、タスク、ス レッド、プロセッサの割当てのカーネルの機能である。 我々の設計は、それぞれのタスクはそれ自身のプロセッサの組を持つ。 方針モジュールは、タスクに応じた割当ての判定と、タスク間の優先度に基い て様々なプロセッサの要求を監視する。この新しい方針モジュールはカーネル 内でもユーザ層のサーバでも実装できる。色々な方針を試すことのできる柔軟 性のある後者を選んだ。これから先に述べる、我々が最終的に選択した方針は、 ユーザ層の「プロセッサ割当てサーバ」にカプセル化し、選択すれば既存のカー ネル機構を使うことができるものである。: プロセッサはそのタスクのプロセッ サセットによってよって割当てられ、そしてそれは、そのセットから除かれる ことで横取りされる。この設計は、このシステムが三つの要素から構成される ことを意味する。 + イベントの通知のような基本的な機構を実装するためのカーネルの変更。こ れらは次の章で検討する。 + スケジューラアクティベーションで使われるタスクの間で割当てられるプロ セッサの管理をするユーザ層のサーバ。このサーバの実装と、その方針につ いては三章で検討する。 + この新しいカーネルの機構を使うためのユーザ層のスレッドパッケージ。こ れは四章で述べる。
