The switch state changes and the callback function does not execute

[caoliuchao]

Hello! I am a college student from China. I am really glad to find litteVGL, which is a very good GUI. However, I met some problems when I studied litteVGL. Maybe my English is not very good. I'm sorry, but may I ask you a question? Is in the website about the switch routines, I register a callback function, if just click on the switch button, the callback function can perform, but when I slide, if release the location of the touch coordinates are beyond the scope of switch button, the state of the button can change, but the callback function does not perform, this is very terrible in some security program. Don't know why? Here is my program code. Maybe the program code format in China is different from that in Europe and America. If it is inconvenient for you to read, I am sorry again.

/ my program / lv_obj_t *sw1;

/*Create styles for the switch*/
lv_style_t bg_style;
lv_style_t indic_style;
lv_style_t knob_on_style;
lv_style_t knob_off_style;

lv_style_copy(&bg_style, &lv_style_pretty);
bg_style.body.radius = LV_RADIUS_CIRCLE;

lv_style_copy(&indic_style, &lv_style_pretty_color);
indic_style.body.radius = LV_RADIUS_CIRCLE;
indic_style.body.main_color = LV_COLOR_HEX(0x9fc8ef);
indic_style.body.grad_color = LV_COLOR_HEX(0x9fc8ef);
indic_style.body.padding.hor = 0;
indic_style.body.padding.ver = 0;

lv_style_copy(&knob_off_style, &lv_style_pretty);
knob_off_style.body.radius = LV_RADIUS_CIRCLE;
knob_off_style.body.shadow.width = 4;
knob_off_style.body.shadow.type = LV_SHADOW_BOTTOM;

lv_style_copy(&knob_on_style, &lv_style_pretty_color);
knob_on_style.body.radius = LV_RADIUS_CIRCLE;
knob_on_style.body.shadow.width = 4;
knob_on_style.body.shadow.type = LV_SHADOW_BOTTOM;

/*Create a switch and apply the styles*/
sw1= lv_sw_create(lv_scr_act(), NULL);
lv_sw_set_style(sw1, LV_SW_STYLE_BG, &bg_style);
lv_sw_set_style(sw1, LV_SW_STYLE_INDIC, &indic_style);
lv_sw_set_style(sw1, LV_SW_STYLE_KNOB_ON, &knob_on_style);
lv_sw_set_style(sw1, LV_SW_STYLE_KNOB_OFF, &knob_off_style);
lv_obj_align(sw1, NULL, LV_ALIGN_CENTER, 0, -50);

lv_sw_set_action(sw1,myfuntion);

/callback function/ lv_res_t myfuntion(struct _lv_obj_t * obj) { if (lv_sw_get_state(obj)) { LED2_ON; } else { LED2_OFF; }

return LV_RES_OK;

}

[embeddedt]

@caoliuchao Which branch of LittlevGL are you using? master (v5.2) or dev-5.3? I ask because @kisvegabor and I altered the switch code substantially to implement animations in dev-5.3.

[caoliuchao]

I'm currently using version 5.2

[embeddedt]

@caoliuchao Can you try with dev-5.3?

[caoliuchao]

In version 5.3，There's something wrong with an if statement in this function“lv_anim_path_bounce(const lv_anim_t * a)”，Because t is unsigned, its value is always greater than or equal to zero in this function If (t >=0 && t < 408) statement, t >=0 is always like true, so some compiler will give some warning, my keil MDK software will give some warning, but also increased the running time of the program, I hope you can improve

[caoliuchao]

I don't know whether littlevgl can be developed and maintained together with you. I want to promote this software in China. Currently, there are relatively few people using this GUI in China compared with ucGUI and STewin. I want to join your team, follow you learn GUI design and development, and because of the jet lag reason, Chinese Internet users to provide some of the problems that may not be able to respond in a timely manner, very hope and you together to learn and develop the GUI, I also can according to the Chinese programming habits, write some localized document, don't know whether to work together with you

[embeddedt]

@caoliuchao Possibly you should just ignore that warning for now. @kisvegabor should probably fix it since I am not familiar with the internals of the animation code yet.

Can you use the benchmark to discover how much of a performance loss there was?

[kisvegabor]

Hi @caoliuchao

I fixed the switch action calling and the animation warning in dev-5.3

I'm very glad to hear that you would like to join us! An active contributor from China would be great! :+1: We got some feedback about Chinese people sometimes have language obstacles, therefore, they ask something what is clearly documented (but understood well enough).

So if you are interested, a Chinese translation would be very welcome! A few weeks ago the source of the documentation became public: https://github.com/littlevgl/docs Here you can learn how to add a translation.

[caoliuchao]

Hello, sorry to bother you, can I make a suggestion, it is this littleVGL transplantation of related functions, can use a. C files and. H file, transplant all related external function, using the conditional compilation statement definition, put the two files folder in version 5.3, this is advantageous to the file management, especially some programming software adopted the practice of engineering management, put all the transplant interface related functions in a file, although the website to give examples of engineering work can be done very simple transplant, but for the sake of the main function of simplicity, Need to define the external function to declare himself, so the main function in the folder will be very large and complex, dare I suggest you look at the FATFS this open source file system model of file organization mode, the file system to transplant related job functions in a file, project file management, reduce the coupling from different parts of the project, I call the transplant function refers to the outer function to littlevgl normal work, For example lv_tutorial_porting. C file ex_disp_flush and ex_disp_map function, because want to use these external function littlevgl some variables, need to add corresponding to these external function in the file header file statement, increased the project different parts of the coupling, is not conducive to transplant, I will encounter these problems, when I was in transplantation littlevgl comparison. And the advantage is external transplant function name is the same, the users only need to pay attention to these functions of the internal realization method of the, if you don't mind, I'll write a template you assess, after you decide whether to join littleVGL, my idea is that could reduce the workload of the user.

[embeddedt]

@caoliuchao I'm having troubles understanding what you are suggesting here. Are you suggesting that we do one or more of the following:

• merge all LittlevGL source files into one source file named lvgl.c?
• merge all LittlevGL header files into the lvgl.h header file?
• split each function into it's own file?

It would probably be best if you showed an example of what you are trying to perform.

[caoliuchao]

Sorry, there may be some things you misunderstand, when I said the port of external interface function is the underlying function, need to be written according to the characteristics of the hardware function. For example lv_examples project directory lv_tutorial_porting. C file void ex_disp_flush (int32_t int32_t x1, y1, int32_t x2, int32_t y2, const lv_color_t color_p); Void ex_disp_map(int32_t x1, int32_t y1, int32_t x2, int32_t y2, const lv_color_t color_p)

Disp_fill, ex_disp_fill, void ex_disp_fill(int32_t x1, int32_t y1, int32_t x2, int32_t y2, lv_color_t color), etc. These functions are very closely related to external hardware and require functions that you write yourself. I'm talking about this kind of function. So these functions are written in a.c file, and the user just has to write these functions.

[embeddedt]

@caoliuchao So you are suggesting that ex_disp_fill and related display driver functions be moved to a separate source file?

[caoliuchao]

yes

[caoliuchao]

That's what I mean by that, putting all the functions that the user has to write in a.c file

[embeddedt]

@caoliuchao The present implementation already allows the user to place all their custom functions in a .c file. Possibly we could make a template with all input and display related functions, would that implement what you are looking for?

[caoliuchao]

Due to the cultural differences, it is also possible that my English is not good enough and my expression is not good enough. I hope you can forgive me.

[embeddedt]

@caoliuchao No problem, I completely understand!

[caoliuchao]

Yes, I think you understand what I mean. I mean all the functions that the user needs to provide, put them in a c file, put the c file in version 5.3, the user just needs to add something inside the function. In this way, users only need to pay attention to the c file, and do not need to refer to the official example, and you only need to provide the name of each function, which is useful for project management. It is also convenient for the migration of different platforms,

[caoliuchao]

This lets the user know what needs to be done. Instead of trying to figure out the official examples,From a platform migration perspective, this approach is very portable. By writing a simple migration manual, users can achieve what they want. Macroscopically defined methods to turn on or off certain functions.The following is a sample migration of the open source file system FATFS that I use, and I only need to focus on this file to migrate the file system. Instead of creating any C files by myself, and I don't need to refer to any official examples, I just need a simple document description.

/*-----------------------------------------------------------------------*/
/* Low level disk I/O module skeleton for FatFs     (C)ChaN, 2014        */
/*-----------------------------------------------------------------------*/
/* If a working storage control module is available, it should be        */
/* attached to the FatFs via a glue function rather than modifying it.   */
/* This is an example of glue functions to attach various exsisting      */
/* storage control modules to the FatFs module with a defined API.       */
/*-----------------------------------------------------------------------*/

#include "diskio.h"     /* FatFs lower layer API */
#include "sdio_sd.h"
#include "w25Qxx.h"

/* Definitions of physical drive number for each drive */
#define SD_Card    0    /* Example: Map SD_Card harddisk to physical drive 0 */
#define SPI_Flash  1    /* Example: Map SPI_Flash to physical drive 1 */
#define USB        2    /* Example: Map USB MSD to physical drive 2 */

/*-----------------------------------------------------------------------*/
/* Get Drive Status                                                      */
/*-----------------------------------------------------------------------*/

DSTATUS disk_status (BYTE pdrv)     /* Physical drive nmuber to identify the drive */
{
    DSTATUS res = RES_OK;

    switch (pdrv) 
    {
        case SD_Card :  
                        res = RES_OK;
                        break;
        case SPI_Flash :  
                        res = RES_OK;
                        break;
        case     USB :  
                        res = RES_OK;
                        break;
        default:  break;
    }

    return res;
}

/*-----------------------------------------------------------------------*/
/* Inidialize a Drive                                                    */
/*-----------------------------------------------------------------------*/

DRESULT disk_initialize (BYTE pdrv) /* Physical drive nmuber to identify the drive */
{
    DRESULT res = RES_ERROR;
    SD_Error result;
    W25QXX_RES w25qxx_res;

    switch (pdrv) 
    {
       case SD_Card : 
                      result = SD_Init();
                      if (result == SD_OK)
                      {
                          res = RES_OK;
                      } 
                      break;
       case SPI_Flash : 
                        w25qxx_res = HW_W25QXX_Init();
                        if (w25qxx_res == W25QXX_OK)
                        {
                            res = RES_OK;
                        }
                        break;           
       case  USB : 
                      break; 
             default: 
                      break;
    }
    return res;
}

/*-----------------------------------------------------------------------
*     name ： disk_read (BYTE pdrv,BYTE *buff,DWORD sector,UINT count)
* function ： Read sector function of SD card
*    input ：
*             pdrv       Physical drive nmuber to identify the drive 
*             buff       DSD_Card buffer to store read dSD_Card 
*             sector     Sector address in LBA 
*             count      Number of sectors to read 
*   output ：
*             DRESULT   
*-----------------------------------------------------------------------*/
DSTATUS disk_read (BYTE pdrv,BYTE *buff,DWORD sector,UINT count)
{
    DSTATUS  res = RES_ERROR;
    SD_Error result;
    W25QXX_RES w25qxx_res;

    switch (pdrv) 
    {
        case SD_Card :  
                        result = SD_ReadDisk((uint8_t *)buff, sector, count);
                        if (result == SD_OK)
                        {
                            res = RES_OK;
                        } 
                        break;
        case SPI_Flash :
                        w25qxx_res = DRI_W25QXX_ReadData((uint8_t *)buff,sector*w25qxx_info.W25QXX_SECTBYTE,
                                                                         count*w25qxx_info.W25QXX_SECTBYTE);
                        if (w25qxx_res == W25QXX_OK)
                        {
                            res = RES_OK;
                        }

                        break;

        case     USB :
                        break;        
             default :   
                        break;
    }

    return res;
}

/*-----------------------------------------------------------------------*
*     name ： disk_write (BYTE pdrv,const BYTE *buff,    DWORD sector,UINT count )
* function ： write sector function of SD card
*    input ：
*             pdrv       Physical drive nmuber to identify the drive
*             buff       DSD_Card to be written
*             sector     Sector address in LBA
*             count      Number of sectors to write
*   output ：
*             DRESULT   
*-----------------------------------------------------------------------*/
DRESULT disk_write (BYTE pdrv,const BYTE *buff, DWORD sector,UINT count )
{
    DRESULT res = RES_ERROR;
    SD_Error result;
    W25QXX_RES w25qxx_res;

    switch (pdrv)
    {
        case SD_Card :  result = SD_WriteDisk((uint8_t *)buff, sector, count);
                        if (result == SD_OK)
                        {
                            res = RES_OK;
                        } 
                        else
                        {
                            SD_Init();  //重新初始化SD卡
                            result = SD_WriteDisk((uint8_t *)buff, sector, count);
                            if (result == SD_OK)
                            {
                                res = RES_OK;
                            } 
                        }

                        break;
        case SPI_Flash: 
                        w25qxx_res = HW_W25QXX_EraseSector(sector);
                        if (w25qxx_res == W25QXX_OK)
                        {
                            w25qxx_res = DRI_W25QXX_WriteData((uint8_t *)buff,sector*w25qxx_info.W25QXX_SECTBYTE,
                                                                       count*w25qxx_info.W25QXX_SECTBYTE);
                            if (w25qxx_res == W25QXX_OK)
                            {
                                res = RES_OK;
                            }
                        }
                        else
                        {
                            res = RES_ERROR;                        
                        }
                        break;
        case    USB :
                        break;
        default:   
                        break;
    }
    return res;
}

/*-----------------------------------------------------------------------
*     name: disk_ioctl(BYTE pdrv,BYTE cmd,void *buff)
* function: Miscellaneous Functions      
*    input: 
*           pdrv Physical drive nmuber (0..) 
*           cmd  Control code 
*           buff Buffer to send/receive control dSD_Card 
*   output:
*           DRESULT
*-------------------------------------------------------------------------*/
DRESULT disk_ioctl(BYTE pdrv,BYTE cmd,void *buff)
{
    DRESULT res = RES_ERROR;

    switch (pdrv)
    {
        case SD_Card : 
            switch(cmd)
            {
                case CTRL_SYNC: res = RES_OK; //刷新磁盘
                                break;
                case GET_SECTOR_SIZE: 
                     *(DWORD*)buff = 512; //得到媒体大小
                     res = RES_OK;
                     break;
                case GET_BLOCK_SIZE:
                    *(DWORD*)buff = SDCardInfo.CardBlockSize;  //块大小
                    res = RES_OK;
                    break;
                case GET_SECTOR_COUNT:
                    *(DWORD*)buff = SDCardInfo.CardCapacity/512;
                    res = RES_OK;
                    break;
                default: break;
            }
            break;
        case SPI_Flash :
                    switch(cmd)
                    {
                        case CTRL_SYNC: res = RES_OK; //刷新磁盘
                                        break;
                        case GET_SECTOR_SIZE: 
                            *(DWORD*)buff = w25qxx_info.W25QXX_SECTBYTE;//得到媒体大小
                            res = RES_OK;
                            break;
                        case GET_BLOCK_SIZE:
                            *(DWORD*)buff = 1; //块大小
                            res = RES_OK;
                            break;
                        case GET_SECTOR_COUNT:
                            *(DWORD*)buff = w25qxx_info.W25QXX_BYTE/w25qxx_info.W25QXX_SECTBYTE;
                            res = RES_OK;
                            break;
                        default: break;
                    }
                    break;
        case USB :
                   break;

          default:  
                  break;
    }
    return res;
}

/*------------------------------------------------------------------
*
*-------------------------------------------------------------------*/
DWORD get_fattime(void)
{
    #if  USE_RTC == 1

    #else 

         return 0;

    #endif
}

/******************************文件结束*********************************/

[caoliuchao]

If you take my advice, I could write a localized transplant document, conducive to China's vast GUI fan, can easily transplant littleVGL to their own platform, it is hard to find a Chinese website transplantation littleVGL detailed instructions, I need to slowly find official transplant example, if you need all of the function, need to refer to the file has a lot of, some programs have nothing to do with transplantation. The first time I touched the GUI, I found it difficult to extract the port information I wanted. I hope you'll think about it,

[caoliuchao]

@embeddedt
lv_hal.c.txt

This is what I do, I wrote a simple lv_hal. C file, hope you can join v5.3 release, so users only need to pay attention to this file can complete the transplantation of littleVGL work, it's just me a simple version, later I will according to what I learned in order to perfect this file, for the users to do less as far as possible to complete littleVGL transplantation. If you don't agree, you can give up my idea.

[embeddedt]

@caoliuchao I like this approach. It's an interesting idea! My two thoughts are:

• It's a lot of code for one file. Maybe you could split it into lv_hal_encoder.c, lv_hal_touchpad.c, lv_hal_display.c, lv_hal_fs.c, and so on.
• All drivers should be functional stubs, meaning that LittlevGL should be able to run with them and simply output nothing.

We should definitely wait and see what @kisvegabor thinks before taking this too far, but I think it would add value to the project.

[caoliuchao]

Splitting into multiple files is also good, and I'd like to add a thread-safe solution that littleVGL itself is thread-safe by adding some necessary code internally. This is very important in projects with real-time operating systems, although officially you can build your own tasks, since RAM allocation is limited, you cannot build more tasks. We can turn on and off support for real-time operating systems by macro definition, just using the operating system-specific mutexes. LittleVGL works well with both real-time and non-real-time operating systems, although this is a lot of work. LittleVGL application scope should be increased to reduce the task of ensuring thread safety by users themselves. I feel that if littleVGL exists in an engineering, the probability of using embedded real-time operating system is relatively high. Since I started looking at littleVGL's source code, I've been particularly interested in adding thread-safe features.

[embeddedt]

@caoliuchao Thread-safety has been suggested before. Currently we do it by requiring the user to guard all their calls with a mutex themselves. The issue with implementing thread-safety internally is that we have to make sure it is implemented around every function.

[caoliuchao]

At present, I have two wishes, one is to integrate the ported code, and the other is to increase littleVGL multi-threaded security solutions. In fact, it should not be too difficult to implement thread safety, I feel no need to consider littleVGL every function, just use a mutex inside those functions that use global variables can be done, for those functions that only use local variables, there is no need to consider thread safety issues

[caoliuchao]

Although the user can achieve thread safety through mutexes, but this will increase the user's programming difficulties, you can refer to UCGUI this software, it is its own support for thread safety.

[kisvegabor]

@caoliuchao @embeddedt

Porting

I like @caoliuchao's idea. Having one or more file with these skeleton function will make the porting more intuitive. However, these file(s) should exist as templates, like lv_conf_templ.h and ask the user to copy these templates outside of lvgl. This way the library will remain untouched and can be easily updated later. It seems to me 3 files might be sufficient:

1. Display: flush, fill, map, mem fill, mem blend
2. Input devices: Touchpad or mouse, keypad, encoder, button
3. File system

We can add these files to a lv_porting folder with:

1. lv_port_disp_templ.c/h
2. lv_port_indev_templ.c/h
3. lv_port_fs_templ.c/h

Having English and Chinese comments in these files would help to understand the basics.

Thread safety

Protecting global resources, like the memory where the objects are allocated, can work. With this, the user can create, delete, set, get objects without any worries. But what if the user tries to set the text of a label in multiple tasks? Then the label becomes a global resource and the user needs to protect it with a mutex? So it becomes his own responsibility again. Anyways, having internal mutexes would simplify most of the cases.

[embeddedt]

@kisvegabor lv_task_handler would still only be called from one thread, right?

[caoliuchao]

@kisvegabor May I make a suggestion? It is you who will write these C files and H files. I will write the porting document. I will write a Chinese and English porting document.

[kisvegabor]

@embeddedt

lv_task_handler would still only be called from one thread, right?

How do you mean it? Is there any other place where it can be called?

@caoliuchao

@kisvegabor May I make a suggestion? It is you who will write these C files and H files. I will write the porting document. I will write a Chinese and English porting document.

If you like my suggestion about using 3 files I can add the files and we can add and improve the comments together.

[embeddedt]

@kisvegabor I mean that the user would still be responsible for ensuring that lv_task_handler is invoked on a single LittlevGL "worker thread".

[turoksama]

@caoliuchao Hi there, I don't think it is a problem to put all these lowlevel transplantation function in one file. I think it is up to the user to decide what to do themselves. For me, I put them together in one file. But someone may love to split into several files.

[turoksama]

@caoliuchao @embeddedt

Porting

I like @caoliuchao's idea. Having one or more file with these skeleton function will make the porting more intuitive. However, these file(s) should exist as templates, like lv_conf_templ.h and ask the user to copy these templates outside of lvgl. This way the library will remain untouched and can be easily updated later. It seems to me 3 files might be sufficient:

1. Display: flush, fill, map, mem fill, mem blend
2. Input devices: Touchpad or mouse, keypad, encoder, button
3. File system

We can add these files to a lv_porting folder with:

1. lv_port_disp_templ.c/h
2. lv_port_indev_templ.c/h
3. lv_port_fs_templ.c/h

Having English and Chinese comments in these files would help to understand the basics.

Thread safety

Protecting global resources, like the memory where the objects are allocated, can work. With this, the user can create, delete, set, get objects without any worries. But what if the user tries to set the text of a label in multiple tasks? Then the label becomes a global resource and the user needs to protect it with a mutex? So it becomes his own responsibility again. Anyways, having internal mutexes would simplify most of the cases.

@kisvegabor Hi, I vote for the idea you mentioned above. For now, it is lv_port_fs_templ.c/h need to be implemented. I think we should be careful with the file system, because users may already have one outside the library.

[embeddedt]

@turoksama

I don't think it is a problem to put all these lowlevel transplantation function in one file. I think it is up to the user to decide what to do themselves. For me, I put them together in one file. But someone may love to split into several files.

Personally, I think having it divided into small files by default makes it easier for someone to read and manage rather than having to scroll through a large file. The user can always combine them later if they want.

[turoksama]

@embeddedt I agree.

[kisvegabor]

@embeddedt @caoliuchao I've added the display and indev porting skeleton files: https://github.com/littlevgl/lvgl/commit/9c7c200048c1cbe22443d8649f77e381004df0d8

Please, let me know what do you think!

[caoliuchao]

@kisvegabor I just think it's great, and it's important to focus on file system portability, because you can use an external file system, sometimes more than one hard drive. And I look at the source code, it seems that only one hard drive can be accessed. I hope you can improve.

void lv_indev_set_button_points(lv_indev_t * indev, const lv_point_t* points)
{
-   if(indev->driver.type == LV_INDEV_TYPE_BUTTON) indev->btn_points = points;
}

void lv_indev_set_button_points(lv_indev_t * indev, const lv_point_t* points)
{
+   if(indev->driver.type == LV_INDEV_TYPE_BUTTON) indev->btn_points = (lv_point_t*)points;
}

[caoliuchao]

If a pointer points to a constant, then the pointer does not seem to be able to pay a normal pointer.

My keil MDK software reported an error for this problem.

[caoliuchao]

Some necessary header files do not exist in the C files you gave. I'd like you to add the necessary header files.

[turoksama]

@kisvegabor I just think it's great, and it's important to focus on file system portability, because you can use an external file system, sometimes more than one hard drive. And I look at the source code, it seems that only one hard drive can be accessed. I hope you can improve.

void lv_indev_set_button_points(lv_indev_t indev, const lv_point_t points) {

• if(indev->driver.type == LV_INDEV_TYPE_BUTTON) indev->btn_points = points; }

void lv_indev_set_button_points(lv_indev_t indev, const lv_point_t points) {

• if(indev->driver.type == LV_INDEV_TYPE_BUTTON) indev->btn_points = (lv_point_t*)points; }

Hi, I think this is an input device driver rather than file system. So, what's your point exactlly?

[caoliuchao]

@turoksama 编译不通过，有错误，

[turoksama]

Hi, Please try GCC, for example: eclipse.

[caoliuchao]

@turoksama 并不是所有的嵌入式都是GCC开发，我没有试GCC，我是用的keil MDK开发的STM32F4项目

我用linux的GCC编译器也是不通过，这本来就是一个语法错误，我感觉在那种编译器都会报错吧 main.c:5:7: warning: assignment discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers] q = p;

[embeddedt]

@caoliuchao Are you saying that your compiler is complaining about discarding const without an explicit cast? If so I think I have seen this behavior in other source files as well.

[caoliuchao]

@embeddedt Yes, I compile in GCC on Linux as if an error was reported, and it's just a warning in visual studio

lv_core / lv_indev.c lv_core/lv_indev.h

[turoksama]

Hi, discarding const will not break your system actually. I am using ecilpse with GCC complier, it's better in faster compiling but worse in debuging.

[embeddedt]

@turoksama This issue is with correctness rather than functionality. We should probably add/remove const in one of those places.

[turoksama]

@embeddedt He reported main.c:5:7: warning: assignment discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers] q = p; I assumed that he discarded the qualifier "const" in his code.

[embeddedt]

@turoksama Oh, I didn't read the file name. Good point.

[kisvegabor]

With the latest version, I don't have any warnings. Please test with the latest version.

[kisvegabor]

I've added the files as discussed above to lv_porting so I close this issue. If you have remarks on it please comment here and reopen the issue.