We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi, when I use MDK Network component(RL-TCPnet) based on RL-RTX, I find that the TCP/IP stack can only use polling mode other than interrupt mode? and it's interval is 20ms(I got it from 'eth_thread' in Event Viewer, it excutes every 20ms). Is that right?
The problem is how can I improve the performance within 1ms? If the Network comonent can not work out, is LWIP the better choice for real-time intended applications?
I'm looking forward for your reply. Thank you very much!
The eth_thread actually waits for events from ethernet driver with a 20ms timeout.
On frame receive event, the thread resumes instantly. A 20ms timeout is there to improve robustness.
On timeout, eth_thread checks the driver again. This behavior improves robustness and stability of the system.
Yeah, got it, thank you!
Just one more doubt, net_main() is the main function of the Network Core. It Polls of the Ethernet controller for received data, and I find the function is called frequently by main thread.
But why it is designed to use polling mode? I think it is better to be designed like this: If there is no data received by the driver, the net_main() just waits for an event to occur; whenever the driver receives data, the driver should send an event to net_main() ,so it can be executed in time . Isn't it more effective? But I just cannot find how to do like this, for the TCPnet source code can't be accessed!
Actually it is the driver who defines the operation mode in Driver Capabilities. Network component is capable of using both, interrupt driven and polling mode of CMSIS ethernet driver.
Here is an example of EMAC_LPC43xx.c ethernet driver capabilities:
/* Driver Capabilities */ static const ARM_ETH_MAC_CAPABILITIES DriverCapabilities = { 0, /* checksum_offload_rx_ip4 */ 0, /* checksum_offload_rx_ip6 */ 0, /* checksum_offload_rx_udp */ 0, /* checksum_offload_rx_tcp */ 0, /* checksum_offload_rx_icmp */ 0, /* checksum_offload_tx_ip4 */ 0, /* checksum_offload_tx_ip6 */ 0, /* checksum_offload_tx_udp */ 0, /* checksum_offload_tx_tcp */ 0, /* checksum_offload_tx_icmp */ (RTE_ENET_RMII) ? ARM_ETH_INTERFACE_RMII : ARM_ETH_INTERFACE_MII, /* media_interface */ 0, /* mac_address */ 1, /* event_rx_frame */ 1, /* event_tx_frame */ 1, /* event_wakeup */ (EMAC_TIME_STAMP) ? 1 : 0 /* precision_timer */ };
The method you are suggesting is already implemented in new Network Dual Stack. The system creates also a Network Core thread in netInitialize function. This thread waits for an event to occur. An event is either a frame received from any interface or a timer tick. Then net_main is processed, protocol timers are updated and Network Core thread waits for another event to come.
Franc,
Is that new Network Dual Stack now available? Last time I looked, it was in beta.
We've got a new project coming up and I'd like to find out as much as possible about the suitability of it.
It is in beta 2 now.
http://www.keil.com/pack/doc/mw/Network_DS/html/index.html
Many thanks.
Thank you , Franc and Gordon. I would choose new Network Dual Stack to ensure real-time.
By the way, Franc , I think there will be more RTX and Network users if there is a list of the Network performance analysis .
For example , what's the maximum pixel(YUV420) can be transmitted stablely over the Network with specified CPU frequency (a lot of people use cortex-M MCU to deal with video processing ), and what's the latency time . Though users can calculate it by themselves, they just want to have a visualized graph or something like that, to increase their confidence in using it.