ART-Pi evaluation application RL-TCPnet realizes Ethernet transceiver function and DTU
[Copy link]
Regarding the application of RTX and RL-TCPnet, we have to mention Anfulai Electronics. A lot of experience and skills are accumulated from the focus on armfly. The source must be cited. This article is mainly about the application of network components. The advantage of using MDK is that it is convenient to add RTX and its components. Conversely, it is most convenient to use MDK to use RTX. First, update the pin initialization of the ETH interface according to the schematic diagram
After the project code is updated, the main task is to transplant RL-TCPnet. The RTE environment still inherits these functions. Select CMSIS Driver, which is the interface of the hardware layer, and then check the relevant options in Network. I don't have an ART-Pi expansion board, but I have a LAN8720 module. ARM happens to provide a standard driver. I will test whether it can be used. You can also use the driver with software reset improved by Eric2013, which also complies with the CMSIS Driver driver specification. And the relevant files of the driver layer are stripped off, which is more conducive to the transplantation work after replacing PHY or modifying the circuit.
After configuring and compiling the code, the following error was found. It should be a problem with the compiler. The project has always defaulted to AC6, and the use of at() does not conform to the syntax.
After searching, I found that there was a related question on the Anfulai forum, and the moderator gave a solution. The code was modified as follows. This is one of the solutions
__attribute__((section(".ARM.__at_0x30040000"))) ETH_DMADescTypeDef DMARxDscrTab[ETH_RX_DESC_CNT]; /* Ethernet Rx DMA Descriptors */
__attribute__((section(".ARM.__at_0x30040060"))) ETH_DMADescTypeDef DMATxDscrTab[ETH_TX_DESC_CNT]; /* Ethernet Tx DMA Descriptors */
__attribute__((section(".ARM.__at_0x30040200"))) uint8_t Rx_Buff[ETH_RX_DESC_CNT]
Another solution is to use the AC5 compiler, which will not report this error. If it is not necessary, it may be more convenient to directly switch the compiler. After all, clicking the mouse is more convenient than changing the code, haha.
You also need to configure several items according to your own link. The details of the code are not shown here. The places that need to be modified have been sorted out, and the network can basically be connected. Witness the real appearance, the module connected by Dupont line is directly connected to the computer network cable, <1 ms is OK.
At this point, we also need to combine the previous serial port application to perform simple data transmission. The message queue is mainly used to transmit content to prepare for the subsequent command transmission. Based on the existing project, you only need to create a message queue, fill it with data received by the serial port, and tcp detects the queue data and sends it to the client, that is, the PC host computer used for testing. On the contrary, tcp receives data and sends it directly through the serial port. This loopback logic realizes the basic DTU function. Part of the code is as follows:
Initialize a queue while creating a thread
net_MsgQueue = osMessageQueueNew(32, sizeof(MSGQUEUE_OBJ_t), NULL);
The serial port receives data and throws it into the queue
if((isISRFlag & USART_FLAG_RXNE) != RESET){
toTcp.Buffer[toTcp.Size] = UART4->RDR;
toTcp.Size += 1;
}
if((isISRFlag & USART_FLAG_IDLE) != RESET){
//__HAL_UART_CLEAR_IDLEFLAG(&huart3);
SET_BIT(UART4->ICR,UART_CLEAR_IDLEF);
osMessageQueuePut(net_MsgQueue, &toTcp, 0U, 0U);
toTcp.Size = 0;
}
The TCP server gets the data and sends it to the client
if(osMessageQueueGet(net_MsgQueue, &DataRecv, NULL, 0U) == osOK){
iCount = DataRecv.Size;
do
{
if(netTCP_SendReady(tcp_sock) == true )
{
maxlen = netTCP_GetMaxSegmentSize (tcp_sock);
iCount -= maxlen;
if(iCount < 0)
{
maxlen = iCount + maxlen;
}
sendbuf = netTCP_GetBuffer (maxlen);
memcpy(sendbuf,DataRecv.Buffer,DataRecv.Size);
netTCP_Send (tcp_sock, sendbuf, maxlen);
}
}while(iCount > 0);
osMessageQueueReset(net_MsgQueue);
}
After some troubleshooting and debugging, we got the following test results. After a period of time of sending and receiving at intervals of 50 ms , the send and receive counts still match, so it is still possible to use it to transmit some instructions.
|