ADC touchgfx

Understanding MVP Architecture Using setADC() in TouchGFX

The Model-View-Presenter (MVP) architecture in TouchGFX ensures a clean separation of concerns between data handling (Model), UI updates (View), and communication logic (Presenter).

Let's break down how setADC() works within MVP step by step.

🛠 Components in MVP and Their Roles

Component	Role
Model	Handles data (e.g., getting ADC values from hardware).
ModelListener	Interface that Presenter implements to receive data updates from Model.
Presenter	Acts as a bridge between Model and View; receives ADC value from Model and updates View.
View	Handles UI elements; updates screen based on Presenter data.

📌 Step-by-Step Flow Using setADC()

Below is the entire data flow for setADC() in the MVP pattern:

1️⃣ Model Retrieves ADC Data and Notifies Presenter

void Model::tick()
{
    // Check if ADC data is available in the queue
    if (osMessageQueueGet(ADCQueueHandle, &ADC_value, 0U, 0) == osOK)
    {
        // Send ADC data to the Presenter via ModelListener
        modelListener->setADC(ADC_value);
    }
}

✅ Model retrieves ADC value from the hardware (queue) and sends it to modelListener.✅ modelListener->setADC(ADC_value); calls the overridden setADC() in the Presenter.

2️⃣ Presenter Receives Data from Model and Passes it to View

void Screen1Presenter::setADC(int val)
{
    // Forward the ADC value to the View to update the UI
    view.setADC(val);
}

✅ Presenter acts as a mediator and passes the ADC value to the View.✅ The Presenter doesn’t modify the data—it just forwards it.

3️⃣ View Updates UI with the ADC Value

void Screen1View::setADC(int val)
{
    // Update the gauge UI element with the new ADC value
    gauge1.setValue(val);

    // Refresh the screen to show the updated value
    gauge1.invalidate();
}

✅ View updates the gauge widget (gauge1) with the new ADC value.✅ invalidate(); ensures the UI redraws the gauge so changes are visible.

🎯 Why Use MVP?

Benefit	How MVP Helps
Separation of Concerns	Model handles logic, Presenter acts as a bridge, View handles UI.
Loose Coupling	Model doesn’t directly depend on View; Presenter manages communication.
Scalability	New screens or logic can be added easily without breaking existing code.
Testability	Model and Presenter can be unit-tested separately from UI logic.

📌 Summary of Data Flow (setADC())

Step	Component	Action
1	Model	Gets ADC data from the hardware.
2	ModelListener	Calls setADC() in the Presenter.
3	Presenter	Forwards ADC data to the View.
4	View	Updates UI (gauge) and refreshes the screen.

🚀 This structure makes the UI code modular, scalable, and easy to maintain.

Would you like a diagram to visualize the flow? 😊

┌───────────────────┐

│ Model │

│ (Handles Data) │

└───────────────────┘

│

(ADC value received from queue)

▼

┌───────────────────┐

│ ModelListener │

│ (Interface) │

└───────────────────┘

│

(Calls setADC() on Presenter)

▼

┌───────────────────┐

│ Presenter │

│ (Bridges Model & │

│ View, No UI code) │

└───────────────────┘

│

(Calls setADC() on View)

▼

┌───────────────────┐

│ View │

│ (Updates UI) │

└───────────────────┘

│

(Updates gauge & refreshes UI)

▼

┌───────────────────┐

│ Gauge Widget │

│ (UI Component) │

└───────────────────┘