I want to know why the system is down

The system will freeze for a long time.
[lv_task_handler ();] function does not respond, what happens if [sys_time] overflows?

LOG [ used: 16400 ( 13 %), frag: 1 %, biggest free: 114656 ]

The overflow should affect only lv_tick_elaps but it’s handled. See:

What does “long time” exactly mean? Overflow occurs in 49 days.

I suggest using LV_LOG_LEVEL_INFO to see where the issue occurs or it would be even better to use a debugger.

If the symptom appears, I will check it using the debugger and post it.

After a certain period of time, the same symptoms appear repeatedly.
used: 16400 (13%), frag: 1%, biggest free: 114656
The above log shows that the system is not down, and there is no memory increase or decrease.
However, lv_task_handler (); The function takes a long time to execute. So I mistakenly thought it was down because the touch did not work.
Is there a reason for the above results?

What happens if you don’t register an input device and let it run for the same period of time? Does it still slow down eventually? If so, it’s probably your input driver.

Let’s test it.
But do you have any problems with the touch driver?
Can I not read the touch information (I2C communication) from the input callback function?

Testing has nothing to do with the input device.

There is a box in the background box that you do not need to control later,
I created one object like [static lv_obj_t * box], and repeatedly used it. Could this be a problem?

box = lv_obj_create (Checking_Area [0], NULL); lv_obj_set_size (box, 139, 165);
box = lv_obj_create (Checking_Area [0], NULL); lv_obj_set_size (box, 139, 165);
box = lv_obj_create (Checking_Area [0], NULL); lv_obj_set_size (box, 139, 165);
box = lv_obj_create (Checking_Area [0], NULL); lv_obj_set_size (box, 139, 165);

In this way, we continued to use the coordinates differently.

Did you see the exact same behavior when the input device was not registered?

Yes Even if you did not register the input device, the same phenomenon occurred.
I changed the above box to box [n] and declared each, and the phenomenon of slowing disappears. I do not think you should use it like that.

@jaeil It shouldn’t matter. If that change makes it work it indicates you have another issue with your platform that does not pertain to LittlevGL which you’ll need to debug. Maybe you have a stack overflow issue?

Platform: mbed
Used MCU: RZA1H 10M SRAM
The stack is enough, and when the stack goes over, the system is configured to stop and leave a log.
The display is in frame buffer mode, and the input device is set as touch screen point input. Changing the above method will not slow you down, but I’ll watch it more.

I will test the same source on the simulator.

1 Like

Good idea! That way we’ll get a better handle on whether it really is a LittlevGL issue or not.

Something seemed to be a mistake.
As you mentioned, I removed the input device and it works. There is nothing wrong with simulation. But what problems with input devices can slow down?

But what problems with input devices can slow down?

Something must be wrong with your input driver. If you show the code I can take a look, but it’s probably something you’re going to have to debug yourself.

The creation code is shown below.

/**

  • @brief Return if there is touch detected or not.
  • @param DeviceAddr: Device address on communication Bus.
  • @retval Touch detected state.
    /
    unsigned char stmpe811::TS_DetectTouch(void)
    {
    unsigned char state;
    unsigned char ret = 0;
    state = ((rd8(STMPE811_REG_TSC_CTRL) & (unsigned char)STMPE811_TS_CTRL_STATUS) == (unsigned char)0x80);
    if(state > 0){
    if(rd8(STMPE811_REG_FIFO_SIZE) > 0){
    ret = 1;
    }
    }else{
    /
    Reset FIFO /
    wr8(STMPE811_REG_FIFO_STA, 0x01);
    /
    Enable the FIFO again */
    wr8(STMPE811_REG_FIFO_STA, 0x00);
    }
    return ret;
    }

/**

  • @brief Get the touch screen X and Y positions values
  • @param DeviceAddr: Device address on communication Bus.
  • @param X: Pointer to X position value
  • @param Y: Pointer to Y position value
  • @retval None.
    */
    void stmpe811::TS_GetXY(unsigned short *X, unsigned short Y)
    {
    char dataXYZ[4];
    unsigned int uldataXYZ;
    rdn(STMPE811_REG_TSC_DATA_NON_INC, dataXYZ, sizeof(dataXYZ)) ;
    /
    Calculate positions values */
    uldataXYZ = (dataXYZ[0] << 24)|(dataXYZ[1] << 16)|(dataXYZ[2] << 8)|(dataXYZ[3] << 0);
    *X = (uldataXYZ >> 20) & 0x00000FFF;
    Y = (uldataXYZ >> 8) & 0x00000FFF;
    /
    Reset FIFO /
    wr8(STMPE811_REG_FIFO_STA, 0x01);
    /
    Enable the FIFO again */
    wr8(STMPE811_REG_FIFO_STA, 0x00);
    }

bool my_input_read(lv_indev_drv_t * drv, lv_indev_data_t*data)
{
if( touch.TS_DetectTouch() ){
touch.TS_GetXY(&x, &y);
data->point.x = x;
data->point.y = y;
data->state = LV_INDEV_STATE_PR;
}else{
data->state = LV_INDEV_STATE_REL;
}
return false;
}

// 터치 패널 등록
lv_indev_drv_t indev_drv;
lv_indev_drv_init(&indev_drv);
indev_drv.type = LV_INDEV_TYPE_POINTER;
indev_drv.read_cb = my_input_read;
lv_indev_t * my_indev = lv_indev_drv_register(&indev_drv);

When the touch is released you need to set the last pressed X and Y coordinates.

Replace the my_input_read function with this:

bool my_input_read(lv_indev_drv_t * drv, lv_indev_data_t*data)
{
static int32_t last_x, last_y;
if( touch.TS_DetectTouch() ){
touch.TS_GetXY(&last_x, &last_y);
data->state = LV_INDEV_STATE_PR;
}else{
data->state = LV_INDEV_STATE_REL;
}
data->point.x = last_x;
data->point.y = last_y;
return false;
}

Then try testing it again.

Yes.
Does x and y need to be entered even when the touch is turned off?

Read my post before that one.