How to do a slide show type of thing


How to do a slide show with littlevGL

What MCU/Processor/Board and compiler are you using?

stm32f103 and arm

What do you want to achieve?

a slide show, show a scene pause show a scene I want to show a bar with a value changing, down to 0. Presumably destroying and redrawing the bar will not increase my demands on flash.

What have you tried so far?

I tried a timeout after displaying my screen, and then using lv_obj_del() on my screen to blank the display. Once the display list is deleted, should we expect to have all the pointers still around?
And I wonder if anyone else has a better idea of how to do this?

I’ve been building something similar and I can highly recommend tileview…

Iterating on my original idea, is there any reason that I can’t put the creation of the screen/label/bar in a subroutine that gets the value to display. Is there something that I wait for, or delay, that will signal me to do the lv_obj_del() and then call that subroutine with the new value?
Thanks for your help

It would make more sense to just change the value (i.e. lv_bar_set_value and a global lv_obj_t * variable) than to recreate the object every time.

LittlevGL is object-oriented. You don’t just render a rectangle on the screen once. You would create a bar object at a specified location on the screen, and change its properties as needed.

That makes a lot of sense. I’m thinking of delaying between the display of changed values by calling a 1 shot task that knows how to delay for a certain time. Then it looks like I can have a callback that knows what the next set of data should be. Or is there a lv_obj_delay() that I can use?



If you’re just looking to call a callback after a specified period of time (and nothing else) you can use the asynchronous calls feature I added.

thanks for the suggestion, I’ll look at that right now.

Now to use it: I make my initial display, and then call asynchronous for whatever timeperiod, my callback knows what the next value should be, and updates the display. Now to get repeated changes, am I going to have to do something recursive? Does that make sense?

It sounds to me like you are polling for when the value needs to be changed. If you’re reading data from an external source, that makes sense. Otherwise, it would be better to update the display at the same time that you change the value (unless you are changing it in an interrupt handler, which requires extra logic).

Sorry I wasn’t clear in what I wrote, I want my “slides” to change at the specified interval based on expired time. So I want to retrigger the asynchronous call with the delay for each of the changes. Could I call the lv_task_reset() each time as the last thing in the callback?

Then you should use a regular lv_task, which will fire over and over at a specified rate (i.e. every 2000 milliseonds).

Hi EmbeddedT
Thanks very much for your excellent advice! I will look at using that

How much heap and ram does starting a regular task take? Do you have any numbers that you can share?

It shouldn’t be noticeable, but my guess from the header file is ~32 bytes.

Do the 32ish bytes come from the stack and/or the heap?

They come from the heap.

If you don’t mind me asking, I’m curious why are you concerned about 32 bytes in this case? :slight_smile: Are you working with an extremely limited amount of memory?

A very limited amount of memory in the modern sense - 120kbytes flash, 20kbytes ram on a stm32f103
I apparently am on the hairy edge of my stack (commenting out the task create/start and its associated variables lets me draw the bar and the label that I want)

Check your stack size. It should be at least 4-6 kilobytes for LittlevGL.

20 kilobytes of RAM will work, but you will need to be conservative about how many objects you show on the screen at a time.

It’s likely that you already overflowed it, but you are lucky and you haven’t seen any weird behavior yet.

A good practice to have (if memory protection is not available) is to initialize the bottom portion of the stack to a known value and periodically check that it remains that way throughout development. That way you’ll know when stack overflow occurs.

You are totally right, I’m looking for the stack definition right now. What do you like to fill the guard band with? I sometimes use pluses or deadbeefs