I’m (still) using a bog standard demo program (heart rate scale demo from Random Nerds).
The scale function does what I want, and everything was working pretty good.
I gave up trying to add an LED indicator, because that just wasn’t happening. So I added a couple of buttons, I could use as indicators and actual buttons for end functions, so win/win for me. (three buttons, three call backs)
But when uploading, I get about 16 call back events for each button. (1 button = 16, 2 = 32, 3 =48). Right on start up, in quick succession. (then it ends with a "asserted at expression: !disp->rendering in progress (invalidate area is not allowed " which I assume is the result of many call backs in rapid fire). Which is why the question is, why would I be getting so many call backs? I shouldn’t be getting any at that point in the program (just starting up).
Any suggestions on what this might be?
The “loop()”
looks like
void loop() {
lv_task_handler(); // let the GUI do its work
lv_tick_inc(5); // tell LVGL how much time has passed
delay(5); // let this time pass
int_operator(); // check for interrupt received flag
update_arc(); //
}
which events did you get ?
The only “event” is the “null pointer” issue I’m dealing with (I’m working on it, making slow progress). That’s where the program conks out (when it happens).
But the callback is operating multiple times no matter what. Even the ones don’t have a NP issue.
If I comment out the code that causes the null pointer issue, everything is still called.
I added back the routines that print the touch screen coordinates when touched, and nothing prints out, so I’m “pretty sure” it’s not the screen. (plus it’s the same number of call backs for each call back, and the same after every reset.
The code is the LVGL tutorial on Random Nerds for the heart rate monitor. About all I did was move the scale over so I could add some buttons, and change the monitor value from heart rate to input from a water flow meter (which isn’t even connected at the moment). Even so, the interrupt from the meter only sets a IR flag so it can be operated on, it doesn’t actually “do” anything else.
It’s not a major issue. In the end product, I can just ignore everything for a couple of seconds. And it happens so fast, the valves it would eventually be connected to wouldn’t have time to do anything anyway.
So it’s more of a curiosity than anything.
In trying to figure out the null pointer issue, I’m going to break the program down to bare bones and kinda start from there. I’m actually learning more about LVGL from it not working, than I am when it works, so there’s that.
Hi @OldMicroGuy
The !disp->rendering in progress assertion can happen in a couple of ways:
- You’re calling an LVGL function from an external context (eg: ISR)
- You’re updating an object property during a draw event
So make sure you don’t call any LVGL function from your ISR directly
Also I noticed a couple of other issues with the snippet of code you sent, here’s a couple of suggestions:
Instead of calling int_operator and update_arc inside your loop, create a LVGL timer and call it there instead. Here’s the documentation for it Timer (lv_timer) - LVGL 9.5 documentation
Also calling tick_inc like that is a bad idea, as lv_timer_handler will take a couple of milliseconds to run and you’re not correctly incrementing it, I recommend using a tick callback instead. Documentation: Connecting LVGL to Your Hardware - LVGL 9.5 documentation
In arduino I assume it should be as simple as:
lv_tick_set_cb(millis);
And you won’t have to call tick_inc anymore
(looks like I forgot to hit the reply button, it saved my reply, nice…)
Thanks for that, I think that’s kinda where I was heading.
I think I have a fundamental misunderstanding of exactly how VLGL works, the nuts-n-bolts.
So I’m thinking my NP issue is mostly the object being out of scope. I think I need to bring it back via something like lv_obj_t * btn = lv_obj_get_child(btn, 0); in whatever routine I used to change the button (color/text).
And that I was doing things where I wasn’t supposed to be doing them.
I think the original demo did have a timer in it. But I was thinking I could just bind the water flow count to the scale value. Which probably would have been ok, untl
I’m trying to get down to the bare essentials, but man my head hurts… I’ve been at this so long, I’m going around in circles. I’m going to post what I have and see if it’s what I need to start wtih.
I need a break, do something dangerous like woodworking…