FTDI より Silicon Labs の USB シリアルを使った方が良い理由

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/58667/3297a13a-190e-d055-0443-8133bfb51639.jpeg" width="75%">


## はじめに

一般にメジャーな USB シリアルデバイスと言えば FTDI の FT232RL だろうと思います。
自分も、最初に購入して使ったのは、このデバイスでした。

このデバイスは、USB シリアルの中では最も成功したデバイスであると思います。

- バリエーションが豊富
- 扱いやすい
- 入手性が良い
- ドライバーなどのカスタム環境が充実している
- サードパーティー製のモジュールが豊富
- ドライバーが安定しており、ＯＳを選ばない
- カスタマイズして、別の用途にも使える

などなど、数え上げればキリが無い程多くのメリットがあります。

難点を上げるとすれば、コストが微妙に高い・・・

みんなが、選択するおかげて、ブランドとして成立しており、多くのメーカーが採用している。

最近、教育用に、組み込みマイコンを扱う小規模ボードを作るのに、もっとコストが安い USB シリアルを探していました。

## Silicon Labs CP2102N

Amazon で、中華製の CP2102 ボードが沢山売られており、購入して、試してみました。

最初、このボードを使う事を考えましたが、CP2102 と CP2102N は、大きく異なる事が判りました。

CP2102 は、１台だけ使うぶんには、そうそう問題は起こらないのですが、複数のデバイスを PC に繋げた場合に、色々なトラブルが発生する事が判りました。

- これは、FTDI では起こりません。
- CP2102 では、異なったデバイスでも、同じデバイスとして認識されてしまい、ＣＯＭポート番号の管理を難しくします。
- この状況を改善する為、ツールがあり、個別のＩＤを設定する事が出来ますが、かなり面倒な作業となります。
- 現状では、CP2102 は、非推奨デバイスとなっており（CP2102N を使え！）ツールを利用する事も難しいです。

そこで、CP2102N を使ったボードを制作して、色々実験してみました。

CP2102N では、個別に ID を設定しなくても、個々にシグネチュアを持っており、デバイスが異なれば、違う物として認識します。
※これで、FTDI と同等で、特に難しい管理は必要ありません。
※CP2102 にあった、COM ポートの乗り移り現象は発生しません。

CP2102N は、FTDI と比べて幾つかの点で優れていると思えます。

- 単価が安い。
- OFN24 で @160 くらい。
- ドライバーの仕様なのか、同じボーレートでも FTDI より高速に転送出来る。
- 後にある参考例として、ＲＸマイコンにシリアルで書き込んだベンチがあります。
- CP2102N でも、FTDI と遜色無く、色々な OS で使える。

## 専用基板の作成

[以前の記事で、PCBGOGO に基板を発注](https://qiita.com/hira_kuni_45/items/4d73299629641779fd86)した物を組み立てました。

QFN パッケージでも、サイド部分にピンが出ており、リフローしなくてもハンダ付け出来るのですが、QFN20 は違ったようです。

基板を制作する時、QFN20 が一番安かったので、何も考えずに、QFN20 を注文して、設計しましたが、フットプリントを見て唖然としました・・・

<img width="575" alt="QFN20.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/58667/07308db0-4bfc-86e0-15d1-06e077d89e8d.png">

上記のように、角のピンだけ別扱いで、横にピンが出ていないのですー

これは、手ハンダには辛い仕様です・・・

※次に作る時は、QFN24 を選びます！

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/58667/f64e143b-cd9b-c2a9-59c7-8ced53703b91.jpeg" width="50%">
※以外と便利、コテライザーに「ブロアー」を付けた物。

これで、ハンダペーストを楊枝で塗り、「ブロアー」して QFN20 のハンダ付けを行った。
ブロアーでハンダペーストが溶けた事を確認後、さらに、フラックスを塗り、サイド側をハンダコテで舐めて、ピンと接続している事を確認。

現在３個やって、１個失敗・・・
※原因が判っていない・・・

---

### 3.3V レギュレータの搭載

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/58667/b3b7514b-fd3f-5d37-5dd1-42503dce5053.jpeg" width="50%">


一般に出回っている USB シリアルモジュールでは、3.3V のレギュレータを載せている物は少なく、ＲＸマイコンのように、基本 3.3V 仕様だと不便です。

なので、3.3V のレギュレータを載せて、切り替え式にしています。

切り替えは、ショートピンで行っていますが、小型のスライド SW を使う事も出来ます。

3.3V のレギュレータは、CP2102N にも内蔵していますが、電流を殆ど流せない為、外部に三端子レギュレータを設ける必要があります。

---

### 6 ピンコネクタ搭載

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/58667/2d0f526b-f006-99f6-87d9-eca5c4e9529a.jpeg" width="50%">

良くある、ヘッダーピンタイプでは、逆接続とか簡単に出来てしまうので、物理的に逆に接続出来ない６ピンコネクタを採用しています。

6 ピンには、以下の信号を配線してあります。

- 1: RXD
- 2: TXD
- 3: GND
- 4: VCC
- 5: /RTS
- 6: /CTS

※ /RTS、は、ハードフロー制御の出力信号ですが、別の用途に使う事も出来ます。

---

### タカチ製のケースに入るデザイン

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/58667/ab5ac517-a10e-40f0-d376-2943301f35a5.jpeg" width="50%">

裸で動かすのは、何かと、不安なので、ケースに入れる前提で基板を設計してあります。

その為、マイクロ USB コネクタを少しだけ飛び出るようにしてあり、ケースの厚みで相殺されるようにしています。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/58667/e9ab0c19-d0c4-bf92-88ee-72353061cb50.jpeg" width="50%">


基板を製造する際、端をカットする指示をしていないので、自分で削りました。

[タカチＣＳ７５Ｎ](https://www.takachi-el.co.jp/assets/attachments/images/CS75N-W_20190412172829.pdf)

※このケース、手頃な大きさで、加工しやすく、値段も安いです。

---

### 他色々

- 全てのピンを出しておき、使えるようにしておきます。
- なるべく地雷を踏まないように Silicon Labs の参考回路や、評価ボードの回路に従った、設計をしています。
- 電源を外に出して利用する前提なので、一応、リセッタブルヒューズも搭載しています。

[KiCAD プロジェクト](https://github.com/hirakuni45/RX/tree/master/rxprog/USB_CP2102N)

<img width="1093" alt="CP2102N_board.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/58667/5bea2371-4525-ab31-dc83-d143fbb5cd35.png">

---

## FTDI/FT232XS と SiliconLabs/CP2102N の速度比較

このベンチだけで、CP2102N の方が優れているとは言えないのですが、大まかに言って、CP2102N を選ぶべきと思います。

- このベンチマークでは、RX64M マイコンのフラッシュ書き換えとしてシリアルインターフェースを使っています。
- フラッシュ書き込みは自制のツール「rx_prog」を使っています。
- このツールはオープンソースで、マルチプラットホームで使えます。（Windows、OS-X、Linux）

[rx_prog プロジェクト](https://github.com/hirakuni45/RX/tree/master/rxprog)

※rx_prog.conf の一部：

```
#speed = 230400
speed_win = 230400
speed_osx = 230400
speed_linux = 230400

# erase-page command wait [uS]
erase_page_wait = 2000
# write-page command wait [uS]
write_page_wait = 5000
```

AUDIO_sample/RX64M/audio_sample.mot (628460 バイト)

```
rx-elf-size audio_sample.elf
   text    data     bss     dec     hex filename
 541476      48   86936  628460   996ec audio_sample.elf
-rw-r--r-- 1 hira hira 1353908  6月  8 03:13 audio_sample.mot
```

FTDI(FT232XS)　@230　秋月電子:

```
time rx_prog -P COM5 -d RX64M --progress --erase --write --verify audio_sample.mot
Erase:  #################################################
Write:  #################################################
Verify: #################################################
0.39user 1.90system 5:57.08elapsed 0%CPU (0avgtext+0avgdata 9304maxresident)k
0inputs+0outputs (2442major+0minor)pagefaults 0swaps
```

※FTDIのメジャーデバイス、FT232RL(@400) でも結果は同じ。

SiliconLabs(CP2102N)　@160　DigiKey:

```
time rx_prog -d RX64M --progress --erase --write --verify audio_sample.mot
Erase:  #################################################
Write:  #################################################
Verify: #################################################
0.28user 1.09system 1:51.59elapsed 1%CPU (0avgtext+0avgdata 9372maxresident)k
0inputs+0outputs (2460major+0minor)pagefaults 0swaps
```

上記のように３倍以上違います。

## 同じボーレートなのに、速度が違う理由

詳細に調査しているのでは無いのですが、USB ドライバーの設計が異なり、送信、受信のマネージメントが違うのだろうと思います。

- 基本的にドライバーの違いのようだ。
- FTDI では、小さいパケットを送ると、「都度送る」
- SiliconLabs の場合は、「貯めて送る」と、「バッファにあったら送る」
- Windows の USB サービスの関係から、「都度送る」と間隔が空いてしまうようだ。
- ハンドシェークを行わない場合、受け手の仕様によっては、相性問題が発生するかもしれない。
- 受け手の作りが「甘い」と、FTDI の方が相性が良い事になる感じか・・

たとえば、１バイトのデータを短いスパンで、送るようなアプリを作ると、速度差が大きくなるようです。

## まとめ

USB シリアルは、FTDI 一択のような状況ですが、SiliconLabs の CP2102N も中々良い選択だと思えます。