Windows 10 IoT Coreに関する膨大な数の例と記事があり、さまざまなデバイスを簡単かつ便利に作成する方法について説明しています。 ただし、実際には、「ハードウェア」での作業は、あまり知られていない多くのニュアンスに常に関連付けられており、その知識は実践にしかありません。 Raspberry Pi2およびWindows 10 IoT CoreでGPIOを操作する機能の一部について説明すると同時に、Insider Previewバージョンで利用可能な新しいリモートクライアント機能についても説明します。

すべては、アクセス制御システム（ACS）のリーダーからカード番号を取得する必要があるという事実から始まりました。 ほとんどすべてのリーダーは、 ウィーガンドインターフェイスを介してこのデータを送信できます。 3本のワイヤで構成されています：ユニットを送信する信号、ゼロとグラウンドを送信する信号。 スタンバイモードでは、各信号線に5Vが設定されます。 データは「逆」パルスで送信されます。 50から200μsのパルス幅、300から3000μsの周期：

データは常にリーダーからコントローラーへの一方通行です。 ビット数は異なる場合があり、その解釈も異なる場合があります。 送信の終了は、50〜250ミリ秒のタイムアウトによって決定されます。

このようなパラメーターの拡散は、明確な標準を持たない「歴史的に開発された」インターフェースであるために発生しました。

wiegand26プロトコルを備えたデバイスを手に入れました。その中の小包には26ビットが含まれており、そのうち2ビットのパリティがあります。

このタスクは、デモスタンドの作成の一部として与えられたため、プラットフォームを試すことができました。 したがって、Windows 10 IoT Coreを搭載したRaspbery Pi2が役に立ちました。

GPIOの問題

この問題を解決するには2つの方法があります。

• ピンの電圧を変更するときに割り込みを使用する
• ピンポーリングを使用する

最も単純なものが最初の選択肢のように思えました。 ピンを正しく初期化すると、一定のポーリングでプロセッサーをロードできず、非同期呼び出しのみを処理できます。 ここのコードは非常に簡単です：

var gpio = GpioController.GetDefault(); var data0 = gpio.OpenPin(data0Pin); var data1 = gpio.OpenPin(data1Pin); // Check if input pull-down resistors are supported if (data0.IsDriveModeSupported(GpioPinDriveMode.InputPullUp)) data0.SetDriveMode(GpioPinDriveMode.InputPullUp); else data0.SetDriveMode(GpioPinDriveMode.Input); if (data1.IsDriveModeSupported(GpioPinDriveMode.InputPullUp)) data1.SetDriveMode(GpioPinDriveMode.InputPullUp); else data1.SetDriveMode(GpioPinDriveMode.Input); var ticksPerMillisecond = TimeSpan.TicksPerMillisecond; var tenMs = ticksPerMillisecond / 1000; //1  data0.DebounceTimeout = TimeSpan.FromTicks(tenMs); data0.ValueChanged += data0_ValueChanged; data1.DebounceTimeout = TimeSpan.FromTicks(tenMs); data1.ValueChanged += data1_ValueChanged; 

すぐにDebounceTimeoutについて言う必要があります。 原則として、重大な干渉のないインターフェースの通常の動作中には「バウンス」がないため、通常はここでは必要ありません。 しかし、一般的なケースでは、どの読者とどの条件でこれが機能するのかわからないという事実のため、私はこのタイムアウトを試すことにしました。

しかし、良いことは何もありませんでした。 例では、DebounceTimeoutはミリ秒単位で指定されていますが、私の場合はマイクロ秒が必要です。 どの値を設定しても、ValueChangedイベントは表示されません。 したがって、タイムアウトは単純にオフになり、すべてが正常に機能し始めました。

 data0.DebounceTimeout = TimeSpan.FromTicks(0); data0.ValueChanged += data0_ValueChanged; data1.DebounceTimeout = TimeSpan.FromTicks(0); data1.ValueChanged += data1_ValueChanged; 

データは次のように読み取られました。

 private void data0_ValueChanged(GpioPin sender, pioPinValueChangedEventArgs e) { if (e.Edge == GpioPinEdge.FallingEdge) { UpdateValue(0); } } private void data1_ValueChanged(GpioPin sender, pioPinValueChangedEventArgs e) { if (e.Edge == GpioPinEdge.FallingEdge) { UpdateValue(1); } } 

次に、パッケージが完成した瞬間に問題を解決する時が来ました。 上で書いたように、送信の終わりは、少なくとも50 msの間、両方の信号接点にパルスがないことです。 ここでは、タイマーが完全に適合し、交換があるかどうかを定期的にチェックし、交換されていない場合は、得られた結果をさらに送信します。

このアプローチはうまくいきませんでした。 コードはUIなしで機能するはずだったので、ThreadPoolTimerを使用しました。 このタイマーの機能は、ハンドラーが新しいスレッドで呼び出されるたびにです。 ハンドラーがタイマー期間より長く実行されると、別のハンドラーが並行して起動され、次に別のハンドラーが起動されます。 さらに、この場合、新しい受信を開始するには、タイマーハンドラーでデータをリセットする必要があります。 したがって、これは重要なセクションであり、複数のインスタンスで同時に実行しないでください。 したがって、短いタイマー間隔は使用できません。
タイマーハンドラーの実行中、ポートからのValueChangedイベントの発生が停止するため、ロックを介したハンドラー同期と同様に、長い間隔も使用できないことが判明しました。 これらのイベントは、タイマーハンドラよりも優先順位が低いようです。 さらに、実験は、イベントが並んでハングせず、単に静かに破棄されることを示しました。

したがって、何を言っても、タイマーを使用すると、GPIOからのイベントが失われ、その結果、データが失われました。 タイマー期間を選択し、ValueChangedで計算を再配布することにより、それらを減らすことができます。 しかし、そのようなアプローチでは理論的にも絶対的な信頼性を達成することはできません。 さらに、ValueChangedの実行がイベントのスキップとデータ損失につながることが判明しました。

タイマーの代わりにストリームを使用することにしました。 同期のために、ValueChangedに到着したビットが追加されたキューが使用されました。 スレッドはしばらくスリープし、この時間内に交換があったかどうかを確認し、そうでない場合は、キューからビットを選択し、結果を収集して送信します。

しかし、それも何も起こりませんでした。 スレッドの実行中にValueChangedが呼び出されないと仮定することもできますが、スレッドがスリープしているときに呼び出されないという事実は、私にとって驚きでした。 Thread.Sleepの代替として、Task.Delayを使用しました。 他のタスクが同時に実行されているかどうかはわかりません（ドキュメントによると、Delayはタイマーで別のタスクを開始します）が、GPIOからのイベントがすべてをブロックします。

一般に、Windows 10 IoT用のGPIOドライバーは、イベントの優先度がシステム上で低いため、非同期で使用することはほぼ不可能な方法で記述されています。

稲妻

GPIOの操作方法を学習する過程で、Windows 10 IoT Coreで使用できる別の高速ドライバーがあることがわかりました。 Lightningと呼ばれ、GPIOだけでなく、ADC、I2C、PWM、SPIでも動作します。 「ダイレクトメモリアクセス」（ダイレクトメモリアクセス）により、作業速度が達成されます。

ドライバーはプレビュー段階にありますが、Windows 10バージョンのIoT Core Insider Previewに既に含まれています。 それを使用するのは、標準ドライバーの速度が十分でない人向けです。 ここで優先度の高いValueChangedを取得することを望んでいました。

上記のリンクには、使用方法に関する指示が含まれていますが、機能しません。 問題はNuGetパッケージです。 すべてがインストールされていますが、名前空間Microsoft.IoT.Lightning.Providersに到達することは不可能です。 さらに、問題は克服できないという唯一の言及は、 この記事で見つけました。 著者は、LEDの制御方法を教えています。 特に、PWMの遅い動作に直面し、Lightningを使用して状況を修正しました。
次のようになります。

 Third, you'll need to reference the Lightning SDK. According to the documentation, you just reference via NuGet. Unfortunately, this doesn't work as of v1.0.3-alpha. I had to download the Microsoft.IoT.Lightning.Providers C++ source, add the Microsoft.Iot.Lightning.Providers.vcxproj project to my solution, and then make a project reference. Incidentally, I contacted some folks at Microsoft, and they said a new nuget will be published shortly with binaries that will fix this issue. 

この記事で説明されている方法が役に立ちました。 また、ソースをダウンロードし、プロジェクトファイルをソリューションに追加して、参照を作成しました。 そして、LightningのValueChangedイベントが実装されていないことが判明したとき、私は驚きました...

その後、非同期アプローチを使用するという考えをあきらめ、ループ内のピンをポーリングすることにしました。

更新：問題を解決する過程で、開発者にValueChangedについて質問しました。 彼らはすぐにすべてをするだろうと答えた。 そして彼らは約束を果たした。

さらに、Microsoft.IoT.Lightning.Providers 1.0.0 が NuGetに登場し、名前空間Microsoft.IoT.Lightning.Providersが表示されるようになりました。

問題解決

その結果、ピンのポーリング周期が10μsのサイクルを作成することで問題を解決しました。 最初は速度が足りないのではないかという懸念がありましたが、標準のドライバーでもすべてが十分に高速で動作することが判明しました。

コードは次のようになります。

 _data0 = gpio.OpenPin(data0Pin, GpioSharingMode.Exclusive); _data1 = gpio.OpenPin(data1Pin, GpioSharingMode.Exclusive); if (_data0.IsDriveModeSupported(GpioPinDriveMode.InputPullUp)) _data0.SetDriveMode(GpioPinDriveMode.InputPullUp); else _data0.SetDriveMode(GpioPinDriveMode.Input); if (_data1.IsDriveModeSupported(GpioPinDriveMode.InputPullUp)) _data1.SetDriveMode(GpioPinDriveMode.InputPullUp); else _data1.SetDriveMode(GpioPinDriveMode.Input); _task = Task.Run(() => TaskHandler()); 

他のスレッドの実行をブロックしないように、ループはタスク内で実行されます。

  private void TaskHandler() { var ticksPerMillisecond = TimeSpan.TicksPerMillisecond; var mks = ticksPerMillisecond / 1000; //1  while (!_stopTask) { Task.Delay(TimeSpan.FromTicks(mks*10)).Wait(); var dt0 = _data0.Read(); var dt1 = _data1.Read(); ..... } } 

安定して動作しますが、カードが1秒間に1回しかリーダーに届かないという条件で動作します。

GitHubで数週間以内に、読者をRaspberry Pi2に接続するためのすべての手順を含むこのプロジェクトを投稿する予定です。

リモートクライアント

Windows 10 IoT Coreを使用する多くの開発者は、リモートデスクトップが本当に不足していることに注目しています。 モニターまたはテレビが常に手元にあるとは限らず、それらを使用することは必ずしも便利ではありません。 最後に、このギャップは解消され、バージョン10.0.14295.1000以降、リモートクライアントが登場しました 。 現在、このバージョンと新しいバージョンはInsider Previewとして利用できます。
すべてが非常に簡単に機能します。 Windows 10 IoT Core側では、Webインターフェースでリモートクライアント接続を有効にする必要があります。

クライアント自体をインストールする

起動してWindows IoT Coreに接続します

説明書には、すべてがRaspberry Pi 2および3、Minnowboard MaxおよびDragonboardで正常に機能することが記載されています。 同時に、GPUがサポートされていないため、Pi2のパフォーマンスはわずかに低下します。

Rapberry Pi2を入手しました。

わずかな遅延がありますが、私の意見では、それらは重大ではありません。 同時に、すべてが安定して問題なく機能します。

結論

上記のすべてを要約すると、Windows 10 IoT Coreは、マイクロコントローラーに慣れている人が期待するように常に機能するとは限らないことに注意してください。 それでも、これは本格的なオペレーティングシステムであり、「ハードウェア」からかなり抽象化されています。

1. GPIOからのイベントの優先度は非常に低いです。 また、イベントのメカニズムは完全には明らかではありません。
2. 割り込みの操作に直接関係しない非同期プログラミングの問題。
3. 既存の機能が常に十分であるとは限らず、プレビューの形式で表示される機能が常に正しく機能するとは限りません。 それはすべて非常に急速に発展しますが。
4. Windows 10 IoT Coreのパフォーマンスは、ランタイムに敏感なタスクに十分です。 同時に、稲妻の形の在庫がまだあります。
5. リモートクライアントが表示され、使いやすさが大幅に向上しました。