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

USBホスト通信時の受信バイト数について

皆様はじめまして。

現在、GR-SAKURA(RX63N)を使用して、HCDC通信(nonOS)を行おうとしております。

 

FIT Modulesのr_usb_hcdc、および、サンプルプログラム「R01AN2235JJ0124 」

(USB ホストコミュニケーションデバイスクラスドライバ(HCDC)による CDC デバイスとの USB 通信を行うサンプルプログラム Firmware Integration Technology )

を元にして、通信対象のデバイスとの送受信を確認しておりますが、受信バイト数、および受信データがうまく取得できません。

 

こちらからの送信(6バイト)は正常に送信できています。

しかし、受信応答を確認(「R_USB_GetEvent」の戻り値が「USB_STS_READ_COMPLETE」のときの状態)すると、以下のようになっています。

 usb_ctrl_t.status→6( USB_ERR_SHORT)

 usb_ctrl_t.size→32(送信されるデータは36バイトです)

 受信バッファの内容→送信データ36バイト中の32バイトまでバッファに入っている

 

そこで、教えていただきたいのですが

・「R_USB_Read」にて、受信サイズに「CDC_DATA_LEN(64)」を指定しているのに、32バイトしか受信しないのはなぜでしょうか。

 (こちらの想定では、36バイトを受信、かつUSB_ERR_SHORTになるのでは?と考えていましたが・・・)

・パイプマックスパケットサイズレジスタ(PIPEMAXP)にも040h(64バイト)が設定されているのに、32バイトしか受信しないのはなぜでしょうか。

・32バイト以降のデータを読み取る方法が、何か用意されているのでしょうか?

 

ヒントだけでもよいので、アドバイスいただければと思います。

よろしくお願いします。


  • よー@名古屋さん、こんにちは。NoMaYと申します。

    相手側機器が送信データ36バイトを32バイトと4バイトの2つのパケットに分割しているということはありませんでしょうか? もしそうであれば、プロトコルの仕様でもって相手側機器から何バイト送信されるかを明確に定義しておき、そのバイト数受信するまで受信関数を繰り返し呼ぶようにしないといけない、ということだったりするのではないだろうか?ということです。

  • In reply to NoMaY:

    NoMaYさん

    こんにちは!お返事ありがとうございます。

    すみません、前提をすべて書ききれておりませんでした。
    今回の通信対象は36バイトを連続で送信してくるので、「USB_STS_READ_COMPLETE」を確認して値を読み取った後、再度「R_USB_Read」を行って連続受信できるようにプログラムしているのですが、受信は常に32バイトで、4バイトが受信できていません。(捨てられている・・・?)

    なので、ご教示いただいたような状況ではないと考えておりました。
    他になにか心当たりがあれば、教えていただければと思います。
    ありがとうございました。
  • In reply to よー@名古屋:

    よー@名古屋さん
    コンフィグレーションのパイプサイズを32Byteに設定しているのではないですか?
  • In reply to IKUZO:

    IKUZOさん

    アドバイスありがとうございます。
    コンフィグレーションのパイプサイズとは、PIPEMAXPレジスタの設定値のことでしょうか。
    こちらは設定箇所、およびR_USB_Readの前に、R_USB_GetPipeInfoを使用して確認しましたが、
    どちらも64Byteでした。
    確認したパイプはBULK_IN(パイプ1)と、BULK_OUT(パイプ2)のみですが、他にパイプサイズを設定する箇所はありますでしょうか。
  • In reply to よー@名古屋:

    よー@名古屋さん
    64Byteであれば64Byteで送信するのがベストではないかと思いますが。
  • よー@名古屋さん、こんにちは。NoMaYです。

    そういうことでしたか。たまたま、今日、別スレッドでFITのソースコードをgrepしていたのですが、この際なのでこちらもan-r01an4659jj0118-rx-fit\FITModules\r_usb_basic_v1.24\r_usb_basic\srcをキーワード"32"でgrepしてみました。結果は以下の通りなのですが、何かを32(バイト?)にする処理がありますね、、、もしも、それだ!と思うアドバイスがありませんでしたら、ものは試しで、ここにブレークポイントをセットして、この辺りに来ているかどうか確かめてみるのはどうでしょうか、、、

    grepした結果

    driver\r_usb_hhubsys.c(862):                 if (g_usb_hstd_class_data[ptr->ip][0] < (uint8_t) ((32 * 2) + 2))
    driver\r_usb_hhubsys.c(869):                     g_usb_hstd_class_data[ptr->ip][0] = (uint8_t) 32;
    driver\r_usb_hhubsys.c(2004):         if (g_usb_hstd_class_data[ptr->ip][0] < (uint8_t) ((32 * 2) + 2))
    driver\r_usb_hhubsys.c(2011):             g_usb_hstd_class_data[ptr->ip][0] = (uint8_t) 32;
    driver\inc\r_usb_basic_define.h(358): #define USB_DEV_B_MAX_PACKET_SIZE_0         (7u)        /* Max packet size for EP0(only 8,16,32,64 are valid) */
    hw\r_usb_creg_access.c(625):  Description     : Data is read from the specified pipemode's FIFO register, 32-bits
    hw\r_usb_creg_access.c(629):  Return value    : CFIFO/D0FIFO/D1FIFO content (32-bit)
    hw\r_usb_creg_access.c(685):  Description     : Data is written to the specified pipemode's FIFO register, 32-bits
    hw\r_usb_creg_access.c(1267):                  : (data = 0x0400), 32 bit (data = 0x0800) access mode.
    hw\r_usb_dma.c(862):     * Transfer data size is 32-bit (long word).
    hw\r_usb_dma.c(1079):     * Transfer data size is 32-bit (long word).
    hw\r_usb_dma.c(1271):     * Transfer data size is 32-bit (long word).
    hw\r_usb_dma.c(1446):     * Transfer data size is 32-bit (long word).

    driver\r_usb_hhubsys.c(862):
    driver\r_usb_hhubsys.c(869):

                /* String descriptor check */
                if (USB_OK == checkerr)
                {
                    if (g_usb_hstd_class_data[ptr->ip][0] < (uint8_t) ((32 * 2) + 2))
                    {
                        g_usb_hstd_class_data[ptr->ip][0] = (uint8_t) (g_usb_hstd_class_data[ptr->ip][0] / 2);
                        g_usb_hstd_class_data[ptr->ip][0] = (uint8_t) (g_usb_hstd_class_data[ptr->ip][0] - 1);
                    }
                    else
                    {
                        g_usb_hstd_class_data[ptr->ip][0] = (uint8_t) 32;
                    }
                }
                else
                {
                    USB_PRINTF0("*** Product name error\n");
                    checkerr = USB_OK;
                }

    driver\r_usb_hhubsys.c(2004):
    driver\r_usb_hhubsys.c(2011):

        /* String descriptor */
        string = g_p_usb_shhub_device_table[ptr->ip][15];
        retval = usb_hhub_get_string_descriptor2(ptr, g_usb_shhub_dev_addr[ptr->ip], (uint16_t) string,
                (usb_cb_t) &class_trans_result);
        if (USB_OK == retval)
        {
            if (g_usb_hstd_class_data[ptr->ip][0] < (uint8_t) ((32 * 2) + 2))
            {
                g_usb_hstd_class_data[ptr->ip][0] = (uint8_t) (g_usb_hstd_class_data[ptr->ip][0] / 2);
                g_usb_hstd_class_data[ptr->ip][0] = (uint8_t) (g_usb_hstd_class_data[ptr->ip][0] - 1);
            }
            else
            {
                g_usb_hstd_class_data[ptr->ip][0] = (uint8_t) 32;
            }

        }
        else
        {
            USB_PRINTF0("*** Product name error\n");
            *table[3] = USB_ERROR;
            return;
        }

     

  • In reply to NoMaY:

    IKUZOさん、NoMaYさん

    ご指摘、コードヒントのご提示、ありがとうございました。
    結論から申し上げますと、NoMaYさんにご指摘いただいた通り、ペリフェラル側からは32バイトに分割して送信されていました。
    連続通信の間隔が短すぎるのか、デバッガでブレークしながら確認したのが悪影響だったのかはまだわかりませんが、その後の受信データが破棄?されていたようです。
    連続送信されているデータを単発送信にしたところ、32バイト受信の後で4バイト受信が確認できました。

    ご報告として、NoMaYさんにご提示いただいたソースもチェックしましたが、driver\r_usb_hhubsys.c(862):の処理はブレークポイントをかけても停止せず(ここの処理を通過していない??)、driver\r_usb_hhubsys.c(2004):は、RTOS用のソースコードでしたので、今回のソフトには関係のない箇所でした。

    また、IKUZOさんにご指摘いただいた、「64Byteであれば64Byteで送信する」も、その通りかと思います。
    今回、通信相手はこちらで作成しているものではないので、受信サイズを32バイトにして作成しようと思います。

    お騒がせして申し訳ございませんでした。

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