This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

EK-TM4C1294XL: Refresh weather report in enet_weather example for mcu TM4C1294NCPDT

Part Number: EK-TM4C1294XL

I want some modifications in enet_weather example, so that i will refresh data after certain time for e.g 60 second, right now it just update once in starting, i want to refresh data from site after 60 second, please suggest me the best way to do that, what changes i need to in existing example.

Please help.

  • I don't have access to run the example today (It is still Sunday here) but I will have someone respond tomorrow.  I think that example already has a 60 second update. 

  • Hi,

      If you look at the UpdateUART() function you will see the below snippet of code. See the highlighted in red where the terminal window is only refreshed every CYCLE_DELAY of delay. The CYCLE_DELAY is defined in the enet_weather.h file with a value of 3000000. You can play with this value to adjust the refresh you want. Or you can use the timer to create a 60s timeout so the UART will only update the terminal window when the timer timeout. 

    //
    // Check if we should scroll the cities.
    //
    if (g_ui32UARTDelay == 0 && g_ui32ShowCities)
    {
    //
    // Clear the terminal. Print the banner and IP place holder.
    //
    UARTprintf("\033[2J\033[H");
    UARTprintf("Ethernet Weather Example\n\n");
    UARTprintf("IP: ");

    //
    // Print the IP address.
    //
    PrintIPAddress(g_pcIPAddr, ui32IPaddr);
    UARTprintf("\n");
    UARTprintf("Hit 'ENTER' to exit\n\n");

    //
    // Print the current city information.
    //
    UpdateCity(ui32City, true);

    //
    // 'Updating' banner.
    //
    UARTprintf("\n__________________________\n\nUpdating:");

    if (g_ui32Cycles >= UPDATE_CYCLES)
    {
    //
    // Reset the cities so that they update.
    //
    for(ui32Idx = 0; ui32Idx < NUM_CITIES; ui32Idx++)
    {
    ResetCity(ui32Idx);
    }

    //
    // Indicate that we have reset all of the cities.
    //
    g_ui32Cycles = 0;
    }

    //
    // Reset the delay.
    //
    g_ui32UARTDelay = CYCLE_DELAY;

  • Greetings Charles,

    Good job - it is wondered "How" the poster missed this.    (Might his 'wants' have justified (some) program investigation?)

    May we gently "squawk" over the use of the "Overly Precise" test of  "UARTDelay?"

    if (g_ui32UARTDelay == 0 && g_ui32ShowCities)

    It is suspected that "<=" proves a "more forgiving" operator (thus Safer) - while accomplishing the same code objective...

  • Hi cb1,

      The g_ui32UARTDelay is of the unsigned int type. I did a quick experiment. Both == and <= produces identical disassembly code as the compiler will use BNE to make the branch. If I change the g_ui32UARTDelay to a signed integer type then the == will compile the same code while the <= will use BGT. In all cases, there is no penalty on the code size one way or the other. 

  • Hi Charles,

    Yes - ok - yet might the 'possibility' of (any) disturbance or disruption cause the (strict) "==" operator to be missed?

    Perhaps - even better - the comparison to "<=3":

    • escapes the "unsigned/signed" intrusion
    • continues the "Forgiving Nature" of a 'less exacting' comparison (i.e. "One & Only One" value no longer achieves the "match!")

    In our (long) work designing/developing Control Systems - employing such "forgiving" tests - have resulted in more ROBUST Systems!    (i.e. the too precise test invites vulnerabilities - and (really) is NOT needed!)

  • Thanks Charles.

    Applause for resolution,

    Thanks Again.