EK-TM4C1294XL: TCP/UDP using LwIP

Hi,

Probably you've misunderstood my question.

I want to implement the connection over Ethernet and not UART.

With UART it's rather easy to do, but i've not done on Ethernet so i just needed a sample code that can demonstrate how to do it (if available any). 

Hi Jay,

I understood what you asked for, e.g. Ethernet TCP/UDP http etc...  you also stated a need to output data to Hyper terminal and that requires access to the virtual COM port via TM4C UART.

Many of the examples in REX cloud portal access have such code pre written such as LWIP Weather and IOT example. You can build your project from those examples and learn to program, write the flash with new firmware etc..

Either way you need to install Code Composer studio v6.x-v7.x  or perhaps forget about this idea you have. CCS v7 has a few new things such as cloud linked GUI composer required to make a custom dash board for your project to have user controls access TM4C launch pad.

http://processors.wiki.ti.com/index.php/Download_CCS

Jay Shah54 said:

and i just need to send RAW data like numbers only which i need to display on PC on TeraTerm or Docklight on PC sort of hyperterminal.

So your Docklight must be Ethernet ready ? even so it still requires you to install CCS to send data to PC.

We modified the Tivaware USB bulk driver example to send data from EK at high speed into Windows. The Windows virtual USB bulk device client is a VS2000 project with source and easily modified to receive data only in echo mode -e added to launch. The EK part of Bulk USB is a CCS project but there is a B2B Ethernet project in the REX cloud that might be modified to do as you need. 

Jay Shah54 said:

I actually meant that my Board and PC will only communicate over Ethernet (No UART).

Ethernet transport is an overkill for slower data packet TX/RX, unless there is a windows GUI being serviced for data such as Telnet TCP 23 and use UDP 23 for commands. Surely your PC has a USB port and much easier to code to handle data at a whopping 250kbps, that ain't to shabby transport speed. Have never seen USB overflow buffer on either end of the connection. The count 32548 packets counted in one second.

The telnet example is the only other code that might be close to what you are searching for. Caution that small packet counts slow data rates you stick with USB it is universal serial and every computer has a USB port unlike TCP that requires a switch be placed near the PC. That might be Ok for research but not practiced in the real world of machines as USB device transport has become champion of late.

Hello B.P.,

Earlier we "Liked" your response to poster. And we support your direction to choose USB over Ethernet.

"Kicker" w/in your "Bulk USB Example" is the fact that, "Host only can initiate transfers!" (and the "echo" feature proves useful during development - but is (beyond) wasteful for "real" applications.

Your post (this thread: Mar 28, 09:17) noted: "B2B Ethernet project in the REX cloud."   Does that project enable TM4C to (both) INITIATE & respond to requests from a "Host" (be it a PC or another MCU) MINUS any "ECHO?"

Thanks much your time/attention.

Like wise!!!

The target (TM4C) receives USB packets from the PC host too. The example MS Visual Studio Bulk client project is easily modified to do much more. Example process user keystrokes at console (dialog posted above) sending that same data to the target who echo's it back to host. A few changes of the bulk client easily turns it into a GUI for the target. Morphing existing code snips makes it much easier for individuals having less background in C++ programming.

We use bulk client sending data from the target into the host and disable RXD event flag, though it's a bidirectional serial transport once you start the serial CDM connection in windows. The programmer only has to get the data from the targets RXD buffer event handler and process it to make it a command processor for the target. So ditch the echo back part in (usb_dev_bulk.c) and modify the VS bulk host program and you have a command GUI of sorts.

//*****************************************************************************
//
// Handles bulk driver notifications related to the transmit channel (data to
// the USB host).
//
// \param pvCBData is the client-supplied callback pointer for this channel.
// \param ulEvent identifies the event we are being notified about.
// \param ulMsgValue is an event-specific value.
// \param pvMsgData is an event-specific pointer.
//
// This function is called by the bulk driver to notify us of any events
// related to operation of the transmit data channel (the IN channel carrying
// data to the USB host).
//
// \return The return value is event-specific.
//
//*****************************************************************************
uint32_t
TxHandler(void *pvCBData, uint32_t ui32Event, uint32_t ui32MsgValue,
          void *pvMsgData)
{
    //
    // We are not required to do anything in response to any transmit event
    // in this example. All we do is update our transmit counter.
    //
    if(ui32Event == USB_EVENT_TX_COMPLETE)
    {

        g_ui32TxCount += ui32MsgValue;
    }
    return(0);
}

//*****************************************************************************
//
// Handles bulk driver notifications related to the receive channel (data from
// the USB host).
//
// \param pvCBData is the client-supplied callback pointer for this channel.
// \param ui32Event identifies the event we are being notified about.
// \param ui32MsgValue is an event-specific value.
// \param pvMsgData is an event-specific pointer.
//
// This function is called by the bulk driver to notify us of any events
// related to operation of the receive data channel (the OUT channel carrying
// data from the USB host).
//
// \return The return value is event-specific.
//
//*****************************************************************************
uint32_t
RxHandler(void *pvCBData, uint32_t ui32Event, uint32_t ui32MsgValue,
          void *pvMsgData)
{
    //
    // Which event are we being sent?
    //
    switch(ui32Event)
    {
        //
        // We are connected to a host and communication is now possible.
        //
        case USB_EVENT_CONNECTED:
        {
            g_bUSBConfigured = true;
            g_ui32Flags |= COMMAND_STATUS_UPDATE;

            //
            // Flush our buffers.
            //
            USBBufferFlush(&g_sTxBuffer);
            USBBufferFlush(&g_sRxBuffer);

            break;
        }

        //
        // The host has disconnected.
        //
        case USB_EVENT_DISCONNECTED:
        {

            g_bUSBConfigured = false;
            g_ui32Flags |= COMMAND_STATUS_UPDATE;

            //
            // Flush our buffers.
            //
            USBBufferFlush(&g_sTxBuffer);
            USBBufferFlush(&g_sRxBuffer);

            break;
        }

        //
        // A new packet has been received.
        //
        case USB_EVENT_RX_AVAILABLE:
        {

            //
            // Get a pointer to our instance data from the callback data
            // parameter.
            //
            psDevice = (tUSBDBulkDevice *)pvCBData;

            /* There should never be returned data from the client */
            USBBufferFlush(&g_sRxBuffer);

            break;

            //
            // Read the new packet and echo it back to the host.
            //
            //return(EchoNewDataToHost(psDevice, pvMsgData, ui32MsgValue));
         }

        //
        // Ignore SUSPEND and RESUME for now.
        //
        case USB_EVENT_SUSPEND:
        case USB_EVENT_RESUME:
            break;

        //
        // Ignore all other events and return 0.
        //
        default:
            break;
    }

    return(0);
}

Thank you - appreciated. So as NOT to hijack poster's thread - might you describe "How or even if you measured" 250Kbps transfer speed?    Assuming that speed was properly measured/valid - such may just induce poster to follow your, "Use USB" direction.

Along poster's, "high speed" desire goals - we note that LX4F & TM4C123 (both) support UART baud rates to 5Mbps!    And - the UART may drive into an RS-422/485 (balanced, differential) transceiver - especially accommodating high "Speed & Distance" - far in excess of that obtained by the "single-ended" USB cable.   If "speed alone" is the prime concern - this (retired) UART may "rise from the ashes" - and warrant further consideration...

cb1_mobile said:

If "speed alone" is the prime concern - this (retired) UART may "rise from the ashes" - and warrant further consideration...

Perhaps a valid point since most the Ethernet Tivaware examples seem to involve the UART though USB cables are sold in 12' lengths or more.

cb1_mobile said:

"How or even if you measured" 250Kbps transfer speed?

The client SW tests USB echo speed but who can type commands that fast other than AI robots. Data's positron brain might develop an orgasmic twitch at such speeds solid state eyes & fingers processing such rapid fired commands. 

BP101 said:

...near future direct support of UART/USB and Ethernet without JTAG port being required.

We're told that the Easter Bunny has full sleigh (or was that Santa?)     I'd expect such "direct support" to arrive on the heels of (both) an understandable & affordable Health-Care Plan.    (and DO remember - if you like your Doctor/JTAG/SWD - you can keep "he/she/it.")   (maybe...)