Hi all,
I have some questions and I would be grateful if you could help me. As you know, by adding a Network library, the library without open source needs good documentations. The documentation @ Keil and ARM websites is appropriate for many uses but for networks needs to be completed.
My questions:
1) In the Net_Config_ETH_0.h file, what is the OS Resource Settings?
2)In Net_Config.c, what is the OS Resource Settings? What does define its size
To change the default OS resource settings for the Network Core, use Core Thread Stack Size. The default value is 1024 bytes
3) In Net_Config.c, what is the Memory Pool Size?
The Memory Pool Size specifies the amount of RAM in bytes allocated for the memory pool. The buffers for the network packets are allocated from this memory pool. Usually, the default value of 12000 bytes is sufficient.
Does it get this memory from RTOS Global Dynamic memory?
4) How can I define the maximum data size and packet numbers per second if I use TCP or UDP protocol? I am using STM32F10x series with 72 MHz and a Phi with 50 MHz resource clock with RMII protocol.
5) How much time does a packet need to be transmitted after using netUDP_Send or netTCP_Send?
6) Is there any limitation for the Network on tick number or Kernel frequency of RTOS?
7) If I send the 30Bytes UDP packet each 100us, how the network library handle it? It sends them very fast or accumulate them in in queue form?
Thank you.
Let me answer your questions:
1. The operating system resource settings define stack size and priority for the ethernet interface thread used for the RTOS. This is documented here
2. As above, but for the Network Core thread documented here.
3. The memory pool is statically allocated at build time. Please compile a network example and check the generated .map file.
4. You specify the data length, the network core then sends the data in one or more packets, depending on the data length.
5. This depends on the core frequency of the processor and the speed of the ethernet connection. With a 100 MBit connection, for example, sending 1000 bytes takes less than 100us.
6. There is no limitation on tick number. The RTOS must provide 100ms ticks for the network core.
7. Sending 30 UDP bytes is not optimal because the network also adds ethernet, IP and UDP protocol headers. However, the ethernet MAC also adds a preamble and a 32-bit CRC. This means at least 46 additional bytes.
Dear Franc Urbanc,
I am truly grateful for your prompt response, and I appreciate the time you took to answer my questions. Frankly, I am using the STM32F1X series, which operates at 72 MHz. As I checked the network interface, the network is up at a speed of 10 Mbit.
In my project, the master (my MCU) should collect about 50 bytes from USART at 921600 baud rate every 600 microseconds and send only 16 bytes of them to the Ethernet PHY every 500 microseconds (if no new data is received, the previous data being sent to Ethernet will continue).
Based on the 16 bytes + 48 bytes header, each packet is about 64 bytes. This was confirmed by my network monitoring software on the PC (front-end).
Regarding my calculation, each USART packet is collected every 400 microseconds. Based on the RTOS periodic thread timer, I send the collected 16 bytes to Ethernet every 500 microseconds. For my 10 Mbit Ethernet, each 64-byte packet takes about 60 microseconds. This means that after using the netUDP_send function and waiting for 500 microseconds after each transmission, we are able to send the next packet.
I started my program, and it worked fine for a few minutes. However, it suddenly stopped sending data and did not respond to my ping command. These are my RTOS settings: the kernel frequency is 10,000 and the tick number is 10.
I was in doubt that my USART data collection interrupts were causing issues with my MCU, so I disabled the USART interrupt. Instead, I began reading the USART bytes using DMA and a GPIO pin for signaling to initiate and stop DMA before and after each transmission. But the same behavior is seen.
Is there any problem with my settings or my procedure? By the way, regarding your explanation,
1) I've read all the mentioned documents before and after your comment. Since I am using RTX v5, I consider all default values.
2) Since I use RTX V5, I have increased the stack size by 512 bytes and left other values at their default settings.
3) Thank you.
4) Since my dataset is small, it is sent in one package. Thank you. Yes, for sending 64 bytes at a 10 Mbit interface speed, the total time is less than 60 microseconds. Thank you.
6) It is my main question.
A)Does it mean that interrupting the 600us delay for receiving USART data will cause my networking and MCU to stop working? Or my periodic timer (every 500 microseconds, triggering the sending of UDP packages) may interfere with the network process.
B) By considering the RTOS kernel frequency of about 10,000 Hz (my MCU is operating at 72 MHz), should I increase the tick number to 1000 so that the network has a 100 ms time? Based on the round-robin process, or the RTOS, it manages its duties.
7) Thank you.
Thank you once again for your explanation and for taking the time to read my questions.
I am looking forward to hearing from you.
Your configuration causes too much processing overhead. Why don't you send the data every 10ms. This would generate 922 byte packets (at 921600 baud). The processing and data overhead is almost the same. You will get a much more stable application. High interrupt rates are not a good idea for the microcontroller anyway.
By the way, how can you configure the tick number? It was removed a long time ago in version v4.7.1 in April 2013. Now the tick rate for the periodic timer is set to 100ms and is fixed. This is a heartbeat for the network component.
Dear Frabc,
Thank you for your comment.
I wish I would have much more time for interrupts. Because each 500us data should be processed to estimate the next value states. If I collect them I would lose the estimation algorithm.
In the RTX_Config.h file, As you can see, I can change the Kernel Tick frequency and also the Round-Robin tick.
Regarding the RTX RTOS output, the net sys timer triggers each 10ms according to my 10,000 kernel frequency which is much less than 100ms.
The tick frequency of the RTOS kernel of 1000 Hz was chosen for good reason. Changing it makes no sense, but results in the RTX kernel spending much more time on kernel management, leaving less CPU time for the user application.
The correct design would be cooperative multitasking. This means that in the interrupt, for example, an event flag or a message is sent to a thread that is waiting for it. The RTX then immediately switches to this thread, regardless of how high the tick frequency of the kernel is. And please stop using round-robin scheduling in your application.
The network kernel generally needs 100ms ticks for correct recovery times. So if e.g. the retransmit timeout should be 2 seconds, then in your case it is only 200ms. This will probably cause some retransmissions to fail and the network stack to behave unstable.
Dear Franc,
I am thankful for your help and sorry for the delay in my response because I was implementing your suggestions during these weeks.
It works fine, with the default RTOS values and I managed the interrupts with your recommendations.
Thank you again for your help.
Dear Frunc,
Sorry again, I take your time.
In Net_Config_TCP.h, I am faced with two options and I would be grateful if you could explain them.
// <o>Number of Retries <0-20> // <i>How many times TCP module will try to retransmit data // <i>before giving up. Increase this value for high-latency // <i>and low throughput networks. // <i>Default: 5 #define TCP_MAX_RETRY 5 // <o>Retry Timeout in seconds <1-10> // <i>If data frame not acknowledged within this time frame, // <i>TCP module will try to resend the data again. // <i>Default: 4 #define TCP_RETRY_TOUT 4 // <o>Default Connect Timeout in seconds <1-65535> // <i>If no TCP data frame has been exchanged during this time, // <i>the TCP connection is either closed or a keep-alive frame // <i>is sent to verify that the connection still exists. // <i>Default: 120 #define TCP_DEFAULT_TOUT 15
It means if each packet is not acknowledged within TCP_RETRY_TOUT time (for example 4 seconds), it will retransmit the data up to TCP_MAX_RETRY(for example 5) times.
1)This means that each packet will be stored in the memory buffer (NET_MEM_POOL_SIZE, for example, 12000 bytes) defined in the Net_Config file until it is acknowledged or the system starts sending packets after the elapsed time of TCP_RETRY_TOUT * TCP_MAX_RETRY. Am I correct?
If we send a 1 kilobyte (1KB) packet every 100 milliseconds (ms), the buffer will store the memory for all of them until they are acknowledged. For the worst-case scenario, TCP_RETRY_TOUT * TCP_MAX_RETRY * 1KB * 10 = 200,000 bytes, which is more than the NET_MEM_POOL_SIZE of 12,000 bytes.
2)If I set the TCP_MAX_RETRY to zero, the sender will save the buffer for TCP_RETRY_TOUT(because it can not be set to zero) and wait for each packet to be acknowledged and after TCP_RETRY_TOUT the memory will be released. This means that after each transmission, it will release the buffer after the TCP_RETRY_TOUT timeout. While we may experience some packet loss during transmission, we will not encounter memory loss. Is there any problem if I set the TCP_MAX_RETRY to zero? Does it disconnect my connection before TCP_DEFAULT_TOUT?
In addition, the "netTCP_Send" function and regarding the documentations, "The buffer will be released, no matter if netTCP_Send is successful or not." , it will save memory at least for TCP_RETRY_TOUT seconds. Am I right?
1. Yes, that is correct. Each packet is stored in the memory pool until it is acknowledged by the other side.
2. The values are actually initial values. TCP sockets implement optimization algorithms that optimize the transmission, such as: slow start, congestion avoidance, fast retransmission, sliding window and others. One of these algorithms is to measure RTT time and reduce retransmission timeouts, which can be as low as 100 ms in low latency networks. I suggest leaving the maximum number of retransmission retries at a default value.
3. Yes you are right about that.
I appreciate your explanations and help. Thank you for your comment.