ADC touchgfx
- balajimail9
- 3 days ago
- 2 min read
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) │
└───────────────────┘
Comments