Bare Metal AMP (Asymmetric Multi-Process Processing Mode)
In the previous blog, we have started and run the Zynq SoC, using two ARM Cortex-A9 MPCore processors in AMP (Asymmetric Multi-Process Processing) mode, but since the previous blog was quite long I did not elaborate on the engineering details of the software. In fact, software engineering running on two processors is also very simple. Here I will show you the communication between the two processors of the Zynq SoC via OCM (on-chip memory device). However, the current software engineering is very simple, so we can start from this basic project and continue to improve. The software engineering in the example we completed last week mainly completed the following tasks: Once Core 0 starts up, Core 1 initializes its private resources, outputs a switching signal, and controls the eight LEDs on the MicroZed I/O expansion board to illuminate. Here we need to use Core 1's proprietary timer counter and enable interrupts via GIC. To achieve the above functions. There is no connection between these applications, they do not share resources. However, next we want to allow these applications to communicate and share resources. The application running on Core 0 is very simple. It mainly implements the activation of the application running on Core 1, and then prints a simple message through the UART 0 output in an infinite loop. However, we plan to use the Core 1 interrupt controller, so the first step we have to configure the GIC (General Purpose Interrupt Controller), add the code shown below to the source code file of the Core 0 application: Core 1's application code may be more complicated because we want to call the GPIO module in the PL (Programmable Logic) section of the Zynq SoC to drive the LEDs on the MicroZed I/O expansion board. Like other Xilinx interfaces, standalone OS uses a #include "xgpio.h" code to provide driver information for the gpio interface, which is used with the xgpio_ps.h that we used to drive the PS portion of the MIO/EMIO GPIO interface. There are some minor differences in the files. In this example I want to show you how to use the GPIO interface in the PL part of the Zynq SoC. To ensure that we can see the switching of the LEDs on and off, we will use the Core 1 proprietary timer, which is the same as our previous Core 0 timer. Before the Core 1 program starts executing its main program, we need to disable the on-chip memory (OCM) cache function, initialize the GPIO interface, initialize the private timer, and configure the interrupt controller so that the private timer interrupt can be Used to control the switching of the LED light on and off. We will do this using the Zynq SoC application and the exception mechanism that prohibits caching. Now we can start writing fairly simple interrupt service routines that can control the LEDs to turn off when the private timers are timed out and then retimed. This process will continue all the time. I chose to use the hexadecimal AA and 55 alternate transitions to assign LED lights to control the LED light on and off. This choice will be that all LEDs "flow", there are some differences between the full or off state of all LEDs. The following figure is the result of the program execution, output to the terminal dialog window through Core 0: Photo Sensor Light,Photo Sensor Types,Electric Photo Sensor,Small Reflective Sensor Shenzhen ShenWu Sensor Co.Ltd. , https://www.szsuenw.com
Core 0 is the primary device that activates Core 1. It also utilizes the on-chip UART serial port to output print information to a terminal with a fixed delay. This delay does not apply to timing counters, etc., although it is easy to use a private timing counter here, I will describe the use of two private timing counters in the following blog. 
