Hi, My customer is using LM3S6432 working as a Serial-to-Ethernet adapter. Using source code revision 8555 of the RDK-S2E Firmware Package. The S2E adapter is used to connect a local device which have only serial port, to a remote server via Ethernet.
During testing, we found the S2E adapter canot work properly. So we test the S2E adapter alone as descripted below:
1. The S2E IP address is 192.168.52.169, we login and configured the S2E module by:
2. We have a USB-to-Serial adapter ( COM3 port ) conneced to the S2E UART0 port. using only TDX and RDX pins. as following
3. test using a windows gui socket tool to send and receive data through the Network interface card, and windows hyper terminal through the COM3 port.
We find that when we send data from the soket tool to hyper terminal(Ethernet to COM), the hyper terminal receives OK, but when we send data back from hyper terminal(COM to Ethernet), the received window shows splited data, normally the first 8 characters comes togerther as the first group, and the rest comes togerther as a group.that is when we send "123456789abcdefg1234" from COM to Ethernet, The received characters are "12345678 (here pause a little bit)9abcd1234".
When using lower baudrate, the senario becomes more obvious, for example, when we set the baudrate to 1200, the received data would be "12345678(pause)9abcdefg(pause)1234" that is to say, not only the first 8 characters, but all characters are received grouped in 8.
When using higher baudrate (115200), the senario may sometimes not present. when it appears, still the first 8 characters gouped together, and the rest (may be larger than 8 characters, can be up to 60 or more characters grouped as the last group).
I found in the E2E community, and found a web page quite alike:
but the suggested methods have no effect, I added #define TCP_TMR_INTERVAL 20 and #define TCP_WND_UPDATE_THRESHOLD 1 in the "lwipopts.h" file, but problem remains.
Please give me some advice.
Can somone help, please?
My apologies for the late response
This is a problem that doesn't have any straight-forward solution yet. The S2E adapter in Serial to Ethernet transfers is designed to send out data a byte at a time to an Ethernet buffer and when a timeout value expires, it sends out whatever's in the buffer. So if the buffer is half full and timeout expires, the incomplete data will still be sent out as an individual packet. Increasing the baud rate reduces the possibility of the timeout expiring happening in the middle of a data transfer but it will still happen.
A proposed fix the customer can implement on the serial-side is to have a temporary/intermediate buffer to ensure that the entire data is collected first and then quickly written to the ethernet buffer. Or another approach from the Ethernet-side can be to increase the timeout value to ensure that data is not split up into separate packets. Unfortunately, presently now the RDK doesn't handle this scenario. Try these approaches and lets see if it helps
An approach I've taken in my own applications when they needed to do serial->ethernet was to collect serial data that was coming in, and use a timeout on the serial data. If 2msec go by w/o receiving a character, then I consider the message complete and send it out (I was typically receiving data at 115200 or higher baud rate). I also sent the serial data if my buffer where the data accumulated got full. My code didn't use periodic timers to send the ethernet data, the ethernet data was always sent immediately on demand. This required some under the hood tinkering with the ethernet code (I used uIP in my projects).
In my applications I ran SysTick at 1kHz, rather than the typical 100Hz so that I could track time in msec increments, as was required by other parts of my application. This made short timeouts convenient for responsiveness.
The main reason you see things happen in about 8 byte increments is because a typical setting for the UART FIFO is to trigger when 1/2 full (or 8 characters have been received), and then the interrupt code will fire receiving the 8 bytes. My code needed to be more responsive to potential incoming commands, so I used 1/8 full as the trigger level (2 characters).
Thank you, Moses Isang and slandrum.
After studying the code, i seem to find the reason. Just as Moses Isang mentioned, the RDK is "designed to send out data a byte at a time to an Ethernet buffer and when a timeout value expires, it sends out whatever's in the buffer. So if the buffer is half full and timeout expires, the incomplete data will still be sent out as an individual packet."
So the reason is the FIFO. For this serial->ethernet applicaion, one effective way is to determine where is the start and the end of a data-train based on the time gap of received data. And when send it via the ethernet, sent it all at one time.
When the SYSTICKHZ is set to 100 by default, because of the use of FIFO and timeout, the MCU send 8 charactrs (1/2 FIFO )first because its fast reaponding. That is to say, it does not finish receiving all the data into the FIFO from the serial port, and now the SYSTICK interrupt happens, and the MCU checks the FIFO, it has data in it, so it sends them out. After that, the next time SYSTICK interrupt happens, the left data-train was found in the FIFO, so the MCU sends them as the second part. I tried to modify the SYSTICKHZ to 1 from 100, and find that the data-train can be send to the ethernet at one time. The spit issue was greatly improved.
But that is not a good way to solve this problem, what slandrum suggest is a much better way, so i will try to modify the code, and use time gap to determine the start and end of a complete data-train. and i can also try not using the FIFO, see if disable the FIFO will make it better.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.