arm-2d移植到STM32F103ZET6 正点原子开发板-精英版-ALIENTEK

# README **NOTE:** 1. This library is a research project used to explore and demonstrate the possibilities of delivering smart-phone modern graphic user interface using low-cost and resource constraint micro-controllers. It is not a committed product from Arm, and the quality of the service is not validated with sophisticated tests but some functional tests. 2. The library name, i.e. **Arm-2D**, is a temporary term and might be subject to change in the future. The term "the Library" used in this documents refers to the **Arm-2D** library unless state otherwise. ## The Purpose of Branches In This Repository | Branch Name | Description | Note | | ----------------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ | | ***master/main*** | The main branch of the repository. It contains the Arm-2D library and simple examples. | | | ***main-arm-2d-developing*** | The development branch for the ***main*** branch. | It will be merged into ***main*** branch. | | ***main-arm-2d-more-examples*** | It has the same content as ***main*** branch but with additional examples. <br />The purpose of this branch is **adding more examples** for people who want to try while still **keeping the main branch simple and small**. <br />**NOTE**: This branch will not modify anything in the Arm-2D library but only focuse on examples. | | | ***main-arm-2d-more-example-developing*** | It is the development branch for the ***main-arm-2d-more-examples-developing*** branch. | The ***main*** branch will be merged into this one which will be merged into the ***main-arm-2d-more-examples*** branch later. | ## Features of the Arm-2D Library #### In this release ( ver0.9.9) The Arm-2D library provides **Low-Level 2D Image Processing Services** that are mainly used in **Display system**. The supported features include but not limited to: - **Alpha-Blending** / **Alpha-Masking** - With or without Colour-Keying - Colour-filling with an Alpha-Mask - Drawing icons/texts with anti-alias in a specified colour - An optional ***Opacity*** can be attached - **Image Copy / Texture Paving** - With or without Colour-Keying (a.k.a colour masking) - Four mirroring mode: None, X-mirroring, Y-mirroring and XY-mirroring - Support **alpha masks** on both the source side and/or the target side - **Colour format support** - **8-bit Grayscale**, **RGB565** and **RGB888** - Generic **8BIT colour**, **RGB16** and **RGB32** - Colour format conversions between **RGB565** and **RGB888** - **Region/Window Clipping** - **Generic Partial Frame-buffer (PFB) Support** - Transparent for upper layer software/GUI services - Easy to Use - No limitation on target screen resolution - No limitation on PFB size and shape (it could be line or cube with any size) - Support the Dirty Region List - Support swapping RGB16 high and low bytes. - Has built-in frame buffer pool and it is easy to support 3FB. - Support User-specified buffers - **Rotation** - Support for the Colour-masking by default - Rotation with/without alpha-blending - Anti-alias support is added. You can enable it by defining macro **\_\_ARM_2D_HAS_INTERPOLATION_ROTATION\_\_** and set it to "**1**" - **Unified and User Friendly Programmers' Mode** - APIs could be used in Synchronous manner ( **Classic Blocking code** ) and/or Asynchronous manner ( **Event-Driven** ) - Support both bare-metal and RTOS - Ultra small memory footprint ### Planned in the Future Following features are planned and to be introduced in the near future: - **Image Filters, e.g. Generic Anti-aliasing algorithms** - **Zooming/Stretching Algorithms** ## 1 Introduction ### 1.1 The Background With more and more smart IoT edge devices introduced to our daily lives, people who are used to the smart-phone like graphic user interfaces (GUIs) want to have the same modernized user experience even when using micro-controller-based products. This trend has been long observed and understood by Arm's eco-partners. As a result, many silicon vendors introduce dedicated hardware accelerators into their microcontroller products to help 2D image processing. Meanwhile, GUI service providers also update their product lines to target micro-controller based graphic user interface applications. Many open-source embedded GUI stacks are hot on GitHub, e.g. [LVGL](https://lvgl.io/). In fact, using GUI with microcontrollers isn't new at all. Still, until the recent rise of IoT and AI, people have found that the simple and monotonous graphical interface in the past is really unbearable. The pursuit of user experience similar to that of a smartphone has become a basic requirement for products. On the other hand, seemingly complicated graphical interfaces often only require simple texture paving. Even the so-called transparency effects are not unaffordable for microcontrollers that often run under tens of MHz or even hundreds of MHz. Technologies used for 2D graphics have been matured as early as the era of 8-bit Gaming Console. As 8-bit 6502 can achieve fancy graphics effects, why can't the most advanced Cortex-M processor of the day? **Figure 1-1 2D Technologies used in Super-Mario-Brothers on NES** <img src="./documents/pictures/TopReadme_1_a.png" alt="image-20210318235155494" style="zoom: 50%;" /> ### 1.2 The Problems in current solutions As shown in **Figure 1-2**, the Linux system has a complete ecosystem from GPU drivers to GUI software services. Compared with it, the resource-constrained embedded system is obviously missing a lot in the ecosystem. To make up for this missing link, the concept of Arm-2D was introduced. **Figure 1-2 Ecosystem Comparison between Rich Embedded and Constraint Embedded System in GUI** <img src="./documents/pictures/TopReadme_1_2a.png" alt="image-20210318235815106" style="zoom:80%;" /> When we look at the conventional GUI graphics architecture in today's embedded ecosystem (as shown in **Figure 1-3** ), we will clearly observe 4 layers: the application and design layer, the GUI software service layer, the rendering layer and hardware driver layer. **Arm-2D focuses on accelerating the low-level 2D image processing**, and will not touch any part of the GUI software service, so the library will not compete with the GUI service providers in the Arm ecosystem. In fact, because Arm has proposed a unified set of low-level acceleration APIs, **a full ecological level of cooperation can be quickly established** between chip manufacturers that provide hardware accelerators and software providers that provide GUI services. **Everyone can concentrate on their own works**: For example, chip manufacturers can ensure that they receive a wide range of software support by adding drivers for their dedicated 2D accelerators following the Arm-2D standard, and GUI providers only need to build their GUI stack upon Arm-2D APIs; hence a wide range of device support is ensured. **Figure 1-3 The Hierarchy of a Typical Embedded GUI System.** <img src="./documents/pictures/TopReadme_1_2b.png" style="zoom:80%;" /> ### 1.3 The Platform **The library is targeting ALL Cortex-M processors with/without various hardware 2D image accelerators:** - Armv6-M processors: Cortex-M0/M0+/M1 - Armv7-M processors: Cortex-M3/M4/M7 - Armv8-M processors: Cortex-M23/M33/M35P - Armv8.1-M processors: Cortex-M55 **The library is designed with ACI (Arm Custom Instructions) in mind.** Specific accelerations using user-defined instructions could be easily integrated into the library without modifying upper