Closed TecDroiD closed 4 months ago
That's because you have the refresh rate too high. You need to turn it down a bit. The refresh is also tied to when it checks for touch input. I would scale it back to 15ms or more.
This is the code block I am talking about.
while True:
time.sleep_ms(1)
lv.tick_inc(1)
lv.task_handler()
Hey Kevin, basically, as far as i understand the pointer_framework, it shouldn't react unless press state changes. When i touch the screen, gt911 driver sends back (lv.PRESSED, x, y). As long as state didn't change, no action should take place- res in pointer_framework._read is set to False.. So basically, no event should fire and nothing should happen until i release the touchscreen.
I wrote a little program to test the GT911:
import application
import lvgl as lv
import display
lv.init()
_display = display.create_display()
_touch = display.create_touch()
#if "run" in application.__dict__:
# application.run()
import time
old_state = _touch.RELEASED
while True:
time.sleep_ms(1)
val = _touch._get_coords()
if val is not None:
if old_state != val[0]:
old_state = val[0]
print(val)
else:
if old_state != _touch.RELEASED:
old_state = _touch.RELEASED
print(val)
This works well when I sleep for about 50ms- so GT911 seems to be slow. Okay.. but setting the sleep in my application as seen above does not have any effect besides a slower moving click counter.
Next thing I tried is adding a callback for ALL events on my screen and printed them. With a current sleep rate of 150 ms, I get about 5 times the pressed event.
In my opinion, something reads the gt911 frequently and too fast. Sadly, I don't know where this is implemented.
When the touch gets pressed is when the state will change to pressed and then when it gets released to will change. while the screen is being pressed it should remain pressed. If the state from the GT911 driver changes from pressed to released while you are still touching the screen then that is a problem with the driver. If it doesn't and you are still getting the double callback then that is a problem in LVGL and it needs to be reported. Before we open an issue in LVGL about it we need to confirm where the issue is first.
You will need to edit the GT911 driver and add a couple of print statements in there for me.
def _get_coords(self):
self._i2c.read_mem(_STATUS_REG, buf=self._mv[:1])
touch_cnt = self._buf[0] & 0x0F
if self._buf[0] & 0x80 or touch_cnt < 6:
self._buf[0] = 0x00
self._i2c.write_mem(_STATUS_REG, buf=self._mv[:1])
if touch_cnt == 1:
self._i2c.read_mem(_POINT_1_REG, buf=self._mv)
x = self._buf[0] + (self._buf[1] << 8)
y = self._buf[2] + (self._buf[3] << 8)
self._buf[0] = 0x00
self._i2c.write_mem(_STATUS_REG, buf=self._mv[:1])
print('touch pressed')
return self.PRESSED, x, y
print('touch released')
go ahead and upload the gt911 driver to the MCU.. If you have the driver baked into the firmware don't worry when you upload the new one it will override the one that is baked into the firmware.
Use this code below along with your normal driver setup and loop code.
count = 0
def callback(_):
global count
count += 1
print('clicked', count)
button = lv.button(lv.screen_active())
button.center()
button.add_event_cb(callback, lv.EVENT.CLICKED, None)
watch and see if you get the double events and if those double events are happening because the touch driver is reporting that the touch has been released when you didn't release it.
if you edit lv_conf.h in the lib folder. search for LV_DEF_REFR_PERIOD
. If that is set to a 1 that might be too fast. 33 is the default amount.
As a note. The PRESSED
and RELEASED
are indev driver states, they are not the same as what is used in events. You also have RELEASED
and PRESSED
in the events as well but these are not good to be used to tell when the state of a button changes. That is what CLICKED
is for in the events. pressed is literally that, when the screen is pressed. the event will keep on firing each loop so long as the display is pressed. Released will only fire a single time. CLICKED
will only fire when the state changes on a control.
okay. LV_DEF_REFR_PERIOD has never been changed and is still at 33. I'll try to set it up to 50 as soon as my computer is completely dry (did you ever sneeze while drinking something?)
here's the output your modification generated:
MicroPython v1.22.1-dirty on 2024-04-11; Generic ESP32S3 module with Octal-SPIRAM with ESP32S3
Type "help()" for more information.
>>> ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x1 (POWERON),boot:0x8 (SPI_FAST_FLASH_BOOT)
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fce3810,len:0xf8c
load:0x403c9700,len:0xb3c
load:0x403cc700,len:0x2dd4
entry 0x403c989c
Touch Product id: bytearray(b'911\x00')
Touch Firmware version: 0x1060
Touch Vendor id: 0x0
Touch Configured width: 800
Touoch Configured height: 480
touch released
touch released
touch released
touch released
touch released
touch released
touch pressed
touch released
clicked 1
touch pressed
touch released
clicked 2
touch pressed
touch released
clicked 3
touch released
touch released
touch released
touch released
touch released
touch released
touch pressed
touch released
clicked 4
touch pressed
touch released
clicked 5
touch released
touch released
touch released
touch released
touch released
touch pressed
touch released
clicked 6
touch pressed
touch released
clicked 7
touch pressed
touch released
clicked 8
touch pressed
touch pressed
touch released
clicked 9
touch pressed
touch released
clicked 10
touch released
touch released
I pressed my button several times with different durations. sleep time in mainloop is 150ms
It looks like when you released there is a single event that gets triggered like it is supposed to be working. If you are actually pressing and holding the button but it is still releasing then that would be an issue with the touch driver.
as you can see clicked only increments a single time when a release occurs. There is not multiple clicks occurring when a release happens.
touch pressed
touch released
clicked 1
touch pressed
touch released
clicked 2
touch pressed
touch released
clicked 3
touch released
touch released
touch released
touch released
touch released
touch released
touch pressed
touch released
clicked 4
touch pressed
touch released
clicked 5
touch released
touch released
see how they are in blocks. and each block only has a single increment of the click.
Now the only thing that might be happening is your single touch might be getting interpreted as multiple. The driver is written so if there is more than one touch then all touches get ignored. I don't know which touch should be considered to be the correct one and that could cause things to jump around wildly which is why I ignore it as an invalid.
I am going to change that behavior I think. I will make it so that if there was a touch happening on the previous poll and then it changes to more than one touch I will recycle the last coords. Once there is a response of a single touch happening or no touch at all is when the state or coords will get updated.
Let me make that change. That might solve the issue you are having.
OK I updated the driver. see if that helps with the problem.
also change your mainloop code to be 33ms delay., 150ms is way to long.
sadly, this didn't change anything. I tried to set LV_DEF_REFR_PERIOD to 50 - just for fun - but that didn't change much besides an annoying flickering..
I am not sure why you are getting double events. according to what I am seeing from the output it looks like it is working properly.
Do me a favor and run that same test script above except this time press the display only a single time and release it only a single time. Paste the output here.
Hi again, sorry.. I needed some time for other work.. so here's the result, all timers I know are set to 33 and I pressed my button for about half a second
�ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0xc (RTC_SW_CPU_RST),boot:0x8 (SPI_FAST_FLASH_BOOT)
Saved PC:0x403842ca
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fce3810,len:0xf8c
load:0x403c9700,len:0xb3c
load:0x403cc700,len:0x2dd4
entry 0x403c989c
Touch Product id: bytearray(b'911\x00')
Touch Firmware version: 0x1060
Touch Vendor id: 0x0
Touch resolution: width=800, height=480
touch released
touch released
touch released
touch released
touch released
touch released
touch released
touch released
touch released
touch released
touch released
touch released
touch released
touch released
touch released
touch released
touch released
touch released
touch released
touch released
touch released
touch released
touch released
touch released
touch released
touch released
touch pressed
touch released
clicked 1
touch pressed
touch released
clicked 2
touch released
touch released
and you only pressed the button a single time?
The reason why I am asking is because if the refresh time is set to 33 milliseconds from the time you pressed the button until the last "released" in your log 165 milliseconds has passed and not 500.
well.. i didn't measure the time but it felt like about half a second. .. i tried a little more precise for about a second and got 20 releases.
OK so the issue is in the touch IC or the driver. We need to sort that out.. There are some settings that can be adjusted in the hardware for the IC that I am going to want you to change.
import gt911 as _gt911
gt911 = _gt911.GT911(i2c_bus)
hw = gt911.firmware_config
print('touch_press_level:', hw.touch_press_level)
print('touch_leave_level:', hw.touch_leave_level)
print('noise_reduction:', hw.noise_reduction)
set up the i2cBus and then ad this code after it. paste what gets output. I think we have an issue with the IC and the releasing of the touch. Lets see what is coded into the firmware and maybe we can adjust it.
okay, here's the result Use Ctrl-] or Ctrl-x to exit this shell ESP-ROM:esp32s3-20210327 Build:Mar 27 2021 rst:0x1 (POWERON),boot:0x8 (SPI_FAST_FLASH_BOOT) SPIWP:0xee mode:DIO, clock div:1 load:0x3fce3810,len:0xf8c load:0x403c9700,len:0xb3c load:0x403cc700,len:0x2dd4 entry 0x403c989c Touch Product id: bytearray(b'911\x00') Touch Firmware version: 0x1060 Touch Vendor id: 0x0 Touch resolution: width=800, height=480 touch_press_level: 90 touch_leave_level: 70 noise_reduction: 10 touch released touch released
Sadly, I have only this single panel. Would be interesting to see how another one reacts..
I have not had any issues with it using the GT911 I have here on my desk. There is another user which helped me develop this driver and his doesn't have this issue either. That is the reason why I am looking at the cause being from a firmware setting.
The touch_press_level
and touch_leave_level
have a setting range of 0 to 255. I would start by adjusting those up to see what happens. set them to 150 and go from there...
import gt911 as _gt911
gt911 = _gt911.GT911(i2c_bus)
hw = gt911.firmware_config
hw.touch_press_level = 150
hw.touch_leave_level = 150
print('touch_press_level:', hw.touch_press_level)
print('touch_leave_level:', hw.touch_leave_level)
print('noise_reduction:', hw.noise_reduction)
hw.save()
This code only needs to run a single time. the settings are saved to NV memory in the touch IC.
You can write a GUI interface to adjust these settings if you want to, that's up to you. In the future I will probably write some kind of a framework for handling touch settings.
Well.. firstly, it doesn't save the configuration. After rebooting the board, it's the defaults of 90 and 70 again. But also, value of 150 did not have any effect. I managed a friend to send me some other boards for testing. Maybe this helps. Currently, I have no idea what the problem may be besides some defective hardware. Sadly, I didn't save the preloaded firmware to test its behavior.
I'll try as soon as the boards arrived
it doesn't save it at all? It should be...
So this is what I want you to do to test something for me.
import gt911 as _gt911
gt911 = _gt911.GT911(i2c_bus)
hw = gt911.firmware_config
hw.width= 300
hw.height= 200
hw.save()
import gc
del hw
gc.collect()
hw = gt911.firmware_config
print(hw.width, hw.height)
okay, here we go.. I used this codefile
import i2c
import gt911 as gt9
i2c_bus = i2c.I2CBus( scl=20, sda=19, freq=100000, use_locks=False)
gt911 = gt9.GT911(i2c_bus)
hw = gt911.firmware_config
print("Setting resolution")
hw.width= 300
hw.height= 200
print(f"resolution set to {hw.width}, {hw.height}")
print ("saving ...")
hw.save()
print("cleanup")
import gc
del hw
gc.collect()
print("reload config")
hw = gt911.firmware_config
print(hw.width, hw.height)
and that's the result
>>> import testgt
Touch Product id: bytearray(b'911\x00')
Touch Firmware version: 0x1060
Touch Vendor id: 0x0
Touch resolution: width=800, height=480
Setting resolution
resolution set to 300, 200
saving ...
Touch Product id: bytearray(b'\x00t8\x00')
Touch Firmware version: 0x4166
Touch Vendor id: 0x5C
Touch resolution: width=23552, height=74
cleanup
reload config
800 480
OK so something is getting boogered up with the firmware. I am going to have do look into that some more.
got some question on gt911._get_coords() in line 117, ff, you reset the status register when bit 7 is set or bits 0:3 are smaller than 6, so less than 6 points are pressed. bit 7, as far as I understand, is set to 1 when gt911 is ready to be read. next, you handle the touch points, without regarding if the machine has readable data or not.. is this correct?
I just updated the GT911 driver, see if that fixes the issue.
I do not believe it is going to change the behavior but I do understand what you are getting at. The thing is if there is no readable data then the touch count is going to be zero. So there is a test that checks for that. I am checking to see if there is data waiting or if the touch count has been set if either of those things has taken place then I set that register to zero to clean that. Because I collected the touch count prior to resetting the register to zero I am able to check the count. Setting the register to zero has no effect on the registers that store the data. It is simply a marker for me to use to tell if the display has been touched or not.
What I am thinking is the verbiage they have used in the data sheet is not ideal. I am thinking that the status simply means that something has changed and I should only change what is getting returned if the status has been set to a one.
So the status can be a 1 and the touch count a zero and that would mean your finger has left the display. While you finger is on the display if the coordinates have not changed at all the status would be set to a zero and I should keep on returning the last data that was collected and not changing the state to released. I would only change the state to released if the status is set and there is no touch count.
This is how I am thinking the behavior might be for the driver.
now there's something wrong in rgb_bus.c which doesn't allow me to compile:
_bus.c
/home/tecdroid/git/lvgl_micropython/ext_mod/lcd_bus/esp32_src/rgb_bus.c: In function 'rgb_bus_trans_done_cb':
/home/tecdroid/git/lvgl_micropython/ext_mod/lcd_bus/esp32_src/rgb_bus.c:55:5: error: parameter 'callbacks' is initialized
55 | esp_lcd_rgb_panel_event_callbacks_t callbacks = { .on_vsync = rgb_bus_trans_done_cb };
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/tecdroid/git/lvgl_micropython/ext_mod/lcd_bus/esp32_src/rgb_bus.c:67:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
67 | {
| ^
/home/tecdroid/git/lvgl_micropython/ext_mod/lcd_bus/esp32_src/rgb_bus.c:226:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
226 | {
| ^
/home/tecdroid/git/lvgl_micropython/ext_mod/lcd_bus/esp32_src/rgb_bus.c:234:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
234 | {
| ^
/home/tecdroid/git/lvgl_micropython/ext_mod/lcd_bus/esp32_src/rgb_bus.c:243:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
243 | {
| ^
/home/tecdroid/git/lvgl_micropython/ext_mod/lcd_bus/esp32_src/rgb_bus.c:252:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
252 | {
| ^
/home/tecdroid/git/lvgl_micropython/ext_mod/lcd_bus/esp32_src/rgb_bus.c:276:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
276 | {
| ^
/home/tecdroid/git/lvgl_micropython/ext_mod/lcd_bus/esp32_src/rgb_bus.c:354:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
354 | {
| ^
/home/tecdroid/git/lvgl_micropython/ext_mod/lcd_bus/esp32_src/rgb_bus.c:440:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
440 | {
| ^
/home/tecdroid/git/lvgl_micropython/ext_mod/lcd_bus/esp32_src/rgb_bus.c:447:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
447 | {
| ^
/home/tecdroid/git/lvgl_micropython/ext_mod/lcd_bus/esp32_src/rgb_bus.c:484:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
484 | {
| ^
/home/tecdroid/git/lvgl_micropython/ext_mod/lcd_bus/esp32_src/rgb_bus.c:501:5: error: parameter 'mp_lcd_rgb_bus_type' is initialized
501 | MP_DEFINE_CONST_OBJ_TYPE(
| ^~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/tecdroid/git/lvgl_micropython/ext_mod/lcd_bus/lcd_types.h:7,
from /home/tecdroid/git/lvgl_micropython/ext_mod/lcd_bus/esp32_src/rgb_bus.c:6:
/home/tecdroid/git/lvgl_micropython/ext_mod/lcd_bus/esp32_src/rgb_bus.c:505:19: error: 'mp_lcd_rgb_bus_make_new' undeclared (first use in this function); did you mean 'mp_lcd_rgb_bus_type'?
505 | make_new, mp_lcd_rgb_bus_make_new,
| ^~~~~~~~~~~~~~~~~~~~~~~
/home/tecdroid/git/lvgl_micropython/lib/micropython/py/obj.h:785:44: note: in definition of macro 'MP_DEFINE_CONST_OBJ_TYPE_EXPAND'
785 | #define MP_DEFINE_CONST_OBJ_TYPE_EXPAND(x) x
| ^
/home/tecdroid/git/lvgl_micropython/lib/micropython/py/obj.h:789:179: note: in expansion of macro 'MP_DEFINE_CONST_OBJ_TYPE_NARGS_2'
789 | #define MP_DEFINE_CONST_OBJ_TYPE_NARGS(_1, _2, _3, _4, _5, _6, _7, _8, _9, _10, _11, _12, _13, _14, _15, _16, _17, _18, _19, _20, _21, _22, _23, _24, _25, _26, _27, _28, N, ...) MP_DEFINE_CONST_OBJ_TYPE_NARGS_##N
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/tecdroid/git/lvgl_micropython/ext_mod/lcd_bus/esp32_src/rgb_bus.c:501:5: note: in expansion of macro 'MP_DEFINE_CONST_OBJ_TYPE'
501 | MP_DEFINE_CONST_OBJ_TYPE(
| ^~~~~~~~~~~~~~~~~~~~~~~~
/home/tecdroid/git/lvgl_micropython/ext_mod/lcd_bus/esp32_src/rgb_bus.c:505:19: note: each undeclared identifier is reported only once for each function it appears in
505 | make_new, mp_lcd_rgb_bus_make_new,
| ^~~~~~~~~~~~~~~~~~~~~~~
/home/tecdroid/git/lvgl_micropython/lib/micropython/py/obj.h:785:44: note: in definition of macro 'MP_DEFINE_CONST_OBJ_TYPE_EXPAND'
785 | #define MP_DEFINE_CONST_OBJ_TYPE_EXPAND(x) x
| ^
/home/tecdroid/git/lvgl_micropython/lib/micropython/py/obj.h:789:179: note: in expansion of macro 'MP_DEFINE_CONST_OBJ_TYPE_NARGS_2'
789 | #define MP_DEFINE_CONST_OBJ_TYPE_NARGS(_1, _2, _3, _4, _5, _6, _7, _8, _9, _10, _11, _12, _13, _14, _15, _16, _17, _18, _19, _20, _21, _22, _23, _24, _25, _26, _27, _28, N, ...) MP_DEFINE_CONST_OBJ_TYPE_NARGS_##N
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/tecdroid/git/lvgl_micropython/ext_mod/lcd_bus/esp32_src/rgb_bus.c:501:5: note: in expansion of macro 'MP_DEFINE_CONST_OBJ_TYPE'
501 | MP_DEFINE_CONST_OBJ_TYPE(
| ^~~~~~~~~~~~~~~~~~~~~~~~
/home/tecdroid/git/lvgl_micropython/lib/micropython/py/obj.h:759:243: error: non-static initialization of a flexible array member
759 | #define MP_DEFINE_CONST_OBJ_TYPE_NARGS_2(_struct_type, _typename, _name, _flags, f1, v1, f2, v2) const _struct_type _typename = { .base = { &mp_type_type }, .name = _name, .flags = _flags, .slot_index_##f1 = 1, .slot_index_##f2 = 2, .slots = { v1, v2, } }
| ^
/home/tecdroid/git/lvgl_micropython/lib/micropython/py/obj.h:785:44: note: in definition of macro 'MP_DEFINE_CONST_OBJ_TYPE_EXPAND'
785 | #define MP_DEFINE_CONST_OBJ_TYPE_EXPAND(x) x
| ^
/home/tecdroid/git/lvgl_micropython/lib/micropython/py/obj.h:789:179: note: in expansion of macro 'MP_DEFINE_CONST_OBJ_TYPE_NARGS_2'
789 | #define MP_DEFINE_CONST_OBJ_TYPE_NARGS(_1, _2, _3, _4, _5, _6, _7, _8, _9, _10, _11, _12, _13, _14, _15, _16, _17, _18, _19, _20, _21, _22, _23, _24, _25, _26, _27, _28, N, ...) MP_DEFINE_CONST_OBJ_TYPE_NARGS_##N
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/tecdroid/git/lvgl_micropython/lib/micropython/py/obj.h:798:71: note: in expansion of macro 'MP_DEFINE_CONST_OBJ_TYPE_NARGS'
798 | #define MP_DEFINE_CONST_OBJ_TYPE(...) MP_DEFINE_CONST_OBJ_TYPE_EXPAND(MP_DEFINE_CONST_OBJ_TYPE_NARGS(__VA_ARGS__, _INV, 12, _INV, 11, _INV, 10, _INV, 9, _INV, 8, _INV, 7, _INV, 6, _INV, 5, _INV, 4, _INV, 3, _INV, 2, _INV, 1, _INV, 0)(mp_obj_type_t, __VA_ARGS__))
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/tecdroid/git/lvgl_micropython/ext_mod/lcd_bus/esp32_src/rgb_bus.c:501:5: note: in expansion of macro 'MP_DEFINE_CONST_OBJ_TYPE'
501 | MP_DEFINE_CONST_OBJ_TYPE(
| ^~~~~~~~~~~~~~~~~~~~~~~~
/home/tecdroid/git/lvgl_micropython/lib/micropython/py/obj.h:759:243: note: (near initialization for 'mp_lcd_rgb_bus_type')
759 | #define MP_DEFINE_CONST_OBJ_TYPE_NARGS_2(_struct_type, _typename, _name, _flags, f1, v1, f2, v2) const _struct_type _typename = { .base = { &mp_type_type }, .name = _name, .flags = _flags, .slot_index_##f1 = 1, .slot_index_##f2 = 2, .slots = { v1, v2, } }
| ^
/home/tecdroid/git/lvgl_micropython/lib/micropython/py/obj.h:785:44: note: in definition of macro 'MP_DEFINE_CONST_OBJ_TYPE_EXPAND'
785 | #define MP_DEFINE_CONST_OBJ_TYPE_EXPAND(x) x
| ^
/home/tecdroid/git/lvgl_micropython/lib/micropython/py/obj.h:789:179: note: in expansion of macro 'MP_DEFINE_CONST_OBJ_TYPE_NARGS_2'
789 | #define MP_DEFINE_CONST_OBJ_TYPE_NARGS(_1, _2, _3, _4, _5, _6, _7, _8, _9, _10, _11, _12, _13, _14, _15, _16, _17, _18, _19, _20, _21, _22, _23, _24, _25, _26, _27, _28, N, ...) MP_DEFINE_CONST_OBJ_TYPE_NARGS_##N
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/tecdroid/git/lvgl_micropython/lib/micropython/py/obj.h:798:71: note: in expansion of macro 'MP_DEFINE_CONST_OBJ_TYPE_NARGS'
798 | #define MP_DEFINE_CONST_OBJ_TYPE(...) MP_DEFINE_CONST_OBJ_TYPE_EXPAND(MP_DEFINE_CONST_OBJ_TYPE_NARGS(__VA_ARGS__, _INV, 12, _INV, 11, _INV, 10, _INV, 9, _INV, 8, _INV, 7, _INV, 6, _INV, 5, _INV, 4, _INV, 3, _INV, 2, _INV, 1, _INV, 0)(mp_obj_type_t, __VA_ARGS__))
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/tecdroid/git/lvgl_micropython/ext_mod/lcd_bus/esp32_src/rgb_bus.c:501:5: note: in expansion of macro 'MP_DEFINE_CONST_OBJ_TYPE'
501 | MP_DEFINE_CONST_OBJ_TYPE(
| ^~~~~~~~~~~~~~~~~~~~~~~~
/home/tecdroid/git/lvgl_micropython/ext_mod/lcd_bus/esp32_src/rgb_bus.c:54:17: error: old-style parameter declarations in prototyped function definition
54 | static bool rgb_bus_trans_done_cb(esp_lcd_panel_handle_t panel, const esp_lcd_rgb_panel_event_data_t *event_data, void *user_data)
| ^~~~~~~~~~~~~~~~~~~~~
/home/tecdroid/git/lvgl_micropython/ext_mod/lcd_bus/esp32_src/rgb_bus.c:512: error: expected '{' at end of input
/home/tecdroid/git/lvgl_micropython/ext_mod/lcd_bus/esp32_src/rgb_bus.c:501:5: error: no return statement in function returning non-void [-Werror=return-type]
501 | MP_DEFINE_CONST_OBJ_TYPE(
| ^~~~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
[1288/1877] Building C object esp-idf/main_esp32s3/CMakeFiles/__idf_main_esp32s3.dir/home/tecdroid/git/lvgl_micropython/ext_mod/lcd_bus/esp32_src/i80_bus.c.obj
[1289/1877] Building C object esp-idf/main_esp32s3/CMakeFiles/__idf_main_esp32s3.dir/home/tecdroid/git/lvgl_micropython/ext_mod/lcd_bus/modlcd_bus.c.obj
[1290/1877] Building C object esp-idf/main_esp32s3/CMakeFiles/__idf_main_esp32s3.dir/home/tecdroid/git/lvgl_micropython/lib/micropython/lib/oofatfs/ff.c.obj
[1291/1877] Building C object esp-idf/main_esp32s3/CMakeFiles/__idf_main_esp32s3.dir/__/__/frozen_content.c.obj
[1292/1877] Building C object esp-idf/main_esp32s3/CMakeFiles/__idf_main_esp32s3.dir/home/tecdroid/git/lvgl_micropython/lib/lvgl/src/core/lv_obj_id_builtin.c.obj
[1293/1877] Building C object esp-idf/main_esp32s3/CMakeFiles/__idf_main_esp32s3.dir/home/tecdroid/git/lvgl_micropython/lib/lvgl/src/core/lv_obj_class.c.obj
[1294/1877] Building C object esp-idf/main_esp32s3/CMakeFiles/__idf_main_esp32s3.dir/__/modespnow.c.obj
[1295/1877] Building C object esp-idf/main_esp32s3/CMakeFiles/__idf_main_esp32s3.dir/home/tecdroid/git/lvgl_micropython/lib/lvgl/src/core/lv_group.c.obj
[1296/1877] Building C object esp-idf/main_esp32s3/CMakeFiles/__idf_main_esp32s3.dir/home/tecdroid/git/lvgl_micropython/lib/lvgl/src/core/lv_obj_event.c.obj
[1297/1877] Building C object esp-idf/main_esp32s3/CMakeFiles/__idf_main_esp32s3.dir/home/tecdroid/git/lvgl_micropython/lib/lvgl/src/core/lv_obj_draw.c.obj
[1298/1877] Building C object esp-idf/main_esp32s3/CMakeFiles/__idf_main_esp32s3.dir/home/tecdroid/git/lvgl_micropython/lib/lvgl/src/core/lv_obj.c.obj
[1299/1877] Building C object esp-idf/main_esp32s3/CMakeFiles/__idf_main_esp32s3.dir/home/tecdroid/git/lvgl_micropython/lib/micropython/lib/littlefs/lfs2.c.obj
[1300/1877] Building C object esp-idf/main_esp32s3/CMakeFiles/__idf_main_esp32s3.dir/__/__/lv_mp.c.obj
ninja: build stopped: subcommand failed.
ninja failed with exit code 1, output of the command is in the /home/tecdroid/git/lvgl_micropython/lib/micropython/ports/esp32/build-ESP32_GENERIC_S3-SPIRAM_OCT/log/idf_py_stderr_output_192825 and /home/tecdroid/git/lvgl_micropython/lib/micropython/ports/esp32/build-ESP32_GENERIC_S3-SPIRAM_OCT/log/idf_py_stdout_output_192825
-e See https://github.com/micropython/micropython/wiki/Build-Troubleshooting
make: *** [Makefile:66: all] Fehler 1
make: Verzeichnis „/home/tecdroid/git/lvgl_micropython/lib/micropython/ports/esp32“ wird verlassen
just found that you pushed an rgb_bus update in between which didn't compile. a9f26c10885d4e1a2332cc1d31fc8f329615a1e9 compiles but doesn't have any effect on the behavior
I modified gt911.py a little.
def _get_coords(self):
self._i2c.read_mem(_STATUS_REG, buf=self._mv[:1])
touch_cnt = self._buf[0] & 0x0F
status = self._buf[0] & 0x80
if not status:
return self.__last_state, self.__x, self.__y
...
this seems to work although I'm not shure if that fires multiple RELEASED events..
when you press and hold the screen you should see multiple pressed events and when you release it you should see a stream of released events.
when I say events I am talking about the events comming from the indev driver not the events getting triggered in LVGL.
Well, basically, GT911 driver does not fire events but replies the current status. LVGL is then able to intereprete status changes. (at least, to my current understanding.. still reading through the code..)
The buffer status flag in 0x814e is low as long as there is no valid data to read. This doesn't mean that there has happened nothing. It just tells you that the chip isn't currently ready to be read.
So I'd suggest __get_coords() to do the following:
by the way, what does bit 4 mean on status register? isn't that for "something has been touched" ? GT911 datasheet doesn't describe those things deeply.. or I'm -again- too stupid to find this..
I am thinking the same thing as well I will update the driver to work in that manner.
bits 0 through 3 is the touch count and 4, 5 and 6 deal with specialty modes like gestures and soft buttons.
I just pushed some changes hopefully it will take care of the problems. Give it a shot and lemme know.
this works great :) I'd like to do some experiment with some more widgets and will close the issue then
FANTASTIC!!! That is what I like to hear.
Took a bit to nail down the exact issue. With both of us sharing thought on it we figured out what the cause was and we were able to fix it. 2 brains are better than one.
Well, that's true :) feels good working that way ... and I learned much more about the internals of lvgl and micropython than any tutorial could give.
However. There is one thing i found with sliders. They only react after the screen has been removed. To my mind, that's a completely different problem to this issue so I will open a new one to help keeping things clean.
For me, this issue is done :)
Sorry for bothering you again..
Firstly, my current code:
Now the problem: Everytime, I press the button, my click counter counts at least two upwards (even when I use RELEASED). When I keep my finger on the button, it starts counting until i release the button).
I'd expect the event to fire only once when the button is released. So what's wrong here?
Also, clicking the Shift (ABC) on the screen-keyboard, it changes to high only for a fraction of a second and then back to decapitalized letters.