Lilygo T-deck?

[asherevan]

Does anyone have any code for using this with the Lilygo T-deck?

[kdschlosser]

There are examples of how to use the library in the README.md file.

[asherevan]

I mean specifically for the T-deck. I don’t see any examples for the hardware that the T-deck uses.

[kdschlosser]

Another user asked for help with one of those things I believe. Take a look in the closed issues to see if there is something in there.

[asherevan]

I couldn’t find anything.

[kdschlosser]

shoot me a link to the manufacturers website for the display and I will key something up for you right quick.

[asherevan]

This should be it: https://lilygo.cc/products/t-deck?variant=43087936520373

…

On Mon, Feb 10, 2025 at 9:37 PM Kevin Schlosser ***@***.***> wrote: shoot me a link to the manufacturers website for the display and I will key something up for you right quick. — Reply to this email directly, view it on GitHub <#297 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BDWNJASMPHTFDYYNWSHFPQT2PF5B7AVCNFSM6AAAAABW3X37HCVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTEMJTGQZDCNA> . You are receiving this because you authored the thread.Message ID: <lvgl-micropython/lvgl_micropython/repo-discussions/297/comments/12134214@ github.com>

[kdschlosser]

OK you have to give me some time. There is a lot of hardware that I am going to have to write drivers for so everything will work out of the box.

[asherevan]

Ok, no problem! Thanks for your work on this!

[kdschlosser]

OK so here is the skinny on this. That device actually has 2 ESP32's onboard, one is an S3 and the other is a C3. The C3 handles only the keys for the keyboard. The connection between the 2 ESP32's is I2C which is a bit of a speed bump. MicroPython only has I2C master mode added to it and that means I am going to need to overhaul the I2C driver that is built into MicroPython so it also supports slave mode. I have been needing to write a new I2C driver and I have been putting it off. So now would be the time for me to do it. It is going to take a bit of time to get it done. It is going to be challenging because of how MicroPython has the driver written and extending the driver is not going to be the easiest thing in the world to do. There is a lot of VooDoo magic code in MicroPython's handling of hardware drivers so it is going to take some time to get all of the kinks ironed out of it. I personally do not really care for how things were written with respect to hardware access in MicroPython. It is complicated and there is no documentation written for it.

You are going to have to be patient in both the time until I get a test version and also through the testing process. Have you learned how to access each of the ESP32's to be able to flash them? If you have not now would be the time to learn how to do this.

There is a very large amount of "extras" in the form of additional hardware on that device. I can make the display work easily but of you want everything else to function I am going to have to invest a decent chunk of time to write custom drivers for the extra bits and pieces. some of them I will be able to get it done in Python code and others I am going to have to write hardware bindings in C code and expose portions to the Python side of things.

[asherevan]

I do know how to flash to the main ESP32-S3 but do we need to flash a new firmware to the keyboard ESP32-C3?

[kdschlosser]

It doesn't really explain how to read the keyboard data from the second esp32.

[asherevan]

You should be able to just read the data from the I2C bus.

[kdschlosser]

OK I just added it.

How to compile is located here

I didn't include use instructions yet as I wanted to get past the compiling part first. Give it a try and paste back any exact errors you get. Please do not make any changes to fix any errors unless you plan on fixing the errors and submitting a PR.

[kdschlosser]

OH.. The only thing that I have not added is the microphone. I need to write a user c module for that which I don't have the time to do at the moment.

[asherevan]

I followed the instructions but it returned this error:

collecting MicroPython 1.24.1
Submodule 'lib/micropython' (https://github.com/micropython/micropython) registered for path 'lib/micropython'
fatal: destination path '/home/ubuntu/lvgl_micropython/lib/micropython' already exists and is not an empty directory.
fatal: clone of 'https://github.com/micropython/micropython' into submodule path '/home/ubuntu/lvgl_micropython/lib/micropython' failed
Failed to clone 'lib/micropython'. Retry scheduled
fatal: destination path '/home/ubuntu/lvgl_micropython/lib/micropython' already exists and is not an empty directory.
fatal: clone of 'https://github.com/micropython/micropython' into submodule path '/home/ubuntu/lvgl_micropython/lib/micropython' failed
Failed to clone 'lib/micropython' a second time, aborting
Submodule 'lib/micropython' (https://github.com/micropython/micropython) registered for path 'lib/micropython'
fatal: destination path '/home/ubuntu/lvgl_micropython/lib/micropython' already exists and is not an empty directory.
fatal: clone of 'https://github.com/micropython/micropython' into submodule path '/home/ubuntu/lvgl_micropython/lib/micropython' failed
Failed to clone 'lib/micropython'. Retry scheduled
fatal: destination path '/home/ubuntu/lvgl_micropython/lib/micropython' already exists and is not an empty directory.
fatal: clone of 'https://github.com/micropython/micropython' into submodule path '/home/ubuntu/lvgl_micropython/lib/micropython' failed
Failed to clone 'lib/micropython' a second time, aborting

[kdschlosser]

OK I will look into it to see what is going on.

[kdschlosser]

OK i just pushed a commit that fixes the problem. It does compile properly you have to flash it and give it a test run to see if it works.

How you are going to test it is you would create a script named 'main.py'm and in that script you put

import display

# your UI code here

couple of things to note...

• display.display is the display driver
• display.touch is the touchscreen driver
• display.keyboard is the keyboard driver
• display.tball is the trackball driver
• display.lora is the lora driver
• display.pwr_button is the power button driver

some of the drivers you are able to view in the custom board path There are things you might need to do for those drivers to work properly (lora and power button) so make sure to read the source files for the drivers.

[asherevan]

It successfully compiled and uploaded to the board, but the REPL will not show.

[kdschlosser]

are you connecting using CDC?

[asherevan]

I am connecting through the USB-C port.

[kdschlosser]

and do you have the CDC drivers installed? The serial drivers? Is there a serial port available for the MCU..

The other thing is I believe there is something goofy you have to do to change the boot mode. It might be holding in on the trackball to get it to change boot modes. I know nothing about how to use that board But you should at the very least be getting a repl prompt.

[asherevan]

Yes. It was working before the update and I actually got it working once after the update, but it hasn’t worked since.

[asherevan]

Do you have any ideas?

[asherevan]

I got the drivers onto the T-Deck (not in the firmware, just as files) but on the task handler initialization it returns this error:

Traceback (most recent call last):
File "task_handler.py", line 136, in _task_handler
File "keypad_framework.py", line 67, in _read
TypeError: 'int' object isn't iterable

[kdschlosser]

so lets take a look at line 67 in keypad_framework. The keypad framework has not been tested as of yet so there are bound to be some issues that need to be hammered out. Lets take a look and se what is going on with it.

The framework files are located in api_drivers/py_api_drivers/frozen These are the base classes for the different drivers like the display and pointer drivers as well as the keypad driver. These are written in Python and they are baked into the firmware.

[kdschlosser]

OK so what is being expected from the _get_key method of a driver is None or state, key I believe the driver I wrote for the TDeck only returns None or the key that is pressed. Pretty simple to add the state to that.

[kdschlosser]

I just pushed a commit that should fix the keypad driver.

[kdschlosser]

I just noticed that you are from Tuscon, AZ. My sister in law lives there and a really good friend of mine that I have known for 40 years lives in Phoenix... I am in Colorado, 45 minutes west of Denver

[asherevan]

I think I have found another problem with the keypad framework.
After checking if the key is none, it is trying to continue and extract two values from the NoneType object. It should instead exit the function.

[kdschlosser]

You are correct. I just fixed it.

[kdschlosser]

i just updated it again with better code.

[asherevan]

Thank you, but it still doesn’t work. The keyboard never returns any value, and the trackball (after modifying it to make it return the correct values) just crashes the device.

[kdschlosser]

I do not know if the C3 has had anything flashed to it. It might not have so it's not sending anything.

[asherevan]

No. It is flashed. The keyboard was working correctly before with a program I had written (not for LVGL)

[asherevan]

It will correctly return the keyboard letter if you use:

i2c_bus.readfrom(0x55, 1).decode()

[kdschlosser]

what are the parameters you are passing to I2C.Bus?

[asherevan]

Sorry. I think when I said it works with i2c_bus.readfrom(0x55, 1).decode() I had mistakenly set i2c_bus to machine.SoftI2C
Sorry.

[kdschlosser]

I don't recall offhand is there is anything that is using the I2C other then the keyboard. Do you know if there is anything else using it?

[asherevan]

The microphone, speaker, and touchscreen also use it.

[kdschlosser]

The microphone and speaker use I2S not I2C.

Does your touchscreen work?

[asherevan]

Oh. Ok. Yes. The touchscreen does work.

[kdschlosser]

adding keyboardread = to the read command doesn't change anything. it's not being used for one but the data that is returned is going to be None because the buf parameter is being used when making the function call. Nothing gets returned because the buffer that has been passed to buf is what gets filled with the data.

This is the code right after I fixed setting key to None when I needed to be returning None
https://github.com/lvgl-micropython/lvgl_micropython/blob/fd18e5ea58083b80931cf7227e3deab7bd05d86e/display_configs/LilyGo-TDeck/keyboard_s3.py

That commit was made over a week ago.

[asherevan]

Sorry! I think the problem before was that the task handler was reading from it constantly and so when I tried to read from it, there was no data. (And when I disabled the task handler, it worked to read from it from the REPL) Do you know how I should test it in the GUI?

[kdschlosser]

my suggestion is to create a text edit box and see if the input works. Remember you are going to need to click on it using the touch to put it into focus before you type anything in.

[asherevan]

I did that but nothing seems to be typed.

[asherevan]

Any ideas?