• State Not Answered
  • Locked Locked
  • Replies 10 replies
  • Subscribers 21 subscribers
  • Views 1952 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

LPC2378 :Integeration of USB CDC with Ethernet Http Demo code

Murthy r

Hi Friends,

I am using the LPC2378 processor.

I have the USB CDC example code and Http Demo example code.

Both codes are working well in alone.
i want to integrate the USBCDC code and the Http code.

so i integrate the both code and connect the USB cable with the PC.

The USBCDC code is working well.

The problem is when i connect the Ethernet LAN cable i am not able to access the web page means i am not able to ping the address.I am getting the message "The connection has timed out".

Is this both USBCDC and http code wont work together?
should i disable any interrupt routine in the USB or http code?

please help me to solve this problem?

with regrads,
Murthy.R

Parents
  • 0 in reply to vicente gurama

    "I want to revise it to make it a USB CDC alone."

    When you know these facts on USB CDC spec, it's deadly easy.

    1) Bulk IN/OUT endpoints
    You can make the handling of Bulk IN/OUT endpoints independent from the rest of CDC implementation. Actually, the transfer over these endpoints is not affected by any setting like baudrate, handshake lines (CTS/RST, DTR/DSR, etc).

    For bulk IN endpoints, ZLP (Zero-Length Packet) is always required when the transfer size is just the multiple of wMaxPacketSize (usually, 64 bytes for full-speed).

    2) Interrupt IN endpoint
    This endpoint is required on the descriptors.
    But you can leave it un-handled, when you don't use SerialState notification, which carries the signaling like DSR, DCD, parity error, etc.
    Of course, you can use these signaling for different purpose from the original function on RS232.

    3) Class specific requests
    At least, you have to keep the function just on the USB side.
    - SetLineCoding holds the line coding setting from host.
    - GetLineCoding returns this line coding setting, or the default one at the start up.
    - SetControlLineState, SendBreak: Just return "no error"

    You can use these setting for different purpose from the original function on RS232.

    Tsuneo

Reply
  • 0 in reply to vicente gurama

    "I want to revise it to make it a USB CDC alone."

    When you know these facts on USB CDC spec, it's deadly easy.

    1) Bulk IN/OUT endpoints
    You can make the handling of Bulk IN/OUT endpoints independent from the rest of CDC implementation. Actually, the transfer over these endpoints is not affected by any setting like baudrate, handshake lines (CTS/RST, DTR/DSR, etc).

    For bulk IN endpoints, ZLP (Zero-Length Packet) is always required when the transfer size is just the multiple of wMaxPacketSize (usually, 64 bytes for full-speed).

    2) Interrupt IN endpoint
    This endpoint is required on the descriptors.
    But you can leave it un-handled, when you don't use SerialState notification, which carries the signaling like DSR, DCD, parity error, etc.
    Of course, you can use these signaling for different purpose from the original function on RS232.

    3) Class specific requests
    At least, you have to keep the function just on the USB side.
    - SetLineCoding holds the line coding setting from host.
    - GetLineCoding returns this line coding setting, or the default one at the start up.
    - SetControlLineState, SendBreak: Just return "no error"

    You can use these setting for different purpose from the original function on RS232.

    Tsuneo

Children
No data