Skip to content

Fix some stuff in README.md #340

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
May 6, 2025
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 11 additions & 11 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -32,13 +32,13 @@ related bits of a microcontroller.

***What is LVGL?***

[LVGL](https://lvgl.io) is a graphics framework writtemn for C99. It is also written to run on resource constrained devices.
[LVGL](https://lvgl.io) is a graphics framework written for C99. It is also written to run on resource constrained devices.
It is a feature rich framework that provides a plethora of different controls (widgets) as well as the ability
to make your owmn custom controls.

***What is a binding?***

A Binding is a code that encapsulates code written in one programming language so it is accessable from another
A Binding is code that encapsulates code written in one programming language so it is accessable from another
programming language. It is best to think of it as a translator, in the case of this project it translates Python
to C99 and vice versa. It allows us access to the LVGL code by using the Python programming language.

Expand Down Expand Up @@ -278,7 +278,7 @@ To compile you will need Python >= 3.10 for for all build types.

#### Compiling for Windows:

* not supported yet
* Not yet supported

<br>

Expand Down Expand Up @@ -331,7 +331,7 @@ Target options is broken down into 2 sections

##### *Model/Variant*

The model is the processor model being used or the build type. the build type is what is
The model is the processor model being used or the build type. The build type is what is
specified when compiling to run on macOS or Unix.

When compiling for macOS or Unix you are able to specify the build type. That is done by using
Expand Down Expand Up @@ -549,9 +549,9 @@ ______________________________________

Common options that are available across all esp32 targets:

* `BAUD={bits per second}`: how fast to flash the firmware, `deploy` must also be set to use this
* `PORT={serial port}`: port the ESP is connected to, `deploy` must also be set to use this
* `deploy`: after building flash the firmware, `PORT` and `BAUD` are optional. The speed will default
* `BAUD={bits per second}`: How fast to flash the firmware, `deploy` must also be set to use this
* `PORT={serial port}`: Port the ESP is connected to, `deploy` must also be set to use this
* `deploy`: After building flash the firmware, `PORT` and `BAUD` are optional. The speed will default
to whatever the ESP-IDF is set to and there will be an attempt at detecting the port automatically
* `--skip-partition-resize`: If you do not want the build system to resize the application partition automatically.
* `--partition-size={app partition size}`: Manually set the application partition size. This is something you want
Expand All @@ -566,8 +566,8 @@ Common options that are available across all esp32 targets:
* `--flash-size={4, 8, 16, 32, 64 or 128}`: Sets the flash size that you have available on your ESP32
* `--ota`: Add this flag if you wanbt to do OTA updates. This creates 2 application partitions that are the same size.
* `--dual-core-threads`: (Experimental) MicroPython is written so that the user is only able to run code on a single core of the ESP32.
That is very limiting. This option allows code to run on both CPU cores. Be warned mthis option also disables the GIL
So care must be given to accessing global variables. You need to put nlocks in place to keep the memory from getting
That is very limiting. This option allows code to run on both CPU cores. Be warned this option also disables the GIL
so care must be given to accessing global variables. You need to put nlocks in place to keep the memory from getting
corrupted. You do not get to decide what core to use. That is automatically done based on the load that is on the cores.
* `--task-stack-size={stack size in bytes}`: Sets the default stack size for threads
* `CONFIG_*={value}`: You can alter the config settings of the esp-idf by using these settings. Refer to the ESP-IDF documentation
Expand Down Expand Up @@ -606,10 +606,10 @@ The global options are broken down into 2 secions

##### *Input/Output*

* `DISPLAY={ic model or path}`: model number of the display driver that is located in `api_drivers/common_api_drivers/display`
* `DISPLAY={ic model or path}`: Model number of the display driver that is located in `api_drivers/common_api_drivers/display`
or it can be the absolute path to a custom driver you have written. This must be the
path to the folder that contains the driver files.
* `INDEV={ic model or path}`: model number of indev driver that is located in `api_drivers/common_api_drivers/indev`
* `INDEV={ic model or path}`: Model number of indev driver that is located in `api_drivers/common_api_drivers/indev`
or it can be the absolute path to your own custom driver (with the .py extension)

The above options are able to be repeated if you want to include multiple drivers.
Expand Down