アルドウィーノを使った
オープンソース、オープンハードの
ローコストＥＣＵ

テージのＥＣＵが壊れているみたいなので
Ｓｐｅｅｄｕｉｎｏ（ＳＴＭ３２）に装換しました。

その２０：
不均等なプライマリパルスが入力された時の
Ｓｐｅｅｄｕｉｎｏの動作と考察


２０２５年
２月２４日
アナログディスカバリのロジアナから生成したパターンジェネレータの不均等プライマリパルスでＳｐｅｅｄｕｉｎｏを動かしてみます。点火パルスが重複して異常です。点火時期は０度に設定しています。手動で入力した不均等パルスでは、この現象は出なかったです。


上の波形を拡大してみます。赤ラインが基準です。基準は３６歯ギアのプライマリとセカンダリパルス位置関係で決まります。現在は基準から１３０度前（トリガアングル１３０度）が上死点です。プライマリパルス１波が２０度なので１３０度は６．５パルス分です。２発出ている点火パルスの前が間違い、後が６．５パルスで正解です。正しい位置より前に出るとケッチン状態になって始動性が悪くなります。


確認のため、基準＝上死点（トリガアングル０度）に設定すると重複は無くなり、正常になります。トリガアングルを調整すると、正しく動作するのは３０〜−３０度くらいの狭い範囲です。また、不均等でない整列しているプライマリパルスなら、どこにトリガアングルを設定しても問題なく動作します。重複して点火パルスが出るのは電気的ノイズでは無く、Ｓｐｅｅｄｕｉｎｏの仕様との不適合の可能性が高いです。



２月２７日
点火パルスが重複して出る不具合の件で、Ｓｐｅｅｄｕｉｎｏの点火のソースコードを解析しています。ＶＳＣはｄｅｆｉｎｅやｉｆｄｅｆが反映された形でソースコードが見られるのでプログラムを追うのに便利です。Ｓｐｅｅｄｕｉｎｏのプロジェクトを読み込んだところ、ｉｎｃｌｕｄｅファイルが無いいうエラーが出ました。別のｕＣＮＣのプロジェクトをビルドした時にｆｒａｍｅｗｏｒｋ−ａｒｄｕｉｎｏｓｔｍ３２が更新されて、インクルードパスが変わってしまったようです。赤枠のインクルードの行に波下線が付いて、下にエラー表示されます。


エラー表示のＸにカーソルを合わせると、ヒントマークに変わります。


プルダウンメニューにインクルードパスの追加が出てきます。


念のため、上で表示されたディレクトリを確認すると見つからなかったｃｌｏｃｋ．ｈがありました。


クリックして追加すると、インクルードパスに１行追加されます。この動作を３回繰り返すと、エラーが無くなりました。


ｆｒａｍｅｗｏｒｋ−ａｒｄｕｉｎｏｓｔｍ３２のあるディレクトリを確認すると、２／７に作られていてました。丁度、ｕＣＮＣをやり始めた時です。元のディレクトリはリネームされてました。


ソースコードの解析で現在までに分かった事をまとめておきます。メイン関数のｌｏｏｐは経過時間別に必要な処理するように記述されています。時間は１ｍＳｅｃ、５ｍＳｅｃ、３３．３３ｍＳｅｃ、６６．６６ｍＳｅｃ、１００ｍＳｅｃ、１Ｓｅｃです。これらの必要な時間にセンサの読み取り、マップの読み取りなどを行います。これ以外の最速で実行される部分に通信処理と点火、噴射のスケジュール登録があります。点火と噴射のスケジュールはハードウェアタイマ（ワンショットモード）のオーバーフロー割り込みを使ってパルス発生させる機能です。


点火スケジュール登録部です。開始角度、上死点からの角度 、現在のクランク角度から、ｃａｌｃｕｌａｔｅＩｇｎｉｔｉｏｎＴｉｍｅｏｕｔ関数で開始時間を計算して、スケジュール構造体、開始時間、ドエル時間を引数にｓｅｔＩｇｎｉｔｉｏｎＳｃｈｅｄｕｌｅ関数でスケジュール登録しています。


開始時間の計算はａｎｇｌｅＴｏＴｉｍｅＭｉｃｒｏＳｅｃＰｅｒＤｅｇｒｅｅ関数によって角度から時間に変換されます。


ｓｅｔＩｇｎｉｔｉｏｎＳｃｈｅｄｕｌｅ関数はＲＵＮ中（スケジュール中）か、そうで無い場合で振り分けられます。


下はＲＵＮ中で無い時の＿ｓｅｔＩｇｎｉｔｉｏｎＳｃｈｅｄｕｌｅＲｕｎｎｉｎｇ関数です。割り込みを禁止し、タイマレジスタに設定して、割り込みを許可しています。ｓｃｈｅｄｕｌｅｒ．ｈに下のような記述があります。
・このスケジューラは、燃料システムと点火システムで使用する２つのスケジュールを維持するように設計されています。
・使用中の各タイマーからのオーバーフローベクトルがオーバーフローするのを待機することで機能し、これにより割り込みがトリガーされます。
・これは他のスケジューラーとは異なり、呼び出しは非定期的です。
（つまり、ある時刻にイベントをスケジューリングし、それが発生すると、明示的に要求/再登録しない限り、そのイベントは再発生しません）。
・各タイマーは常に１つのコールバックしか持つことができません。ｓｅｔＣａｌｌｂａｃｋ関数を２回呼び出すと、元のスケジュールは上書きされ、発生しなくなります。


こちらはＲＵＮ中の次のスケジュール登録をする＿ｓｅｔＩｇｎｉｔｉｏｎＳｃｈｅｄｕｌｅＮｅｘｔ関数です。次の準備のために変数に設定して終了しています。この後はスケジュール登録とハードウェアタイマの関係を調べる必要があります。



３月２日
ソースコードの解析での続きです。点火用のタイマはＴＩＭ２を使います。下のｂｏａｒｄ＿ｓｔｍ３２＿ｏｆｆｉｃｔａｌ．ｈのコメントは間違えています。ＴＩＭ２は１６ビットのアップカウンタと４個のコンペアレジスタから構成されます。コンペアレジスタとアップカウンタが一致した時に割り込みを発生して、ハンドラを呼びます。４つのコンペアレジスタはそれぞれＩＧＮ１〜ＩＧＮ４に対応しています。テージではＩＧＮ１（水平気筒）とＩＧＮ２（垂直気筒）の２つみです。クロックは２５０ＫＨｚで約０．２６秒でオバーフローします。１つの点火に使えるリソースは共通アップカウンタと１つのコンペアレジスタなので、必要な時間を待つには、アップカウンタの値を読んで、必要な時間を加算してコンペアレジスタに設定する必要があります。点火パルスを出力するには、開始（今から何ｕＳｅｃ後にＯＮする（通電開始））と終了（今から何ｕＳｅｃ後にＯＦＦする（点火））で、この動作をハンドラ（ＩＧＮ信号のポート出力のＯＮ／ＯＦＦ）を切替てセットで行う必要があります。


メインループの点火動作の解析を進めます。下はＩＧＮ１のみに単純化したメインループです。点火タイミングのスケジュールを登録するために、ｇｅｔＣｒａｎｋＡｎｇｌｅ関数で現在のクランク角度を得ています。


ｇｅｔＣｒａｎｋＡｎｇｌｅ関数の大まかな動作は初めに、処理に使う一時使用変数を用意します。

続いて、割り込み禁止にして、計算に必要な広域変数を一時使用変数にコピーして、割り込み許可します。


クランク角の計算は現在のプライマリ歯カウント数にプライマリ歯１つ分の角度を掛けて、基準になるプライマリ歯の１番目の上死点からの位置を加算して粗い角度を計算します。その後、経過時間分を補正しています。



３月３日
点火のソースコードの解析での続きです。ｇｅｔＣｒａｎｋＡｎｇｌｅ関数に続いて、ｃａｌｃｕｌａｔｅＩｇｎｉｔｉｏｎＴｉｍｅｏｕｔ関数で点火の開始時間を計算しています。


ｃａｌｃｕｌａｔｅＩｇｎｉｔｉｏｎＴｉｍｏｕｔ関数の大まかな動きは１番シリンダの上死点が基準と一致しているか、していないかで処理が分かれています。これはｃｈａｎｎｅｌ１ＩｇｎＤｅｇｒｅｅｓ変数で切り分けています。ソースにも次のコメントがあります”これは１番シリンダが上死点からに達するまでのクランク角度（これは、ほぼすべてのエンジンで明らかに０ですが、異なるものもあります）”。普通のエンジンでは１番シリンダの上死点がクランク０度＝基準に設定されていますが、今回デュアルホイールに改造したテージでは３６歯ギアの取り付け鉄ボルトがセカンダリパルスなので、たまたま上死点前約１３０度になっています。今回の場合は一致していないので角度の差分を修正した後で緑枠の＿ｃａｌｃｕｌａｔｅＩｇｎｉｔｉｏｎＴｉｍｏｕｔ関数が実行されます。


＿ｃａｌｃｕｌａｔｅＩｇｎｉｔｉｏｎＴｉｍｏｕｔ関数は開始角から現在クランク角を引いて角度の差分を計算し、その後、ａｎｇｌｅＴｏＴｉｍｅＭｉｃｒｏＰｅｒＤｅｇｒｅｅ関数で角度を時間に変換しています。


ａｎｇｌｅＴｏＴｉｍｅＭｉｃｒｏＰｅｒＤｅｇｒｅｅ関数は引数の角度に１度あたりの時間を掛けて、時間に変換し、その後、丸めて返しています。



３月５日
点火のソースコード解析の続きです。ｓｅｔＩｇｎｉｔｉｏｎＳｃｈｅｄｕｌｅ関数を解析します。実際に点火動作を行う肝心の部分で、今から何マイクロＳｅｃ後に点火するかをスケジュール登録します。


現在のステータス変数でＲＵＮ中か、そうで無いかで登録関数が切り分けられます。下は切り分けのためのコードです。


ＲＵＮ中で無いときは、名前が紛らわしいですが、＿ｓｅｔＩｇｎｉｔｉｏｎＳｃｈｅｄｕｌｅｓＲｕｎｎｉｎｇ関数が使われます。ＲＵＮ中は点火パルスが通電している時間で、幅は狭いので多くの場合はこちらを通ることになります。引数のｔｉｍｅｏｕｔをコンペアレジスタ用に変換してｔｉｍｅｏｕｔ＿ｔｉｍｅｒ＿ｃｏｍｐａｒｅ変数に入れています。タイマのレジスタにアクセスする前に割り込みを禁止にし、その後、ｓｔａｒｔＣｏｍｐａｒｅ変数にｃｏｕｎｔｅｒ（ＴＩＭ２のタイマのフリーランしているハードウェアのカウンタレジスタ）とｔｉｍｅｏｕｔ＿ｔｉｍｅｒ_ｃｏｍｐａｒｅを加算して入れています。


ＳＥＴ＿ＣＯＭＰＡＲＥはｄｅｆｉｎｅで、タイマのハードウェアのコンペアレジスタにｓｔａｒｔＣｏｍｐａｒｅ変数の値を書いています。その後、ステータスをペンディングにして割り込みを許可して終了です。


ＲＵＮ中のときは＿ｓｅｔＩｇｎｉｔｉｏｎＳｃｈｅｄｕｌｅＮｅｘｔ関数が使われます。ここでは次のスケジュールのために設定をして、終了します。


ここまでの解析で、いつ点火するのかを角度から時間に変換しているため、上死点近くで圧縮が高くなると、回転が遅くなって登録時の点火タイミングでは、まだ本来の角度まで来ていないというのが、点火パルスが重複する原因と思われます。上にも書きましたが、メイン関数のｌｏｏｐで経過時間別に必要な処理をします。５ｍＳｅｃ、６６．６６ｍＳｅｃ、１００ｍＳｅｃなどで、変化の少ないセンサなどは間引いて処理されます。点火と噴射のスケジュール登録はこれらとは別に最速で実行されます。クランキングのログから、どのくらいの速さでループしているか計算できます。ログの中に回転数（ｒｐｍ）と１秒あたりのメインループのループ数（ｌｏｏｐ／Ｓ）があります。ｒｐｍを６０で割ってからｌｏｏｐ／Ｓを割れば１回転中に回ったループ数が分かります。クランキング時の３３１回転で３５２７になりました。因みに、９５００回転では約１２３になります。１０以下になると、点火、噴射の処理が不正確になります。


下は約２８０回転でクランキング中の重複の無い正常な点火タイミングの波形です。下の黄色の基準に対してＩＧＮ１はプライマリパルスで６．５個手前にあります。１パルスは２０度なので２０＊６．５＝１３０度で設定しているクランクアングルと一致します。ＩＧＮ２はプライマリパルスで約７個後にあります。（６．５＋７）＊２０＝２７０度でＬツインの点火間隔と一致します。緑の数字は広域変数のｔｏｏｔｈＣｕｒｒｅｎｔＣｏｕｎｔでプライマリパルスの立ち上がりで起動される割り込みルーチンでインクリメントされます。３６歯なので１〜３６の間でカウントされ、これを参照すれば今どこのプライマリパルスを通過したかが分かります。上の表計算ではクランキング中は３５００回ほどメインループを回っているので、ループ内でｔｏｏｔｈＣｕｒｒｅｎｔＣｏｕｎｔを参照すれば、かなり正確に今どこにいるか分かります。例えばＩＧＮ１の場合は下の波形からｔｏｏｔｈＣｕｒｒｅｎｔＣｏｕｎｔが３０の時に、待ち時間６．２５ｍＳｅｃでＩＧＮ１の点火スケジュールを１回のみ登録すれば、少なくとも複数パルスが出ることは無くなると思います。ただし、プライマリパルスの位置で点火するので、クランキング中はクランクアングル設定は無効になります。待ち時間の６．２５ｍＳｅｃはクランキング回転数によって変化しますが、これを回避するはクランキング時の点火タイミングをプライマリパルスの立ち上がりに合わせれば良いです。この場合はＩＧＮ１／ＩＧＮ２とも、待ち時間無で点火登録できます。因みに、プライマリパルスが３６歯の場合、２７０が２０で割り切れないので両方のタイミングを待ち時間を０にはできません。４０歯なら可能です。



３月６日
プログラムを修正するにあたり、修正部分をＴｕｎｅｒＳｔｕｄｉｏから動的に制御できないか調べます。修正したプログラムをイネーブルにするスイッチとＩＧＮ１のプライマリパルスからの待ち時間が可変できると便利です。とりあえず、ＩＧＮ２は固定しておきます。ＴｕｎｅｒＳｔｕｄｉｏのメニューで流用できそうなパラメータを探すと、アクセサリの一番上に電動ファンの制御がありました。テージは空冷なので、この機能は使っていません。


ファンのモードにＯＦＦ、ＯＮ／ＯＦＦとＰＷＭがあり、ＯＮ／ＯＦＦは修正コードのイネーブルに使えそうです。また、切り替え温度でＩＧＮ１の待ち時間が設定できそうです。


上のパラメータがソースコードでは何という変数名なのか調べる必要があります。ＴｕｎｅｒＳｔｕｄｉｏの機能名とＳｐｅｅｄｕｉｎｏの変数名は一致していないので、初めにＤｏｘｙｇｅｎのＷＥＢページでｆａｎで検索して当たりを付けます。ｆａｎが付く変数や関数が多数ヒットしました。ｆａｎＥｎａｂｌｅは分かりやすく、モード値が入っていることが分かります。


切り替え温度は名前からは、それらしいのが見つからないのでＳｐｅｅｄｕｉｎｏのソースコードで上のキーワードを順次検索します。ｆａｎＳＰが切り替え温度のようです。