Improve platformio demo/tutorial

[puzrin]

In continuation of #667

Goals

Simplify quick-start for beginers and promote modern best practices

1. Allow setup as simple as possible (1-click preferred).
2. Allow quick start with interface prototyping without hardware.
3. Provide good example of project structure.

Suggestion

1. Create demo/template with platformio (improve existing)
   • When project opened in vscode, it will install as much as possible automatically for current OS (platformio itself, compilers, flashers, lib dependencies, ...).
2. Support most demanded pio platforms:
   • native - mandatory, for prototyping on PC.
   • stm32 - desired. Example 1, Example 2, example 3 + display
   • esp32 - optional. Example 1, example 2, example 3 + display.
3. Suggest good project structure, to minimize platform-specific code.

For discuss

• Should demo be RTOS-based to minimize difference between platforms (delays, timers, internal communications)?
• What platforms should be supported?
  • native - mandatory
  • stm32/esp32 - both optional, just to prove code is working and suggested project structure is convenient.
• Is it possible to use CubeMX for stm32 specific code setup/update? IMHO it's convenient for beginners and has nice GUI. But it's horrible for integration, because contains main() in generated code.
• Display content?
  • transparent overlay for debug messages (convenient)
  • "settings" menu with +/- incremented params (popular demand)
  • animated graph (just for fun)
• anything else missed?

[kisvegabor]

Thanks for the opening this issue! I can try to make dual-port config for native and STM32F429-discovery. I already have drivers to this board which are using the HAL_... drivers.

[puzrin]

IMHO, any dev board will be ok, if the only required action is "attach board to USB cable and play with awesome lvgl". It should not require additional wires, external power and so on.

I tried to sort out, why one may wish to play with dev board, if simulator available. And could invent 2 reasons:

1. Check interface tactile feelings on something real (but still without custom hardware).
2. Understand required MCU performance if heavy animations used and so on.

So, STM32F429-discovery is my favorite candidate too. 35-40$ is a bit more than expected, but still acceptable price for "quick play". And one can always stay in sim and pay nothing for extra hardware.

• Should we care about sample boards without touch screen (small OLED + buttons / encoder / joystick)? I think no, because simulator should be enougth.
• Should we care about esp8266/esp32? Probably - only once. Make sure multi target in pio config works on real device and forget about it.
• Should we care about low budget dev boards? I would like to say "yes", but, to be honest... i don't know. Low budged dev boards with touch screens - i could find only "arduino uno" form factor at aliexpress. Type in search "stm32 arduino uno", "esp32 arduino uno", "arduino uno display".

Summary:

• STM32F429-discovery is preferable as start point
• esp32 - at start point successful compilation is enougth.
• Everything else hardware can be postponed to volunteers (forever, lol).

[puzrin]

What else can be useful for beginners? Those may be interested in correct implementations for:

1. Thouch screen input:
   • Calibration
   • (?) Driver for raw outputs [X+/X-/Y+/Y-] (common case for cheap displays)
2. Keyboard-related inputs: buttons, encoder, 5-way tactile switches (5 buttons as micro-joystick):
   • Jitter filter.
   • Auto-repeat on long press.

Can this be unified somehow without falling into low level drivers and platform-specific code (for example, on RTOS level)?

I whould use touch screens everywhere, but could not find cheap displays < 2.4". The only well known case is "ipod 6 nano display", but it's interface is very inconvenient.

If someone can advice displays < 2.4" (1.44..1.8), < 10$, with SPI and good availability (multiple sellers at aliexpress/ebay) - let me know.

[kisvegabor]

• STM32F429-discovery is preferable as start point
• esp32 - at start point successful compilation is enougth.
• Everything else hardware can be postponed to volunteers (forever, lol).

I agree with it! First, let's have two platforms to see it works.

Thouch screen input: Calibration

Already implemented: https://github.com/littlevgl/lv_examples/tree/master/lv_apps/tpcal

Driver for raw outputs [X+/X-/Y+/Y-]

I've never used a display with raw analog output, I thought it's not so common. There is a repo for the drivers here: https://github.com/littlevgl/lv_drivers Maybe it can be integrated later.

Keyboard-related inputs: buttons, encoder, 5-way tactile switches (5 buttons as micro-joystick):

LittlevGL already supports keyboard and encoder navigation. So it just the question of some I/O reads from the driver's point of view.

Auto-repeat on long press.

It's supported on buttons with LV_ACTION_LONG_PR and LV_BTN_ACTION_LONG_PR_REPEAT.

I played with the dual target config. I added the STM32 driver to next to the simualtor drivers but when I modified the drivers they didn't recompile. I haven't found a way to make a clean build. The libraries were never updated again...

At this point my platform.ini looks like this and is used this drivers for STM:

[platformio]
env_default = native

lib_deps =
  littlevgl
  littlevgl_sdl_drivers

[env:native]
platform = native
build_flags =
  -D BUILD_ENV_NAME=$PIOENV
  -I include 
  -D LV_CONF_INCLUDE_SIMPLE
  -lSDL2

[env:disco_f429zi]
platform = ststm32
board = disco_f429zi
framework = stm32cube
board_build.f_cpu = 180000000L
upload_protocol = stlink
build_flags =
  -D BUILD_ENV_NAME=$PIOENV
  -I include 
  -D LV_CONF_INCLUDE_SIMPLE
  -DHSE_VALUE=8000000U

I added #if BUILD_ENV_NAME == native to the drivers to enable/disable them based on the current configuration.

[puzrin]

I've never used a display with raw analog output, I thought it's not so common.

There are many strange things in this world :)

• Small TFT displays without "motherboard" are 2x cheaper and much more compact. There you will have controller + raw touch pins. When you prefer order PCBs at jlcpb/pcwbway, and consider breadboards as "useless waste of time" - using raw TFT display may be an interesting option.
• TFT displays with motherboard but without touch controller are a bit more cheap and more compact.

Key point of such interface - touch screen analog pins can be SHARED with digital display wires. So you can't just have independent DMA & ADC drivers. You should orchestrate those via locks and switch pin modes too.

but when I modified the drivers they didn't recompile. I haven't found a way to make a clean build. The libraries were never updated again...

Quick solution - just delete .pioenvs & .piolibdeps if something goes wrong. Then wait a bit, until pio redownload files.

In normal mode (not dependency development), you should specify dependency version or commit hash. The same for platform version.

http://docs.platformio.org/en/latest/projectconf/section_env_library.html

When you change dependency version, existing libs will be updated if not match. When no version - no updates until manual folder delete.

---

Just to clarify. Does this board looks like your one? I'd like to make order and be sure it will work with demo as is.

[seyyah]

I've never used a display with raw analog output, I thought it's not so common.

There are many strange things in this world :)

We have to use +1

[kisvegabor]

Touchpad with ADC

I see. It seems I was lucky so far to meet only with SPI TP controllers. :)

Library update

Quick solution - just delete .pioenvs & .piolibdeps if something goes wrong. Then wait a bit, until pio redownload files.

Then how to develop a library? I modify the lib in .piolibdeps. Can you show a link about the intended process? Where shall I put the libraries which are under development?

Board

Just to clarify. Does this board looks like your one? I'd like to make order and be sure it will work with demo as is.

Yes, it is!

[puzrin]

Then how to develop a library? I modify the lib in .piolibdeps. Can you show a link about the intended process? Where shall I put the libraries which are under development?

I have no good recommendations. Can share only some things i know:

• in node.js it's common to place developped sub-module in convenient place and create symlink to node_modules folder.
• in platformio you can temporary place driver into lib subfolder and remove it from dependency.
• you can constantly push your driver changes into temporary branch, and change commit hash in demo's platform.ini.
• if you modify sources directly in .piolibdeps, try to force clean platformio run -t clean https://docs.platformio.org/en/latest/projectconf/section_env_general.html#targets
• try to remove .pioenvs/ folder only. May be that will be enougth.

May be that can help. But i did not tried this.

[kisvegabor]

Thank you for the hints. I'll try them soon.

[kisvegabor]

It played with it for a while but it gave same tough hours. Even if I remove a lib lib_deps it's still rebuilt and linked. Maybe it's cached somehow.

Unfortunately, I need to postpone it to work on the new features in v6.0.

@puzrin Do you time to deal with it?

[puzrin]

If this not require good C knowledge - i could try. I mean, if knowledge of PIO required, or "merge 2 existing demo into single one" and so on.

Could you push your current progress somewhere into temporary branch and explain details?

[kisvegabor]

I'll put together what I have so far and clean up the required STM32 driver. I think no serious C knowledge is required.

[kisvegabor]

I've have created two branches:

• Drivers: https://github.com/littlevgl/platformio_sdl_drivers/tree/stm
• Main projects: https://github.com/littlevgl/pc_simulator_sdl_platformio/tree/stm

I've used an #if BUILD_ENV_NAME == stm32f429_disco / native #endif guard in the platform specific files.

The STM drivers are tested on STM32F429 Discovery board.

[stale[bot]]

This issue or pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[puzrin]

this is not stale

[puzrin]

I started to dig demo and have some questions.

1.

Did you published lvgl? I see driver only.

Warning! Library `{'requirements': None, 'name': 'littlevgl'}` has not been found in PlatformI
O Registry.

You can ignore this message, if `{'requirements': None, 'name': 'littlevgl'}` is a built-in li
brary (included in framework, SDK). E.g., SPI, Wire, etc.

2.

Is it necessary to put everything in repo into subdirectiry (lv_pio_sdl) instead of root?

3.

What are reasons to put headers into /include folder?

• This is not a library, where headers can be used separate
• IMHO including from local dir via relative path would be less fragile

[puzrin]

May be worth give me temporary permissions for direct commits to pio demo repo?

[kisvegabor]

May be worth give me temporary permissions for direct commits to pio demo repo?

I sent the invitation.

Did you published lvgl? I see driver only.

I published it but it seems when I renamed the repos and changed the project structure I messed it up somehow. What do you think where should we add library.json for LittlevGL? Open a new repo for it? Or when lvgl is restructured (adding src folder) add a misc folder for things like that?

Is it necessary to put everything in repo into subdirectiry (lv_pio_sdl) instead of root?

I think it's not necessary.

3. What are reasons to put headers into /include folder?

I though the include folder is for header files. It's not the usual way in Pio feel free to change it.

[puzrin]

I sent the invitation

Seems you added me to https://github.com/littlevgl/lvgl instead of https://github.com/littlevgl/pc_simulator_sdl_platformio

What do you think where should we add library.json for LittlevGL? Open a new repo for it? Or when lvgl is restructured (adding src folder) add a misc folder for things like that?

I have no experience to give qualified advice about. All projects i know, have library.json in the root, in the same repo. Usually they also have library.properties for arduino.

You can open libs with empty search from "pio home" tab in editor, and inspect top downloaded packages.

[kisvegabor]

Seems you added me to https://github.com/littlevgl/lvgl instead of https://github.com/littlevgl/pc_simulator_sdl_platformio

Uh, really. I added you to both PIO projects.

I have no experience to give qualified advice about. All projects i know, have library.json in the root, in the same repo. Usually they also have library.properties for arduino.

Ok, I'll figure out something until tomorrow.

[puzrin]

Thanks. I need something build-able under linux to verify upcoming updates. Any branch, at least 1 platform. Then i'll be able to suggest reorganized project.

[kisvegabor]

Finally, I've created a library branch in the pio repo and added library.json there: https://github.com/littlevgl/pc_simulator_sdl_platformio/tree/library

We can add examples here later too.

Once the library will be approved the PC simulator should work again.

This repo should be renamed later once we will have more than 1 supported platform.

[puzrin]

https://github.com/littlevgl/pc_simulator_sdl_platformio/tree/vit

• Reorganized everything to isolate hw dependencies into drivers/ folder (no messy #ifdefs everywhere)
• Make native build-able. I have no idea what should it do, but at least it show some window on run.

What is not done:

• Not sure to split main loop code right.
• Not touched stm32 driver (need back cleanup from #if BUILD_ENV_NAME == stm32f429_disco + check on real hardware).
• May be functions/files names can be improved. I did only preliminary iteration of project structure cleanup.

Could you take a look and fix the reset or should i improve something else?

[puzrin]

Note, i don't know why lvgl did not appeared in pio registry, so used github links in config

https://github.com/littlevgl/pc_simulator_sdl_platformio/blob/40138deb5b2d43a4598cec87738e7905081bd9ff/platformio.ini#L25

If you have problems with sdl drivers - use the same approach.

Also note, stm32 hal headers probably should be included without subdirs in path. The same problem was with sdl drivers (already fixed).

[kisvegabor]

Hi,

littlevgl is available in PIO again: https://platformio.org/lib/show/6228/littlevgl Can you add it to platformio.ini? After that I can test it on PC and STM too.

Your approach with the driver folder is way better. :+1: I didn't know it can be solved this way.

[puzrin]

Can you add it to platformio.ini? After that I can test it on PC and STM too.

See https://github.com/littlevgl/pc_simulator_sdl_platformio/commit/dd3b4373206e567fac8733f3f66aec8ac912c267. It was build-able (native), but i replaced link as you requested. If something goes wrong again - uncomment old variant.

Probably main loop in sdl is broken now. I was not sure how to do it right (HAL_Delay not available in SDL). It can be emulated from event via flag polling:

https://github.com/speedcontrols/ac_sc_grinder/blob/master/src/app.cpp#L56-L59

but i was not sure and left it intact.

Your approach with the driver folder is way better. +1 I didn't know it can be solved this way.

Thanks. It's incomplete. Only to move forward with demo.

• Still has to decide, should we use RTOS or not for timer events. Current main loop in drivers are kludge to allow work with more important things.
• Should we abstract "delay()" into driver (i don't like use of delay() at all, but in this case we need some events interface)

I plan return to this questions after sdl2 builds start work and show ~ "hello world".

---

https://github.com/platformio/platform-ststm32/blob/develop/builder/frameworks/stm32cube.py seems PIO does some magick with paths to include libraries. I did not understood yet, how to include board-specific headers.

Since disco-specific things are not very useful for final bare metal, i suggest to postpone it and finalize [demo + sdl2] to useable state first. Then i'll be able to create list of usability issues (for example, sdl window is not scaled on retina displays).

[puzrin]

https://community.platformio.org/t/how-in-include-disco-f429zi-headers/7001

Got preliminary help at pio forum. Change of framework from stm32cube to mbed, will magically repair extra libs :). In short - mbed is well supported, stm32cube - not. But i did not used both and can not insist.

Consider this as memo for next iterations, after simulator start work somehow.

[puzrin]

Here are details how to fix things for stm32cube framework:

https://community.platformio.org/t/how-in-include-disco-f429zi-headers/7001/13?u=vit

It also contains basic sample for LCD. With next release patching of variants_remap.json will not be needed.

After inspecting current stm32-releted sources, seems most are copy-paste of standard libs, not needed for normal work. Stubs for stdio (syscalls.c) can be removed too.

Everything from dropped files can be replaced by this strings in driver.c:

void SysTick_Handler(void)
{
    HAL_IncTick();
    HAL_SYSTICK_IRQHandler(); // Is this really needed?
    lv_tick_inc(1);
}
void NMI_Handler(void) {}
void HardFault_Handler(void) { while (1) {} }
void MemManage_Handler(void) { while (1) {} }
void BusFault_Handler(void) { while (1) {} }
void UsageFault_Handler(void) { while (1) {} }
void SVC_Handler(void) {}
void DebugMon_Handler(void) {}
void PendSV_Handler(void) {}

[puzrin]

https://github.com/littlevgl/pc_simulator_sdl_platformio/commits/vit - pushed more commits.

Seems simulator finally works.

• I can't type from PC keyboard and don't see reaction to arrows. No ideas if this should work at all.
• Need to clean/fix/test stm32 build.

[embeddedt]

@puzrin

I can't type from PC keyboard and don't see reaction to arrows. No ideas if this should work at all.

This is how the regular PC simulator is by default as well.

[kisvegabor]

I'd like to try the updates but something seems to be wrong with PIO at this moment. I can't log in, nothing is loaded in VS Code and nothing happens when I hit the build button. Probably it's a server issue. I'll try again in a few hours.

[puzrin]

You can try atom editor with pio. The only difference - no debugger.

Just checked atom and installed vscode - both works.

[kisvegabor]

I've tried Atom but still not working. My older projects are working with Atom and VS Code too.

It halts here in Atom:

In VSCode I noticed that "IntelliSense Index Rebuild" is running indefinitely.

Do you have any idea?

[puzrin]

The first link in google VSCode "IntelliSense Index Rebuild" is running indefinitely:

https://github.com/platformio/platformio-vscode-ide/issues/68

May be that helps?

[kisvegabor]

In the lined issue they said it working without an Internet connection. And it was really for me too. It seems like an issue with the Python version. Thank you for the hint.

Anyway, the PC simulator was working here too.

I'd like to try the STM version too but without an internet connection, PIO couldn't download the required libraries/boards. I'll investigate it.

[puzrin]

Consider increase priority of this issue if possible. When it's solved, i could do some things in parallel:

• polish multiplatform samples/recommendations
• create pio demo for lv_i18n
• ask friends to start some projects for disco (need real touchscreen)
• kick pio devs to add emscripten support

Of cause, all that can be done for SDL only, but full-featured project is more "impressive" when asking new people for help.

[kisvegabor]

I've spent some time with investigating my issue with Pio. However, I didn't find an appropriate solution yet... It's just not working with internet connection. Probably my Python version is not compatible with Pio but I don't want to change it because I use it other projects and toolchains too.

Anyone else can test it on STM32F429?

I move this issue to the PIO repository because it's related to it instead of LittelvGL core.

[stale[bot]]

This issue or pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[puzrin]

not stale

[stale[bot]]

This issue or pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[puzrin]

not stale

[stale[bot]]

This issue or pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[puzrin]

Does anyone plan to fix demo for STM32F429-discovery board? I can create issue with summary, but would like to avoid coding.

[kisvegabor]

Please create an issue to summarize the current state.