ソースコードにあっても、107を選んだ時に#ifdefなどのプリプロセッサーでなくなってしまう。ひとつひとつのソースレベルまで見ないとわからない。半日近く、ソースをいじりまわして納得した。これはやっぱりあきらめるしかない。107には、103と違うハード(USBのOTGなど)がついているので、ライブラリの構造が大きく変わっている。今までのやり方の手直しぐらいでは動きそうもない。USB仮想UARTは道半ばだが、諦めることにする。それにこれが目的ではない。何とウェブでまたも、ねむいさんの記事がヒットした。STM32F107でVCOM(USB仮想UART端末)を動かしたデモプロジェクトである。なんだ、なんだ、ちゃんと動いているソースがあるじゃないか。ありがたくソースをいただいた。STM32F107の仮想UARTのソースでも泥沼(1/23/2012)ねむいさんのソースは、STマイクロのV3ライブラリのVCOMのデモがベースになっているようである。実はこれを探していたのだが、自分では見つけられなかった。みんなが言っているようにSTマイクロのサイトは欲しい情報が実に探しにくい構造になっている。誰のためのサイトなのだろう。ビルドそのものは、前に一回通しているので、Makefileの修正は楽で、順調にビルドは進んだ。MCUISPでファームを焼く。このSTマイクロのVCOMデモソースは、標準のUART1とUSB仮想UARTをつなぐブリッジ機能のデモである。USBケーブルを差し込んで電源を入れる。良いぞ、PCが107のUSB仮想UARTを認めた。次に、PCのシリアル端末ソフト(Teraterm)で、通常のCOM1のシリアルコンソールも立ち上げる。2枚のシリアル端末を前にしてキーボードを叩く。どちらから打ってもデータは行き来しない。うーむ、ビットレートが合っていないのか。ソースコードの通りUSB-UARTを11520bpsパリティ無し、ストップビット1、COM1を9600bps、奇数パリティ、などとするが、うんともすんとも言わない。こちらの目的はCOM1とつなぐためではなく、前やったように単にUSBの仮想UARTを動かしたいだけである。不確定要素のあるハードのCOM1のUARTの方は余計だ。コードを削って、前にやったような仮想UARTモニターにしようとソースをいじり始めた。このVCOMのソースコードは何かおかしい。USBのエンドポイント周りのコーディングは、同じような処理が複数あって混乱する。新しく加わった新機種(STM32F107クラス)のために#ifのプリプロセッサーで分けて機種ごとにコードを追加しているので余計読みにくい。ソースコードが年を経て劣化するというやつである。安易な#ifの使用は、あとが大変で、こんなコードを書いていると、書いた本人でもこの先メンテナンス不能になるのではないかと心配になる。それにしても、UARTとUSBのバッファーの間のデータ移動ロジックは稚拙としか言いようがない。受信したUARTデータのサイズとUSBのパケットサイズを比較しながら無理やりデータを移している。素人が書いたようなプログラムである。要するに目の前のデータの形に気を取られて、本質がわかっていない。いうときは、ストリームの概念を持てばプログラムは非常に簡単になるはずで、少し大きめのリングバッファーかFIFOに一旦データを移して、そこからUSBのエンドポイントのパケットサイズ分を採っていけば良い。それにしても、ひどいコーディングだなあと思っていたら、違う視点でこのコードの不安について書いているサイトを見つけた。USBの割り込みが2箇所あって、排他処理しているのは良いが、全く同じような処理が重複している。バッファーの終端処理が考えられていない。このページの通り、バッファーを使っているのに、リングバッファーとして使わず、2048バイトという大量の容量にして、その管理をサボっている。そもそも、オリジナルのソースでは、UARTの速度が9600bps、USBが115200bpsなのに、USBからのデータは受け取るばかりで、ソースには何らかのフロー制御をしている形跡がない。フロー制御をしなければバッファーをどんなに大きく(2KB以上)とっていても、持続して送受信を続けることは出来ない。こんなソースを書いてはいけないという見本のようなものだが、悪態をついたところで正しい修正が行えるわけではない。黙々と、少しづつ直していくしかない。スランプなので、集中してデバッグする気力がなかなか生まれない。ことでVCOMが動いた。不安定(1/28/2011)やれやれ、やっとSTM32F107の仮想UARTが動いた。えらい時間がかかった。ヤキが廻ったとしか言いようがない。モチベーションが低い時に作業を無理に進めると、こういうものである。USB仮想端末は、実行のたびにUSBケーブルを抜き差ししないと動かないことを思い出し、動き始めた(最初から動いていた)のは良いが、どうしても文字化けが解決しない。1文字のエコーバック程度なら問題ないが、複数データの送信では正しく送られない。ねむいさんのブログにも、このソースについての不安が同じように出ていたが、わかってしまえば、いつものように自分のお馬鹿な基本的ミスで、とりあえず問題は解決した。USBのエンドポイントバッファーに書き込む配列の番号がオリジナルのままになっていた。これでは、常にデータを送り終わったところが始点で、いつもゴミを送ることになる。これをバッファーの最初、&EP_Buffer[0]にすることで字化けしていた複数データは一応正常に表示された。