Embedded/lvgl
1
0
Fork 0
mirror of https://github.com/lvgl/lvgl.git synced 2025-01-14 06:42:58 +08:00
Code Issues Projects Releases Wiki Activity

docs minor fixes

Browse Source
This commit is contained in:
Gabor Kiss-Vamosi 2021-05-20 22:25:47 +02:00
parent 6f42088dec
commit 46253b1286
9 changed files with 94 additions and 143 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
docs/build.py
View File

@ -28,7 +28,7 @@ urlpath = re.sub('release/', '', br)
# Be sure the github links point to the right branch
f = open("header.rst", "w")
f.write(".. |github_link_base| replace:: https://github.com/lvgl/docs/blob/" + br)
f.write(".. |github_link_base| replace:: https://github.com/lvgl/lvgl/blob/docs/" + br)
f.close()
base_html = "html_baseurl = 'https://docs.lvgl.io/" + urlpath + "/en/html/'"

64
docs/intro/index.md
View File

@ -14,7 +14,7 @@ LVGL (Light and Versatile Graphics Library) is a free and open-source graphics l
- Various input devices such as touchpad, mouse, keyboard, encoder etc.
- Multi-language support with UTF-8 encoding
- Multi-display support, i.e. use more TFT, monochrome displays simultaneously
- Fully customizable graphic elements
- Fully customizable graphic elements withh CSS-like styles
- Hardware independent to use with any microcontroller or display
- Scalable to operate with little memory (64 kB Flash, 16 kB RAM)
- OS, External memory and GPU supported but not required
@ -23,7 +23,7 @@ LVGL (Light and Versatile Graphics Library) is a free and open-source graphics l
- Simulator to start embedded GUI design on a PC without embedded hardware
- Binding to MicroPython
- Tutorials, examples, themes for rapid GUI design
- Documentation is available as online and offline
- Documentation is available online and PDF
- Free and open-source under MIT license
## Requirements
@ -36,7 +36,7 @@ Basically, every modern controller  (which is able to drive a display) is suita
<ul>
<li> Static RAM usage: ~2 kB depending on the used features and objects types</li>
<li> Stack: &gt; 2kB (&gt; 8 kB is recommended)</li>
<li> Dynamic data (heap): &gt; 2 KB (&gt; 16 kB is recommended if using several objects).
<li> Dynamic data (heap): &gt; 4 KB (&gt; 32 kB is recommended if using several objects).
    Set by <em>LV_MEM_SIZE</em> in <em>lv_conf.h</em>. </li>
<li> Display buffer:  &gt; <em>"Horizontal resolution"</em> pixels (&gt; 10 &times; <em>"Horizontal resolution"</em> is recommended) </li>
<li> One frame buffer in the MCU or in external display controller</li>
@ -46,7 +46,7 @@ Basically, every modern controller  (which is able to drive a display) is suita
<li> Basic C (or C++) knowledge:
<a href="https://www.tutorialspoint.com/cprogramming/c_pointers.htm">pointers</a>,
<a href="https://www.tutorialspoint.com/cprogramming/c_structures.htm">structs</a>,
<a href="https://www.geeksforgeeks.org/callbacks-in-c/">callbacks</a></li>
<a href="https://www.geeksforgeeks.org/callbacks-in-c/">callbacks</a>.</li>
</ul>
<em>Note that the memory usage might vary depending on the architecture, compiler and build options.</em>
@ -64,11 +64,10 @@ You can choose from [many ways of contributions](/CONTRIBUTING) such as simply w
## Repository layout
All repositories of the LVGL project are hosted n GitHub: https://github.com/lvgl
You fill these repositories there:
- [lvgl](https://github.com/lvgl/lvgl) The library itself
- [lv_examples](https://github.com/lvgl/lv_examples) Examples and demos
You find these repositories there:
- [lvgl](https://github.com/lvgl/lvgl) The library itself with many [examples](https://github.com/lvgl/lvgl/blob/master/examples/).
- [lv_demos](https://github.com/lvgl/lv_demos) Demos created with LVGL.
- [lv_drivers](https://github.com/lvgl/lv_drivers) Display and input device drivers
- [docs](https://github.com/lvgl/docs) Source of the documentation's site (https://docs.lvgl.io)
- [blog](https://github.com/lvgl/blog) Source of the blog's site (https://blog.lvgl.io)
- [sim](https://github.com/lvgl/sim) Source of the online simulator's site (https://sim.lvgl.io)
- [lv_sim_...](https://github.com/lvgl?q=lv_sim&type=&language=) Simulator projects for various IDEs and platforms
@ -76,8 +75,6 @@ You fill these repositories there:
- [lv_binding_..](https://github.com/lvgl?q=lv_binding&type=&language=l) Bindings to other languages
- [lv_...](https://github.com/lvgl?q=lv_&type=&language=) Ports to other platforms
The [lvgl](https://github.com/lvgl/lvgl),  [lv_examples](https://github.com/lvgl/lv_examples) and [lv_drivers](https://github.com/lvgl/lv_drivers) are the core repositories which gets the most attentions regarding maintenance.
## Release policy
The core repositories follow the rules of [Semantic versioning](https://semver.org/):
@ -85,42 +82,35 @@ The core repositories follow the rules of [Semantic versioning](https://semver.o
- Minor version for new but backward-compatible functionalities. E.g. v6.1.0, v6.2.0
- Patch version for backward-compatible bug fixes. E.g. v6.1.1, v6.1.2
Tags like `vX.Y.Z` are created for every release.
### Release cycle
- Bugfixes: Released on demand even weekly
- Minor releases: In every 3-4 month
- Major releases: Approximatelly yearly
### Branches
The core repositories have at least the following branches:
- `master` latest version, patches are merged directly here.
- `dev` merge new features here until they are merged into `master`.
- `release/vX` stable versions of the major releases
- `release/vX.Y` stable versions of the minor releases
- `fix/some-description` temporal branches for bug fixes
- `feat/some-description` temporal branches for features
### Release cycle
LVGL has 2 weeks release cycle. On every first and third Tuesday of a month:
1. A major, minor or bug fix release is created (based on the new features) from the `master` branch
2. `master` is merged into `release/vX`
3. Immediately after the release `dev` is merged into `master`
4. In the upcoming 2 weeks the new features in `master` can be tested
5. Bug fixes are merged directly into `master`
6. After 2 weeks start again from the first point
### Tags
Tags like `vX.Y.Z` are created for every release.
### Changelog
The changes are recorded in [CHANGELOG.md](https://github.com/lvgl/lvgl/blob/master/CHANGELOG.md).
### Side projects
The [docs](https://github.com/lvgl/docs) is rebuilt on every release. By default, the `latest` documentation is displayed which is for the current `master` branch of lvgl.
The documentation of earlier versions is available from the menu on the left.
The simulator, porting, and other projects are updated with best effort. Pull requests are welcome if you updated one of them.
The changes are recorded in [CHANGELOG.md](/CHANGELOG).
### Version support
In the core repositories each major version has a branch (e.g. `release/v6`). All the minor and patch releases of that major version are merged there.
Before v8 every minor release of major releases are supproted for 1 year.
From v8 every minor release is supported for 1 year.
It makes possible to add fixed older versions without bothering the newer ones.
All major versions are officially supported for 1 year.
| Version | Release date | Support end | Active |
|---------|--------------|-------------|--------|
| v5.3 | Feb 1, 2019 |Feb 1, 2020 | No |
| v6.1 | Nov 26, 2019 |Nov 26, 2020 | No |
| v7.11 | Mar 16, 2021 |Mar 16, 2022 | Yes |
| v8.0 | In progress | | |
## FAQ
@ -155,7 +145,7 @@ Some examples of the supported display types:
See the [Porting](/porting/display) section to learn more.
### Nothing happens, my display driver is not called. What have I missed?
Be sure you are calling `lv_tick_inc(x)` in an interrupt and `lv_task_handler()` in your main `while(1)`.
Be sure you are calling `lv_tick_inc(x)` in an interrupt and `lv_timer_handler()` in your main `while(1)`.
Learn more in the [Tick](/porting/tick) and [Task handler](/porting/task-handler) section.

47
docs/porting/display.md
View File

@ -4,7 +4,7 @@
```
# Display interface
To set up a display an `lv_disp_draw_buf_t` and an `lv_disp_drv_t` variables have to be initialized.
To register a display for LVGL an `lv_disp_draw_buf_t` and an `lv_disp_drv_t` variables have to be initialized.
- `lv_disp_draw_buf_t` contains internal graphic buffer(s), called draw buffer(s).
- `lv_disp_drv_t` contains callback functions to interact with the display and manipulate drawing related things.
@ -22,23 +22,23 @@ static lv_disp_draw_buf_t disp_buf;
static lv_color_t buf_1[MY_DISP_HOR_RES * 10];
static lv_color_t buf_2[MY_DISP_HOR_RES * 10];
/*Initialize `disp_buf` with the buffer(s) */
/*Initialize `disp_buf` with the buffer(s). With only one buffer use NULL instead buf_2 */
lv_disp_draw_buf_init(&disp_buf, buf_1, buf_2, MY_DISP_HOR_RES*10);
```
Note that `lv_disp_draw_buf_t` needs to be static, global or dynamically allocated and not a local variable destroyed if goes out of the scope.
As you can see the draw buffer can be smaller than the screen. In this case, the larger areas will be redrawn in smaller parts that fit into the draw buffer(s).
If only a small area changes (e.g. a button is pressed) then only that area will be refreshed.
A larger buffer results in better performance but above 1/10 screen sized buffer(s) there is no significant performance improvement.
Therefore it's recommended to choose the size of the draw buffer(s) to at least 1/10 screen sized.
If only **one buffer** is used LVGL draws the content of the screen into that draw buffer and sends it to the display.
If only **one buffer** is used LVGL draws the content of the screen into that draw buffer and sends it to the display.
This way LVGL needs to wait until the content of the buffer is sent to the display before drawing something new in it.
If **two buffers** are used LVGL can draw into one buffer while the content of the other buffer is sent to display in the background.
DMA or other hardware should be used to transfer the data to the display to let the CPU draw meanwhile.
DMA or other hardware should be used to transfer the data to the display to let the MCU draw meanwhile.
This way, the rendering and refreshing of the display become parallel.
In the display driver (`lv_disp_drv_t`) the `full_refresh` bit can be enabled to force LVGL always redraw the whole screen. It works in both *one buffer* and *two buffers* modes.
@ -47,43 +47,43 @@ If `full_refresh` is enabled and 2 screen sized draw buffers are provided, LVGL
It means in `flush_cb` only the address of the frame buffer needs to be changed to provided pointer (`color_p` parameter).
This configuration should be used if the MCU has LCD controller periphery and not with an external display controller (e.g. ILI9341 or SSD1963).
You can measure the performance of different draw buffer configurations using the [benchmark example](https://github.com/lvgl/lv_examples/tree/master/src/lv_demo_benchmark).
You can measure the performance of different draw buffer configurations using the [benchmark example](https://github.com/lvgl/lv_demos/tree/master/src/lv_demo_benchmark).
## Display driver
Once the buffer initialization is ready a `lv_disp_drv_t` display drivers need to be
1. initialized with `lv_disp_drv_init(&disp_drv)`
2. its fields needs to be set and
2. its fields needs to be set
3. registered in LVGL with `lv_disp_drv_register(&disp_drv)`
Note that `lv_disp_drv_t` needs to be static, global or dynamically allocated and not a local variable destroyed if goes out of the scope.
Note that `lv_disp_drv_t` also needs to be static, global or dynamically allocated and not a local variable destroyed if goes out of the scope.
### Mandatory fields
In the most simple case only the following fields of `lv_disp_drv_t` needs to be set:
- `draw_buf` pointer to an initialized `lv_disp_draw_buf_t` variable.
- `hor_res` horizontal resolution of the display in pixels.
- `ver_res` vertical resolution of the display in pixels.
- `flush_cb` a callback function to copy a buffer's content to a specific area of the display.
`lv_disp_flush_ready(&disp_drv)` needs to be called when flushing is ready.
LVGL might render the screen in multiple chunks and therefore call `flush_cb` multiple times. To see which is the last chunk of rendering use `lv_disp_flush_is_last(&disp_drv)`.
- `hor_res` horizontal resolution of the display in pixels.
- `ver_res` vertical resolution of the display in pixels.
### Optional fields
There are some optional data fields:
- `color_chroma_key` A color which will be drawn as transparent on chrome keyed images. Set to `LV_COLOR_CHROMA_KEY` by default from `lv_conf.h`.
- `user_data` A custom `void `user data for the driver..
- `anti_aliasing` use anti-aliasing (edge smoothing). Enabled by default if `LV_COLOR_DEPTH` is set to at least 16 in `lv_conf.h`.
- `rotated` and `sw_rotate` See the [rotation](#rotation) section below.
- `rotated` and `sw_rotate` See the [Rotation](#rotation) section below.
- `screen_transp` if `1` the screen itself can have transparency as well. `LV_COLOR_SCREEN_TRANSP` needs to enabled in `lv_conf.h` and requires `LV_COLOR_DEPTH 32`.
- `user_data` A custom `void `user data for the driver..
Some other optional callbacks to make easier and more optimal to work with monochrome, grayscale or other non-standard RGB displays:
- `rounder_cb` Round the coordinates of areas to redraw. E.g. a 2x2 px can be converted to 2x8.
It can be used if the display controller can refresh only areas with specific height or width (usually 8 px height with monochrome displays).
- `set_px_cb` a custom function to write the draw buffer. It can be used to store the pixels more compactly i nthe draw buffer if the display has a special color format. (e.g. 1-bit monochrome, 2-bit grayscale etc.)
This way the buffers used in `lv_disp_draw_buf_t` can be smaller to hold only the required number of bits for the given area size. Rendering with `set_px_cb` is slower than normal rendering.
- `monitor_cb` A callback function that tells how many pixels were refreshed in how much time.
- `set_px_cb` a custom function to write the draw buffer. It can be used to store the pixels more compactly in the draw buffer if the display has a special color format. (e.g. 1-bit monochrome, 2-bit grayscale etc.)
This way the buffers used in `lv_disp_draw_buf_t` can be smaller to hold only the required number of bits for the given area size. Note that, rendering with `set_px_cb` is slower than normal rendering.
- `monitor_cb` A callback function that tells how many pixels were refreshed in how much time. Called when the last chunk is rendered and sent to the display.
- `clean_dcache_cb` A callback for cleaning any caches related to the display.
To use a GPU the following callbacks can be used:
LVGL has built-in support to several GPUs (see `lv_conf.h`) but if something else is required these functions can be used to make LVGL use a GPU:
- `gpu_fill_cb` fill an area in the memory with a color.
- `gpu_wait_cb` if any GPU function return, while the GPU is still working, LVGL will use this function when required the be sure GPU rendering is ready.
@ -105,7 +105,8 @@ Here are some simple examples of the callbacks:
```c
void my_flush_cb(lv_disp_drv_t * disp_drv, const lv_area_t * area, lv_color_t * color_p)
{
/*The most simple case (but also the slowest) to put all pixels to the screen one-by-one*/
/*The most simple case (but also the slowest) to put all pixels to the screen one-by-one
*`put_px` is just an example, it needs to implemented by you.*/
int32_t x, y;
for(y = area->y1; y <= area->y2; y++) {
for(x = area->x1; x <= area->x2; x++) {
@ -137,15 +138,15 @@ void my_gpu_fill_cb(lv_disp_drv_t * disp_drv, lv_color_t * dest_buf, const lv_ar
void my_rounder_cb(lv_disp_drv_t * disp_drv, lv_area_t * area)
{
/* Update the areas as needed.
* For example make the area to start only on 8th rows and have Nx8 pixel height:*/
* For example it makes the area to start only on 8th rows and have Nx8 pixel height.*/
area->y1 = area->y1 & 0x07;
area->y2 = (area->y2 & 0x07) + 8;
}
void my_set_px_cb(lv_disp_drv_t * disp_drv, uint8_t * buf, lv_coord_t buf_w, lv_coord_t x, lv_coord_t y, lv_color_t color, lv_opa_t opa)
{
/* Write to the buffer as required for the display.
* Write only 1-bit for monochrome displays mapped vertically:*/
/* Write to the buffer as required for the display.
* For example it writes only 1-bit for monochrome displays mapped vertically.*/
buf += buf_w * (y >> 3) + x;
if(lv_color_brightness(color) > 128) (*buf) |= (1 << (y % 8));
else (*buf) &= ~(1 << (y % 8));
@ -181,9 +182,9 @@ Support for software rotation is a new feature, so there may be some glitches/bu
## Further reading
See [lv_port_disp_template.c](https://github.com/lvgl/lvgl/blob/master/examples/porting/lv_port_disp_template.c) for a template for your own driver.
Check out the [Drawing](/overview/drawing) section to learn more about how rendering works in LVGL.
- [lv_port_disp_template.c](https://github.com/lvgl/lvgl/blob/master/examples/porting/lv_port_disp_template.c) for a template for your own driver.
- [Drawing](/overview/drawing) to learn more about how rendering works in LVGL.
- [Display features](/overview/display) to learn more about higher level display features.
## API

13
docs/porting/indev.md
View File

@ -6,7 +6,7 @@
## Types of input devices
To set up an input device an `lv_indev_drv_t` variable has to be initialized:
To register an input device an `lv_indev_drv_t` variable has to be initialized:
```c
lv_indev_drv_t indev_drv;
@ -188,11 +188,16 @@ Besides `read_cb` a `feedback_cb` callback can be also specified in `lv_indev_dr
Every Input device is associated with a display. By default, a new input device is added to the lastly created or the explicitly selected (using `lv_disp_set_default()`) display.
The associated display is stored and can be changed in `disp` field of the driver.
### Event driven reading
### Buffered reading
By default LVGL calls `read_cb` periodically. This way there is a chance that some user gestures are missed.
To solve this you write an event driven driver for your input device that buffers measured data. In `read_cb` you can set the buffered data instead of reading the input device.
You can set the `data->continue_reding` flag to LVGL there is more data to read and call `read_cb` again.
To solve this you can write an event driven driver for your input device that buffers measured data. In `read_cb` you can set the buffered data instead of reading the input device.
You can set the `data->continue_reding` flag to tell that LVGL there is more data to read and it should call the `read_cb` again.
## Further reading
- [lv_port_indev_template.c](https://github.com/lvgl/lvgl/blob/master/examples/porting/lv_port_indev_template.c) for a template for your own driver.
- [INdev features](/overview/display) to learn more about higher level input device features.
## API

1
docs/porting/index.md
View File

@ -10,7 +10,6 @@
.. toctree::
:maxdepth: 2
sys
project
display
indev

49
docs/porting/log.md
View File

@ -4,49 +4,34 @@
```
# Logging
LVGL has built-in *log* module to inform the user about what is happening in the library.
LVGL has built-in *Log* module to inform the user about what is happening in the library.
## Log level
To enable logging, set `LV_USE_LOG 1` in *lv_conf.h* and set `LV_LOG_LEVEL` to one of the following values:
- **LV_LOG_LEVEL_TRACE** A lot of logs to give detailed information
- **LV_LOG_LEVEL_INFO** Log important events
- **LV_LOG_LEVEL_WARN** Log if something unwanted happened but didn't cause a problem
- **LV_LOG_LEVEL_ERROR** Only critical issue, when the system may fail
- **LV_LOG_LEVEL_NONE** Do not log anything
To enable logging, set `LV_USE_LOG 1` in `lv_conf.h` and set `LV_LOG_LEVEL` to one of the following values:
- `LV_LOG_LEVEL_TRACE` A lot of logs to give detailed information
- `LV_LOG_LEVEL_INFO` Log important events
- `LV_LOG_LEVEL_WARN` Log if something unwanted happened but didn't cause a problem
- `LV_LOG_LEVEL_ERROR` Only critical issue, when the system may fail
- `LV_LOG_LEVEL_USER` Only user messages
- `LV_LOG_LEVEL_NONE` Do not log anything
The events which have a higher level than the set log level will be logged too. E.g. if you `LV_LOG_LEVEL_WARN`, *errors* will be also logged.
The events which have a higher level than the set log level will be logged too. E.g. if you `LV_LOG_LEVEL_WARN`, errors will be also logged.
## Logging with printf
If your system supports `printf`, you just need to enable `LV_LOG_PRINTF` in *lv_conf.h* to send the logs with `printf`.
## Printing logs
### Logging with printf
If your system supports `printf`, you just need to enable `LV_LOG_PRINTF` in `lv_conf.h` to send the logs with `printf`.
## Custom log function
### Custom log function
If you can't use `printf` or want to use a custom function to log, you can register a "logger" callback with `lv_log_register_print_cb()`.
For example:
```c
void my_log_cb(lv_log_level_t level, const char * file, uint32_t line, const char * fn_name, const char * dsc)
void my_log_cb(const char * buf)
{
/*Send the logs via serial port*/
if(level == LV_LOG_LEVEL_ERROR) serial_send("ERROR: ");
if(level == LV_LOG_LEVEL_WARN) serial_send("WARNING: ");
if(level == LV_LOG_LEVEL_INFO) serial_send("INFO: ");
if(level == LV_LOG_LEVEL_TRACE) serial_send("TRACE: ");
serial_send("File: ");
serial_send(file);
char line_str[8];
sprintf(line_str,"%d", line);
serial_send("#");
serial_send(line_str);
serial_send(": ");
serial_send(fn_name);
serial_send(": ");
serial_send(dsc);
serial_send("\n");
serial_send(buf, strlen(buf));
}
...
@ -58,4 +43,4 @@ lv_log_register_print_cb(my_log_cb);
## Add logs
You can also use the log module via the `LV_LOG_TRACE/INFO/WARN/ERROR(description)` functions.
You can also use the log module via the `LV_LOG_TRACE/INFO/WARN/ERROR/USER(text)` functions.

16
docs/porting/project.md
View File

@ -15,23 +15,21 @@ The graphics library is the **lvgl** directory which should be copied into your
## Configuration file
There is a configuration header file for LVGL called **lv_conf.h**. It sets the library's basic behaviour, disables unused modules and features, adjusts the size of memory buffers in compile-time, etc.
There is a configuration header file for LVGL called **lv_conf.h**. In this you can set the library's basic behaviour, disable unused modules and features, adjusts the size of memory buffers in compile-time, etc.
Copy **lvgl/lv_conf_template.h** next to the *lvgl* directory and rename it to *lv_conf.h*. Open the file and change the `#if 0` at the beginning to `#if 1` to enable its content.
*lv_conf.h* can be copied other places as well but then you should add `LV_CONF_INCLUDE_SIMPLE` define to your compiler options (e.g. `-DLV_CONF_INCLUDE_SIMPLE` for gcc compiler) and set the include path manually.
*lv_conf.h* can be copied other places as well but then you should add `LV_CONF_INCLUDE_SIMPLE` define to your compiler options (e.g. `-DLV_CONF_INCLUDE_SIMPLE` for gcc compiler) and set the include path manually.
In this case LVGL will attempt to include `lv_conf.h` simply with `#include "lv_conf.h"`.
In the config file comments explain the meaning of the options. Check at least these three configuration options and modify them according to your hardware:
1. **LV_HOR_RES_MAX** Your display's horizontal resolution.
2. **LV_VER_RES_MAX** Your display's vertical resolution.
3. **LV_COLOR_DEPTH** 8 for (RG332), 16 for (RGB565) or 32 for (RGB888 and ARGB8888).
In the config file comments explain the meaning of the options. Be sure to set at least `LV_COLOR_DEPTH` according to your display's colro depth.
## Initialization
To use the graphics library you have to initialize it and the other components too. The order of the initialization is:
1. Call *lv_init()*.
1. Call `lv_init()`.
2. Initialize your drivers.
3. Register the display and input devices drivers in LVGL. More about [Display](/porting/display) and [Input device](/porting/indev) registration.
3. Register the display and input devices drivers in LVGL. Lear more about [Display](/porting/display) and [Input device](/porting/indev) registration.
4. Call `lv_tick_inc(x)` in every `x` milliseconds in an interrupt to tell the elapsed time. [Learn more](/porting/tick).
5. Call `lv_task_handler()` periodically in every few milliseconds to handle LVGL related tasks. [Learn more](/porting/task-handler).
5. Call `lv_timer_handler()` periodically in every few milliseconds to handle LVGL related tasks. [Learn more](/porting/task-handler).

29
docs/porting/sys.md
View File

@ -1,29 +0,0 @@
```eval_rst
.. include:: /header.rst
:github_url: |github_link_base|/porting/sys.md
```
# System overview
![](/misc/sys.png "System architecture with LVGL (formerly LittlevGL)")
**Application**
Your application which creates the GUI and handles the specific tasks.
**LVGL**
The graphics library itself. Your application can communicate with the library to create a GUI. It contains a HAL (Hardware Abstraction Layer) interface to register your display and input device drivers.
**Driver**
Besides your specific drivers, it contains functions to drive your display, optionally to a GPU and to read the touchpad or buttons.
* * *
Depending on the MCU, there are two typical hardware set-ups. One with built-in LCD/TFT driver periphery and another without it. In both cases, a frame buffer will be required to store the current image of the screen.
1. **MCU with TFT/LCD driver**
If your MCU has a TFT/LCD driver periphery then you can connect a display directly via RGB interface.
In this case, the frame buffer can be in the internal RAM (if the MCU has enough RAM) or in the external RAM (if the MCU has a memory interface).
2. **External display controller**
If the MCU doesn't have TFT/LCD driver interface then an external display controller (E.g. SSD1963, SSD1306, ILI9341) has to be used.
In this case, the MCU can communicate with the display controller via Parallel port, SPI or sometimes I2C.
The frame buffer is usually located in the display controller which saves a lot of RAM for the MCU.

16
docs/widgets/extra/meter.md
View File

@ -34,26 +34,28 @@ Labels are added automatically on major ticks with `label_gap` distance from the
Indicators needs to be added to a Scale and their value is interpreted in the range of the Scale.
All the indicator add functions returns `lv_meter_indicator_t *`.
#### Needle line
`lv_meter_indicator_t * indic = lv_meter_add_needle_line(meter, scale, line_width, line_color, r_mod)` adds a needle line to a Scale. By default the length of the line is the same as the scale's radius but `r_mod` changes the length.
`indic = lv_meter_add_needle_line(meter, scale, line_width, line_color, r_mod)` adds a needle line to a Scale. By default the length of the line is the same as the scale's radius but `r_mod` changes the length.
`lv_meter_set_indicator_value(meter, inidicator, value)` sets the value of the indicator.
`lv_meter_set_indicator_value(meter, indic, value)` sets the value of the indicator.
#### Needle image
`lv_meter_indicator_t * indicator = lv_meter_add_needle_img(meter, scale, img_src, pivot_x, pivot_y)` sets an image that will be used as a needle. `img_src` should be a needle pointing to the right like this `-O--->`.
`indic = lv_meter_add_needle_img(meter, scale, img_src, pivot_x, pivot_y)` sets an image that will be used as a needle. `img_src` should be a needle pointing to the right like this `-O--->`.
`pivot_x` and `pivot_y` sets the pivot point of the rotation relative to the top left corner of the image.
`lv_meter_set_indicator_value(meter, inidicator, value)` sets the value of the indicator.
#### Arc
`lv_meter_indicator_t * indicator = lv_meter_add_arc(meter, scale, arc_width, arc_color, r_mod)` adds and arc indicator. . By default the radius of the arc is the same as the scale's radius but `r_mod` changes the radius.
`indic = lv_meter_add_arc(meter, scale, arc_width, arc_color, r_mod)` adds and arc indicator. . By default the radius of the arc is the same as the scale's radius but `r_mod` changes the radius.
`lv_meter_set_indicator_start_value(meter, inidicator, value)` and `lv_meter_set_indicator_end_value(meter, inidicator, value)` sets the value of the indicator.
`lv_meter_set_indicator_start_value(meter, indic, value)` and `lv_meter_set_indicator_end_value(meter, inidicator, value)` sets the value of the indicator.
#### Scale lines (ticks)
`lv_meter_indicator_t * indicator = lv_meter_add_scale_lines(meter, scale, color_start, color_end, bool local, width_mod)` adds an indicator that modifies the ticks lines.
`indic = lv_meter_add_scale_lines(meter, scale, color_start, color_end, local, width_mod)` adds an indicator that modifies the ticks lines.
If `local` is `true` the ticks' color will be faded from `color_start` to `color_end` in the indicator's start and end value range.
If `local` is `false` `color_start` and `color_end` is mapped to the start and end value of the scale and only a "slice" of that color gradient will be visible in the indicator's start and end value range.
`width_mod` modifies the width of the tick lines.
@ -67,7 +69,7 @@ If `local` is `false` `color_start` and `color_end` is mapped to the start and e
Learn more about [Events](/overview/event).
## Keys
Keys have effect on the close button and button matrix. You can add them manually to a group if required.
No keys are handled by the Meter widget.
Learn more about [Keys](/overview/indev).