using lgfx::v1::i2c::transaction*() methods in non-LovyanGFX external driver - example?

[mhaberler]

I have a lovyan LVGL app which works great - except when an external RFID2 driver tramples over LovyanGFX I2C transactions in progress by say the touch driver code - as it is not aware of LovyanGFX I2C transaction locks

does rewriting the this driver's I2C ops to use lgfx::v1::i2c::transaction*() make sense?

or is there a simpler way to acquire/release the LovyanGFX i2c transaction locks?

has anybody done this before and is willing to share a code fragment?

thanks in advance

Michael

[tobozo]

is lvgl polling the touch from a task?

if so, maybe a semaphore logic shared between the touchpad_read() and the rfid2_read() could prevent double-accessing the bus

[mhaberler]

that is the case, but it does not change the situation

I think it is an incarnation of espressif/arduino-esp32#8056

[mhaberler]

that bug aside - do you think it actually makes sense to use lgfx::v1::i2c::* code for non - Lovyan drivers?

[tobozo]

sharing the touch _bus_instance between lvgl and the i2c sensor makes more sense than using a conflicting and redundant Wire(SDA,SCL), but keep in mind that lgfx::Bus_I2C isn't available for all platforms

[mhaberler]

appreciated, thanks!

[mhaberler]

actually the problem was more mundane..

the sensor is connected to the second i2c bus (red port on M5StackCoreS3) and could not have possibly interfered with touch on internal i2c

however, to supply power to the red port, the Power_Class.setExtPower needs to be called to turn on the red port 5V supply

there is no method to handle the AXP2101 in the CoreS3 short of using M5Unified
the AXP2101 settings survive resets - they do not survive power off
so if you flash an M5Unified build and then a LovyanGFX build without turning off the power, things work - until a power cycle

I rest my case..

[ammaree]

We have a different problem situation that have come up.

We have a dedicated I2C task handling communications with 5~8 I2C devices, primarily readings sensors. The I2C task provides a high level interface to the application supporting basic read and write operations to be combined with task events, asynchronous handler calls, delays, on-the-fly modify (mask AND / OR operations), priority (add to front/back of queue), and block (wait till completion) to provide functionality such as:
WDRC - Write[Data] - Delay[Period] - Read[Data] - Call[Handler]
WERC - Write[Data] - Event[Mask] - Read[Data] - Call[Handler]
WRMW_PBD - Write[RegAd] - Read[Data] - Modify[AND/OR masks] - Write[RegAd+Modified Data] with Priority, Block & Debug

Sensor reading are scheduled by a sensor reading / logging task or triggered by an IRQ for things like meter pulse counters.
Up to now we have used LGFX primarily with non-touch displays, using buttons as inputs.
We are now trying to move towards capacitive touch interfaces but have found that most/all use I2C touch controllers.

Our I2C task is built using the new I2C master driver and causes conflict with the LGFX use of the old (to be discontinued) I2C driver. In order to get our I2C task to co-exist with LGFX we need to separate the I2C support LGFX requires and replace it with basic high level primitives that will 1) "discover", identify and configure the I2C device and 2) perform the required read and write operations to support touch functionality.

Where we need help is in identifying the simplest possible mechanism to replace LGFX I2C support with our high level I2C primitives.

All assistance will be highly appreciated.

[tobozo]

if you want that dedicated I2C task to also handle the readings from the touch, you'll need a custom bus class (derivated from lgfx::IBus) where the I2C task logic can be handled.

you'll also need a custom version of the touch driver to link to that custom bus instead of lgfx::i2c.

[ammaree]

Any pointer to the files where these can be found. I am 99.5% C focussed, very little C++but would like to give it a try… On 24/02/13, 20:14, "tobozo" ***@***.******@***.***>> wrote: if you want that dedicated I2C task to also handle the readings from the touch, you'll need a custom bus class (derivated from lgfx::IBus) where the I2C task logic can be handled. you'll also need a custom version of the touch driver to link to that custom bus instead of lgfx::i2c. — Reply to this email directly, view it on GitHub<#524 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAYT7GGBG2UAEMDCWDMAO6LYTOUQPAVCNFSM6AAAAABDDOGDXOVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DINJXGI2DC>. You are receiving this because you commented.Message ID: ***@***.***>

[tobozo]

I'm afraid I can't explain more without pasting quantities of code which I'd need to write first :-)

Maybe using an esp-idf touch driver would me more C-focused? That would kick lgfx::i2c out of the problem, LVGL doesn't require a LGFX driver to manage the touchpad anyway, so any driver can do.

[ammaree]

Looking at this problem again, but from a different angle.

The old/original ESp-IDF driver has been marked as to be discontinued...
Our I2C task has wrapped all the required APIs from the new I2C master driver, part of ESP-IDF v5.1 onwards I think, in order to redirect these API calls to I2C task APIs.

Since the old I2C support is to be discontinued, are there any plan to the use of the old I2C driver with the new, and much improved, I2C master driver.

Should this be in the pipeline I can maybe hang back a bit longer since LGFX I2C operations will then be transparently using our I2C task functionality....