"1. Background introduction
With the development of various industries towards intelligence, the requirements of embedded products for energy consumption and efficiency are becoming more and more stringent. Especially in the fields of smart grid, industry and medical treatment, the core MCU processor of a product faces multiple challenges. For example, an automatic motor system or distributed industrial system, on the one hand, needs more digital signal processing capabilities to control the motor more accurately, on the other hand, it also needs more and more advanced network interfaces (can, Ethernet or wireless, etc.) to realize real-time distributed monitoring or control functions. As another example, in Figure 1, a solar inverter system, on the one hand, needs a DSP engine to realize the DC / AC or DC / DC algorithm, on the other hand, it also needs to form a network of multiple inverters through wireless or Ethernet, so as to realize intelligent diagnosis and monitoring.
Facing these needs, there are two traditional solutions. One scheme is to use two separate MCU / DSP, one MCU or DSP is used to realize digital signal processing or control algorithm, and the other MCU realizes network protocol stack or graphical display interface. This kind of scheme has many disadvantages. Firstly, two MCU increase the area of PCB, and the reliability and data throughput of communication between two MCU are limited. In addition, the power consumption will also increase significantly. Program developers even need to maintain multiple software and hardware development environments. Another scheme is to use a single core MCU / DSP with higher dominant frequency and more on-chip resources to complete data processing and auxiliary communication or display functions in time-sharing. This scheme significantly increases the system cost and power consumption. The most fatal thing is that when the customer's product needs to add new functions, the engineer needs to recalculate the resources of MCU core and the running time required for different tasks, It requires more testing time, so it is not conducive to expansion and product maintenance.
In the face of various shortcomings, heterogeneous dual core architecture came into being, which can solve the above problems. In fact, asymmetric dual core architecture MCU can allocate different system tasks to different MCU cores, with fine division of labor, and can best balance performance, power consumption and cost. The communication between two MCU cores can be realized in different ways, such as sharing memory area and message area, which is very simple and easy to implement. In the following chapters, this paper will take ti's latest Concerto series product tms320f28m35h52c as an example to elaborate the advantages of asymmetric heterogeneous dual core MCU and the performance improvement it brings to the system.
2. Features of C2000 Concerto dual core MCU
C2000 Concerto Series MCU is an innovative heterogeneous dual core product launched by Ti. Concerto hybrid architecture provides high performance, high efficiency and reliability by integrating the best real-time control function and communication function in the industry into one chip, so as to realize real-time control loop and fast communication response with low delay [1]. The following describes its characteristics from the aspects of kernel, memory architecture and communication peripherals. The functional block diagram of Concerto series tms320f28m35h52c is shown in Figure 2 below.
The first is the high-performance kernel. Concerto Series MCU includes Cortex-M3 and c28x cores. Cortex-M3 core is the master subsystem core of concerto's main system, and the main frequency can run at 125 MHz at most. Cortex-M3 core is a 32-bit ARM core with ultra-high cost performance. It has been widely used in the industry. Its performance and stability have been widely accepted by users. It is very suitable for communication and event control. C28x is a new generation of 32-bit DSP core. It is the core of most existing C2000 products of Ti. It can run at 150 MHz at most. C28x in concerto has super performance with floating-point unit and VCU coprocessor. It is very suitable for high-throughput data processing. As a control subsystem, c28x is controlled by the Cortex-M3 master subsystem.
The second is the optimized memory architecture. As shown in Figure 2, the c28x of tms320f28m35h52c can control 512KB flash memory with ECC check, 64KB ROM and 36KB RAM with ECC check; Cortex-M3 can control 512KB flash memory with ECC check, 64KB ROM and 32KB RAM with ECC check [3]. Between the two cores, there are shared peripherals and storage areas. A total of 64K bytes of shared RAM and 4K bytes of message ram.
And then it's a peripheral. As shown in Figure 2, the c28x core of tms320f28m35h52c can control DMA, high-speed ADC (3msps), multi-channel high-precision PWM (24 channel PWM and 16 channel high-precision hrpwm), ECAP, eqep and other control peripherals optimized for closed-loop control; Cortex-M3 core can control multiple serial interfaces, Ethernet, can and other industrial communication peripherals. At the same time, the two cores can also share ADC and other peripherals to enhance the flexibility of the whole system.
Finally, the software architecture. As shown in Figure 3, controlsuite is a development resource, software package and development platform that integrates all C2000 MCU. It provides peripheral routines, DSP libraries, documents and development board materials for developers of tms320f28m35h52c. Controlsuite also provides a free full-featured real-time operating system ti-rtos platform, as shown in Figure 4. Ti-rtos is based on sys / BIOS real-time kernel and integrates stable middleware, such as TCP / IP protocol stack, USB protocol stack, fat file system, IPC multi-core communication components, etc.
3. IPC inter kernel communication
The communication between Cortex-M3 and c28x kernel mainly completes two functions: one is data communication, and the other is the transmission of state and control information. IPC (inter kernel communication) data communication needs large ram to support, and only a series of status flag bits are needed to transmit status and control information. In addition, uart4 on Cortex-M3 side and SCIA on c28x side; And the ssi3 on the Cortex-M3 side and the SPIA on the c28x side are interconnected inside Concerto without external hardware connection. Whether to enable such functions depends on the cortex m3 system configuration.
3.1 message RAM memory area
Tms320f28m35h52c uses message ram to realize IPC data communication. As shown in Fig. 5, the 2K byte MTOC message ram is used to transfer messages from the master (Cortex-M3) subsystem to the control (c28x) subsystem; 2K bytes of ctom message ram is used to transfer messages from the control subsystem to the master subsystem. Since both subsystems are equipped with DMA peripherals, DMA can also read and write message ram to improve system efficiency. The message RAM area ensures the mutually exclusive access of messages through the read-write permission of RAM memory. For example, c28x CPU and DMA can read and write access ctom message RAM area, while Cortex-M3 CPU and UDMA can only read and access ctom message ram. Similarly, the read and write access permissions of the two kernels to the MTOC message RAM area are just the opposite.
Message ram is only used as the data cache of IPC, and IPC needs to be completed with the help of specific control logic circuit. As shown in Figure 6, the master subsystem and control subsystem realize the logic flow control of IPC through five registers: ipcack, ipcsts, ipcflg, ipcclr and ipcset. These five registers are all 32 bits, and each bit corresponds to one channel of IPC. Therefore, handshake communication of up to 32 channels can be realized. A total of 4 channels from bit0 to bit3 can trigger the IPC interrupt of the message receiver. A total of 28 channels from bit4 to bit31 require the software query of the message receiver to obtain whether the data is received in the message ram. If only status and control information (such as semaphore in RTOS) is transferred between the two cores, it can be realized only through the above registers without the participation of message ram.
The following is a brief introduction to the operation flow of the IPC module by giving an example of the master subsystem sending a frame of data to the control subsystem.
1. Cortex-M3 writes a frame of data in MTOC message ram first;
2. Cortex-M3 sets bit9 of mtocipcset (cm3 mapped memory area), as shown in Figure 6. At this time, bit9 of mtocipcsts (c28x mapped memory area) will also be set;
3. C28x polls bit9 of mtocipcsts and finds that bit9 has been set（ If the previous operation is one of bit0 to bit3, c28x will be triggered to generate an IPC interrupt)
4. C28x reads the data in MTOC message ram. At this time, Cortex-M3 successfully sends a frame of data to c28x.
3.2 shared RAM memory area
In most cases, the 2K byte IPC message RAM area can meet the data communication between c28x and M3 subsystems, and the communication efficiency can be further improved with DMA. If the user wants to transfer larger pieces of data in two subsystems at one time, another method is to use shared RAM memory.
Tms320f28m35h52c has a shared RAM area of 64K bytes, with a total of 8 s0-s7 blocks, and the size of each block is 8K bytes, as shown in Figure 7. Cortex-M3 can be set so that any shared RAM area is controlled by c28x or m3. For example, after mapping S0 to c28x side, c28x CPU and DMA can read and write S0, while m3 and UDMA can only read S0, not write and prefetch.
If Cortex-M3 needs to send 6K bytes of data to the c28x side at one time, it can first map the shared RAM area S0 to the local memory space, and then send a flag bit to c28x through IPC to inform it that the data can be taken away.
3.3 software driver of IPC
The controlsuite software development package provides two kinds of IPC software driver libraries, IPC driver and IPC_ Lite Driver。 IPC_ Lite driver only uses IPC register to realize communication and does not need additional ram. However, users can only support one IPC interrupt service ISR and do not support processing IPC requests in the form of queue. IPC_ Lite driver is used as follows:
1. The kernel that initiates the data request will call IPC first_ The function name provided by Lite driver. In this example, m3 is the kernel that sends data and executes the "ipclititemtocdataread" function.
• IPC_ Flag2 is the C28 interrupt flag, indicating the arrival of a message from the C28 kernel.
• IPC_ Flag17 is a response flag used by C28 to indicate that a command of M3 core has been processed.
• the address of C28 that needs to read data is also passed to C28 kernel as a parameter.
• this function is called in the while loop because it may return status_ Fail and will not send information to C28 until MTOC IPC interrupt 2 and flag 17 are available, after which the function returns status_ PASS.
2. The kernel that passively receives the data request will parse the command of its ipccom register in the ISR. In this example, C28 mtocipcint2 ISR knows that the flag is set, parses the command of mtocipccom register, and recognizes that it is a read data command.
3. The kernel that passively receives the data request will call the same function name as the kernel that actively initiates the data request. In this example, C28 executes ipclititemtocdataread, IPC_ Flag2 as an interrupt flag parameter, IPC_ Flag17 is used as the status flag parameter.
4. If the command received is valid, IPC_ Lite's driver functions handle read commands and acknowledge status and interrupt flags. If the received command is invalid, only the interrupt flag is acknowledged to release the interrupt to the subsequent command, and the status flag is still set.
The IPC driver establishes a ring buffer in the message ram, so that multiple IPC communication commands can be buffered in the form of a queue and processed one by one, and can support multiple IPC interrupt service programs ISR at the same time. Of course, the IPC driver needs more RAM to support. and
Our other product:
