GD32F350 Experience 8 (Alternative Freemodbus Transplantation Successful)

RCSN

GD32F350 Experience 8 (Alternative Freemodbus Transplantation Successful) [Copy link]

 

I started porting this modbus protocol stack again at noon today. To be honest, it is very easy to port. There are also porting methods for STM32 on the Internet, including forums, but there are none for GD32. I won’t say much about what the modbus protocol is. In the company, most of my projects also use custom protocols. This is my first time to contact Modbus. The idea of receiving a complete Modbus protocol frame on the freemodbus on the Internet, including the official one, is also analyzed according to the following block diagram. That is to say, I need to turn on a hardware timer T35us to always detect whether the line is idle. If the idle time reaches the specified time, it is determined to be a complete frame of data. This is the idea of receiving a frame of protocol data. For sending, the official method is to send byte by byte, then enable the sending completion interrupt, and send one byte at a time. For the low serial port rate and small data capacity, this sending idea is no problem. This sending and receiving idea is applicable to different platforms for universality. But the OP wants to use the previous DMA to send a frame of data, and receive a frame of data by using the receiving + idle interrupt, and integrate it on freemodbus, that is, in sending, cancel one byte sending, and turn it into DMA sending and enabling the sending completion interrupt at the same time. After sending a frame of data, an interrupt is entered, which can reduce the number of multiple sending interrupts. In receiving, use the idle interrupt instead of the T35us timer interrupt to reduce the use of one peripheral. Of course, this is not universal, and other platforms may not have this interrupt event. Therefore, the idea of sending and receiving has become the following block diagram: This content is originally created by EEWORLD forum user RCSN. If you need to reprint or use it for commercial purposes, you must obtain the author’s consent and indicate the source

RCSN

    Then let's talk about the transplantation process. According to the freemodbus source code posted above, there is no STM32 demo project in the source code. Of course, transplantation is also very easy. For the protocol stack part, most of it is abstracted. You only need to write some registration interfaces, such as the serial port initialization interface, the sending interface, and other peripheral-related things. Before transplantation, let's talk about the freemodbus protocol stack idea in general. The project block diagram is as follows: It is also very simple in application. Initialize the peripheral interface, turn on RTU, and then search for the event change interface in the while polling. Next, let's look at the eMBInit function interface, which mainly implements the registration of related peripheral functions to the protocol stack processing interface. These peripheral functions need to be implemented by us The MBPoll function interface is used to implement polling to find event status changes, such as receiving a frame of data, executing events, sending events, etc. If a related event occurs, the corresponding event processing is executed.

RCSN

The protocol processing of freemodbus has been roughly described. We don't need to pay too much attention to the specific implementation of some function codes, we only need to pay attention to the actual data sent and received. So, how to integrate the sending and receiving ideas posted above into freemodbus? Here the official also provides us with interface files Including port.c, which is the relevant configuration file of the platform; it is relatively simple, just set the platform's total interrupt switch interface, which is equivalent to the critical area. In some important processing, set the critical area to prevent interference from external factors. But officially, it seems that many interfaces use critical areas. portevent.c is the event processing of the platform, mainly the writing and obtaining function interfaces of peripheral events. There are four of these events, which are defined and declared using enumeration. Including initialization completion event, one-frame protocol frame reception completion event, protocol frame processing event, and sending completion event. These events can be read and written through post and get.

RCSN

    postserial.c is a registration interface for some serial port peripherals. It provides interfaces but the internal logic needs to be ported according to the platform. The following is a screenshot of the code: For the above three callback functions, we need to judge the interrupt event flag in the serial port global interrupt, and then jump to the corresponding callback. porttimer.c is about the timer, which is used to detect whether the bus is idle. Here we use the idle interrupt to handle the internal functions of our related interfaces. For example, enable the idle interrupt inside the timer interface.

RCSN

mbrtu is the operation interface related to rtu, such as opening, closing, receiving, sending, sending and receiving callback, etc., here we do not change much, mainly sending here, the official uses single-byte sending, the original poster uses DMA sending, so the eMBRTUSend sending interface needs to be changed, here the original poster can use the debugged DMA code posted above.

RCSN

Here we use modbus poll software, you can search Baidu for specific usage. Let's first verify whether the protocol stack is connected. Use function code 04 to read the input register. At this time, the corresponding data will be returned. Loop 1000ms to send and receive, the effect is as follows:

RCSN

Currently, RTC, Usart, and freemodbus protocol stacks have been adjusted. Next step: Add hardware PWM control servos and sun tracking algorithms. Make a prototype. Finally, use the modbus protocol to formulate relevant instructions and develop QT tools to enable upper and lower functions to perform configuration and data transmission.

nmg

How's the progress now? I haven't updated for a long time.

RCSN

nmg posted on 2018-9-23 10:11 What's the progress now? It's been a long time since I updated

I've been very busy at work recently. I picked it up again during the Mid-Autumn Festival. I'm currently working on the host computer.

carverzhang

How did you implement the sun tracking algorithm? Can you share it with me?

sdtsuper

Is there any source code for the transplant? I don't understand some of the transplanted parts. I can't convert it according to stm32. My skills are not deep enough.

nmg

Source code reference author's work post: https://en.eeworld.com/bbs/thread-1054488-1-1.html

yuzhizu

Very valuable for reference, I just want to make a similar mechanism: DMA transceiver + idle interrupt