Hello,
State of install:
- I downloaded the latest rev from git.
- I built the project , got 100% compile no error.
- I ran the demo app titled TFT Simulator with the 3 tabs on it
Based on that I assume my installation is OK.
Next I took a look at:
lv_examples/lv_tutorial/1_hello_world
Seemed like a good place to start looking at some code.
My question:
- After compilation all the compiled .o files are in the top folder
- A main.c file serves as entry point to run LVGL example called demo.
The Makefile associated with the project does compile every example in .o files but only creates one executable for the example named demo.
The example named demo seem to be the largest of all, so probably not a good place to start with LVGL for me. How do I alter the files to compile one of the simpler example (like lv_examples/lv_tutorial/1_hello_world) to an executable binary?
Thank you
Add this to the include header list:
#include "lv_examples/lv_tutorial/1_hello_world/lv_tutorial_hello_world.h"
And then replace the call to demo_create() with lv_tutorial_hello_world().
Thanks, I understand how the samples and tutorials have been organized now.
I would like to cross compile to run on two boards I have a BB White and a BB Black.
How can alter the project to switch between cross compilation for the boards and local compile?
Thank you
Unless the BeagleBone boards are running a full Linux distribution with SDL, I would suggest that you use this project for those boards.
If you do want to use the PC simulator, are you compiling it using Eclipse or using the Makefile?
Yes beaglbone boards run Ubuntu Linux.
They are based on ARM.
SDL-2.0 library works fine on those.
My goal is to try LittevGL as a potential GUI solution that does not require loading a Desktop manager to drive small displays.
My question is related to compile tool chain:
How to cross compile LittlevGL app for an ARM so I can scp the resulting executable file over to the board file system and run it there?
I suggest you use the project designed to work directly with the Linux framebuffer. You just need to change this line to point at the compiler you want.
Hello,
My arm-linux-gnueabi-gcc cross-compiler is working, creating a simple hello-world.c that is not based on littlevgl compiles fine and runs fine once I scp the binary onto the board.
I changed the CC line in the Makefile to use the cross compiler (I removed the ? before the = to overwrite the value) as below:
CC = arm-linux-gnueabi-gcc
However the example binary that is compiled (after doing a clean) and is placed inside bin/ folder is still not a binary for ARM? i.e. I can run it on the laptop but board complains it is not an ARM binary?
The fact that it runs on the laptop confirms that, so why could the build be ignoring CC = arm-linux-gnueabi-gcc and using regular gcc instead?
Thank you
Can you check the link command that the build outputs (it should be the very last line) and confirm that arm-linux-gnueabi-gcc does not get used?
You could also try CC := arm-linux-gnueabi-gcc (colon added).
Hello!
Not sure how to do what you asked.
I made an attempt at building directly onto the board and it build the main binary but when I try to run the binary instead of the GUI showing I get the following output in the console:
/tmp/tmp.wo67zSRbOR/cmake-build-arm-debug-remote/../bin/main
used: 2648 ( 3 %), frag: 1 %, biggest free: 128388
used: 2648 ( 3 %), frag: 1 %, biggest free: 128388
used: 2648 ( 3 %), frag: 1 %, biggest free: 128388
used: 2648 ( 3 %), frag: 1 %, biggest free: 128388
used: 2648 ( 3 %), frag: 1 %, biggest free: 128388
used: 2648 ( 3 %), frag: 1 %, biggest free: 128388
used: 2648 ( 3 %), frag: 1 %, biggest free: 128388
What could be the issue here?
Is it possible that it is compiling the PC Simulator as part of the binary?
The ARM board I am targeting purposely does not run a Window Manager.
I want the GUI to display through /dev/fb0 framebuffer
If the answer is yes to the above question:
How to compile and run the examples without PC Simulator wrapper?
Thank you
It turns out I had removed the code to use framebuffer.
After switching HAL code for framebuffer code I get the following instead when executing the binary (compiled on the board):
The framebuffer device was opened successfully.
320x240, 16bpp
The framebuffer device was mapped to memory successfully.
Warn: lv_obj_create: not display created to so far. No place to assign the new screen (/tmp/tmp.wo67zSRbOR/lvgl/src/lv_core/lv_obj.c #144)
Error: lv_cont_create (/tmp/tmp.wo67zSRbOR/lvgl/src/lv_objx/lv_cont.c #73)
Error: Out of memory (0x00000000) (/tmp/tmp.wo67zSRbOR/lvgl/src/lv_core/lv_debug.c #167)
Hello,
Getting closer as GUI is displaying on ARM target device, but a couple of issues persist:
-
Device pointer is not working: touching the screen has no effect.
How to configure littlevgl app to receive pointer device inputs?
-
The blinking character position marker from the shell overwrites littlevgl in the framebuffer and therefore it keeps blinking in the middle of LittlevGL GUI?
How to prevent that from happening? (I found some solutions on the web for that and one that works is to $echo -e ‘\033[?16;0;224c’ before starting the LittlevGL app, but I am sure something more elegant than that exist)
You need to add the evdev driver (example code here). It can be configured in lv_drv_conf.h; you should point it to whatever eventX device your touchscreen is.
I’m not aware of any better solutions for hiding the framebuffer cursor.
A big thank you for the tips and pointers, very much appreciated 
Everything is working as expected now on the ARM target.
I still have to compile directly on the target device via ssh as the cross-compiler tool-chain on the host complains about SDL2 library even though I have SDL2 installed on the host and on the target, something about an SDL2-Config.cmake or something like that.
If I can resolve that cross-compiler too-chain issue I will be able to cross compile from the host computer which would be much nicer and much faster.
Regarding the blinking cursor overriding Linux framebuffer, that was an interesting journey:
- there are many ways to stop the cursor from blinking interactively from the target device itself, however who want to physically plug a keyboard to an embedded device after each restart just to remove the blinking cursor from the middle of the GUI, no one So a few of those solutions are OK for dev time but not practical when in use.
- there are less ways to do it in a way that is resilient to reboot, and those solutions also change greatly from one distro to another apparently, so no bueno either
- Finally, the almost hidden way that can be resilient to reboots, is easy to implement, and easy to remotely control:
Remotely stop blinking cursor on TTY Console login screen running on remote device (via ssh):
sudo -i
/usr/bin/tput civis > /dev/tty1
That stops the cusrsor from blinking, and therfore it also stops it from overiding the framebuffer once the application is started on the remote device via ssh.
If for some mysterious reason you want to later, turn the cursor blinking back on, then use:
sudo -i
/usr/bin/tput cnorm > /dev/tty1
cnorm: for cursor normal
civis: for cursor invisible
I hope that will save someone else time.
As far as I know, some of these methods simply write to a file in /sys. You could open the same file in your C code, write the value to it, and close the file. It should behave the same way and might be more contained.
The echo method might also work if you used printf to print the value beforehand (or used write to send it directly to stdout).
