Shulou(Shulou.com)06/01 Report--

In this issue, the editor will bring you about how to use TouchGFX's MVP architecture to achieve two-way interaction between GUI and hardware. The article is rich in content and analyzes and describes for you from a professional point of view. I hope you can get something after reading this article.

1. How to understand the MVP architecture of Screen in TouchGFX

The full name of MVP is Model-View-Presenter,Model to provide data, View is responsible for display, Controller/Presenter is responsible for logical processing. There is a major difference between MVP and MVC: in MVP, View does not directly use Model, the communication between them is carried out through Presenter (Controller in MVC), and all interactions take place within Presenter.

Summarize MVP in one sentence: all data can only be saved in a class object called Model (simply a file). Presenter is the link between View and Model, and View can only read data through Presenter.

Advantages of MVP:

The model is completely separated from the view, and we can modify the view without affecting the model

The model can be used more efficiently because all interactions take place in one place-within the Presenter

We can use a Presenter for multiple views without changing the logic of the Presenter. This feature is very useful because view change events are always more frequent than model changes.

If we put the logic in Presenter, then we can test the logic out of the user interface (unit tests).

Screen concept

In TouchGFX applications, developers can create as many Screen as the project needs. The Screen here refers to the UI element and its associated business logic. A Screen usually consists of two things: a View that covers all the space displayed on the Screen, and a Presenter that covers all the business logic on the Screen.

TouchGFX has its own memory allocation scheme, which is allocated only to the largest View and the largest Presenter, and the allocated RAM can be reused on all Screen of the application.

Model

The Model class is a singleton that is always active and has two purposes:

Stores the status information of the UI. When switching Screen, View and Presenter are released, so they cannot be used to store information that should be retained during Screen switching. All, Model is required to store the status information of UI.

Acts as an interface to the back-end system, passing events back and forth between the currently active Screen.

The Model class has a pointer that automatically sets to the currently active Presenter. When a change occurs in the Model, the change is notified to the currently active Presenter. This is done through the methods in the application's Model Listener interface.

View

The View class (or, more specifically, a user-defined class derived from the TouchGFX View class) contains all the controls displayed in the current Screen. It also contains a setScreen and a tearDownScreen function, which is automatically called when entering or exiting the current Screen. Typically, you can set the control in the setupScreen function.

The View also contains a pointer to the associated Presenter. The pointer is automatically set by the frame. Using this pointer, you can pass the UI event to Presenter.

Presenter

The Presenter class (which is also a user-defined class derived from the TouchGFX Presenter class) is responsible for the business logic of the currently active Screen. It will receive "backend" events from Model, as well as UI events from View, and decide which action to take.

Summary

In MVP architecture, all data can only be kept in the class object of Model. Presenter is the link between View and Model. View can only read data through Presenter, not data in Model directly.

two。 Using TouchGFX MVP to realize the two-way interaction between UI and hardware

Model-View-Presenter Software Architecture:

2.1 users control hardware LED through UI keypad

Use TouchGFXDesigner to design the interface and add toggleButton buttons

Use the MVP architecture to fill in the code:

2.2 pass CPU usage parameters to UI display

Use TouchGFXDesigner to make a custom control for cpu usefulness, and then add the control to the desired interface

The utilization algorithm of cpu can be found directly under the rt-thread\ examples\ kernel file in rtthread's github. There are many articles on the Internet to analyze the specific implementation principles, so we will not analyze them here.

The following sends the CPU usage parameters directly to Screen through the Model layer.

The above is how to use TouchGFX's MVP architecture to achieve two-way interaction between GUI and hardware. If you happen to have similar doubts, please refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.