USB Type-Cの徹底解説^H^H解析(2)

市販のUSB3.0対応のA-Cケーブルを切って確認した結線図を示します。なお、GNDとD+/D-は省略しています。プルアップ抵抗はUSB Type-Cの黒い部分に入っているようです。

2ペアある高速差動信号は、TX1/RX1側を使うか、TX2/RX2側を使うかはケーブルによってさまざまで両方のタイプがあります。TX1/RX1を使うほうはCC1とVBUSの間にプルアップ抵抗が入っています。

いずれもUSB 3.0のType A-Cケーブルは、TX1/RX1かTX2/RX2のどちらか一方の配線しか使っていません。使っている側のCCをプルアップ、使っていない側のCCは無接続でした。

なので、デバイス側（自作機器）で片側しかつながない場合、ケーブルの裏表が一致すればうまく通信できますが、

裏返ってしまうと高速差動通信ができなくなってしまいます。

USB2.0のD+/D-は接続されているのでUSB2.0では通信可能です。

裏返った場合、CCのプルダウンが無接続になるので、ホストがしっかりしていれば電力を供給してくれないかもしれません。私が試した環境ではType-A Cで変換していて所詮はType-Aなので電力は供給してくれますが、Type-C Type-Cでつなぐとダメかもしれませんね。

結論を言うと、

• USB3.0に対応したデバイス(機器)を作る場合は、片側だけ結線しておくのはダメ
• ちゃんとマルチプレクサ(スイッチャ)を使って両方をつなぐべき

特定の顧客向けの機器で「速度が出なければ裏返してください」で許してくれるならば片側結線でもいいんじゃないかと思いますが、市販する装置を作る場合はちゃんとマルチプレクサを使いましょう。

問題は、今の半導体不足の世の中でUSB 3.0のマルチプレクサが手に入るかどうかなんですよね・・・

USB Type-Cの徹底解説^H^H解析(1)

トラ技2020年2月号にUSB Type-Cの徹底解説という特集がありますが、これを読んでも、USB Type-Cの使い方が全然わからないので、自分で調べることにしました。

私が本当に知りたいことは「USB3.0 SuperSpeedで動くType-Cのターゲット側を自作する場合の結線方法」なのですが、トラ技を読んでもケーブルの作り方と、USB2.0機器の結線方法、USB3.0のEZ-USB FX3をType-Bで使う記事はあるのですが、本当に知りたかったことは書いてありませんでした。（せっかくEZ-USB FX3を使うならば、FX3のターゲットボードを自作してType-Cのコネクタを乗せるくらいのことはしてほしかったのですが・・・）

さらに、もっと知りたいことは、「USB 3.1 Type-C 機器を作るに場合には、マルチプレクサは絶対に使わなきゃいけないのか？」ということです。

直結するのはNGだとしても、片側だけつないでおけばなんとかならないだろうか・・ということです。だいいち、世の中のUSBホストなんてほとんどがType-Aで、変換ケーブルかましてType-Cにしているわけですから、高速差動配線なんて所詮片側しか使っていないんです。

というわけで、秋葉原に行って使えそうなアイテムを買ってきました。

USB 3.0のType-A C変換ケーブル、秋月のUSB Type-C変換基板、USB 3.0のType-B C変換ケーブルです。

秋月の変換基板はこれ。（ピンヘッダは付けていません。）

千石で買った変換ケーブルの中で、Type-BとCの変換というのがあって、これがすごく役立ちました。

どう役立ったかというと、ケーブルをバラします。

そしてUSB 3.0のType-Bが出ているFPGA評価ボードに挿して、どこに配線がつながっているかを調べます。

次にUSBケーブルのType-C側を秋月の変換基板に挿して、配線の色と端子の照合を行います。

結果は

赤:VBUS 黒:GND 緑:D+ 白:D- 青:RX2- 黄色:RX2+ 橙:TX2+ 紫:TX2- 透明:GND

でした。

CC2とVBUSの間には56kΩくらいの抵抗が入っているようです。

ケーブルの結線が分かったので、切断したケーブルのType-Bの側を変換基板に挿して動かしてみると・・・見事に失敗！

• Type-Cをある側にしたときには、USB認識されず
• Type-Cを裏返したときには、USB 2.0の速度しか出ない

でした。

もしやと思い、TXとRXを入れ替えてみると見事に動きました。（TXとRXをクロスしなければならないとは・・💦。Type-B-Cだから、か）

速度もちゃんと346MByte/sとか、SuperSpeedの速度が出ています。

ただしUSB Type-Cのコネクタを裏返すと、48MByte/sぐらいにまで落ちてUSB2.0になってしまいました。

それから、ケーブルのちょっとした状態の違いでUSB3.0の通信が不安定でエラーが頻発するときがあります。変換基板の配線が高速差動信号を考慮していないのが原因ではないかと思われます。

以上の結果から、市販の変換ケーブルの結線がどうなっているか、自作機器をどうすればよいかがわかってきました。

続きは明日のブログで！！

Gitlabをやめ、Githubに移行した

特電ではいくつかのプロジェクトをgitで管理していて、某サーバ業者で借りたVPS上にgitlabを立ててリモートにレポジトリをアップロードして複数の人で共有していました。

ただ、gitlabは結構重いのでそこそこのランクのサーバが必要になるし、そもそも従業員がいないのでリモートで管理する必要がないので、gitlabのサーバを手放すことにしました。

gitlabからgithubに移行する際には、

git clone --mirror https://<旧サーバ上のURL>/<レポジトリ名>.git

と、mirrorを付けてcloneする。(これをするとHEADとかいうファイルが作られるらしい)

それからgithubで新しいレポジトリをprivateで作り、

cd <レポジトリ名>.git
git remote remove origin
git remote add --mirror=push origin https://github.com/<新しいレポジトリ名.git>

をやってremoteを設定しなおす。もしくは、

git remote set-url origin https://github.com/<新しいレポジトリ名.git>

でremoteを設定しなおして、 

git push

で新レポジトリにアップロード。

という手順でよいのかなと思います。

より高度な機能やissueなどを使っている人はこれだけでいけるのかどうかわかりませんが、私の場合はあまり高度なことをしていないので、更新履歴も含めて全部アップロードできたようです。

githubに移行したとはいっても、やはりgitは、更新履歴を見るツールとしてしか使っていません。

ローカルPCと社内RAIDのファイルが絶対のマスターなんですよね。なぜならば、ファイルの作成日付を重要な情報として使っているからです。gitに上げた瞬間から作成日付がなくなってしまうのがどうしても許せないので、gitにすべてをゆだねる気にならないのです。

USB 3.1をType-Cにする方法のお勉強

USB 3.1をType-Cにする方法を調べてトラ技2020年2月号を読んでいます。

が、初見では読んでも、さっぱりわからない(^^

何度か読みながら、とりあえずコネクタの絵を自分でも描いてみる。

Type-CのケーブルにはB6とB7のD+/D-の線がなく、B5のCC2はVconnになっている。

ホストがCC1/2をプルアップし、デバイスがCC1/2をプルダウンする。ケーブルの中でCCはつながっているけど、Vconnはつながっていなくてプルダウン抵抗が入っているので、ケーブルの裏表がわかるということらしい。

P51の図9によればUSB2.0のType-BをType-Cに変換するには裏表のD-とD+を相互につなぐらしい。D-とD+をつないでしまっていいのだろうか？図にするとこういうことになる↓

しかし、図9はCC1がVBUSにつながってて、VBUSを抵抗でプルダウンしているので、あきらかにおかしい。図9の回路図自体に誤植がたくさんあるということもあり得る🤔 

USB3.0のType-BをType-Cに変換するにはD-とD-、D+とD+を裏表でクロスしてつなぐらしい。これなら納得がいく。2組ある高速差動信号は直結するのではなくスイッチャでマルチプレクスしなければならないらしい。ひぇぇ、ICが増えてしまう・・勘弁してくれ・・

ただし、ダイレクト・コネクト・デバイスの場合はCC信号を片側だけ(CC1だけ)プルダウンしてTX1とRX1だけを使えばよいらしい。

ダイレクト・コネクト・デバイスの説明としてトラ技P52に「写真３に示す．本体とプラグが一体化したUSBデバイス（USBメモリが代表的）は、・・」とあるが、写真がない。うーん。

トラ技以外の資料としてマクニカさんのWebを見てみるとダイレクト・コネクト・デバイスの例はないが、ポートコントローラのTUSB320LAIを使う例が載っている。なお、USB2.0の場合の接続はD-とD-、D+とD+だった。やはりトラ技の回路図が誤植なのかもしれない。

追加のICを使わずにUSB 3.0をType-Cにしたい場合にはダイレクト・コネクト・デバイス とやらにワンチャン賭けるしかないのだろうか。

ZYNQで使えるUSB ULPIのドライバIC

ZYNQでUSBを使うにはULPIというインタフェースICを使う必要があります。

ULPIってなんじゃ？LinuxのカーネルをコンパイルしていてもULPI,ULPIって「うるぴー」って言いたくなります。

ULPIとはUTMI+ Low Pin Interfaceの略で、UTMI+はUSB2.0 Transceiver Macrocell Interfaceの略です。つまり、USB2.0 Transceiver Macrocell InterfaceのLow Pin Interface版がULPIということのようです。

これだと何が何だかわからないので、まずUTMI+ですが、UTMI+の仕様書はIntelが出しています。

https://www.intel.co.jp/content/www/jp/ja/products/docs/io/universal-serial-bus/usb2-transceiver-macrocell-interface-specification.html

で読むことができます。USBの通信をパラレルで送信するための規格がUTMI+で、それを少ないピンで実現するバージョンがULPIです。UTML+が54本の信号なのに対してULPIは12本で済みます。EtherにおけるMIIとRMIIのような関係と言えます。

ZYNQのMIOにULPIをつなぐ際にULPI用のトランシーバとしてMicrochip社のUSB3320を使うのが定番になっています。

DATA[7:0]のほか、STP、NXT、DIRという信号があり、ULPIのインタフェースICからFPGAに対してCLKが送られます。

さて、ZYNQで使えるULPIといえばUSB3320が定番だったのですが、USB3320は品薄で、現時点で注文しても来年の3月まで入荷することができません。そこでUSB3320の代わりになるデバイスを探す必要が出てきました。

Digikeyで「ULPI」や「USB Transceiver」をキーワードに検索してみると、

• STULPI01BTBR (ST)
• USB3311 (Microchip Technology)
• USB3314 (Microchip Technology)
• USB3315 (Microchip Technology)
• USB3316 (Microchip Technology)
• USB3317 (Microchip Technology)
• USB3318-CP (Microchip Technology)
• USB3319 (Microchip Technology)
• USB3320 (Microchip Technology)
• USB3340 (Microchip Technology)
• USB3343 (Microchip Technology)
• CY7C68003 (Cypress)
• TUSB1210 (Texas Instruments)
• STULPI01A (ST)
• FUSB2805 (Onsemi)
• ISP1504 (NXP)

と、いくつかの候補が出てきます。MicrochipにはUSB3320以外にもいろいろ候補があるようですね。

この中のどれが実際に使えるのかというと、Linuxでどれがサポートされているかというのを知る必要があります。Linuxのソースを読んでみると、https://github.com/Xilinx/linux-xlnx/blob/master/drivers/usb/phy/phy-ulpi.c に定義されています。

/* ULPI hardcoded IDs, used for probing */
static struct ulpi_info ulpi_ids[] = {
	ULPI_INFO(ULPI_ID(0x04cc, 0x1504), "NXP ISP1504"),
	ULPI_INFO(ULPI_ID(0x0424, 0x0006), "SMSC USB331x"),
	ULPI_INFO(ULPI_ID(0x0424, 0x0007), "SMSC USB3320"),
	ULPI_INFO(ULPI_ID(0x0424, 0x0009), "SMSC USB334x"),
	ULPI_INFO(ULPI_ID(0x0451, 0x1507), "TI TUSB1210"),

};

なんと、NXP1504、USB331x、USB3320、USB334x、TUSB1210しかサポートされていないようです。(上のファイルに定義を追加すればどれでも認識されるとは思うが、冒険する気にはならない)

ISP1504はDigikeyで扱っていないので×。TUSB1210はDigikeyには在庫はないのですがメーカー在庫はありそうですが即納はできなさそう。

そうするとUSB3318あたりが候補になってくるのかなという感触です。

では、Microchip社のUSB PHYはどこがどうちがうのかというと、データシートを見比べれて差異を読み取ってみました。

まず、いずれの製品も

• USB 2.0 HighSpeed
• ULPI 1.1
• On-The-Go Supplyment 2.0
• FS preampleはUTMI+ level3 (?)

という仕様のようで、USB PHYの基本機能としてはどれも同じように使えるようです。

USB3340はBattery Charging 1.2 Specificationに対応していてバッテリが関わって来る場合に選択肢になるのでしょう。

USB331xは2008年ごろにまだSMSC社だったころの製品で、USB3320はMicrochip社になってからの新しい製品であるようです。USB3320は様々な周波数のリファレンスクロックが選べます。

USB331x内での相違点は、

• USB3310 1.8V I/O, Switchなし, 24QFN, クロックは13, 19.2, 24 or 26MHz
• USB3311 1.8V I/O, Switchなし, 24QFN, 26MHz
• USB3315 1.8V-3.3V I/O,  Switchなし, 24QFN, 24MHz
• USB3316 1.8V I/O, Switchあり, 24QFN/25BGA, 19.2MHz
• USB3317 1.8V-3.3V, Switchなし, 24QFN/25BGA, 26MHz
• USB3318 1.8V-3.3V, Switchなし, 24QFN, 13MHz 
• USB3319 1.8V I/O , Switchあり, 24QFN/25BGA, 13MHz 
  
  

つまり、USB331xシリーズの中の違いは、I/O電圧と、USB Switchの有無、外部クロックの周波数にあるようです。SMSC/Microchip社のUSB PHY特徴としてはCarkit（UARTモードやオーディオモードになる）というのがあるようですが、詳しくはわかりません。

結論を言うと、ド定番のUSB3320は来年まで入手できないので、USB3318などの他のICを使うしかなさそうです。型番が違ってもおまけ機能的な違いであって、USB PHYとしては機能するように見えます。

再掲になりまｓが、Linuxのカーネルがデフォルトで対応しているのは、

• NXP ISP1504
• SMSC USB331x
• SMSC USB3320
• SMSC USB334x
• TI TUSB1210

です。

選択肢はいろいろあるように見えますが、TIのTUSB1210も半導体不足のため来年まで入手できません。ISP1504はDigikeyでもMouserでも扱っていないようなので、結局はSMSCのUSB331xを使うしか他に選択肢はなさそうです。

このICの在庫が尽きなければZYNQでウルピーを使う回路がまだ作れそうです。

ZYNQ+Ubuntu 18.04LTSで5GのWiFiの速度を測定

ZYNQのUbuntu Linux 18.04LTSでWiFiが動くようになってきたので、速度を測ってみました。

回路の構成は以下のようになっています。

ZYNQのMIOから出てきた8bit 60MHzのパラレル＆制御信号をUSB3320でUSBの普通のD+/D-のバスに変換します。そこからLAN9514というUSB HUB&LANのICを使って100BASEのEthernetと、4つのUSB2.0 HighSpeedポートを出します。このUSB2.0のポートにUSB WiFiをつなぎます。

使用したUSB WiFiは2.4GがWDC-150SU2MBK、

5GはWDC-433SU2M2です。

速度の測定はローカルネットワークとWANの両方で行います。

ZYNQのUbuntu Linux上で16～256MByteの乱数を発生させてそれをファイルに保存しておき、ローカルネットワークにWindows10のIISで動くFTPサーバとの間の転送速度を測ります。（Ubuntu上でのファイルはRAMDISKに格納しておきます。そうしないとSDカードの転送速度を測ってしまうことになるからです。）

測定結果は以下のとおりでした。

3～4回ほどFTPでファイル転送を行い、最もよかった値を記しています。あまりファイルサイズと転送速度に相関関係はないようです。有線無線といろいろあるので、実際の通信路では何ビットでエンコードされているかはわかりませんが、1バイト=8bitとすると、

• 2.4GHzのUSB-WiFiは約15Mbps
• 有線LANは約90Mbps
• 5GHzのUSB-WiFiはPUTが140Mbps、GETが100Mbps

となりました。

有線の100BASEは100Mbpsで頭打ちですが、無線の5GはUSBの480Mbpsの速度まで出せるはずなので、無線の方が速いようです。

それから、speedtestというツールを使ってWANにもつないでみました。サーバはいろいろ選べるようなので、OPEN ProjectのSINET接続という強そうなものを選びます。

まずは有線

root@cszmini:~# speedtest -s 15047
Speedtest by Ookla
Server: OPEN Project (via 20G SINET) - Tokyo (id = 15047)
ISP: Softbank BB
Latency: 3.31 ms (0.64 ms jitter)
Download: 81.86 Mbps (data used: 145.3 MB)
Upload: 84.86 Mbps (data used: 70.4 MB)
Packet Loss: 0.0%

次は無線2.4G。

root@cszmini:~# speedtest -s 15047
Speedtest by Ookla

Server: OPEN Project (via 20G SINET) - Tokyo (id = 15047)
ISP: Softbank BB
Latency: 4.39 ms (0.58 ms jitter)
Download: 21.54 Mbps (data used: 12.7 MB)
Upload: 21.30 Mbps (data used: 34.7 MB)
Packet Loss: 0.0%

最後は無線5G

root@cszmini:~# speedtest -s 15047
Speedtest by Ookla
Server: OPEN Project (via 20G SINET) - Tokyo (id = 15047)
ISP: Softbank BB
Latency: 7.42 ms (0.56 ms jitter)
Download: 51.36 Mbps (data used: 67.6 MB)
Upload: 81.65 Mbps (data used: 142.9 MB)
Packet Loss: 0.0%

結果を図にすると、有線の100Mと無線5Gはアップロードに関してはほぼ同じスループットが出ています。

WANとLANで結果が少し異なるのは、遅延時間が効いてきているのかもしれません。

ZYNQ Ubuntu 18でELECOM WDC-433SU2M2(5GHz)を動かす

手元に5GHz帯に対応したUSB-WiFiのELECOM WDC-433SU2M2があったので、ARM版Ubuntu 18.04で動かないかどうか試してみました。

もちろんLinuxのカーネルに最初からこのUSB-WiFiのドライバが入っているわけではないので、有志が作ったものをダウンロードして自分でビルドすることになります。このUSB WiFiのドライバは下記のURLからgitcloneしてきます。

git clone https://github.com/gnab/rtl8812au/

ビルドするには

export CROSS_COMPILE=arm-linux-gnueabihf-

で環境変数を設定して、

cd rtl
cd rtl8812au/
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- KSRC=<Linuxカーネルのパス>

でできます。

出来上がった8812au.koをターゲットマシンにscpか何かでコピーして、insmod 8812au.koでインストールできます。

このときに、Linuxのカーネルを構築したときのフォルダ(数ギガバイトある)を指定しなければならないので、USB WiFiドライバだけをターゲット上でビルドするというわけにはいきません。

さて、WDC-433SU2M2のドライバはRealTekのRTL8812というものなのですが、このようにしてビルドしてもそのままでは動きません。なかなかハマったのですがlsusbで見てみるとWDC-433SU2M2のUSBであるVID 0x056E、PID 0x400Eの組み合わせが登録されていないようでした。

0x056E 0x400Eで検索すると、このページがみつかりました。

「GitHub gnabのrtl8812au driverには2019-07に更新があった」

rtl8812au/os_dep/linux/usb_intf.cの305行目付近に

{USB_DEVICE(0x056E, 0x400E),.driver_info = RTL8821}, /* ELECOM - WDC-433SU2M2 */

を追加すればよいようです。

これでビルドしてできた8812au.koをinsmodしたら、全くハマることなくインストールできて無線LANを認識できました。

Cosmo-Z MiniのOSをUbuntu18にアップデートする

あるお客様から、Cosmo-Z MiniでWiFiを使いたいというご要望をいただきました。

Cosmo-Z MiniはもともとUbuntu14.04がインストールされていて、Ubuntu 14で認識するGW-USNANO2AというUSB-WiFiが付属していたのですが、そのUSB-WiFiが入手できなくなってしまいました。

現在入手可能なWDC-150SU2に置き換えたのですが、Ubuntu 14では認識できないのでUbuntu18にアップデートする必要がでてきたのです。

やり方としては、「Zynqberry(ジンクベリー)にUbuntu 19をインストール」の記事を見ながら、Ubuntu18の綺麗な状態のSDカードを作ります。

ホストPCでSDカードをマウントしてQEMUでセットアップするのですが、気になったのですが、

sudo mount -o loop /dev/sdb2 /mnt

と、マウントするときにloopbackデバイスとしてマウントするのですね。なぜなのでしょう。SDカードをマウントするときになぜloopを付けるのだろう。うーん🤔

途中まではだいたい同じです。

そして、Cosmo-Zのインストールですが、

• /etc/rc.localを作る
• Cosmo-Zから/var/wwwフォルダ一式を持ってくる
• apache2のセットアップ
  
  • /etc/apache2/sites-available/000-default.confを書き換えて、DocumentRoot /var/www/を設定する。また、Directory /var/www/でCGIが実行できるようにする
  • /etc/apache2/conf-available/serve-cgi-bin.confを編集して、ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/以下の6行をコメントアウトする。デフォルトでは/usr/lib/cgi-binしかCGIを実行できない
  • a2enconf serve-cgi-bin.conf
  • sshdの設定
• sambaのインストールと設定
• emacsのインストール
• .vimrcに以下の設定をする。これをしないとviの先頭が文字化けする
  set encoding=utf-8
  set fileencodings=iso-2022-jp,sjis,utf-8
• /home/shareの作成
• /home/share/autorunと/home/share/setupの作成
• /home/share/CosmoZPy/フォルダを持ってくる
• chmod 777 pngwave.elf をしないとWeb画面で波形が表示されない
• update-cszminiが動くようにする。動かない場合はフォルダを作ったりフォルダのパーミッションを変えたり
• sudo apt-get install usbutilsでUSBユーティリティのインストール

と、いろいろな設定がありました。

困ったことは、私が使っているCosmo-Z Miniは試作機なのでEEPROMの配線が間違っていて、LAN9514のMACアドレスが固定されません。そのため、DHCPでつなぐたびにIPアドレスが変わってしまいます。（お客様に出荷したものはEEPROMを修正済み）

LAN9514のMACアドレスをLinuxのコマンドから固定する方法があればいいのですが・・と思っていたらnetplanに書いておけばよさそうでした。

sudo vim /etc/netplan/50-cloud-init.yaml

network:
    version: 2
    renderer: networkd
    ethernets:
        eth0:
            dhcp4: yes
            dhcp-identifier: mac
            macaddress: 02:11:10:00:22:01
            dhcp6: no
            #addresses: [192.168.1.80/24]
            #gateway4: 192.168.1.1
            #nameservers:
            #addresses: [192.168.1.1, 8.8.8.8, 8.8.4.4]

これでセットアップはうまくいったのですが、IoT機器独自の起動スクリプトのようなものを書きたい場合、いままではrc.localに書いておけばよかったのですが、本来はサーバスクリプトを作って番号付けてsystemdから起動するということをするべきだそうです。まぁ、Ubuntu18でもrc.localでも動くのですが、いずれ対応しないといけないですね。

 

さて、本命のUSB-WiFiを動かそうと8188eu.koをinsmodすると、

root@cszmini:/home/share# insmod 8188eu.ko
insmod: ERROR: could not insert module 8188eu.ko: Invalid module format

とエラーが出てうまくいきませんでした。

Zynqberry用に作ったkoファイルだからダメなのかもしれません。もしかするとカーネルごとに作り替えなければならないのかもしれません。

MITOUJTAGのJTAGスクリプトでレジスタを直接操作できるように拡張中

MITOUJTAGの今後のバージョンアップ方針の第一はJTAGスクリプトの拡張です。

今日はJTAGスクリプトのこれまでのマイナーなアップデートで何を更新してきたのかを整理して、JTAGデバイスのプライベート命令を発行したり、プライベートレジスタを操作したりできるよう、機能の拡張を図っています。

まずは、以下のようなコードを実行できるようにすることを考えました。

chain->devices[0]->ir->set("EXTEST");
chain->devices[1]->ir->send("BYPASS");
chain->devices[0]->dr->setlen(122);
chain->devices[1]->dr->setlen(1);
chain->devices[0]->dr->set(0x55,100,8);
chain->devices[0]->dr->send(0,0,12);

まぁ、JTAGの操作が間違いなくできそうな感じのコードです。

ただ、いかにもC++の書き方で、chainとかdevicesとか毎回書くのも煩わしいです。

スクリプトというからにはもっと簡単にしたいですね。

JTAGスクリプトは、=でレジスタの値のセット、<=でセットとシフト(入出力)という規則で動いていたので、以下のような文法でできないかどうかを考察してみます。

IR[1]  = "BYPASS"; // 2番目のデバイスのIRにBYPASSをセットすることを予約
IR[0] <= 0x01;     // 1番目のデバイスのIRに0x01をセットし、IR SHIFT
DR[0].len = 122;   // 1番目のデバイスのDRの長さを122に変更
DR[1].len = 1;     // 2番目のデバイスのDRの長さを1に変更
DR[0](107 downto 100) = 0x55; // 1番目のデバイスのDRの[107:100]に0x55をセット
DR[0] <= 12; // 1番目のデバイスのDRの下位32bitに0x12をセット

関数でsetとsendを使い分けるよりも見やすくなります。N+1番目のJTAGデバイスのレジスタにDR[N]とIR[N]でアクセスできるようにするのも、いいと思います。

このような文法でうまくいきそうな気がしたのですが、JTAGのデータレジスタの長さは任意長でだいたい長いんですよね。デバイスごとにみんな違いますが、100ビットとかざらにある。それに対してC++だと扱える整数は32bitとか64bitだから、どうしても、どこからどこまでのレジスタに値をセットするかという機能が簡単に使えないと、使いにくい言語になってしまいます。

別の考えをしてみます。JRegというJTAGレジスタ型のクラスがあったとして、

JReg dr = DR[0]; // 最初のデバイスのデータレジスタ

これをどう考えるかです。=をオーバーロードするのは当然として、データの実体をコピーするのか、実体は元のオブジェクトに残して参照するだけにするのか。

また、データレジスタの操作は

dr[100] = 1; // データレジスタのbit 100を1にする。

のように1ビットだけ操作する場合もあるのですが、たいていは長いビット列を設定する場合です。

任意の長さのビットを操作するための簡潔な記述ってどうやればいいのでしょう。

dr(200 downto 100) = 0; // bit100～200までの101ビットを操作 (downtoを,に#defineで置換)
dr(200,100) = 0; // bit100～200までの101ビットを操作
dr(200) = 0; // bit200のみ1ビット操作
dr = 0; // 全ビットを操作

この書き方のほうがいいかもしれませんね。

そうして、

JReg tmp(64); // 64bitのレジスタを作成

tmp = 0x12345678;
tmp(63,32) = 0xaabbccdd; // tmpに0xaabbccdd12345678をセット
dr(200) = tmp; // bit263..200にtmpの値を代入

うん。いいかも。

切り出しは、

JReg slice = dr(200,100);

で、101bitのレジスタができる。

このようなことができるJReg型を作ればよさそうですね。

MITOUJTAGの最終バージョンアップに向けて

喫茶店に籠って今後のMITOUJTAGバージョンアップの方針を練っていました。

現時点でのMITOUJTAGの最新版バージョンはMITOUJTAG Pro 3.4.2で、2019年4月のリリースです。なんと最後のバージョンアップから2年以上も空いてしまいました。

今後のやりたいことなどの構想をまとめていたのですが、使用しているコンパイラがBorland C++ Builder 6という超古いものなので、どうにもなりません。

とりあえず、現在のMITOUJTAGの拡張はあと数回のバージョンアップで終了し、MITOUJTAGは「完成」としようかと思います。

Version 3.5(PROのみ)

AJFG(JTAGスクリプトのこと)のアップデートがメインです。
2021年8月にリリースできるように頑張ります

• AJFGでプライベート命令の発行、BSR操作、データレジスタの操作ができるようにする。
• AJFG用にMinGWを内包し、デフォルトのコンパイラをMinGWにする。
• Windows10＋VC2019の組み合わせでユーザが設定に苦労せず動作するようにする。
• AJFGのリモート接続機能。すなわち、ユーザが作ったアプリからMITOUJTAGを操作するためのDLLを提供する。

Version 3.6(BASIC,PRO)

2021年の11月ごろのリリースを目指します

• JTAGケーブルにMPSSEとXVCを正式対応
• JTAGケーブルにTCP/IPリモート接続を追加
• これまでのマイナーなアップデートの累積的な更新
• BSDLデバイスデータベースの更新

Version 3.7(PROのみ)

2022年春のリリースを目指します。実質的な最終バージョン。

• XVCサーバモードのリリース。VivadoからMITOUJTAGを介して様々なJTAGケーブルを操作できるようにする。
• XVC操作手順の記録

以後のバージョンアップは軽微なバグフィックスのみ行います。

Version 3.8(PROのみ)

追加的な最終バージョン。リリースするかどうか未定です。

• Python3のリモート接続インタフェースを提供。Pythonから基板検査ができるようにする

2003年に開発を開始したMITOUJTAGは18年かけて完成し、晴れて開発終了となります。

開発終了といってもJTAGソフトの開発やJTAGの探求を終わりにするのではなく、C#に移行するため今までのコードを破棄して全面的に作り直すことにします。

もちろん、MITOUJTAGのライセンスをお持ちの方は次のソフトへも引き継げます。

その次のMITOUJTAGをMITOUJTAG 4.0にすると4が日本的には縁起悪いし、5も風水的によくないので、何か新しいよい名前に変えたいと思っています。

MITOUJTAG CSとか、MITOUJTAG NXとか・・。

そもそもMITOUJTAG(みとうジェイタグ)って読めない。電話でお問合せが来て「御社の製品でなんて読むんですか？ミト？ミ・・ミ・」なんて言われたりします。

何かいい名前はないでしょうかね（笑）

JTAGスクリプトのコンパイラでMinGWを使う

MITOUJTAG ProにはJTAGスクリプトという機能が備わっています。

JTAGスクリプトを使うとC++で簡単にバウンダリスキャンの手順を書くことができるのですが、その実体は、裏で汎用のCコンパイラが動いてスクリプト（C++のプログラム）からDLLを作成するという仕組みになっています。

CコンパイラにはBorland C++、Visual C++、MinGWなどが使えるのですが、ここではWindows 10の環境でMinGWを使う方法を説明します。MinGWはオープンソースであり自由に使えるので、今後のJTAGスクリプトの標準にしようかと思っています。

このたび、MITOUJTAG Proをお買い上げいただいたお客様から、「JTAGスクリプトを起動するとJSMファイルが見つかりませんと一瞬表示されて起動しない」というお問合せがあったので、Windows10とMinGWでの動作を検証してみました。

まず、MinGWのダウンロードとインストールは基本的には「AJFGをMinGWで使う場合の導入方法」のページに書いたとおりです。ただ、書いた当時と少し変わっていて、PCの環境変数の設定が、Windows 10では「Windowsボタンを右クリック」→「システム」→「システムの詳細設定」と操作します。

システムのプロパティが出たら、環境変数のボタンを押します。

そして、ダイアログの上の側のユーザ環境変数のところのPathと書かれた行をクリックします。

ここで新規を押します。

MinGWをインストールしたフォルダのC:\MinGW\binを入力します。

環境変数にMinGWが追加されれば成功です。

これだけで基本的にはOKでした。

では起動しようとしたときに「必要なモジュールが見つかりません」というエラーはなぜ出るのでしょうか。

作られたJSMファイル(DLL)をDependencyで見てみると、MinGWの提供しているlibgccやlibstdc++などのランタイムを必要とするようなDLLになっていることがわかります。

上記の手順で環境変数を設定していれば、JTAGスクリプトの実行時にこれらのMinGWのランタイムを見つけることができるのですが、環境変数を設定しなくてもMinGWのコンパイルだけはできるように、MITOUJTAGの側で設定されていたのです。

それが、MITOUJTAGをインストールしたフォルダの C:\Program Files (x86)\Tokudenkairo\MJ3Pro\ajfg\sys にあるcompile.mgwというファイルです。

C:\MinGW\bin\g++ -I"$SYSPATH" -I"$SYSPATH\..\lib" -L"$SYSPATH" -shared -o $TARGET $SOURCES "$SYSPATH\jsenv_mingw.a"

という内容が書かれていて、MinGWでコンパイルするときにはC:\MinGW\bin\g++を実行することが明示的に書かれています。このファイルに絶対パスでC:\MinGW\bin\g++と書かれていたので、環境変数の設定をしなくてもコンパイルは通ってしまうけど、実行時のDLLが見つからないという事態になってしまうようでした。

なお、g++の設定でオプション -static を指定すると、上記のランタイムが埋め込まれるようです。

そのため、compile.mgwの2行目を絶対パスなしの

g++ -I"$SYSPATH" -I"$SYSPATH\..\lib" -L"$SYSPATH" -static -shared -o $TARGET $SOURCES "$SYSPATH\jsenv_mingw.a"

に書き換えるとさらに良さそうです。

なお、MinGWはダウンロードしてインストーラからインストールしなくてもよく、環境変数のpathがMinGW\binフォルダに通っていればコンパイルができるようでした。お手軽ですね。

MITOUJTAGのJTAGスクリプトをWindows10x64+VC2019で動かしてみる

MITOUJTAG ProにはJTAGスクリプトという機能があります。

C++でJTAGバウンダリスキャンを操作できるように拡張したものなのですが、バックグラウンドでは汎用のC++コンパイラを使って動かすようになっています。

汎用のC++コンパイラというのは、Borland C++や、MinGW、Visual C++などですが、もともとこの機能を作ったのが10年以上前なので、今のWindows 10 x64とVisual Studio 2019(Visual C++)でも動くのかどうかを確かめてみました。

まず、新しいマシンを用意する・・のは大変なので仮想マシンにWindows 10x64とVisual Studio (+VC)を入れ、MITOUJTAG Pro 3.4.2をインストールします。

特電のSpartan-6ボードのデバイスドライバを入れ、USBをつないで認識させてみると、ちゃんと認識して可視化されます。

ここで、チュートリアルにしたがってJTAG Scriptを作成し、コンパイラをVC2019を選択してコンパイルしてみると・・

どうやらうまくいかないようです。

2021/08/06 17:45:00  ------------------------------コンパイル開始-------------------------------
C:\Program Files (x86)\Tokudenkairo\MJ3Pro\projects>del "C:\Users\user\Documents\MITOUJTAG3\default.jsm" 

C:\Users\user\Documents\MITOUJTAG3\default.jsm が見つかりませんでした。
C:\Program Files (x86)\Tokudenkairo\MJ3Pro\projects>call "VsDevCmd.bat" 
'"VsDevCmd.bat"' は、内部コマンドまたは外部コマンド、操作可能なプログラムまたはバッチ ファイルとして認識されていません。
C:\Program Files (x86)\Tokudenkairo\MJ3Pro\projects>cl /LD /I"C:\Program Files (x86)\Tokudenkairo\MJ3Pro\ajfg\sys" /I"C:\Program Files (x86)\Tokudenkairo\MJ3Pro\ajfg\sys\..\lib" /Fe"C:\Users\user\Documents\MITOUJTAG3\default.jsm" "C:\Users\user\Documents\MITOUJTAG3\noname.cpp"  "C:\Program Files (x86)\Tokudenkairo\MJ3Pro\ajfg\sys\jsenv_vc.lib" 
'cl' は、内部コマンドまたは外部コマンド、操作可能なプログラムまたはバッチ ファイルとして認識されていません。

2021/08/06 17:45:01  ------------------------------コンパイル終了-------------------------------
2021/08/06 17:45:01  AJFGスクリプトの翻訳でエラーが発生しました

MITOUJTAGはVisual C++のclを起動しようとして環境変数設定用のVsDevCmd.batを実行しようとするのですが、%VS160COMNTOOLS%という環境変数が設定されていないため、デフォルトのインストール状態では起動できないようです。

なお、Visual Studio 2015のころの%VS140COMNTOOLS%や、2017のころの%VS150COMNTOOLS%はシステムの環境変数として登録されていたと思うのですが、VS 2019をインストールしても%VS160COMNTOOLS%は定義されていなかったようです。こういった環境変数がVisual Studioのいつまで使えていたのかどうかはわかりません。

MITOUJTAGが外部ツールを呼び出してJTAGスクリプトをコンパイルするための手順は、C:\Program Files (x86)\Tokudenkairo\MJ3Pro\ajfg\sysにバッチファイルのひな型として用意されています。

この中のcompile.vc2019をメモ帳などで編集します。もともと下記のようなファイルになっているので、

del $TARGET
call "%VS160COMNTOOLS%VsDevCmd.bat"
cl /LD /I"$SYSPATH" /I"$SYSPATH\..\lib" /Fe$TARGET $SOURCES "$SYSPATH\jsenv_vc.lib"

この2行目の%VS160・・%の行を絶対パスで

call "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\Tools\VsDevCmd.bat"

に書き換えます。

こうするとVsDevCmd.batが呼び出すことができるようになって、コンパイラが起動するようになります。

しかし、permission deniedというエラーメッセージが出て止まってしまいます。

ログを見ると、起動コマンドとエラーメッセージは以下のとおりです。

cl /LD /I"C:\Program Files (x86)\Tokudenkairo\MJ3Pro\ajfg\sys" /I"C:\Program Files (x86)\Tokudenkairo\MJ3Pro\ajfg\sys\..\lib" /Fe"C:\Users\user\Documents\MITOUJTAG3\default.jsm" "C:\Users\user\Documents\MITOUJTAG3\noname.cpp" "C:\Program Files (x86)\Tokudenkairo\MJ3Pro\ajfg\sys\jsenv_vc.lib"
・・・
C:\Users\user\Documents\MITOUJTAG3\noname.cpp : fatal error C1083: コンパイラの生成した ファイルを開けません。'C:\Program Files (x86)\Tokudenkairo\MJ3Pro\projects\noname.obj':Permission denied

noname.cppというファイルをコンパイルしてnoname.jsmを作るのですが、途中でnoname.objというオブジェクトファイルを作るカレントディレクトリがファイルを作成できないところにあるためと思われます。

BorlandのVCLライブラリのGetCurrentDirを呼び出してしらべてみると、

2021/08/06 18:47:33 GetCurrentDir=C:\Program Files (x86)\Tokudenkairo\MJ3Pro\projects

と、Program Files (x86)の配下の、プログラムをインストールしたディレクトリを指していました。

昔のWindowsのソフトならこれでも動いたのですが、さすがにWindows 10時代にはこのフォルダには一時ファイルは作れないですね。

対策方法としては、MITOUJTAGで新しいプロジェクトを始めるときには、「ファイル」メニューの「新規プロジェクトの作成」を行って、

プロジェクトのカレントディレクトリを設定することです。

ユーザデータフォルダ、C:\Users\<ユーザ名>\Documents\MITOUJTAG3\ の配下にプロジェクトのフォルダが作られて、そこをカレントディレクトリにするので、permission deniedが出なくなります。

Pocket JTAG Cableの再製造（２）

プラスチックケースの在庫が尽きたという問題で、次の製造をどうするか悩んでいます。

候補としては

• タカチのカスタム加工＋インクジェット
• いままでのシール屋さんに再発注
• ACCEAさんで即日シール製造

があるのですが、少し進展がありました。

まず、ACCEAさんで作ったシール。

さすがオンデマンド印刷。早いですね。

ケースに貼ってみると、

若干、色のムラが気になります。

ラミネート加工していない(ACCEAさんでは透明シールにはラミネートできない)ので、シール全体の厚さが薄く、表面を撫でてもシールの端がひっかかる感じがしないのは良いです。ラミネートしなくても大丈夫なのかという不安はありますが、水をかけたくらいでは全くにじんだりしません。

ただ、専業のシール屋さんのシールと比べてみると、シール屋さんのは色にむらがなく滑らかで、ラミネートされているので強い光沢があります。

やはり2週間かけたシールのほうが仕上がりは綺麗です。

それから、昨日、aiファイルの出力結果が真っ黒になっていると書きましたが、どうやらホワイト加工をしていたようです。デザイナーさんがホワイト加工の部分をレイヤーで分けて、そのホワイトを黒で塗っていたため、全面的に真っ黒に見えたのでした。

なんでホワイト加工したかというと、もともとはタカチのSX-90Aというちょっとクリーム色をしたケースを使っていたのです。シールの緑色とケースのクリーム色が混ざって色合いが変わってしまうので、デザイナーさんがシールが透過しないようにホワイト加工を追加してくれたようなのです。

ホワイト加工というのは、裏が透けないように不透明な白のインクで塗る加工で、これをやると発色がとてもよくなります。

これですべての疑問が解決しました。

あとは、タカチからインクジェット印刷された試作品と、シール屋さんから再製造したシールが届くのを待つのみです。

Pocket JTAG Cableの再製造

特電のMITOUJTAGではPocket JTAG CableというUSB-JTAGを使うのが標準となっています。

しかし、このPocket JTAG Cableで使っているケースの在庫がなくなって製造できなくなっていました。もちろん、プラスチックのケース自体はタカチのカスタム加工品なのでいくらでも作れるのですが、表面に貼っているシールの在庫がないのです。

シールにはコネクタを挿すための角丸の四角い穴があるし、長いこと手に触れて使うものだから擦り減らないように上からラミネートをかけたいところです。

特電の過去の発注履歴を調べたところ2014年に作ったIllustratorのファイルを見ると、通常のaiファイルと、アウトライン化されたと思われるOLと付いたファイルがあります。

印刷屋さんの履歴を見てみると最後に発注したのが2018年。そして印刷屋さんのデータ保存期限が2年とのことです。ステッカー印刷屋さんによれば昔のものなのでデータが残っていないから再入稿してくださいとのこと。

ここで、ちょっと悟りました。印刷物は大量に作ってストックするのではなく半年分くらいにするべきですね。なぜならば「前回と同じのをお願いします」で発注できないからです。それに2014年に作ってくれたデザイナーさんはもういない。

さて、過去の発注履歴を調べて同じ材質を探して、aiファイルを復元して注文するのは大変だぞ・・・

もとい。OLが付いたaiファイルを開くと真っ黒。

なんで真っ黒なんだろう・・・

元のaiファイルを開くと「フォントが見つかりません」の嵐。私の使っていたIllustratorがCS3という超古いバージョンだからかと思い、Adobeの最新版が使えるように申し込んで開いてみても、フォントが見つからない。

KalingaとShurtruというフォントがないようです。

どうやらこれらのフォントはWindows7のころにはあったけれどもWindows10では標準からは抜かれてしまったらしい。

インドの文字のようなのですが、どうやら普通のアルファベットの部分にKalingaを使っている謎。デザインがかっこよかったのかな。

なんとかフォントを見つけてきてインストールしてファイルを開いたものの、フォントが太字か標準かどうかで四角になってしまっていたり、謎の黒い塗りがあったりというありさまでした。

この黒塗りを消して、フォントを修正してようやく最新のIllustratorでエラーなく開けるaiファイルが出来ました。

さて、ケースを作るのですが、どうやらタカチのカスタム加工では、インクジェットで印刷するサービスを行ってくれるようです。

今までどおりシールを作って貼るか、タカチのインクジェットで印刷するか、試作なので全部試してみることにしました。お盆の時期にはいるので少し納期が延びるはずで、

• タカチのカスタム加工＋インクジェット・・・2週間くらい
• 今まで通りのシール印刷・・・2週間くらい
• ACCEAさんでシール印刷・・・1日

というわけで各業者さんにデータを送信して結果を待つことにします。

SAMTECコネクタのはんだ付け失敗！

SAMTECのLSHM-150-04.0-L-DV-A-S-K-TRというコネクタがあるのですが、

実装業者さんが混みあっているとのことだったので、自分ではんだ付けできないかどうか、頑張ってみました。

手元にあるはんだごてステーションはGootのRX-802です。

この半田ごては、コテ先がヒータと温度センサのを内蔵したモジュール式になっていて、いろいろと取り替えることができます。

コテ先が腐食したり、ヒーターやセンサが劣化してダメになってきたら先っちょのモジュールだけ交換すればよいのでとても経済的です。しかも1500円くらいなので安い。

LSHMコネクタは、端子部分の基板からの高さが低いので、隙間に入り込むためには細いはんだごてが必要です。

そこで、以下の3種類を買ってみました。

• RX-80HRT-3K・・・ナイフみたいになっているタイプ
• RX-80HRT-0.5C・・・すごく細いタイプ
• RX-80HRT-SB・・・細いタイプ

その結果ですが、

ものの見事に失敗でした。

基板とケースの間にコテ先を差し込んでも、SBタイプは端子に届かず上のケースにはんだ付けしてしまいます。

ナイフのようなKタイプなら何とか端子に届きますが、金属ケースに付く方が多い。

0.5Cタイプも何とか端子に届きますが、やっぱり金属ケースに付く方が多い。

結局のところ、市販のはんだごてでLSHMコネクタに実装するのは失敗でした。この隙間にはコテ先が入りません。1本2本のはんだ付けなら何とかできるかもしれませんが160本とかやれば不良が出るでしょう。

実装業者さんにリフローしてもらうのが一番ですね。