qshinoの日記

Powershell関係と徒然なこと

USB request timeout

# The Setup Packet


Every USB device must respond to setup packets on the default pipe. The setup packets are used for detection and configuration of the device and carry out common functions such as setting the USB device’s address, requesting a device descriptor or checking the status of a endpoint.

A USB compliant Host expects all requests to be processed within a maximum period of 5 seconds. It also specifies stricter timing for specific requests :

Standard Device requests without a data stage must be completed in 50ms.
Standard Device requests with a data stage must start to return data 500ms after the request.
Each data packet must be sent within 500ms of the successful transmission of the previous packet.
The status stage must complete within 50ms after the transmission of the last data packet.
 

The SetAddress command (which contains a data phase) must process the command and return status within 50ms. The device then has 2ms to change address before the next request is sent.
These timeout periods are quite acceptable for even the slowest of devices, but can be a restriction during debugging. 50mS doesn't provide for many debugging characters to be sent at 9600bps on an asynchronous serial port or for a In Circuit Debugger/Emulator to single step or to break execution to examine the internal Registers. As a result, USB requires some different debugging methods to that of other microcontroller projects.

Casually reading through the XP DDK, one may note the Host Controller Driver now has a USBUSER_OP_SEND_ONE_PACKET command which is commented to read "This API is used to implement the 'single step' USB transaction development tool." While such a tool has not been released yet, we can only hope to see one soon.

Each request starts with a 8 byte long Setup Packet which has the following format,

喫茶店

中野島 ドトール wi2, cocacola-fine

登戸 ドトール wi2

溝の口 ドトール wi2,電源なし。

タリーズ、不明、少ないが電源あり

サンマルク、電源見つからず

武蔵小杉 エクセルシオール wi2

武蔵中原 ドトール, wi2

武蔵新城 ドトール, 不明

南多摩 星乃珈琲店、不明

コメダ珈琲、不明

府中白糸台、コメダ珈琲、無線なし。電源あり。

新宿、コメダ珈琲、電源あり。

 

iOS android programming

# iOS

https://blog.mbaas.nifcloud.com/entry/11383

#Android

https://blog.mbaas.nifcloud.com/entry/11393?amp=1

# sl4a + python for android

android アプリを作成できる。

https://android.keicode.com/devenv/sl4a-hello-world.php

チュートリアル

http://keitaiseikatsu.blogspot.com/2013/07/python-android-sl4a-aide-pythonandroid.html?m=1

# 余録

多過ぎて迷う。選ぶ基準は様々だが、いくつか並べると、

1. GUIが作れるか?

2. 作成物をネイティブアプリの様に扱えるか?

3. OS固有機能を扱えるか?

位置情報、デバイス、マルチスレッド等。

4. 外部ライブラリの利用、NDK等。

5. 外部アプリとの連携、DB,httpd,browser等

6. IDEの使いやすさ、入力補完、GUIプレビュー、デバッグ等。

AndroidをBluetooth keyboardにする

# AndroidBlueToothキーボードにする

 

アンドロイド端末をBlueTooth端末にする方法を探した結果、下記で動作した。

 

試したのは下記の構成。

キーボード側: Android 6.0

入力側: iOS 12.1.4

# 補足

android 5.0以上が必要な模様。また、キーボードのキーが限られている。ピリオドがないなど。

 

# アンドロイド側

1. 下記の2つをインストール

Device Web API Manager

- https://play.google.com/store/apps/details?id=org.deviceconnect.android.manager

HoGPプラグインAPK

- https://github.com/DeviceConnectUsers/deviceconnectusers.github.io/releases/download/v2.4.1-release-20180330-Android/dConnectDeviceHOGP.apk

2. Bluetooth on

3. Device web api manager/DWAM 起動

4. DWAM設定

「デバイスプラグイン管理」⇒「HOGP(Device Connect Device Plug-in)」⇒「設定を開く」

5. mouse をrelative

keybord をon にした後に、HoGPサーバをOnにする

6. デバイス操作ボタン

バイス操作ボタンをおす。画面にマウスパッドとキーボードが現れる。

 

以後はiOS側で操作。

 

# iOS

1. Bluetoothをオン

2. 該当するデバイスと接続

3. ペアリングのダイアログがでたら、ペアリングする。

4. キー入力

キー入力できるアプリを開く。

 

以後Androidからキー入力可能。

 

 

 

# 参考

https://qiita.com/dcm_yamazoe/items/840dadeafbfb2151ca5a

https://github.com/DeviceConnect/DeviceConnect-Android/blob/master/dConnectDevicePlugin/dConnectDeviceHOGP/README.md

 

スイッチの代わりにnat

NATできないスイッチで、NATしたい

下記の様な構成で、GがグローバルなLAN, sw1がNATできないスイッチ、PがプライベートなLAN, SVがNAT先のサーバ。sw2もNAT不可。

  • G -> sw1 -> P -> sw2 -> SV

SVは直接Gに見せず、private lan に設置。NATでGへアクセスしたい。しかし、sw1はNAT機能がない為、止むを得ず、SVにグローバルを割当る。

結局、

  • G -> sw1 -> G+P -> sw2 -> SV

とは言え、PのエリアにGのパケットが流れるのは問題である。そこで、sw1-SV間をtagVlanで運用したい。

つまり、

  • G -> sw1 -> G/tagvlan -> sw2 -> SV
    • sw1 -> P/native
      

tagvlanを使わずとも、svにポートを追加し、sw1に直結すれば?

  • G -> sw1-> G -> SV
  • sw1 -> P -> sw2-> SV

これだとSVにGのipアドレスが必要. svをGに公開したくなかったのでは? あれ?

後はssh tunnel とか?

ここで詰まる。また、いつか。