Top Page [◀◀]  2   3   4   5   6   7   8   9   ... [▶▶Last Page

USB対応マイコンによるFTDI素子とのUSB通信

こんにちは。

Synergy (又はルネサスのUSB機能実装マイコン)で FTDI 素子を用いた機器と

通信を行いたいのですが、データの送受信を実現された方はいらっしゃいますでしょうか?

現在確認しているのは、

 CDCのClass Request(UX_HOST_CLASS_CDC_ACM_IOCTL_SET_LINE_CODING)は非対応である。

   非対応である為、上記関数を使用してボーレートやビットレートの設定は出来ない。

   従って、CDCドライバを使用して、FTDIデバイスを使用したUSB機器とデータのやり取りが出来ない。 

実現された方は、どのように対応されたのか、教えて頂けないでしょうか?

また、こうすればいいのではというご意見あれば教えて下さい。

是非、皆様のお知恵をかしてください。

よろしくお願い致します。

  • えん さん、こんにちは。NoMaYと申します。

    以下のスレッドにリプライをしたことがありますが、えんさんが以下のスレッドにも質問されているということは、Synergy(又はルネサスのUSB機能実装マイコン)側をUSBホストにして、そこにFTDIのUSBシリアル変換チップを繋ぎたい、ということですよね?

    rx111におけるCDCドライバを使用したFTDIチップ搭載デバイスとのシリアル通信について
    japan.renesasrulz.com/cafe_rene/f/forum5/3903/rx111-cdc-ftdi

    このスレッドにリプライしていたのは随分昔でしたので、改めて読み直してみたのですが、yamayamaさんが解決された方法は以下のような方法なのではないだろうか、と思いました。

    (1) FTDIチップのエンドポイントの構成は、INが1つ、OUTが1つ、コントロールが1つ、である。

    (2) INエンドポイントでは、最初の2バイトは以下のヘッダファイル記載の通り、ある目的の為に割り当てられている。
    (3) INエンドポイントの3バイト目以降は、FTDIチップが受信したシリアルデータではないかと、思われる。

    (4) OUTエンドポイントでは、最初の1バイトは以下のヘッダファイル記載の通り、データ長を示す為に割り当てられている。
    (5) OUTエンドポイントの2バイト目以降は、FTDIチップが送信するシリアルデータではないかと、思われる。

    (6) コントロールエンドポイントでのFTDIチップとのやりとりには、以下のヘッダファイル記載のコマンドが使用される。

    uClinux-H8のヘッダファイルの1つ(上記のスレッドでyamayamaさんが提示されていたURLです
    osdn.net/projects/uclinux-h8/scm/git/linux/blobs/master/drivers/usb/serial/ftdi_sio.h

    Synergyは使ったことがありませんが、INが1つ、OUTが1つ、コントロールが1つ、のバルク転送モードはありますでしょうか?あれば、そのバルク転送モードを使用して、FTDIチップと通信することになると思いました。

  • NoMaYさん、こんにちは。
    ご投稿有難う御座います。返信方法が分からず、おそくなりました。

    ご確認内容の件、SynergyのUSBをホストにしてFTDIのUSBに対して
    通信するイメージで間違いありません。製品構成は以下のようになります。
    Synergy(USB ホスト) ⇔ (USB デバイス) FTDI ⇒ 別製品のCPU

    yamayamaさんの投稿ではCDCドライバを使用せず、流用出来るとなっておりました。
    そこでご提示いただいているftdi_sio.hのソースも見ましたが、USBの細かい知識が
    ありませんので、全くどのように流用できたのかがわかりません。
    その流用で(1)~(6)を行っているかも私にはわかっておりません。[すみません。]

    バルク転送モードかわかりませんが、SynergyのSSPはUSBXホストスタック・
    ユーザガイドを参照するそうですので、ルネサスのCPUであれば同じ設計方法に
    なると思っています。

    よろしくお願いします。
  • えん さん、こんにちは。NoMaYです。

    USB通信での、エンドポイントとか、バルク転送とか、そういうところからの知識が無いのですね。そうなりますと、SynergyのUSBXホストスタックのAPI関数を使用した、少なくとも機能限定版的なものでも、実際に動作する具体的なサンプルコードが無いと、この作業に着手することが無理そうな感じですね、、、

    ごめんなさい。私では、ここから先のお手伝いは無理そうな感じです。すみません。他の方からのリプライを待って頂けますか、、、

  • NoMaYさん、こんにちは。
    ご返信ありがとうございます。追加で教えて下さい。
    先ほど、エンドポイントやパイプについて学びました。
    www.picfun.com/usb02.html ←学習先

    (1)と(6)の推測にもとづくとボーレート設定は(1)と(6)が関連していると推測しました。
    コントロールのエンドポイントが1つで 、そのコントロールエンドポイントでのFTDIチップとのやりとりには、
    以下のヘッダファイル記載のコマンドが使用される。
    とのことですが、ボーレートを設定しているコマンドは頂いていいるURLのヘッダファイルから推測可能なのでしょうか?

    https://osdn.net/projects/uclinux-h8/scm/git/linux/blobs/master/drivers/usb/serial/ftdi_sio.h

    よろしければ、ご確認お願いします。

  • えん さん、こんにちは。NoMaYです。

    > ボーレートを設定しているコマンドは頂いているURLのヘッダファイルから推測可能なのでしょうか?

    ボーレートに関してはyamayamaさんが提示して下さっていたもう一方の以下の2つ目のURLも関係していますよ。uClinux-H8のヘッダファイル単独では分かりにくい部分をこれで補うことが出来るよ、という意図で提示して下さっていたのだと思います。

    uClinux-H8のヘッダファイルの1つ (yamayamaさんが提示されていた先ほどのURLです)
    osdn.net/projects/uclinux-h8/scm/git/linux/blobs/master/drivers/usb/serial/ftdi_sio.h

    /*
     * BmRequestType:  0100 0000B
     * bRequest:       FTDI_SIO_SET_BAUDRATE
     * wValue:         BaudDivisor value - see below
     * wIndex:         Port
     * wLength:        0
     * Data:           None
     * The BaudDivisor values are calculated as follows:
     * - BaseClock is either 12000000 or 48000000 depending on the device.
     *   FIXME: I wish I knew how to detect old chips to select proper base clock!
     * - BaudDivisor is a fixed point number encoded in a funny way.
    。。。以後省略。。。

    AN232B-05 Configuring FT232R, FT2232 and FT232B Baud Rates (yamayamaさんが提示されていたもう一方のURLです)
    www.ftdichip.com/Support/Documents/AppNotes/AN232B-05_BaudRates.pdf

    1.3 Baud Rate Calculation
    A Baud rate for the FT232R, FT2232 (UART mode) or FT232B is generated using the chips
    internal 48MHz clock. This is input to Baud rate generator circuitry where it is then divided by 16
    and fed into a prescaler as a 3MHz reference clock. This 3MHz reference clock is then divided
    down to provide the required Baud rate for the device's on chip UART. The value of the Baud rate
    divisor is an integer plus a sub-integer prescaler. The original FT8U232AM only allowed 3 subinteger
    prescalers - 0.125, 0.25 or 0.5. The FT232R, FT2232 (UART mode) and FT232B support
    a further 4 additional sub-integer prescalers - 0.375, 0.625, 0.75, and 0.875. Thus, allowed values
    for the Baud rate divisor are:
    Divisor = n + 0, 0.125, 0.25, 0.375, 0.5, 0.625, 0.75, 0.875; where n is an integer between 2 and
    16384 (214).
    。。。以後省略。。。

     

  • NoMaYさん、こんにちは。
    コメント、有難う御座います。

    説明はなんとくわかりましたが、C言語のコメント部ですので、どんな命令を転送しているかわからないです。

    0100 0000B がコマンドでその後、BaudDivisor の設定される値をコントロール伝送でホストからデバイスへ送信する?でしょうか・・・・

    もう少し調べてみます。
  • えん さん、こんにちは。NoMaYです。

    > 0100 0000B がコマンドでその後、BaudDivisor の設定される値をコントロール伝送でホストからデバイスへ送信する?でしょうか・・・・

    そういうことであれば、ネットに情報が無いか、私も検索してみました。ここなどはどうでしょう。

    9.3 USB Device Request - とりメモ - ホーム >‎USB2.0メモ‎>‎9. USB Device Framework >
    sites.google.com/site/toriaezunomemo/home/usb2-0memo/usb-device-framework/9-3-usb-device-request

    [追記]

    以前のリプライで以下のように書きましたが、“コマンド”→“リクエスト”の方がよかったかな、と思いました。(そして、それらのリクエストを送信(or送受信)する、SynergyのUSBXホストスタックのAPI関数を探し、恐らく引数の構造体(実際の引数は構造体へのポインタかと思います)に該当する値をセットし、そのAPI関数を呼び出すことになる筈、だと思っています。)

    (6) コントロールエンドポイントでのFTDIチップとのやりとりには、以下のヘッダファイル記載のコマンドが使用される。

    (6) コントロールエンドポイントでのFTDIチップとのやりとりには、以下のヘッダファイル記載のリクエストが使用される。

    [追記2]

    以下のように書いた方がよかったかも知れません。

    それらのリクエストを送信(or送受信)する、SynergyのUSBXホストスタックのAPI関数

    それらのリクエスト(どのリクエストかはAPI関数の引数の構造体(実際の引数は構造体へのポインタかと思います)に値をセットすることで指定する)を送信(or送受信)することが出来るコントロール転送を行う、SynergyのUSBXホストスタックのAPI関数

  • えん さん、こんにちは。NoMaYです。

    その後どうでしょうか?進展はありましたでしょうか?

  • NoMaYさん、こんにちは。いろいろ有難う御座います。
    まだ、情報の整理が出来ていず、調べています。

    一番最初の投稿
    (1) FTDIチップのエンドポイントの構成は、INが1つ、OUTが1つ、コントロールが1つ、である。
    について普通にそのような構成にしてエンドポイントの番号は固定にして、
    記載のコマンド?任意なコマンドを送信する方法や、一番簡単なサンプルを探しているところです。

    わからず、書いていますが、
    CDC_ACMのクラスは用意されたコントロール伝送しかできない?かとおもっていて、
    どのクラスが該当しそうかみています。
  • 便乗にて失礼いたします。

    RX113にて、FTDIチップ(FT232R)搭載のデバイスからシリアル通信を実現するため、
    r01an2167xx0112_usb を使用して RX113とFT232R 間のCDC通信処理を構築しています。

    現在、以下スレッドのyamayama 様の投稿時点の動作と同様、アタッチステートから変化がなく、
    GET_DESCRIPTORコマンドの送信、応答エラーのNAK割り込みが発生する状況です。

    <japan.renesasrulz.com/.../rx111-cdc-ftdi>

    48MHzのクロックを作成する件については、メインクロック16MHzからPLL回路を使用し
    UCLK 48MHzに設定しています。

    完成までの内容が判る方がおられれば、詳しく教えていただけないでしょうか。
  • In reply to sak:

    GET_DESCRIPTORコマンドの件を解決した後に考える話になりますが、先述のスレッドの以下内容を読んで、以下を対応しています。

    > 1、まず、CDCドライバのクラスリクエストはFTDIチップに対応していないためクラスリクエストの処理を削除しました。
    ⇒r01an2167xx0112_usb, r_usb_hcdc_apl.c の以下処理をコメントアウト。
    - set_control_line_state()
    - set_line_coding()
    - get_line_coding()

    > 2、以下のサイトを参考にFTDIチップに対応している2つのリクエストを行う記述を追加しました。
    ⇒set_line_coding() を参考に、R_USB_Write を呼び出し。
    p_ctrl の設定内容は以下。
    [FTDI_SIO_SET_BAUDRATE]
    - type = USB_REQUEST
    - setup.type = 0x0340 (bmRequestType 0x40, bRequest = 0x03)
    - setup.value = 0x4138 (とりあえずですが、9600bps設定のイメージ)
    - setup.index = 0 (wIndex : Port)
    - setup.length = 0 (wLength : 0)

    [FTDI_SIO_SET_DATA]
    - type = USB_REQUEST
    - setup.type = 0x0440 (bmRequestType 0x40, bRequest = 0x04)
    - setup.value = 0x0008 (8bit, パリティなし, Stop 1bit, TxOff設定)
    - setup.index = 0 (wIndex : Port)
    - setup.length = 0 (wLength : 0)

    ⇒本件、GET_DESCRIPTORが解決していないため、R_USB_Write()がエラーを返し送信できません。
    無理やりデバッガでエラー条件を回避すれば、送信します。
    (USBプロトコルアナライザで見る限り、PCとFT232間の送信内容と一致)

    > 3、CDCドライバで既に用意されているデータ送信関数をそのまま流用して送信処理を行いました。
    ⇒R_USB_Write () を呼び出すのだろう、と考えております。(こちらは動作確認など出来ていません)
    RS232C通信したいデータを第2引数 *p_buf、データサイズを第3引数 size に設定する想定。
  • In reply to sak:

    取り急ぎですが以下の進展があり、自己解決しました。

    現在、FT232R へのUSB通信と、RS232Cのデータ送信を実現しており
    対向先のPC(TeraTerm)で、受信確認できています。

    [進展した内容]
    ・アタッチステートメントから変化がない件の解消
    ・クラスリクエストの送信
    - FTDI_SIO_SET_BAUDRATE
    - FTDI_SIO_SET_DATA
    ・RS232C データ送信 (受信は開発予定なしのため、見ていません)

    成功した方法は、別途まとめて連絡いたしますが、
    FTDI は Vendorクラスであることがポイントでした。

    結論としては、Vendorクラスの通信に対応できる様に、CDCドライバのコンフィグ設定と
    r01an2167xx0112_usb, r_usb_hcdc_apl.c の処理修正が必要となるようです。
  • In reply to sak:

    私の方で確認した変更点を以下にまとめました。

    1. CDCドライバのコンフィグを変更する。
    以下を除き、r_usb_basic_mini, r_usb_hcdc_mini の変更はしていません。
    - r_usb_basic_mini_config.h
    #define USB_CFG_HVND_USE を追加
    (#define USB_CFG_HCDC_USE はそのまま残します)

    - r_usb_hcdc_mini_config.h
    #define USB_CFG_HCDC_IFCLS の設定を USB_CFG_CDC から USB_CFG_VENに変更

    2. r_usb_hcdc_apl.c の処理修正 (USB オープン処理)
    - R_USB_Open () の引数 ctrl.type を USB_HCDC から USB_HVNDに変更。
    アタッチステートメントから変化があり、エニュメレーションも完了するようです。

    3. r_usb_hcdc_apl.c の処理修正 (セットアップ処理)
    - R_USB_GetEvent の戻り値の switch 判定 USB_STS_CONFIGURED の箇所
    (おそらく、エニュメレーションの完了通知に相当?)で、
    以前に記載済みの FTDI_SIO_SET_BAUDRATE クラスリクエストを送信する。
    (ctrl.type = USB_HCDC を設定)

    - R_USB_GetEvent の戻り値の switch 判定 USB_STS_REQUEST_COMPLETE で
    以前に記載済みの FTDI_SIO_SET_BAUDRATE クラスリクエストを送信する。
    (ctrl.type = USB_HCDC を設定)

    4. r_usb_hcdc_apl.c の処理修正 (データ送信処理)
    - R_USB_PipeWrite () を呼び出す。
    RS232C通信したいデータを第2引数 *p_buf、データサイズを第3引数 size に設定しました。
    (第1引数は ctrl.type = USB_HVND, ctrl.pipe = USB_CFG_HCDC_BULK_OUT を設定)
    以前、R_USB_Write () を呼び出すのだろう、とした部分です。

    5.上記以外の処理はしていません。
    USB_STS_READ_COMPLETE, USB_STS_WRITE_COMPLETE 処理は削除しました。
    ⇒データ受信が必要なシステムであれば、何か対応が必要?
    従来のクラスリクエストも処理していません。

    私の環境では上記で確認ができております。
    不手際などあるかも知れないので、あくまで参考程度でお願いします。
  • In reply to sak:

    すみません。以下、訂正します。

    > 3. r_usb_hcdc_apl.c の処理修正 (セットアップ処理)
    > - R_USB_GetEvent の戻り値の switch 判定 USB_STS_CONFIGURED の箇所
    >
    > (ctrl.type = USB_HCDC を設定)

    > - R_USB_GetEvent の戻り値の switch 判定 USB_STS_REQUEST_COMPLETE で
    >
    >(ctrl.type = USB_HCDC を設定)

    どちらも、ctrl.type は USB_REQUEST 設定です。

Top Page [◀◀]  2   3   4   5   6   7   8   9   ... [▶▶Last Page