久々にVinculumIIのIDEが更新されていた模様。
http://www.ftdichip.com/Firmware/VNC2tools.htm
This update fixes bugs in the compiler tools and the Integrated Development Environment. The firmware libraries are moved from the default location of the system "Program Files" area to the "ProgramData" area.
ということだが、デバッガ使用時に散発していたバグはFixしているのだろうか。
2014年12月26日
VinculumII/IDEが新調される。
posted by Yasuski at 15:54| Vinculum2
2013年12月20日
FTDIから問題の解決法が提示された
FTDIから以下の様なUARTの通信バグに関する解決法が提示された。
if (status == VINCO_USBHOSTFT232_OK)
{
// Now read data from FT232 device
USBHostFT232.getRXStatus(ft232Handle, &dataAvail);
if (dataAvail > sizeof(ft232Buffer))
{
dataAvail = sizeof(ft232Buffer);
}
if (dataAvail > 0)
{
status = USBHostFT232.read(ft232Handle, ft232Buffer, dataAvail, &actual);
// Wait for a while to ensure the data has been written
delay(30);
if (status == VINCO_USBHOSTFT232_OK)
{
for (i = 0; i < dataAvail; i++)
Serial.write(&ft232Buffer[i], 1);
}
}
dataAvail = (unsigned short) Serial.available();
if (dataAvail > sizeof(uartBuffer))
{
dataAvail = sizeof(uartBuffer);
}
if (dataAvail > 0)
{
for (i = 0; i < dataAvail; i++)
{
uartBuffer[i] = (unsigned char) Serial.read();
}
// Then write data to FT232 device
status = USBHostFT232.write(ft232Handle, uartBuffer, dataAvail, &actual);
}
}
ということで、コメントアウトされていた部分
// Send data back to UART
//ft232Buffer[actual] = '\0';
//Serial.write(char *ft232Buffer, dataAvail);
//Serial.printstr((char *) ft232Buffer);
の代わりに、赤字のforでバッファに入力完了分のアドレスを回してデータを吐き出させる仕組みに書き換えれば良いということらしい。
似た構成の文が、UART→USBの側にもあって、、、
if (dataAvail > 0)
{
for (i = 0; i < dataAvail; i++)
uartBuffer[i] = (unsigned char) Serial.read();
}
// Then write data to FT232 device
status = USBHostFT232.write(ft232Handle, uartBuffer, dataAvail, &actual);
この辺りが問題解決のヒントだったのだが、未熟な自分には理解が足りなかったようだ、、、。
if (status == VINCO_USBHOSTFT232_OK)
{
// Now read data from FT232 device
USBHostFT232.getRXStatus(ft232Handle, &dataAvail);
if (dataAvail > sizeof(ft232Buffer))
{
dataAvail = sizeof(ft232Buffer);
}
if (dataAvail > 0)
{
status = USBHostFT232.read(ft232Handle, ft232Buffer, dataAvail, &actual);
// Wait for a while to ensure the data has been written
delay(30);
if (status == VINCO_USBHOSTFT232_OK)
{
for (i = 0; i < dataAvail; i++)
Serial.write(&ft232Buffer[i], 1);
}
}
dataAvail = (unsigned short) Serial.available();
if (dataAvail > sizeof(uartBuffer))
{
dataAvail = sizeof(uartBuffer);
}
if (dataAvail > 0)
{
for (i = 0; i < dataAvail; i++)
{
uartBuffer[i] = (unsigned char) Serial.read();
}
// Then write data to FT232 device
status = USBHostFT232.write(ft232Handle, uartBuffer, dataAvail, &actual);
}
}
ということで、コメントアウトされていた部分
// Send data back to UART
//ft232Buffer[actual] = '\0';
//Serial.write(char *ft232Buffer, dataAvail);
//Serial.printstr((char *) ft232Buffer);
の代わりに、赤字のforでバッファに入力完了分のアドレスを回してデータを吐き出させる仕組みに書き換えれば良いということらしい。
似た構成の文が、UART→USBの側にもあって、、、
if (dataAvail > 0)
{
for (i = 0; i < dataAvail; i++)
uartBuffer[i] = (unsigned char) Serial.read();
}
// Then write data to FT232 device
status = USBHostFT232.write(ft232Handle, uartBuffer, dataAvail, &actual);
この辺りが問題解決のヒントだったのだが、未熟な自分には理解が足りなかったようだ、、、。
posted by Yasuski at 10:12| Vinculum2
2013年12月18日
FTDIからレスが来た
Our UK software engineer said that 0x00 is treated as a terminate character of a string.
You can find below code in our sample code. We add a zero at the end of a buffer to make it become a string.
I asked our engineer to find a solution to change it for your case, and waiting for his response.
Hope this issue can be fixed soon.
ということだったので、プログラムの「仕様」であることが確定した。
確かに怪しそうだと認識していた部分ではあったが、自分の力量ではFixできず。
ということで、対処法を現在打診中。
You can find below code in our sample code. We add a zero at the end of a buffer to make it become a string.
if (status == VINCO_USBHOSTFT232_OK)
{
// Send data back to UART
ft232Buffer[actual] = '\0';
Serial.printstr((char *) ft232Buffer);
}
I asked our engineer to find a solution to change it for your case, and waiting for his response.
Hope this issue can be fixed soon.
ということだったので、プログラムの「仕様」であることが確定した。
確かに怪しそうだと認識していた部分ではあったが、自分の力量ではFixできず。
ということで、対処法を現在打診中。
posted by Yasuski at 11:12| Vinculum2
2013年12月13日
monomeをケースに実装する計画
monome関連のケースの製作の目処が付いた。
SDRをスーツケースに詰めたギミックラジオを分解して、monomeのケースを製作することにした。
試しに組み込むmonome＆arc4の外型描いてみたところ、ギリギリではあるがクリアランスを確保できたので、製作時間短縮というご利益もあることから、この板を再利用することにした。
結果、いい感じにまとまっているが、インチサイズの文化の元で造られた構造物同士だけあって、ガチガチに尺が詰まっている。
スペース的な余白が上下5ミリ程と、殆ど余裕の無いギリギリの配置ではあるが、操作上の問題はない。
無線・有線の切り替えや、通信端末的なHUB機能を持たせることなどいろいろと機能を組み込めそうなので、機構面のヴァージョンアップが簡単に行えるように、あらかじめまとまった構造設計を行っておくべきだろう。
最終的に、ヒンジは取り外し可能なタイプのものに取り替えたいところだが、今回は時間切れ。
monomeを実装する前に、サブフレームを構成する方法を考える。
まず、L型アングルを中央の梁に接着して、Z軸方向のフレーム強度を確保する。
アングルとフレームの接続面はアングル分の厚みが増えてmonomeの基板とツライチになる。 フレームがmonomeと接触する他の部分にも薄いアルミ板を追加して、ツライチを完成させる。
それらの面を覆う、薄い板を基板の周りに展開し、基板のネジを使ってmonome側に固定する。
要は、monomeのアルミ製表板と基板がフレームをサンドイッチする形で、monomeとフレームを結合することになる。
フレームの両サイドにもアングルを追加しておくと、強度的に安心できるだろう。
SDRをスーツケースに詰めたギミックラジオを分解して、monomeのケースを製作することにした。
試しに組み込むmonome＆arc4の外型描いてみたところ、ギリギリではあるがクリアランスを確保できたので、製作時間短縮というご利益もあることから、この板を再利用することにした。
結果、いい感じにまとまっているが、インチサイズの文化の元で造られた構造物同士だけあって、ガチガチに尺が詰まっている。
スペース的な余白が上下5ミリ程と、殆ど余裕の無いギリギリの配置ではあるが、操作上の問題はない。
無線・有線の切り替えや、通信端末的なHUB機能を持たせることなどいろいろと機能を組み込めそうなので、機構面のヴァージョンアップが簡単に行えるように、あらかじめまとまった構造設計を行っておくべきだろう。
最終的に、ヒンジは取り外し可能なタイプのものに取り替えたいところだが、今回は時間切れ。
monomeを実装する前に、サブフレームを構成する方法を考える。
まず、L型アングルを中央の梁に接着して、Z軸方向のフレーム強度を確保する。
アングルとフレームの接続面はアングル分の厚みが増えてmonomeの基板とツライチになる。 フレームがmonomeと接触する他の部分にも薄いアルミ板を追加して、ツライチを完成させる。
それらの面を覆う、薄い板を基板の周りに展開し、基板のネジを使ってmonome側に固定する。
要は、monomeのアルミ製表板と基板がフレームをサンドイッチする形で、monomeとフレームを結合することになる。
フレームの両サイドにもアングルを追加しておくと、強度的に安心できるだろう。
posted by Yasuski at 17:10| Vinculum2
2013年12月11日
やはり、Vinculoのサンプルコードに問題があった
台湾のFTDI/AsiaHQの人は、本国イギリスの担当よりも真面目。
で、先程こんなメイルがきた。
I can also found that our sample code cannot return data 0x00. I am still checking the root cause.
自分は重大なバグを発見したのかもしれない。
で、先程こんなメイルがきた。
I can also found that our sample code cannot return data 0x00. I am still checking the root cause.
自分は重大なバグを発見したのかもしれない。
posted by Yasuski at 13:53| Vinculum2
2013年12月09日
処理ループをデバッガを使って検証してみた
デバッグ作業を行う過程の映像を記録したが、H00が無視される案件はこの作業では検証できなかった。
ご覧のように、スイッチを押した時と離した時、何れの場合も綺麗にUART送出の処理ルーティンをなぞっている。
入力後に処理ルーティンを一巡した後の、入力に変化の無いループ回からは、送信ルーティンがスキップされるところも正常にみえる。
USBHOST端子の左には、GPIOと接続されたグリーンのLEDが実装されていて、これがUSB端子に入力されたデータのアクセスランプとなっている。このLEDが反応するのは、スイッチをリリースしたタイミングのみであって、押し込んだ時は沈黙したままだ。 これが、今回発生している不具合の原因を探るためのヒントなのかもしれない。ただ、コードを眺めても、どの段階でインターラプトが掛かっているのか今一つ理解できないのがもどかしい。
これらの結果から類推すると、送出を行うサブルーティン内に問題が潜んでいそうな雰囲気がするのだが、サポートからの返答はまだない。
追記:
なんとVinculumはRTOSで動いているらしい。 マルチスレッド対応なのでSubRoutineで遅延が発生する可能性は低いと思われる、、、、、、、、、。オミットしたLEDの発光ルーティンに関しては若干の遅れが生じる構造なので、これはスキップしたままにしておく。
ご覧のように、スイッチを押した時と離した時、何れの場合も綺麗にUART送出の処理ルーティンをなぞっている。
入力後に処理ルーティンを一巡した後の、入力に変化の無いループ回からは、送信ルーティンがスキップされるところも正常にみえる。
USBHOST端子の左には、GPIOと接続されたグリーンのLEDが実装されていて、これがUSB端子に入力されたデータのアクセスランプとなっている。このLEDが反応するのは、スイッチをリリースしたタイミングのみであって、押し込んだ時は沈黙したままだ。 これが、今回発生している不具合の原因を探るためのヒントなのかもしれない。ただ、コードを眺めても、どの段階でインターラプトが掛かっているのか今一つ理解できないのがもどかしい。
これらの結果から類推すると、送出を行うサブルーティン内に問題が潜んでいそうな雰囲気がするのだが、サポートからの返答はまだない。
追記:
なんとVinculumはRTOSで動いているらしい。 マルチスレッド対応なのでSubRoutineで遅延が発生する可能性は低いと思われる、、、、、、、、、。オミットしたLEDの発光ルーティンに関しては若干の遅れが生じる構造なので、これはスキップしたままにしておく。
posted by Yasuski at 16:11| Vinculum2
問題は全く解決していないが
件の部分のコードを解析中だが、情けないことに自分はCに関する知識を殆ど持ちあわせておらず、全くの手探りで対策にあたっている。
現時点で認識される最大の問題点は、キーを押した瞬間のデータが尽く無視されるプログラムの仕様で、正常に動作しているV2DIPからTerminalに出力されている文字列の構成から類推した結果、
例えば、文字列
✝P(00010000 01010000)
は受け入れられるが
<00>P (00000000 01010000)
は撥ねられて仕舞うことが判った。
これは、<00>の文字列を出力するパートが混在するarc4をVinculoに接続した時に明らかになった反応で、該当するパートにあたる左端のロータリーエンコーダーの出力は、ノブを左右に回転させた場合であっても全く同じStringsを吐き出していた。
monome128を接続した状態でHEX表記でデータを読むと、SwitchedOnの状態の先頭番号が00となるために、これらの入力は全て無視される。 SwitchedOff時には先頭番号10が出力されるので、それらのデータは受理されている。
Terminalの画像は、手前2列32個分のオフ情報を表示しているが、よく見ると最小桁の00が見事に無視されていることが解る。
また、Terminalを使った双方向通信実験の結果、Terminal側の信号を反映させるために、常にmonomeのキーを叩く必要があった。 これにより、UART側にとっては意味のない条件分岐が仕込まれていることが判明したので、その部分を外すことでTerminal側からの入力がmonome上でリアルタイムに反映されるようになった。
当初は、00入力をスルーするbranch命令を疑っていたのだが、コード上のどこを探してもそれが見つからない。乏しい知識を絞って考えた最も怪しい部分は、
ft232Buffer[actual] = '\0';
で、\0はNULLを返し、そのコードは00ということなのだが、、、この部分をコメントアウトしても、00が撥ねられる状況は変わらなかった。
アップロードしたコードは違うものの、V2DIPでは何ら問題が発生していないことから、Vinculoのみに関係する設定ファイルの中に悪影響を与えている設定が存在する可能性が大きい。 が、どの場所にその設定が潜んでいるのか、いまのところ判明はしていない。
以下、不完全ではあるが、改変したコードを掲載しておく。
現時点で認識される最大の問題点は、キーを押した瞬間のデータが尽く無視されるプログラムの仕様で、正常に動作しているV2DIPからTerminalに出力されている文字列の構成から類推した結果、
例えば、文字列
✝P(00010000 01010000)
は受け入れられるが
<00>P (00000000 01010000)
は撥ねられて仕舞うことが判った。
これは、<00>の文字列を出力するパートが混在するarc4をVinculoに接続した時に明らかになった反応で、該当するパートにあたる左端のロータリーエンコーダーの出力は、ノブを左右に回転させた場合であっても全く同じStringsを吐き出していた。
monome128を接続した状態でHEX表記でデータを読むと、SwitchedOnの状態の先頭番号が00となるために、これらの入力は全て無視される。 SwitchedOff時には先頭番号10が出力されるので、それらのデータは受理されている。
Terminalの画像は、手前2列32個分のオフ情報を表示しているが、よく見ると最小桁の00が見事に無視されていることが解る。
また、Terminalを使った双方向通信実験の結果、Terminal側の信号を反映させるために、常にmonomeのキーを叩く必要があった。 これにより、UART側にとっては意味のない条件分岐が仕込まれていることが判明したので、その部分を外すことでTerminal側からの入力がmonome上でリアルタイムに反映されるようになった。
当初は、00入力をスルーするbranch命令を疑っていたのだが、コード上のどこを探してもそれが見つからない。乏しい知識を絞って考えた最も怪しい部分は、
ft232Buffer[actual] = '\0';
で、\0はNULLを返し、そのコードは00ということなのだが、、、この部分をコメントアウトしても、00が撥ねられる状況は変わらなかった。
アップロードしたコードは違うものの、V2DIPでは何ら問題が発生していないことから、Vinculoのみに関係する設定ファイルの中に悪影響を与えている設定が存在する可能性が大きい。 が、どの場所にその設定が潜んでいるのか、いまのところ判明はしていない。
以下、不完全ではあるが、改変したコードを掲載しておく。
// First, read data from FT232
if (status == VINCO_USBHOSTFT232_OK)
{
// Now read data from FT232 device
USBHostFT232.getRXStatus(ft232Handle, &dataAvail);
if (dataAvail > sizeof(ft232Buffer))
{
dataAvail = sizeof(ft232Buffer);
}
if (dataAvail > 0)
{
status = USBHostFT232.read(ft232Handle, ft232Buffer, dataAvail, &actual);
// Wait for a while to ensure the data has been written
delay(30);
// Send data back to UART
ft232Buffer[actual] = '\0';
Serial.printstr((char *) ft232Buffer);
}
dataAvail = (unsigned short) Serial.available();
if (dataAvail > sizeof(uartBuffer))
{
dataAvail = sizeof(uartBuffer);
}
if (dataAvail > 0)
{
for (i = 0; i < dataAvail; i++)
{
uartBuffer[i] = (unsigned char) Serial.read();
}
// Then write data to FT232 device
status = USBHostFT232.write(ft232Handle, uartBuffer, dataAvail, &actual);
}
}
posted by Yasuski at 07:55| Vinculum2
不具合の原因がある程度特定される
VinculoからTerminalで送信されてくるデータを眺めた結果、<00>が無視されることがわかった。
まずはV2DIPで受信した場合のデータは正常で、arc4、monome128共に、すべての動作を受け入れている。
ところが、これがVinculoで走らせているプログラム上では、全ての<00>が撥ねられていることが解る。
この <00> という文字列がバイナリーデータ送信のルールに抵触して、送信が意図的にストップされている可能性がある。 以下は正常に動作しているarc4を繋いだV2DIPから送られてくるUARTにトランスレートされた信号をTerminal上でコピペしたもの。
<00>pp<00>pp<00>qq<00>qq<00>bb<00>AA<00>AA<00>BB<00>CC<00>CC<00>CC<00>BB<00>22
実験の結果、✝P(00010000 01010000)は受け入れられるが <00>P (00000000 01010000) が撥ねられて仕舞うようだ。
まずはV2DIPで受信した場合のデータは正常で、arc4、monome128共に、すべての動作を受け入れている。
ところが、これがVinculoで走らせているプログラム上では、全ての<00>が撥ねられていることが解る。
この <00> という文字列がバイナリーデータ送信のルールに抵触して、送信が意図的にストップされている可能性がある。 以下は正常に動作しているarc4を繋いだV2DIPから送られてくるUARTにトランスレートされた信号をTerminal上でコピペしたもの。
<00>pp<00>pp<00>qq<00>qq<00>bb<00>AA<00>AA<00>BB<00>CC<00>CC<00>CC<00>BB<00>22
実験の結果、✝P(00010000 01010000)は受け入れられるが <00>P (00000000 01010000) が撥ねられて仕舞うようだ。
posted by Yasuski at 03:25| Vinculum2
2013年12月08日
USBHostFT232Loopback
Vinculoをhardware_monome_serial化するためのステップを紹介する。
まず、VinculumIDEの最大とも言える問題点は、buildを行う度にオリジナルのファイルが意図せずに上書きされてしまう仕様にある。 初心者にとってこれは失敗をリカバーできない恐ろしい仕組みで、自分もまずはここで躓いた。
VinculumIDEをインストールすると、MyDocumentフォルダの中に、自動的にFTDIフォルダが生成される。
その中を辿って行くとSampleフォルダが見つかるので、まずはコレをまるまる別場所にコピペしておく。
複製したフォルダの中のvincoフォルダーを開くと、、、
UsbHostFT232というフォルダが見つかるので、それを開く。
その中はUSBHostFT232Loopbackというフォルダが存在するのみなので、それを開く。
フォルダ内のUSBHostFT232Loopback.vprojが目的のファイルなのだが、ここで一つ上の階層からオリジナルを保存しておくとリカバーに便利なので、コピペを推奨する。
プロジェクトを開くと、IDEが展開されるが、以下に改変が必要なポイントを挙げていく。
まず、オリジナルの/* Default Settings for FT232 interface */ はFT232の通信設定のみが記述されているだけなので、ここにUARTの設定項目を追加する。
最初の項目は通信速度設定なので、これらをオリジナルの9600baudから115200baudに変更する。残りの項目はそのままでよい。
ついでに、SetUpRoutine内でTerminalで確認を行うために表示される文字列の通信速度設定も115200baudに変更しておく。 前述した追加項目で既に通信速度を設定済みなので、この部分は削っても問題がないかもしれない。
既に動作を確認しているV2DIP48での可動実績を参考に、バッファーの値をそれぞれ2048に変更。 4096だと何故か動かないことがある。
そして、プログラムの以下の部分を改編する。
オリジナルの記述を示しておく。
最初に、このプログラムを走らせた時に自分が混乱したのは、USBHOSTに接続したデバイスからの入力に対して、TerminalSoftware上に一切反応がなかったためだった。
これは前述したプログラムの冒頭の部分を読めば簡単に理解できることなのだが、まず最初にUART側からの入力がないと、USB側の入力は反応しない仕掛けになっている。 つまり、最初のトリガーがUART側に必要で、この場合はTerminalSoftwareに何らかの入力が行われるまで、USBHOST側のアクションは黙殺され続ける。
このプログラムは、本来USBHOST端子にループバック接続（RxとTxを直結する）されたFT232の存在が前提なので、ターミナル側からの入力が優先されるのは当然の処置なのだ。
つまり、現状はUSBHOST側に接続されたmonomeからの"入力信号"が優先されるべきhardware_monome_serialとはプライオリティーが逆になっていることになる。
実際は、UART側から何らかの形で信号が入力されれば、以降USBHOST側の信号もピックアップされるのだが、このままでは不便なので、USBHOST側のmonomeからの入力がトリガーとなって通信が開始されるように、処理のプライオリティーを入れ替えることにした。
以上の改変を行った結果、monomeからの入力と同時にTerminalに文字列を確認することが出来た。
追記：
スイッチを押した瞬間は反応せずに、リリース時のみ反応するという奇っ怪な現象が発生しているので、追試を行う予定。 あと、AC/DCからの電源供給だと誤動作する謎仕様も発覚している。
追記2：
V2DIPを接続して追試したところ、スイッチをオン状態にした時には＜00＞＠2のような文字列が吐かれていることを確認した。 現在、データをセンシングするタイミングがどの部分で策定されているのかを調査中。
まず、VinculumIDEの最大とも言える問題点は、buildを行う度にオリジナルのファイルが意図せずに上書きされてしまう仕様にある。 初心者にとってこれは失敗をリカバーできない恐ろしい仕組みで、自分もまずはここで躓いた。
VinculumIDEをインストールすると、MyDocumentフォルダの中に、自動的にFTDIフォルダが生成される。
その中を辿って行くとSampleフォルダが見つかるので、まずはコレをまるまる別場所にコピペしておく。
複製したフォルダの中のvincoフォルダーを開くと、、、
UsbHostFT232というフォルダが見つかるので、それを開く。
その中はUSBHostFT232Loopbackというフォルダが存在するのみなので、それを開く。
フォルダ内のUSBHostFT232Loopback.vprojが目的のファイルなのだが、ここで一つ上の階層からオリジナルを保存しておくとリカバーに便利なので、コピペを推奨する。
プロジェクトを開くと、IDEが展開されるが、以下に改変が必要なポイントを挙げていく。
まず、オリジナルの/* Default Settings for FT232 interface */ はFT232の通信設定のみが記述されているだけなので、ここにUARTの設定項目を追加する。
最初の項目は通信速度設定なので、これらをオリジナルの9600baudから115200baudに変更する。残りの項目はそのままでよい。
ついでに、SetUpRoutine内でTerminalで確認を行うために表示される文字列の通信速度設定も115200baudに変更しておく。 前述した追加項目で既に通信速度を設定済みなので、この部分は削っても問題がないかもしれない。
既に動作を確認しているV2DIP48での可動実績を参考に、バッファーの値をそれぞれ2048に変更。 4096だと何故か動かないことがある。
そして、プログラムの以下の部分を改編する。
オリジナルの記述を示しておく。
//
// First, read data from UART
dataAvail = (unsigned short) Serial.available();
if (dataAvail > sizeof(uartBuffer))
{
dataAvail = sizeof(uartBuffer);
}
if (dataAvail > 0)
{
for (i = 0; i < dataAvail; i++)
{
uartBuffer[i] = (unsigned char) Serial.read();
}
// Then write data to FT232 device
status = USBHostFT232.write(ft232Handle, uartBuffer, dataAvail, &actual);
// Wait for a while to ensure the data has been written
delay(30);
if (status == VINCO_USBHOSTFT232_OK)
{
// Now read back data from FT232 device
USBHostFT232.getRXStatus(ft232Handle, &dataAvail);
if (dataAvail > sizeof(ft232Buffer))
{
dataAvail = sizeof(ft232Buffer);
}
if (dataAvail > 0)
{
status = USBHostFT232.read(ft232Handle, ft232Buffer, dataAvail, &actual);
if (status == VINCO_USBHOSTFT232_OK)
{
// Send data back to UART
ft232Buffer[actual] = '\0';
Serial.printstr((char *) ft232Buffer);
}
}
}
}
}
最初に、このプログラムを走らせた時に自分が混乱したのは、USBHOSTに接続したデバイスからの入力に対して、TerminalSoftware上に一切反応がなかったためだった。
これは前述したプログラムの冒頭の部分を読めば簡単に理解できることなのだが、まず最初にUART側からの入力がないと、USB側の入力は反応しない仕掛けになっている。 つまり、最初のトリガーがUART側に必要で、この場合はTerminalSoftwareに何らかの入力が行われるまで、USBHOST側のアクションは黙殺され続ける。
このプログラムは、本来USBHOST端子にループバック接続（RxとTxを直結する）されたFT232の存在が前提なので、ターミナル側からの入力が優先されるのは当然の処置なのだ。
つまり、現状はUSBHOST側に接続されたmonomeからの"入力信号"が優先されるべきhardware_monome_serialとはプライオリティーが逆になっていることになる。
実際は、UART側から何らかの形で信号が入力されれば、以降USBHOST側の信号もピックアップされるのだが、このままでは不便なので、USBHOST側のmonomeからの入力がトリガーとなって通信が開始されるように、処理のプライオリティーを入れ替えることにした。
// First, read data from USBHOST
if (status == VINCO_USBHOSTFT232_OK)
{
// Now read back data from FT232 device
USBHostFT232.getRXStatus(ft232Handle, &dataAvail);
if (dataAvail > sizeof(ft232Buffer))
{
dataAvail = sizeof(ft232Buffer);
}
if (dataAvail > 0)
{
status = USBHostFT232.read(ft232Handle, ft232Buffer, dataAvail, &actual);
if (status == VINCO_USBHOSTFT232_OK)
{
// Send data back to UART
ft232Buffer[actual] = '\0';
Serial.printstr((char *) ft232Buffer);
dataAvail = (unsigned short) Serial.available();
if (dataAvail > sizeof(uartBuffer))
{
dataAvail = sizeof(uartBuffer);
}
if (dataAvail > 0)
{
for (i = 0; i < dataAvail; i++)
{
uartBuffer[i] = (unsigned char) Serial.read();
}
// Then write data to FT232 device
status = USBHostFT232.write(ft232Handle, uartBuffer, dataAvail, &actual);
}
}
}
}
}
以上の改変を行った結果、monomeからの入力と同時にTerminalに文字列を確認することが出来た。
追記：
スイッチを押した瞬間は反応せずに、リリース時のみ反応するという奇っ怪な現象が発生しているので、追試を行う予定。 あと、AC/DCからの電源供給だと誤動作する謎仕様も発覚している。
追記2：
V2DIPを接続して追試したところ、スイッチをオン状態にした時には＜00＞＠2のような文字列が吐かれていることを確認した。 現在、データをセンシングするタイミングがどの部分で策定されているのかを調査中。
posted by Yasuski at 17:09| Vinculum2
VinculoにUSBHOST機能を実装できた
Vinculo上へのmonomeInterpreterの実装を完了した。
成功のヒントは、Vinculo専用の定義ファイルの存在だった。 いろいろといじり倒す前のクリーンなコードをアプリを別ドライヴに再インストールして復活させることを思い付いたのもプロジェクト達成のための大きな助けとなった。
ちなみに、機種変更が簡単に行えるという触れ込みだったVinculumIDEの「Modifｙ機能」は、ほぼ使いものにならないことが発覚している。
映像は、VinculoのUSBHOSTに接続したmonome128からの信号を、UARTポートに接続したUSB/Serial変換IC、FT232で受信したものを、TeraTermで復調しているところ。monomeから出力されるケッタイな文字列を、設定した通信速度で確認することが出来た。
monomeEmulatorとの相性を確かめていないので「即使える」という保証はないが、これでやっとVinculoにUSBHOSTらしい働きを与えることが出来た。
成功のヒントは、Vinculo専用の定義ファイルの存在だった。 いろいろといじり倒す前のクリーンなコードをアプリを別ドライヴに再インストールして復活させることを思い付いたのもプロジェクト達成のための大きな助けとなった。
ちなみに、機種変更が簡単に行えるという触れ込みだったVinculumIDEの「Modifｙ機能」は、ほぼ使いものにならないことが発覚している。
映像は、VinculoのUSBHOSTに接続したmonome128からの信号を、UARTポートに接続したUSB/Serial変換IC、FT232で受信したものを、TeraTermで復調しているところ。monomeから出力されるケッタイな文字列を、設定した通信速度で確認することが出来た。
monomeEmulatorとの相性を確かめていないので「即使える」という保証はないが、これでやっとVinculoにUSBHOSTらしい働きを与えることが出来た。
posted by Yasuski at 12:57| Vinculum2
2013年12月06日
V2DIPのファームウエアを改良する
今日も、なんやかんやでVinculum2をいじっているが、既に2回目となる接続用のデバッガーユニットのコネクターが折れてしまう事故が発生。 これはもう根本的に機械的な構造がおかしいので、中継用のリボンコネクター等「力を逃がす」方法を考えなければならない。
なんせ、Vinculoは「動かない」開発ボードなのである。 必然としてクソいまいましい焼きこみ作業を延々と行ってバグ潰しの作業を行うのだから、ある程度の機械的な堅牢さは必要なのだ。
が、その辺の事をディベロッパーは全くわかっていない。 要はユーザーからのフィードバックが期待できないほど「売れていない」商材なのだと思われるが、文句を言っても無意味なので、自分で改良を行っていくしかない。
で、開発ツールどころか、開発できないツールであることが判明しつつあるVinculoだが、稼働実績のあるVinculum２の方も問題が無いわけではない。
昨日はmonomeを接続して連続24時間のランニングテストを終了し、ある程度の安定性を証明できたV2DIPだが、arc4運用時にLED点灯コマンドを受け損なう現象は全く解決できていない。
UART回線の状態を安定させる方法として、シグナルラインに小容量のコンデンサーをグランドする事例が何処かで紹介されていたが、これは高周波的には波形にリンギングを発生させるアウトな方法で、出来ればフェライトコアでノイズを除去するのが得策と思われる。 が、いつものことだが部品が行方不明。現在ラジオ系パーツの在庫を捜索中だ。
UARTの戻り回線の不安定さを改善することはひとまず諦め、次にV2DIPとFT232Rを基板へ実装するフェイズに移った。
一足先に完成しそうなのが、受け側のFT232RとWiPortを使った受信部で、こちらは外部電源による駆動方式を採用したコンパクトなアルミ製の筐体にUSBコネクターを2個配置した。
出来る限り小さなフットプリントに纏まるように努力しつつ、WiPortのGPIO端子の引き出しも行わねばならないので、部品配置はタイト気味になる。
一方、サテライト側の製作だが、ピギーバックスタイルのV2DIPのサイズが思った以上に大きく、
配置に苦労している。 また、WiPortへの配線が最短距離になるように部品の配置を考えているのだが、これには、後に派生するであろうデバッグ作業のことも考える必要があり、あまり急ぎすぎると失敗しそうな雰囲気だ。
何れの作業にもフェライトコアが必要なので、製作はこの段階でストップしている。
そこで、今一度Vinculum2のファームウエアの検討に戻ることにした。
不慣れながらもコード上に記述されている処理の過程を追ってみたが、GPIOに出力されているLEDの挙動が気になった。
これは、回線の接続を確認するためのインジケーターなのであるが、アクセスが行われる度にLED点灯のインターラプトが掛けられている。
もちろん、接続を全部拾っているわけではなくて、バッファーにある量が溜まったらフラッシュさせるという感じなのだが、それでも結構な頻度でアクセスが行われている。
で、、、、、、今更ながらの感はあるが、そもそも接続の可否を考える以前にLEDが光っていようがいまいが、「そんな事をステージ上では確認する暇が無い」ことに気付いた。
以前、ベンダーに質問を送ったところ、「打つ手なし」というにべもない解答を得たのだが、ここにきてようやく無駄そうなルーティンを発見することができた。 そこで、ダメ元でLEDを発光させるルーティンを削除していくのだが、短気を起こして一気に関連部分をコメントアウトした途端にシステム全体が動かなくなった。
どうもこれは、LED点灯の合間にちょろっとデータハンドリングの処理を行っているようなので、怪しい部分は残して、律儀にLED点灯のルーティンだけにコメントアウトを付けていく。
結果、目視でスピードアップは確認できなかったものの、LEDの点灯を排除したファームウエアの完成にこぎつけた。
残念ながら、今は実際にmonomeをPCにチェインして実験を行える状態ではない（インターフェイスの無線化を行っているので）のだが、PCに接続した別のFT232Rを使い、comPort接続でmonomeとの接続を確認したところ、正常に115200baudで文字列を吐いているようである。
以上で、ソフト面からの改善は自分の実力内ではあるがある程度やり尽くしたと思う。 物理面の作業は波形改善用のコア待ちだが、とりあえず受信側だけはラジオから引っぺがしたパーツでなんとかなった。
この程度の細工で安定した受信が行えればよいのであるが、ひとまずは作業を中断して、フットコントローラーへの部品の実装に移る。
なんせ、Vinculoは「動かない」開発ボードなのである。 必然としてクソいまいましい焼きこみ作業を延々と行ってバグ潰しの作業を行うのだから、ある程度の機械的な堅牢さは必要なのだ。
が、その辺の事をディベロッパーは全くわかっていない。 要はユーザーからのフィードバックが期待できないほど「売れていない」商材なのだと思われるが、文句を言っても無意味なので、自分で改良を行っていくしかない。
で、開発ツールどころか、開発できないツールであることが判明しつつあるVinculoだが、稼働実績のあるVinculum２の方も問題が無いわけではない。
昨日はmonomeを接続して連続24時間のランニングテストを終了し、ある程度の安定性を証明できたV2DIPだが、arc4運用時にLED点灯コマンドを受け損なう現象は全く解決できていない。
UART回線の状態を安定させる方法として、シグナルラインに小容量のコンデンサーをグランドする事例が何処かで紹介されていたが、これは高周波的には波形にリンギングを発生させるアウトな方法で、出来ればフェライトコアでノイズを除去するのが得策と思われる。 が、いつものことだが部品が行方不明。現在ラジオ系パーツの在庫を捜索中だ。
UARTの戻り回線の不安定さを改善することはひとまず諦め、次にV2DIPとFT232Rを基板へ実装するフェイズに移った。
一足先に完成しそうなのが、受け側のFT232RとWiPortを使った受信部で、こちらは外部電源による駆動方式を採用したコンパクトなアルミ製の筐体にUSBコネクターを2個配置した。
出来る限り小さなフットプリントに纏まるように努力しつつ、WiPortのGPIO端子の引き出しも行わねばならないので、部品配置はタイト気味になる。
一方、サテライト側の製作だが、ピギーバックスタイルのV2DIPのサイズが思った以上に大きく、
配置に苦労している。 また、WiPortへの配線が最短距離になるように部品の配置を考えているのだが、これには、後に派生するであろうデバッグ作業のことも考える必要があり、あまり急ぎすぎると失敗しそうな雰囲気だ。
何れの作業にもフェライトコアが必要なので、製作はこの段階でストップしている。
そこで、今一度Vinculum2のファームウエアの検討に戻ることにした。
不慣れながらもコード上に記述されている処理の過程を追ってみたが、GPIOに出力されているLEDの挙動が気になった。
これは、回線の接続を確認するためのインジケーターなのであるが、アクセスが行われる度にLED点灯のインターラプトが掛けられている。
もちろん、接続を全部拾っているわけではなくて、バッファーにある量が溜まったらフラッシュさせるという感じなのだが、それでも結構な頻度でアクセスが行われている。
で、、、、、、今更ながらの感はあるが、そもそも接続の可否を考える以前にLEDが光っていようがいまいが、「そんな事をステージ上では確認する暇が無い」ことに気付いた。
以前、ベンダーに質問を送ったところ、「打つ手なし」というにべもない解答を得たのだが、ここにきてようやく無駄そうなルーティンを発見することができた。 そこで、ダメ元でLEDを発光させるルーティンを削除していくのだが、短気を起こして一気に関連部分をコメントアウトした途端にシステム全体が動かなくなった。
どうもこれは、LED点灯の合間にちょろっとデータハンドリングの処理を行っているようなので、怪しい部分は残して、律儀にLED点灯のルーティンだけにコメントアウトを付けていく。
結果、目視でスピードアップは確認できなかったものの、LEDの点灯を排除したファームウエアの完成にこぎつけた。
残念ながら、今は実際にmonomeをPCにチェインして実験を行える状態ではない（インターフェイスの無線化を行っているので）のだが、PCに接続した別のFT232Rを使い、comPort接続でmonomeとの接続を確認したところ、正常に115200baudで文字列を吐いているようである。
以上で、ソフト面からの改善は自分の実力内ではあるがある程度やり尽くしたと思う。 物理面の作業は波形改善用のコア待ちだが、とりあえず受信側だけはラジオから引っぺがしたパーツでなんとかなった。
この程度の細工で安定した受信が行えればよいのであるが、ひとまずは作業を中断して、フットコントローラーへの部品の実装に移る。
posted by Yasuski at 22:51| Vinculum2
2013年12月02日
monome128のdata transferが成功する。
monome128のUSB出力をUART変換する作業がようやく完結した。
UARTを無線化すれば、ステージ上にPCを置かずに手軽にmonome系インターフェイスを使用できることになる。 ほぼ常時返し出力が送信されてくるarc4と違って、monomeの場合は同時にスイッチングを行うのが最大10ポイント程なので、データの取りこぼしはほとんど発生しなかった。
当初は、Mac側のアプリがmonomeを認識せずハードウエアの死亡をも疑ったが、prefixの文言やシリアルUSBインターフェイスの設定が微妙に違った事が原因で認識が行われなかったようだ。 設定をほぼ完全にコピーしたあとは、双方向の通信が確保された。
この時点で、arc4/monome128共にWiFi化の道が開けた。 今後は、データの取りこぼしを補完するための方策を練っていくことになる。
UARTを無線化すれば、ステージ上にPCを置かずに手軽にmonome系インターフェイスを使用できることになる。 ほぼ常時返し出力が送信されてくるarc4と違って、monomeの場合は同時にスイッチングを行うのが最大10ポイント程なので、データの取りこぼしはほとんど発生しなかった。
当初は、Mac側のアプリがmonomeを認識せずハードウエアの死亡をも疑ったが、prefixの文言やシリアルUSBインターフェイスの設定が微妙に違った事が原因で認識が行われなかったようだ。 設定をほぼ完全にコピーしたあとは、双方向の通信が確保された。
この時点で、arc4/monome128共にWiFi化の道が開けた。 今後は、データの取りこぼしを補完するための方策を練っていくことになる。
posted by Yasuski at 22:46| Vinculum2
2013年12月01日
残念ながらVinculoへの対応は無理っぽい
まあ、リンク先の投稿を見ても解るように、海外でもVinculoに関してはこういった評価らしい、、、、。 チップの素性云々よりも、サポートとIDEがダメってことなのか。 そして、Web上の製作例は皆無である。
自社製品のUSB/シリアル変換IC同士で絶対に相性が良いはずなのに、これは非常に勿体無いことだ。 ちなみにこれは直感だけれども、Vinculoはどこか物理的に結線がおかしいと思っているのだが、、、。
あと、予想できるケースは、チップの仕様違いで48pinではオッケーだったのが64pinになると不適合になる場合。 VDIPは48pin、Vinculoは64pinだから、これは大いに有り得る。
自社製品のUSB/シリアル変換IC同士で絶対に相性が良いはずなのに、これは非常に勿体無いことだ。 ちなみにこれは直感だけれども、Vinculoはどこか物理的に結線がおかしいと思っているのだが、、、。
あと、予想できるケースは、チップの仕様違いで48pinではオッケーだったのが64pinになると不適合になる場合。 VDIPは48pin、Vinculoは64pinだから、これは大いに有り得る。
posted by Yasuski at 23:26| Vinculum2
UART経由でmonomeの接続を確認できた
Max側では、monomei2cとして認識されているが、arc4として立派に機能している事がわかる。
送信側は概ね問題はなさそうだが、LEDを駆動する返りデータの取りこぼしが非常に気になる。
バッファーの容量512byteがプログラム的にはMaxな状態なのだが、容量不足が原因で取りこぼしが発生していると思われる。
Kernelのdevman.hにメモリー容量の設定が記載されているが、
#define VOS_BUFFER_SIZE_64_BYTES 0x00
#define VOS_BUFFER_SIZE_128_BYTES 0x40
#define VOS_BUFFER_SIZE_256_BYTES 0x80
#define VOS_BUFFER_SIZE_512_BYTES 0xC0
と512byteが容量一杯だと思われる。
これを拡張する方法がないか、サポートに質問を投げる予定だ。
ちなみに、monomeフォーラムへの投稿によると受け側の通信速度は115200と設定されているらしく、現在V2DIPで行っている速度設定が正解っぽい。
送信側は概ね問題はなさそうだが、LEDを駆動する返りデータの取りこぼしが非常に気になる。
バッファーの容量512byteがプログラム的にはMaxな状態なのだが、容量不足が原因で取りこぼしが発生していると思われる。
Kernelのdevman.hにメモリー容量の設定が記載されているが、
#define VOS_BUFFER_SIZE_64_BYTES 0x00
#define VOS_BUFFER_SIZE_128_BYTES 0x40
#define VOS_BUFFER_SIZE_256_BYTES 0x80
#define VOS_BUFFER_SIZE_512_BYTES 0xC0
と512byteが容量一杯だと思われる。
これを拡張する方法がないか、サポートに質問を投げる予定だ。
ちなみに、monomeフォーラムへの投稿によると受け側の通信速度は115200と設定されているらしく、現在V2DIPで行っている速度設定が正解っぽい。
posted by Yasuski at 04:39| Vinculum2
2013年11月30日
とりあえず、monomeのDataTransferを確認した
午前中に、VinculoでLoopbackのテストを行っていたが、何の反応もなくmonome用Wireless通信システムの構築はあえなく玉砕の様相が、、、。
monome云々を考えるよりも、単純にUARTデバイスをリング状に繋いでLoopbackの通信実験を行ったほうが効率が良かったと反省する。
やはり改変した部分が悪さをしている感があるので、オリジナルのコードを探しているのだが、ファイルの改変に気を付けて作業を行っていても、IDEが勝手にどんどん元ファイルに上書きを行う悪魔の様な仕様なので、元ネタは紛失してしまった可能性が、、、。が、とにかく「素」に近いコードを探すことにした。
鳴り物入り？で導入したVinculoの不調に昼間は落ち込んでいたのだが、試しにダメ元でV2DIP1/48 の方をブレッドボードに接続して実験を行ってみたところ、ちゃんとデータを吐くではないか、、、。
1年間放置していたmonomeのデータトランスファー実験が、ようやく成功というか第一歩を踏み出せたことになる。
なんのことはない、1年以上前にコンパイル＆デバッグ＆アップロード済みのVinculumII/V2DIP1/48が正常に動いていたという非常にマヌケなリザルトだ。
すでに忘却の彼方にあったVinclumIIデバイスは、48pinの旧型タイプをDebuggerと共に2個、ウクライナから購入していた。 確認したところ、書き込んでいたデータは同じものではなかったようで、UARTには38400baudと115200baudの2種類の異なる通信速度が設定されていた。 このうち、midiっぽい通信速度の38400baudに設定したデバイスは、接続するmonomeに発生するデータストリームの総量を考えると余裕が無さそうだったので、掘り出した旧いデータを元に115200baudに書き換えておいた。 書き込みには安全のため旧型のDebuggerを使用している。
この段階で、VDIPは2つとも正常にmonomeの出力を受けていたが、どちらかの設定にバグが有ったのか、デバイス毎に読み出す文字列が異なっていた。 怪し気な文字を吐いている方のデバイスがアウトっぽかったので、これに再度データをアップロードして確認したところ選択は正解で、2つとも同じ文字列を吐くようになった。 写真はループバックテスト中のもの。 何故か「素」のFT232Rよりもmonomeとの接続が安定していた。 ちなみに、画像の"Hello World"は、VinculumIIのUSB端子にループバック配線をした別のFT232Rを繋いでチェックを行った時にTerminalに入力した文字列だ。
この時点ではまだ双方向接続の確認が行えていなかったので、macbookをLionOSで立ち上げて実験しようとしたところ、今度はmonome用に仕込んであったMax系の音源が動かない。
階下にあるmacbookは正常に動いているが、確かOSをスイッチした直後は、SoftwareUpdateを数回繰り返してようやくマトモに動いたことを思い出した。 現在、macbook15吋のOSアップデートを敢行中だ。
だらしのない結果となったVinculoの導入だったが、このままでは悔しいのでなんとか動く状態に持ち込みたい。 とはいうものの、ライヴの期限までに他の仕込みを行わねばならず、残念ながらそろそろ時間切れとなる。
monome云々を考えるよりも、単純にUARTデバイスをリング状に繋いでLoopbackの通信実験を行ったほうが効率が良かったと反省する。
やはり改変した部分が悪さをしている感があるので、オリジナルのコードを探しているのだが、ファイルの改変に気を付けて作業を行っていても、IDEが勝手にどんどん元ファイルに上書きを行う悪魔の様な仕様なので、元ネタは紛失してしまった可能性が、、、。が、とにかく「素」に近いコードを探すことにした。
鳴り物入り？で導入したVinculoの不調に昼間は落ち込んでいたのだが、試しにダメ元でV2DIP1/48 の方をブレッドボードに接続して実験を行ってみたところ、ちゃんとデータを吐くではないか、、、。
1年間放置していたmonomeのデータトランスファー実験が、ようやく成功というか第一歩を踏み出せたことになる。
なんのことはない、1年以上前にコンパイル＆デバッグ＆アップロード済みのVinculumII/V2DIP1/48が正常に動いていたという非常にマヌケなリザルトだ。
すでに忘却の彼方にあったVinclumIIデバイスは、48pinの旧型タイプをDebuggerと共に2個、ウクライナから購入していた。 確認したところ、書き込んでいたデータは同じものではなかったようで、UARTには38400baudと115200baudの2種類の異なる通信速度が設定されていた。 このうち、midiっぽい通信速度の38400baudに設定したデバイスは、接続するmonomeに発生するデータストリームの総量を考えると余裕が無さそうだったので、掘り出した旧いデータを元に115200baudに書き換えておいた。 書き込みには安全のため旧型のDebuggerを使用している。
この段階で、VDIPは2つとも正常にmonomeの出力を受けていたが、どちらかの設定にバグが有ったのか、デバイス毎に読み出す文字列が異なっていた。 怪し気な文字を吐いている方のデバイスがアウトっぽかったので、これに再度データをアップロードして確認したところ選択は正解で、2つとも同じ文字列を吐くようになった。 写真はループバックテスト中のもの。 何故か「素」のFT232Rよりもmonomeとの接続が安定していた。 ちなみに、画像の"Hello World"は、VinculumIIのUSB端子にループバック配線をした別のFT232Rを繋いでチェックを行った時にTerminalに入力した文字列だ。
この時点ではまだ双方向接続の確認が行えていなかったので、macbookをLionOSで立ち上げて実験しようとしたところ、今度はmonome用に仕込んであったMax系の音源が動かない。
階下にあるmacbookは正常に動いているが、確かOSをスイッチした直後は、SoftwareUpdateを数回繰り返してようやくマトモに動いたことを思い出した。 現在、macbook15吋のOSアップデートを敢行中だ。
だらしのない結果となったVinculoの導入だったが、このままでは悔しいのでなんとか動く状態に持ち込みたい。 とはいうものの、ライヴの期限までに他の仕込みを行わねばならず、残念ながらそろそろ時間切れとなる。
posted by Yasuski at 23:05| Vinculum2
Vinculoに他のプラットフォームで製作したプロジェクトをインポートする
以前は簡単に出来たはずのハードウエアの乗り換えが何故か出来ない。特に、設定を変更したファイルはおしなべてエラー返してくる。
原因は、なんとなくだがIDEの編集機能にあるような気がしてきたので、UART関連の素のコードを見つけて、それを元にVinculo対応に変更したところ、やっとマトモにコンパイルを完了できた。
所謂Arduino的な仕組みを取り入れようとしたり、手動で書き換えずにIDEのModify機能を使うとバグることも判った。
例えば、VinculoではUSB1はMiniUSBポートで楽器接続には使い難いので、これをUSB2に変更しようとする。 一見これはIDEのModify機能を使うと簡単に行えそうな気がするのだが、Modifyを行った途端に再起不能となり、再度Modifyを使って元に戻すこともできなくなってしまう。
修正は、error表記を元に手書きでコードを追えばよいのだろうが、長大な数になりかねない修正作業をイチイチ手動でやるのはあまりにもアホらしい。 よって、最初からFind & Replaceでポートの設定を変更するのが正解だった。
とにかく、Modifyを下手に起動しないこと。 その度に、中途半端に変更した記述をデフォルト値に戻された結果、エラーが頻発する。
LEDの出力ポイントを編集中にI/OmuxでVinculoの端子を確認したが、DIPタイプのVinculum2ではアサインがバラけていたLEDが、Vinculoではシンプルなラインに割り振りが出来、より簡単な配線でLEDを配置できそうだ。 また、接続可能なLEDが増えたので、本来の設計通りにデバイスの動作を目視出来るようになった。
原因は、なんとなくだがIDEの編集機能にあるような気がしてきたので、UART関連の素のコードを見つけて、それを元にVinculo対応に変更したところ、やっとマトモにコンパイルを完了できた。
所謂Arduino的な仕組みを取り入れようとしたり、手動で書き換えずにIDEのModify機能を使うとバグることも判った。
例えば、VinculoではUSB1はMiniUSBポートで楽器接続には使い難いので、これをUSB2に変更しようとする。 一見これはIDEのModify機能を使うと簡単に行えそうな気がするのだが、Modifyを行った途端に再起不能となり、再度Modifyを使って元に戻すこともできなくなってしまう。
修正は、error表記を元に手書きでコードを追えばよいのだろうが、長大な数になりかねない修正作業をイチイチ手動でやるのはあまりにもアホらしい。 よって、最初からFind & Replaceでポートの設定を変更するのが正解だった。
とにかく、Modifyを下手に起動しないこと。 その度に、中途半端に変更した記述をデフォルト値に戻された結果、エラーが頻発する。
LEDの出力ポイントを編集中にI/OmuxでVinculoの端子を確認したが、DIPタイプのVinculum2ではアサインがバラけていたLEDが、Vinculoではシンプルなラインに割り振りが出来、より簡単な配線でLEDを配置できそうだ。 また、接続可能なLEDが増えたので、本来の設計通りにデバイスの動作を目視出来るようになった。
posted by Yasuski at 05:17| Vinculum2
2013年11月29日
Vinculoが来た
IDEを開いて早速Buildを掛けみたが、こちらはmbedよりもさらに敷居が高いという感想を持った。
しかも、USB経由ではプログラムの書き込みができず、Debuggerユニットを同時に買い揃えておかなければならない。 Debuggerは既に旧い機種を持っているが、今回の購入時に大事を取ってもう1つ揃えておいたのは正解。
ただし、Arduino/Leonardoのように、書き込むその都度に接続が遮断されるのも鬱陶しいので、一概にこれを悪い設計とはいえない。 特に試行錯誤が多そうなUSBHOSTの開発を行う場合は、Debugger経由で書き込みを行ったほうが効率的なのかもしれない。
その他の不安要因は、使用者コミュニティの存在を知り得ないことで、今のところ公式以外の各種情報にアクセスする方法がわからない。 とりあえずは、手持ちのサンプルコードを頼りに試行錯誤をするほかはなさそうだ。
詳しい日本語のリファレンスは「トラ技２０１２年２月号」に掲載されており、これは既に入手済である。
とまあ、ハイアマチュアをターゲットにしているにしても、造りが中途半端な感のあるVinculoではあるが、ArduinoライクにADCやデジタルポートを備えた便利なボードなので、使い方次第では面白いことが出来そうだ。
ハードウエアの接続を確認できたので、Laptopの中に眠っていたFT232専用のUSBSerial/UART変換コードを見付けて書き込んでみたが、デバッガを動作させると同時に、USB端子に接続済みで沈黙していたArc4が、再びUSB端子にプラグインした時と同じ「LEDをフラッシングさせる動作」を行うことが確認出来た。 IDE側に表示されるテキストラインをステップ動作させた時の動きも正常そうに見えている。
ただし、XBee直結では通信レートが不明なために、現時点では内容を拾うことは出来なかった。
その後、FTDIチップ専用のプログラマー、FTPlogを起動してmonomeとArc4の通信形態を調査してみた。
monomeは問題なくROMの内容を読み込む事ができたが、
monome128.xml
Arc4は何故かソフトに認識されない。 仕方がないので、DeviceManagerを開いてcomPortの接続を調べたところ、Arc4はcom10に割り振られているようだ。 アプリによっては10桁以上のcomナンバーを認識をしないものがあるので、設定で無理矢理comナンバーを変えたところ、PCがクラッシュしてしまった。
PCを再起動した後、再度FTProgを立ち上げてArc4を接続すると、予想した通りに認識が行われ
monomeArc4.xml
monomeと接続がダブるとクラッシュするので、Arc4をcom10に戻した後、FTPlogを立ち上げて確認すると、やはり認識は行われなかった。
データが揃ったので、手持ちのFT232のROMを書き直した後、ニセmonome＆Arc4を製作する。 ひとまずWiredでUARTを結線してデータトランスファーが正常に行われているかをチェックする。 問題がなければ、通信速度を特定して（FTPlogの情報から、多分115200baud） XBeeもしくはWiPortとの接続を行う。
忘れないうちに、VinculumIDEで編集中のUSBHostFT232Loopback.cの中に2箇所あるUART速度設定を9600baudから115200baudに変更しておく。 また、Bufferの設定容量がデフォルトでは少なすぎるので、これを4096に増やす。
FTPlogの内容をから推測すると、monomeは通常のmidi機器よりもデータトラフィックが多そうなので、（だからFT245をインターフェイスに使用している）安全のため、通信系はハードウエアを分離して2ch体制で行う。 受け側もFT232を別個用意して、それぞれの楽器に対応することになる。
しかし、このDebuggerのコネクタは信じられない位に華奢な作りで、勝手に数度折れ曲がった後に分解してしまった。
通常はストレートな端子を水平に配線して強度をもたせるものなのだが、この造りは酷い。 偶々手持ちにXBee用の2mm規格のソケットがあったので、ピン数は合わないがそれを流用してコネクターを修理した。
そういえば、最初に購入した旧式も似たような造りだったので、ガラスエポキシの台座を足して強度を確保した事を思い出した。
時間に余裕ができたらDebugger基板にケースに収納して、そこから短いコネクターケーブルを介してVinculumが乗った各種ボードにアクセス出来るような仕組みを造ることにしよう。
比較的詳し目のインプレッションが書かれているサイトを発見したので、リンクしておく。
しかも、USB経由ではプログラムの書き込みができず、Debuggerユニットを同時に買い揃えておかなければならない。 Debuggerは既に旧い機種を持っているが、今回の購入時に大事を取ってもう1つ揃えておいたのは正解。
ただし、Arduino/Leonardoのように、書き込むその都度に接続が遮断されるのも鬱陶しいので、一概にこれを悪い設計とはいえない。 特に試行錯誤が多そうなUSBHOSTの開発を行う場合は、Debugger経由で書き込みを行ったほうが効率的なのかもしれない。
その他の不安要因は、使用者コミュニティの存在を知り得ないことで、今のところ公式以外の各種情報にアクセスする方法がわからない。 とりあえずは、手持ちのサンプルコードを頼りに試行錯誤をするほかはなさそうだ。
詳しい日本語のリファレンスは「トラ技２０１２年２月号」に掲載されており、これは既に入手済である。
とまあ、ハイアマチュアをターゲットにしているにしても、造りが中途半端な感のあるVinculoではあるが、ArduinoライクにADCやデジタルポートを備えた便利なボードなので、使い方次第では面白いことが出来そうだ。
ハードウエアの接続を確認できたので、Laptopの中に眠っていたFT232専用のUSBSerial/UART変換コードを見付けて書き込んでみたが、デバッガを動作させると同時に、USB端子に接続済みで沈黙していたArc4が、再びUSB端子にプラグインした時と同じ「LEDをフラッシングさせる動作」を行うことが確認出来た。 IDE側に表示されるテキストラインをステップ動作させた時の動きも正常そうに見えている。
ただし、XBee直結では通信レートが不明なために、現時点では内容を拾うことは出来なかった。
その後、FTDIチップ専用のプログラマー、FTPlogを起動してmonomeとArc4の通信形態を調査してみた。
monomeは問題なくROMの内容を読み込む事ができたが、
monome128.xml
Arc4は何故かソフトに認識されない。 仕方がないので、DeviceManagerを開いてcomPortの接続を調べたところ、Arc4はcom10に割り振られているようだ。 アプリによっては10桁以上のcomナンバーを認識をしないものがあるので、設定で無理矢理comナンバーを変えたところ、PCがクラッシュしてしまった。
PCを再起動した後、再度FTProgを立ち上げてArc4を接続すると、予想した通りに認識が行われ
monomeArc4.xml
monomeと接続がダブるとクラッシュするので、Arc4をcom10に戻した後、FTPlogを立ち上げて確認すると、やはり認識は行われなかった。
データが揃ったので、手持ちのFT232のROMを書き直した後、ニセmonome＆Arc4を製作する。 ひとまずWiredでUARTを結線してデータトランスファーが正常に行われているかをチェックする。 問題がなければ、通信速度を特定して（FTPlogの情報から、多分115200baud） XBeeもしくはWiPortとの接続を行う。
忘れないうちに、VinculumIDEで編集中のUSBHostFT232Loopback.cの中に2箇所あるUART速度設定を9600baudから115200baudに変更しておく。 また、Bufferの設定容量がデフォルトでは少なすぎるので、これを4096に増やす。
FTPlogの内容をから推測すると、monomeは通常のmidi機器よりもデータトラフィックが多そうなので、（だからFT245をインターフェイスに使用している）安全のため、通信系はハードウエアを分離して2ch体制で行う。 受け側もFT232を別個用意して、それぞれの楽器に対応することになる。
しかし、このDebuggerのコネクタは信じられない位に華奢な作りで、勝手に数度折れ曲がった後に分解してしまった。
通常はストレートな端子を水平に配線して強度をもたせるものなのだが、この造りは酷い。 偶々手持ちにXBee用の2mm規格のソケットがあったので、ピン数は合わないがそれを流用してコネクターを修理した。
そういえば、最初に購入した旧式も似たような造りだったので、ガラスエポキシの台座を足して強度を確保した事を思い出した。
時間に余裕ができたらDebugger基板にケースに収納して、そこから短いコネクターケーブルを介してVinculumが乗った各種ボードにアクセス出来るような仕組みを造ることにしよう。
比較的詳し目のインプレッションが書かれているサイトを発見したので、リンクしておく。
posted by Yasuski at 20:37| Vinculum2
2012年10月05日
Vinclum2＠ProgLoaderの書換え
Vinculum2が搭載されているボードのうち、サイズの大きな水晶発振子が装着されている旧いタイプの製品はインストールされているProgLoaderが最新のIDEに対応しておらず、アプリに撥ねられてVerifyを行うことが出来ない。
この状況に対処するには、FTDのサポートに連絡して.romファイルを入手し、コマンドプロンプトを使って書き込み専用のファームウエアを書直す必要がある。
ProgLoader書込みの手順を以下に示す。
１）ROM格納用のディレクトリーを製作し、添付ファイルで送付されてきた.romファイルを格納する。
２）コマンドプロンプトを起動する前に右クリック→Propertyで参照するディレクトリーを指定しておく。
３）Administratorモードでコマンドプロンプトを起動。
４）コマンド、VinPrg.exe -a で、接続中のデバイスを確認する。
５）コマンド、VinPrg.exe -u-d "V2Debug module" ProgLoaderv1.7.rom で書込みを開始する。
ターゲットとなるデバイスはヴァージョンが違うと名称が若干異るようなので、予め VinPrg,exe -a で確認を行っておくと、エラー発生の手間が省ける。
ちなみに、FT232Uart_iomux.c で規定されている DebuggerPin のデフォルト値 "199" でROMをFlashすると、Verifyを行った段階でアプリが固まる現象が発生する。
Pin#をボード側のデフォルト値 "11" に書換えた後は、Verifyのパスが通るようになるが、今度はInternalErrorが表示されてしまう。
ということで、残念ながら問題は完全には解決していない模様。
新たにProgLoaderを書換えたV2DIP1-48でDebugの作業を行なってみたが、こちらの動作は先に書き込んだチップと同じく、問題は無さそうだった。
この状況に対処するには、FTDのサポートに連絡して.romファイルを入手し、コマンドプロンプトを使って書き込み専用のファームウエアを書直す必要がある。
ProgLoader書込みの手順を以下に示す。
１）ROM格納用のディレクトリーを製作し、添付ファイルで送付されてきた.romファイルを格納する。
２）コマンドプロンプトを起動する前に右クリック→Propertyで参照するディレクトリーを指定しておく。
３）Administratorモードでコマンドプロンプトを起動。
４）コマンド、VinPrg.exe -a で、接続中のデバイスを確認する。
５）コマンド、VinPrg.exe -u-d "V2Debug module" ProgLoaderv1.7.rom で書込みを開始する。
ターゲットとなるデバイスはヴァージョンが違うと名称が若干異るようなので、予め VinPrg,exe -a で確認を行っておくと、エラー発生の手間が省ける。
ちなみに、FT232Uart_iomux.c で規定されている DebuggerPin のデフォルト値 "199" でROMをFlashすると、Verifyを行った段階でアプリが固まる現象が発生する。
Pin#をボード側のデフォルト値 "11" に書換えた後は、Verifyのパスが通るようになるが、今度はInternalErrorが表示されてしまう。
ということで、残念ながら問題は完全には解決していない模様。
新たにProgLoaderを書換えたV2DIP1-48でDebugの作業を行なってみたが、こちらの動作は先に書き込んだチップと同じく、問題は無さそうだった。
posted by Yasuski at 17:14| Vinculum2
VNC2のDebuggerを作動させてみた
FT232が実装されたUSB-Serial変換ボードをUSB2_HOSTに接続してデバッグを行なってみた。
FT232を接続しない状態ではDisassemblyウインドウが開き、Step送りのテストは行えない。
FT232を接続した後にデバッグを開始すると、画像のように処理プロセスを確認することが出来る。
なお、今回の実験ではFT232のUART端子への接続は行なっていない。
以上、dataAvailの条件判定とWhileの間でループしていることを確認できた。なんとか動いているっぽい。UART信号を認識した場合の挙動は不明。
次は、もう一つFT232Rを用意してデータの受け渡しが行われているかを確認する予定。
FT232を接続しない状態ではDisassemblyウインドウが開き、Step送りのテストは行えない。
FT232を接続した後にデバッグを開始すると、画像のように処理プロセスを確認することが出来る。
なお、今回の実験ではFT232のUART端子への接続は行なっていない。
以上、dataAvailの条件判定とWhileの間でループしていることを確認できた。なんとか動いているっぽい。UART信号を認識した場合の挙動は不明。
次は、もう一つFT232Rを用意してデータの受け渡しが行われているかを確認する予定。
posted by Yasuski at 01:37| Vinculum2
2012年10月04日
Vinculum-II UART to FT232Host Bridgeについて
Vinculum2の構造が徐々に解って来ているが、問題は「VinculumEVALboard」向きに作られた表題サンプルのアプリケーションを、より小型で機能を制限された「V2DIP1」に移植する際に、対応するボードに合わせて設定を変更するWizardがマトモに機能していないことに集約される。
正常な動作が保証されるピン・アサインを行うためには、FT232Uart_iomux.h、もしくはFT232Uart.hの該当する部分を手動で書き換える必要がある。
通常、Vinculum2のピン・アサインの変更は専用のアプリケーションioMaxで行うが、主要項目の変更は可能なものの、細かな点に関しては修正しきれていないことがある。 エラーが発生した場合は、項目を再確認すること。Buildが通っても実際に稼働させた場合の動作がおかしい場合は、Debuggerの出番となる。
変更が必要となる関連ファイルを以下に示す。
FT232Uart_iomux.h はセットアップファイルで
// SPI_Slave_0_MOSI to pin 22 as Input.
vos_iomux_define_input(22, IOMUX_IN_SPI_SLAVE_0_MOSI);
のような形式でチップのピンアサインが記述されている。
記述されているピン/アサインはチップ・サイズに応じた記述が必要で、デフォルトの状態では3種類存在するパッケージ分の記述が併記されている。 ただし、この部分の編集をioMuxで行った場合、偶におかしな数値が書き込まれていることがあるようなので、チェック後に不正な指定がある場合は修正が必要だ。
一方、ヘッダーファイル FT232Uart.h には使用するLEDマトリックスのアドレスが
#define LED3 0x01
#define LED4 0x02
#define LED5 0x80
のように、記入されている。 これはLEDを接続するGPIOのアドレスを示している。
FT232Uart.c では unsigned char leds とデータ格納先が指定されていて、以下に示すような用法で、LEDの点滅をコントロールしている。
vos_delay_msecs(250);
leds = LED3;
vos_gpio_write_port(GPIO_PORT_A, leds);
vos_delay_msecs(250);
leds = 0;
vos_gpio_write_port(GPIO_PORT_A, leds);
LED点滅のために指定されているアドレスはHEXで表記されていて、例えば0x02は00000010となり、これはGPIO_A_Port1がオンになることを意味する。
同様に、0x04 は 00000100 で、Port2がオン、0x20 は 00100000 で、Port5がオンになる。
ちなみに、今回使用する V2DIP1-48 のGPIO出力は、0、1、2、7 しか存在しないので、指定できるアドレスは、0x01、0x02、0x04、0x80となる。
故にオリジナルのコードに表記されている #define LED5 0x40 はVDIP1上に反映される出力が存在せず、これは LED5 0x80 と書換えるべきだろう。
正常な動作が保証されるピン・アサインを行うためには、FT232Uart_iomux.h、もしくはFT232Uart.hの該当する部分を手動で書き換える必要がある。
通常、Vinculum2のピン・アサインの変更は専用のアプリケーションioMaxで行うが、主要項目の変更は可能なものの、細かな点に関しては修正しきれていないことがある。 エラーが発生した場合は、項目を再確認すること。Buildが通っても実際に稼働させた場合の動作がおかしい場合は、Debuggerの出番となる。
変更が必要となる関連ファイルを以下に示す。
FT232Uart_iomux.h はセットアップファイルで
// SPI_Slave_0_MOSI to pin 22 as Input.
vos_iomux_define_input(22, IOMUX_IN_SPI_SLAVE_0_MOSI);
のような形式でチップのピンアサインが記述されている。
記述されているピン/アサインはチップ・サイズに応じた記述が必要で、デフォルトの状態では3種類存在するパッケージ分の記述が併記されている。 ただし、この部分の編集をioMuxで行った場合、偶におかしな数値が書き込まれていることがあるようなので、チェック後に不正な指定がある場合は修正が必要だ。
一方、ヘッダーファイル FT232Uart.h には使用するLEDマトリックスのアドレスが
#define LED3 0x01
#define LED4 0x02
#define LED5 0x80
のように、記入されている。 これはLEDを接続するGPIOのアドレスを示している。
FT232Uart.c では unsigned char leds とデータ格納先が指定されていて、以下に示すような用法で、LEDの点滅をコントロールしている。
vos_delay_msecs(250);
leds = LED3;
vos_gpio_write_port(GPIO_PORT_A, leds);
vos_delay_msecs(250);
leds = 0;
vos_gpio_write_port(GPIO_PORT_A, leds);
LED点滅のために指定されているアドレスはHEXで表記されていて、例えば0x02は00000010となり、これはGPIO_A_Port1がオンになることを意味する。
同様に、0x04 は 00000100 で、Port2がオン、0x20 は 00100000 で、Port5がオンになる。
ちなみに、今回使用する V2DIP1-48 のGPIO出力は、0、1、2、7 しか存在しないので、指定できるアドレスは、0x01、0x02、0x04、0x80となる。
故にオリジナルのコードに表記されている #define LED5 0x40 はVDIP1上に反映される出力が存在せず、これは LED5 0x80 と書換えるべきだろう。
posted by Yasuski at 21:03| Vinculum2
