• Locked Locked
  • Replies 6 replies
  • Subscribers 100 subscribers
  • Views 2382 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

SYS/BIOS with Ethernet and TCP/IP on Concerto

Andreas
Prodigy 45 points
Other Parts Discussed in Thread: CONTROLSUITE

Hi all,

I am using a Concerto Control Card with on board Ethernet controller, CCSv4.2.5 and SYS/BIOS (bios_6_33_02_31). The aim of may software development is, to have an application which acquires data of various sensors over I²C, display status information over SPI and LCD and to send the collected sensor data via Ethernet (currently with TCP/IP) to a central computer in a small subnet running a data base.

Without the Ethernet part, everything is running perfectly so far. I adapded the enet_uip example comming with controlSUITE. After establishing a connection (socket), the collected data should be sent from the Concerto server to the central computer (client, only triggers transmission once) without further bidirectional communications. We developed a special frame structure with time stamps for tramsmitting the collected sensor data.

Two bad things happen concerning Ethernet communications with SYS/BIOS in my application:

1. Some frames are missing (every tenth, frame rate: 10Hz, each frame about 50 to 100 bytes), some frames arrive twice

2. The application hangs after some indefinet time. I was not able to localize or reproduce the source of the error.

I spent hours of debugging and trying out various settings and changes of TCP/IP parameters in the program. Without success. Now, my hopes are on the one hand the MCUSDK with CCSv5 which I'am waiting for to be released and on the other hand the usage of UDP instead of TCP/IP, because flow control isn's that important as everything happens only in a small subnet with about five communication nodes, end points respectively.

So, after a brief description, please help me answer the following questions:

1. I think, UDP is the more appropriate protocol for my application. Where can I find example applications using C2000 with UDP? Is it better to use lwIP or uIP, ore some other third party support?

2. When will it be possible to get a copy of the announced MCUSDK packet? I would be very happy with an alpha or beta version

3. Which way of integrating Ethernet communications (either TCP/IP or UDP) in an RTOS, preferably SYS/BIOS can you recommend?

Currently, my feeling is, that the biggest problem is the lack of insight in what the adapded enet-uip application, it's TCP/IP stack respectively, exactly does in my application.

Many thanks in advance for your help, best regards:

Andreas

  • TI__Mastermind 20480 points

    Hi 1931436,

    I've just sent you a friend request to answer these questions via direct email.

  • in reply to Tom Kopriva
    TI__Genius 15855 points

    1. I think, UDP is the more appropriate protocol for my application. Where can I find example applications using C2000 with UDP? Is it better to use lwIP or uIP, ore some other third party support?

    From my personal experience, with both TI and even non-TI MCU architectures, in general lwIP is a better implementation overall.  While uIP is simpler, more compact, and often easier to implement, it often lacks in data throughput and overall performance/capability.  lwIP is a bit more complex, likely larger in memory footprint, but can more often support higher bandwidth/throughput and overall functionality.  Depending on your specific needs, lwIP might be a better implementation for your system.

    -Chris

  • Prodigy 105 points

    Hi Andreas,

    Were you able to find a solution to your problem? We are using the concerto board in a similar application - M3 is used for sending sensor data through Ethernet (using uip -TCP/IP) & c28 core is used for ADC & control functions. We have experienced the same problem as you.  The ethernet data hangs after some indefinite time, and we need to reset power to the concerto board to establish Ethernet connection again. So far, we haven't been able to identify the cause. The problem is much worse in Stand alone mode than in Debug Mode. All other control / indicator functions work well even while Ethernet is not working hence it does not look like that the concerto has frozen.

    We are using this in a remote monitoring application, and it is not possible to reset power every time the Ethernet connection is lost. It would be great if you could let me know if you've found a solution

    Many Thanks,

    Mihika

  • in reply to Mihika Perera
    Prodigy 45 points

    Hi Mihika,

    In our case, UDP solved the issue in the end. I used the clock functions of Ti's SYS/BIOS operating system which is contained in the MCU SDK(really nice to handle, good networking an other useful capabilities, TCP/IP also, but i did'nt try it!) to periodically pack and send the sensor data to a UDP client running under WinCE on the main system. The Concerto device is a subsysten implementing a UDP server. In comparison to TCP/IP, with UDP we saved a lot of protocol overhead and connection complexity which is not necessary for only sending data periodically. Otherwise, UDP isn't as secure as TCP/IP (no retransmission querries in case of packet loss). It was possible to do it that way, because the Concerto device is a real-time data logger and sender in a physically small network, i.e., the UPD client is only a few meters away (distriputed system on an small aeroplane).

    The system and data exchange is testet and running stable for several days. We need guaranteed stability for a few hours for the flight missions. So erverything is fine now.

    Please let me know, if a client-server-application, architecture respectively, is solving your problems, too. UDP is much easier to handle and has less sub-sub-sub ... routine calls in complex program hierarchies. I also can recommend using the MCU SDK. I had a smooth quickstart with that. Many thanks to TI for providing the at that time brand new software development kit!

    Feel free to contact me again.

    Best regards:

    Andreas

  • in reply to Andreas
    TI__Guru* 96960 points

    Please note that "MCU SDK" is now called "TI-RTOS". For more details see http://processors.wiki.ti.com/index.php/TI-RTOS

    Todd

  • in reply to Andreas
    Prodigy 105 points

    Hi Andreas & Todd,

     

    Thank you very much for your replies. I will look in to implementing UDP. Even though currently we test with the client in close range, our end application requires the client to be linked through a long range (2.5 miles) Wi-Fi link. Hope UDP will be reliable enough :) ... I don't mind losing few seconds of data as long as we don't have to reset the power in the concerto to re-establish connection.

     

    Thanks again,

    Mihika.