Error from PSRAM default(?) with LVGL_Micropython on ESP32_S3 #77
Replies: 26 comments 76 replies
-
|
You are not specifying is you are using SPI ram or not.. or If you can provide me with a link to the board you are using I will do the legwork to find out if you are using octal flash and or octal PSRAM The S3 always has PSRAM to my knowledge. I don't believe there is a version of the MCU made without it. From that error if I had to take a guess I would think that you have octal PSRAM |
Beta Was this translation helpful? Give feedback.
-
|
Hey, Thanks for your help, I am using the ESP32-S3FN8 chip, integrated into an M5 Dial development board. (https://shop.m5stack.com/products/m5stack-dial-esp32-s3-smart-rotary-knob-w-1-28-round-touch-screen) As far as I can tell, there is no external PSRAM chip on the board. After reading your response; I've tried building the firmware using a few variations, but I continue to get the same PSRAM error after flashing. From the ESP32_S3 datasheet, it seems that the ESP32_S3FN8 chip doesn't have PSRAM and instead has QUAD SPIRAM, which is why I tried using "BOARD_VARIANT=SPIRAM_QUAD", unfortunately to no avail. Here are the three variations I tried using: Would you be able to provide any guidance on the correct configuration for the internal PSRAM on the ESP32-S3FN8? Or perhaps suggest any further troubleshooting steps I could take? Thanks heaps for your fast and helpful reply. |
Beta Was this translation helpful? Give feedback.
-
|
ok so the ESP32-S3FN8 in fact doesn't have any SPIRAM. so you are correct with that... Issue is you are not going to have a lot of memory left over for use. There is only 384kb of usable memory and a large chunk of that is going to get used up by MicroPython. Then another large chunk is going to get used up with the display driver and loading LVGL. Then you are going to take another memory hit for the frame buffer and depending on the size of the display and how the display is connected to the MCU that could end up being more than what you have available. If I had to take a guess you would be left with something around 80k to 100k of free memory. To put that into perspective. To load a single PNG file that is 32 x 32 in size would use up at a minimum 7,304 bytes of memory and that is not even dealing with the additional overhead of storing objects as python objects. I wouldn't be surprised if it comes close to 10k being used up to load a single 32x32 png file. What display are you working with?... |
Beta Was this translation helpful? Give feedback.
-
The above is the build command you would use. You would need to replace supported display IC's supported touch driver IC's of course if you do not have one of the IC's used you are more then welcome to develop your own driver. |
Beta Was this translation helpful? Give feedback.
-
|
I am using the 240x240px display that came with the M5 Dial; my project is rather simple, I will likely need few, if any images, mostly just a couple different sliders and text-based interfaces, along with the touchscreen and rotary encoder and a very basic serial connection with another MCU, do you think that could make the memory constraints more manageable? That being said though; I am hearing what you're saying about the lack of memory being a likely unmanageable barrier. I would be either writing drivers or integrating the ones I have found from another repo, I'm sure there will be lots more learning to get that working, no matter which strategy I end up taking. I don't mean to overstep the help you've been giving me, but feel I am kinda dancing around just saying what the project actually is; my idea is to have the ESP32 connect to a CNC machine mainboard and send GCODE commands so I can jog the machine around and home it from the touchscreen/rotary encoder. To me, this seems like it could all be achieved with little memory, but I have just more than 0 experience here. I think I will use the commands you've provided to compile and just keep going with this until I hit a memory limitation, or some other barrier; then figure out where I should go from there; I don't think I can add external RAM and I'm not sure how viable switching to an ESP32 with more RAM, while still using the display and rotary encoder from the M5 Dial will be. If all else fails, I imagine I can just make a basic UI by manipulating the framebuffer directly, without LVGL, I have done something similar with Arduinos years ago; though I don't remember it and will definitely need to relearn that process. Of course, this is all not really relevant to the great work you've been doing, so I will keep trying. I really appreciate your continued and exhaustive help. Thanks heaps |
Beta Was this translation helpful? Give feedback.
-
|
I am trying to get a better understanding of what you are wanting to do and to see if it is even going to be possible for ya to do. If you told me that you are using that MCU with a 640x480 RGB display I would tell you there is no way it will run and that you need to use a different MCU. Without knowing the connection type the display is using it is going to be hard to tell you if it will work or not. So a 240 x 240 display connected using 16 lanes that is RGB you would need 230,400 bytes of RAM just for the frame buffers. I am going to say.. It;'s not going to work because there is not enough memory. The MicroPython stack consumes a decent amount of RAM and once the frame buffers are added there isn't anything left. If you have a 240x240 display that is 16 bit color and connected using SPI the frame buffers are going to take up 23,040 bytes of memory which will leave you with enough ram so long as you are not doing anything overly complicated. I did give you the build command so you can compile it to see if it works. What sucks is spending a heap of time trying to get something to work only to find out in the end it's not going to. Not having the PSRAM put a huge limitation on what can be done. If you didn't use MicroPython there would be a hell of a lot less overhead and that would free up a lot of memory... I just don't want to see you wasting more time on something that ends up not working out for ya. It is really frustrating when that happens. I don't want you to continue to bang your head against the wall, I want you to see some forward progress. There is a problem upstream in MicroPython that needs to be addressed. SPIRAM is still trying to be used even tho the SPIRAM board variant is not being used. That is a bug in the code and\ I am going to open an issue upstream for it. |
Beta Was this translation helpful? Give feedback.
-
|
I appreciate your continued support so much, you've really given my project a lot of expertise that I couldn't find elsewhere. The display is connected using SPI, so the memory limitations may be less strict, but I have had some issue getting the compiled firmware working on the board, which gives me some pause about whether it's right to have you continue working on my problem when I might reach a limitation and be unable to continue with it anyway, while I am gaining experience in micropython and LVGL, as well as general embedded systems, I do feel bad about the prospect of having you spend even more time helping me, only for me to end up needing to go another direction anyway. For context at least; when I run the new compilation command; all runs fine and when I flash it to the board, I no longer get any PSRAM errors, which is a good sign; but the board doesn't have a functional REPL and I can't run scripts using mpremote or AMPY. Again, I really appreciate you going above and beyond to help me, explaining things in a way that I can understand and being honest about the potential limitations of my strategy. I think it's time for me to consider C or writing direct to framebuffer; a part of the justification for this project was to get more comfortable and familiar with micropython and python in general, so I have been reluctant to change to C. I hope you don't feel obligated to continue replying, I don't wish for you to spend anymore of your time trying to help me, at least not until I have an issue more directly relevant to the work you've been doing with this script. |
Beta Was this translation helpful? Give feedback.
-
|
it doesn't bother me at all to help. I enjoy doing it. Just to let you know I did open up an issue at MicroPython's repo for the SPIRAM being set up when it is not specified for a board variant. The build command I gave you should have overridden the config options that were set by MicroPython. This should have turned off the setup of SPIRAM. Now that I know exactly what you are working with for a device I can tell you that you should be OK memory wise so long as the GUI isn't crazy complicated. Even if it is crazy complicated if you manage things right and release objects from memory that are not actively being displayed you will be fine. The display being connected using SPI allows for a much smaller memory footprint and you can also make use of DMA memory and double buffering which greatly improves the performance by allowing one buffer to be written to the display while LVGL is filling the second one. DMA memory allows the data to be transferred without the processor needing to be used so it frees up the processor to do other things like loading the second frame buffer... Trust me when I say we will get it up and running for ya. There are far too many different boards that are made that have displays attached for me to include a script that will get you up and running right away without needing to set things up.... You should have opened an issue for your problem instead of opening a discussion which is fine, but also in the discussion section there is a topic for providing scripts that are board specific. This will take time to populate and if you allow me to help you get up and running I will then add the script for your board to that topic. This will help anyone else in the future should they have the same board and want a quick jump to get up and running. I am more than happy to assist you further if you want to do that. The choice is yours. The lack of a REPL is an easy fix as well. I have already coded in the solution for that... so new build command... give that a go and see if it takes care of your issue... do you know what display IC your board is using? touch IC as well.... |
Beta Was this translation helpful? Give feedback.
-
|
Should I open an issue now then? I'm a bit illiterate when it comes to github, so I'm sorry about that. It would be cool to make this easier for anyone else who ends up wanting to do the same thing in the future, I can imagine how straightforward your script would make the process of compiling for a board that's fully supported. The touch sensor is the "FT3267" and the display is the "GC9A01", there is a micropython repo(github.com/mattytrentini/micropython/) that has a writeup and all the requisite drivers. Presumably I will need to make some sort of intermediary between that display driver and the LVGL bindings. Your new command worked, I now have a functional REPL and I've started trying to get the driver working (just on it's own first, not worrying about interfacing with LVGL yet). I would like some advice with whether trying to get the GC9A01 driver that already exists working makes sense, and whether such a driver is likely to work without more effort than it's worth; I expect this requires investigation, which I'm not asking you to do. I've had a look at the example you provide using the "st7796" display but struggle to decipher how my approach needs to differ, given the different displays. In any case I'm gonna sleep on it; didn't want to leave you any longer without a response, but I haven't really hit a wall yet, so might end up responding with more progress, if I manage any. |
Beta Was this translation helpful? Give feedback.
-
|
I managed to get Russ Hughes gc9a01py driver working, with the touchscreen using the I2C implementation from another repo, albeit very slowly, then I realized you already have a driver for the gc9a01, so I have pivoted to trying to get that working. I took your driver_use_example.py and changed the pin assignments, frequency and resolution, then I changed the script to import the "gc9a01" driver instead of the "st7796" driver and exchanged every instance of "st7796" with "gc9a01", when I try to execute this script on my board, I get the error: "TypeError: 'spi_bus' argument required". This error has me a bit confused, I gather I need an spi_bus argument in display_bus but merely initializing the SPI bus using your modified SPI implementation doesn't seem like the appropriate strategy. I would really appreciate any help, as I have hit a wall and don't know where to go from here. This is the command I used to build the firmware: "python3 make.py esp32 clean submodules mpy_cross BOARD=ESP32_GENERIC_S3 DISPLAY=gc9a01 --usb-otg CONFIG_SPIRAM_TYPE_AUTO=n CONFIG_SPIRAM_MODE_QUAD=n CONFIG_SPIRAM_SPEED_80M=n CONFIG_SPIRAM=n CONFIG_SPIRAM_BOOT_INIT=n CONFIG_SPIRAM_USE_MALLOC=n" Here is the modified "driver_use_example.py" (I had to cut the comments out for the sake of formatting, hopefully I didn't break anything more): |
Beta Was this translation helpful? Give feedback.
-
from micropython import const # NOQA
import lcd_bus # NOQA
import machine # NOQA
_WIDTH = const(240)
_HEIGHT = const(240)
_DC_PIN = const(4)
_MOSI_PIN = const(5)
_MISO_PIN = const(16)
_SCLK_PIN = const(6)
_CS_PIN = const(7)
_FREQ = const(60000000)
_RESET_PIN = const(8)
_POWER_PIN = None
_BACKLIGHT_PIN = const(9)
_OFFSET_X = const(0)
_OFFSET_Y = const(0)
spi_bus = machine.SPI.Bus(
host=1,
sck=_SCLK_PIN,
mosi=_MOSI_PIN,
miso=_MISO_PIN,
)
display_bus = lcd_bus.SPIBus(
spi_bus=spi_bus,
dc=_DC_PIN,
freq=_FREQ,
cs=_CS_PIN,
dc_low_on_data=False,
cs_high_active=False,
)
import gc9a01 # NOQA
import lvgl as lv # NOQA
display = gc9a01.GC9A01(
data_bus=display_bus,
display_width=_WIDTH,
display_height=_HEIGHT,
# we are going to let the driver handle the allocation of the frame buffers
frame_buffer1=None,
frame_buffer2=None,
reset_pin=_RESET_PIN,
reset_state=gc9a01.STATE_HIGH,
power_pin=_POWER_PIN,
power_on_state=gc9a01.STATE_HIGH,
backlight_pin=_BACKLIGHT_PIN,
backlight_on_state=gc9a01.STATE_HIGH,
offset_x=_OFFSET_X,
offset_y=_OFFSET_Y,
color_space=lv.COLOR_FORMAT.RGB565,
rgb565_byte_swap=True
)
display.set_power(True)
display.init()
display.set_backlight(100)
import task_handler # NOQA
th = task_handler.TaskHandler() |
Beta Was this translation helpful? Give feedback.
-
|
That script runs without errors and the backlight turns on, but when I try adding my own LVGL UI (just ripped from the MPY+LVGL examples page) I get no output on the display, just a black screen (with the backlight on). The absence of any errors is making it difficult for me to do any troubleshooting on my own, I tried someone else's LVGL UI from another github discussion and that also resulted in no errors, but no output too. Here's the code for the UI , I appended it to your initialization script and then ran it: Here's the other code I also tried, that I ripped from "#17": slider = lv.slider(screen) label = lv.label(screen) I would really appreciate any help, it seems like I'm close to getting the UI on the display but don't know where to go from here. Thanks for all your help thus far. |
Beta Was this translation helpful? Give feedback.
-
|
I need to see all of the code you are running. |
Beta Was this translation helpful? Give feedback.
-
|
Here is the complete script, apologies for not just sending the whole thing in the first place: |
Beta Was this translation helpful? Give feedback.
-
|
try changing the reset pin to |
Beta Was this translation helpful? Give feedback.
-
|
also do you have a link to who makes the board? I want you to make sure that you have the pin numbers correct. The numbers that are being used are unusual so I want to double check them. |
Beta Was this translation helpful? Give feedback.
-
|
Here is the product page, I got those pins from another repo that was working, so I assume they're correct. |
Beta Was this translation helpful? Give feedback.
-
|
Changing the reset to STATE_LOW has the screen on, it's reversed (horizontally), which I'm sure won't be much hassle to fix and I'm very excited to see my button on the screen! Thank you so much for all your help, I'd best be off to bed, it's 3am; I'll keep working on this tomorrow. |
Beta Was this translation helpful? Give feedback.
-
|
OK if the display is displaying in reverse then we have to change how it is setting up the display. Give me a few to do some research... |
Beta Was this translation helpful? Give feedback.
-
|
OK I just updated the code in the repo. See if that fixes the problem. |
Beta Was this translation helpful? Give feedback.
-
|
That does appear to have fixed the problem! Thank you for all your help in getting this working, I'm excited to have a break from uni so I can get my UI working. Thanks again for your help, I really appreciate all the time and effort you've put into getting this working for me! |
Beta Was this translation helpful? Give feedback.
-
|
no worries m8. glad to have helped and glad to have gotten it going too... |
Beta Was this translation helpful? Give feedback.
-
|
I've been trying to get the touchscreen working now, first I used the code from "#17" and got the touch screen printing the coordinates to the REPL, I figured this would be the hard part done but quickly realized I can't just pass touch events to LVGL directly. Upon going through the display drivers in your repo I noticed (deja vu) that your "ft6x36" driver ostensibly supports the "ft3267" touch IC that my device is using; so I recompiled with that driver included and tried to get that working, I got some error that the driver needs some arguments which I guessed as being the I2C object, then I get an error: Here is the script that gives me the AtttributeError: and here is the script that gives no errors and prints the coordinates to the REPL: |
Beta Was this translation helpful? Give feedback.
-
|
It takes care of everything for you all you need to do is to initialize the touch driver and then touch will work. give me a minute to key out an example for ya. |
Beta Was this translation helpful? Give feedback.
-
from micropython import const # NOQA
import lcd_bus # NOQA
import machine # NOQA
import time
_WIDTH = const(240)
_HEIGHT = const(240)
_DC_PIN = const(4)
_MOSI_PIN = const(5)
_MISO_PIN = const(16)
_SCLK_PIN = const(6)
_CS_PIN = const(7)
_FREQ = const(60000000)
_RESET_PIN = const(8)
_POWER_PIN = None
_BACKLIGHT_PIN = const(9)
_OFFSET_X = const(0)
_OFFSET_Y = const(0)
spi_bus = machine.SPI.Bus(
host=1,
sck=_SCLK_PIN,
mosi=_MOSI_PIN,
miso=_MISO_PIN,
)
display_bus = lcd_bus.SPIBus(
spi_bus=spi_bus,
dc=_DC_PIN,
freq=_FREQ,
cs=_CS_PIN,
dc_low_on_data=False,
cs_high_active=False,
)
import gc9a01 # NOQA
import lvgl as lv # NOQA
display = gc9a01.GC9A01(
data_bus=display_bus,
display_width=_WIDTH,
display_height=_HEIGHT,
# we are going to let the driver handle the allocation of the frame buffers
frame_buffer1=None,
frame_buffer2=None,
reset_pin=_RESET_PIN,
reset_state=gc9a01.STATE_LOW,
power_pin=_POWER_PIN,
power_on_state=gc9a01.STATE_HIGH,
backlight_pin=_BACKLIGHT_PIN,
backlight_on_state=gc9a01.STATE_HIGH,
offset_x=_OFFSET_X,
offset_y=_OFFSET_Y,
color_space=lv.COLOR_FORMAT.RGB565,
rgb565_byte_swap=True
)
display.set_power(True)
display.init()
display.set_backlight(100)
import i2c
import ft6x36
i2c_bus = i2c.I2C.Bus(
host=1,
scl=12,
sda=11
)
touch_i2c = i2c.I2C.Device(
i2c_bus,
dev_id=ft6x36.I2C_ADDR,
reg_bits=ft6x36.BITS
)
indev = ft6x36.FT6x36(touch_i2c)
scr = lv.obj()
btn = lv.button(scr)
btn.align(lv.ALIGN.CENTER, 0, 0)
label = lv.label(btn)
label.set_text('btn')
lv.screen_load(scr)
import task_handler # NOQA
th = task_handler.TaskHandler() |
Beta Was this translation helpful? Give feedback.
-
|
First, I want to say how much I appreciate you providing so much help, I really appreciate it. I tried using that code; 13 seconds(consistently) after I start the script, I get this error: This error is similar to one I was getting when I was playing around with a basic touch script, my solution was to use interrupts to avoid polling the touch driver when an interrupt hadn't been raised; because it seems for some reason that polling was causing the error, though with that script the error presents itself sporadically, whereas when I get the error from the code you've provided, it very consistently happens 13 seconds after running the script (I timed it because I figured if it was consistent it's more likely that i2c isn't connecting at all). Nonetheless, I continued, hoping that i2c was connecting and I would just have to figure out how to address the error after getting touch working, obviously there's no way to determine whether touch is actually working from the script, so I attempted to add an event, this was a bit confusing because I'm not really sure whether this event should be an LVGL event or whether the task_handler should deal with it. I tried both and neither gave me functional touch anyway, but here's one attempt: I tried adding a bunch of print statements to task_handler, i2c, ft6x36 and pointer_framework, but I think that will require recompiling(I will if you think it helpful), as placing them in /lib/ either didn't work like I had hoped, or the script isn't making it into any functions in any of these modules(I doubt this). I have spent quite a lot of time reading other issues and discussions on this github, to no avail, but I tried a few different things, like using a slider instead of a button and implementing the callback differently(I think it was using the task_handler, somehow). The only other thing I can think of is sharing the basic script I wrote while I was waiting for your help getting touch working with LVGL, all it does is displays the most recent touch coordinates and current rotary encoder position in LVGL labels, I'm sure this is of little value, beyond showing that these i2c settings and pin mappings did work with the touchscreen: |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, the touch interrupt is on pin 14. I am not familiar with subclassing, but I've done a bit of research and what you're suggesting makes sense, I will have to learn a bit but I will start looking at it. I was struggling to find where the I2C read is actually happening in your code, obviously just my own inexperience but if I use subclassing; I guess I avoid worrying about that anyway?. If I understand you correctly, I would just be replacing the "_get_coords" function with a modified version of the working code I was using before, then all will just work, assuming the subclassed function returns the appropriate values. Thanks for your help; I'll start figuring out how to approach this. |
Beta Was this translation helpful? Give feedback.
-
|
OK I pushed the changes to the repo. I believe I located the problem. The IC was going to sleep. added the command to send to the IC to stop that from happening. Give it a try and see if the problem is fixed. Just to let you know you can also pass The touch drivers are almost 100% written in Python. The only part that isn't is the I2C connection portion, That is written in C code. I did write a wrapper class around the I2C to make it behave like SPI. I did this because there are touch IC's that depending on how they are wired can accept an I2C connection or an SPI connection. I wanted the touch drivers so they would work without needing to know anything about how the data is being sent to the IC. There is a framework in place that handles all of the input that can happen in LVGL. This framework covers mice, touch screens, keyboards, etc... Here is a link to the base framework. That framework is then subclassed by 4 input type frameworks. You have keypad, encoder, button and pointer. Here is the framework that is specific to the pointer (touch) If you look you will see You see Subclassing is a mechanism that is used so you don't need the same code in multiple places. It eliminates duplicate code which makes things easier to maintain. If there is a problem across all of the drivers I am able to patch them all at once by making a code change in one of the parent classes. Subclassing also gives the ability to override how something works. In the case of the pointers there is a function names |
Beta Was this translation helpful? Give feedback.
-
|
I am more than happy to explain anything you want to know. I am self taught and I didn't have anyone that I could ask. I spent a HUGE amount of time doing the trial and error thing. hundreds of times over and over again trying to do one simple thing to understand how it works. I spent thousands of hours reading.. I gave up asking for help because I found that the majority of programmers have a god complex and they talk down on ya. I do my best to explain everything as much as possible when a question is asked. I don't just hand people the code most times. I will spend the time to key out a full detailed explanation of what is happening and why something needs to be done. I do this to educate so a person knows how it actually works so if they do encounter a problem they have some knowledge that they can use to possibly fix their issue. |
Beta Was this translation helpful? Give feedback.
-
|
I will get started compiling the new firmware now, hopefully that will work, even if I might be able to get it working by subclassing, it's better if this will work for everyone going forwards and not just me. Thank you for the lesson, I had read something online after you mentioned it but I didn't realize how extensively you were using subclassing in your repo. Between your responses; I did try to subclass the _get_coords() function, it seems like I was getting close to it working and if your driver update doesn't fix my issue I will continue with this. I was just about to start interpreting your i2c implementation, because obviously the original mpy machine implementation won't work now. Here's the script with my attempt at subclassing: |
Beta Was this translation helpful? Give feedback.
-
I'll keep this in mind when I run into issues, sometimes I am a bit reluctant to ask for help, even after a google search fails to help. I really appreciate this attitude, I feel like so often people start to lose sight of the time and effort they had to put in, even amongst relative beginners like myself, I find a lot of people develop an unreasonable degree of narcissism as they develop some knowledge. That said, sometimes the person asking for help sucks too; I do notice people asking for help and then never responding or having a dev make some custom support that they promptly forget about and never use. Though in your specific case, most of the time someone else is likely to come along with the same board/display at some point anyway. |
Beta Was this translation helpful? Give feedback.
-
|
Now that I've compiled the new firmware, I get the error: |
Beta Was this translation helpful? Give feedback.
-
|
I just edited that to avoid the error and will try recompiling, so I can see if the other changes avoided the error I was running into before. |
Beta Was this translation helpful? Give feedback.
-
|
Big progress; when I use the new drivers, I get an error when I touch the button: This is pretty exciting, because it doesn't happen when I touch the screen anywhere but the button. Unfortunately, I still get the |
Beta Was this translation helpful? Give feedback.
-
|
With my other code; subclassing "_get_coords" to add interrupts, things work even better, no errors after ~2 minutes, I get the X and Y coordinates printed to REPL when I tap anywhere but the button and when I tap on the button, I get the same error. Here is that code, I will look into the error now: |
Beta Was this translation helpful? Give feedback.
-
|
This is a better way to handle the subclassing with the interrupt pin. from micropython import const # NOQA
import lcd_bus # NOQA
import machine # NOQA
import time
_WIDTH = const(240)
_HEIGHT = const(240)
_DC_PIN = const(4)
_MOSI_PIN = const(5)
_MISO_PIN = const(16)
_SCLK_PIN = const(6)
_CS_PIN = const(7)
_FREQ = const(60000000)
_RESET_PIN = const(8)
_POWER_PIN = None
_BACKLIGHT_PIN = const(9)
_OFFSET_X = const(0)
_OFFSET_Y = const(0)
spi_bus = machine.SPI.Bus(
host=1,
sck=_SCLK_PIN,
mosi=_MOSI_PIN,
miso=_MISO_PIN,
)
display_bus = lcd_bus.SPIBus(
spi_bus=spi_bus,
dc=_DC_PIN,
freq=_FREQ,
cs=_CS_PIN,
dc_low_on_data=False,
cs_high_active=False,
)
import gc9a01 # NOQA
import lvgl as lv # NOQA
display = gc9a01.GC9A01(
data_bus=display_bus,
display_width=_WIDTH,
display_height=_HEIGHT,
# we are going to let the driver handle the allocation of the frame buffers
frame_buffer1=None,
frame_buffer2=None,
reset_pin=_RESET_PIN,
reset_state=gc9a01.STATE_LOW,
power_pin=_POWER_PIN,
power_on_state=gc9a01.STATE_HIGH,
backlight_pin=_BACKLIGHT_PIN,
backlight_on_state=gc9a01.STATE_HIGH,
offset_x=_OFFSET_X,
offset_y=_OFFSET_Y,
color_space=lv.COLOR_FORMAT.RGB565,
rgb565_byte_swap=True
)
display.set_power(True)
display.init()
display.set_backlight(100)
import i2c
import ft6x36
#subclassing _get_coords
class FT6x36(ft6x36.FT6x36):
def __init__(self, dev, int_pin):
self._int_pin = machine.Pin(int_pin, machine.Pin.IN)
super().__init__(dev)
def _get_coords(self):
if self._int_pin.value() == 0:
return None
self._tx_buf[0] = 0x03
self._device.write_readinto(self._tx_mv[:4], self._rx_mv[:4])
buf = self._rx_buf
x = ((buf[0] & 0x0F) << 8) | buf[1]
y = ((buf[2] & 0x0F) << 8) | buf[3]
return self.PRESSED, x, y
i2c_bus = i2c.I2C.Bus(
host=1,
scl=12,
sda=11,
)
touch_i2c = i2c.I2C.Device(
i2c_bus,
dev_id=ft6x36.I2C_ADDR,
reg_bits=ft6x36.BITS
)
def button_pressed(*args):
print("buttonpressed!!!!#@!#@!#@!#@!#32321323213213213@#WEQWFDWEfwgf67ewgfwegfgwe8fgew")
indev = FT6x36(touch_i2c, 14)
scr = lv.screen_active()
btn = lv.button(scr)
btn.set_size(65, 65)
btn.center()
label = lv.label(btn)
label.set_text('btn')
label.center()
btn.add_event_cb(button_pressed, lv.EVENT.CLICKED, None)
import task_handler # NOQA
th = task_handler.TaskHandler()
|
Beta Was this translation helpful? Give feedback.
-
|
As far as I can tell; it has just the 512kb on board RAM, it's the "ESP32-S3FN8". It is weird that the communication with the touch IC works fine but it seems to default to some mode that doesn't work unless using interrupts. All the examples I've found based on this device use interrupts for the touch functionality, but I did find this from the mpy repo with M5 Dial support "https://github.com/mattytrentini/micropython/tree/add-m5stack-dial-board/ports/esp32/boards/M5STACK_DIAL":
" |
Beta Was this translation helpful? Give feedback.
-
|
OK do this... Run this code and tell me what you get for an output... This script is going to take 20 seconds to run. There should be 2 printed statements when it is done. import i2c
import time
i2c_bus = i2c.I2C.Bus(
host=1,
scl=12,
sda=11,
)
print(i2c_bus.scan())
# sleep for 20 seconds
time.sleep_ms(2000)
print(i2c_bus.scan()) |
Beta Was this translation helpful? Give feedback.
-
|
First time I ran, it was 2 seconds and I got: Changed it to 20s, this is the result: |
Beta Was this translation helpful? Give feedback.
-
|
yeah see the device is going to sleep for some reason... That's what I thought.. Do me a favor and try touching the screen just before the 20 seconds is up I am willing to bet you it wakes up. |
Beta Was this translation helpful? Give feedback.
-
|
When I use your subclassing, the error has returned, but touch works until the error happens; at which point it locks up. I won't post it again, because I copied your code verbatim and uploaded it. |
Beta Was this translation helpful? Give feedback.
-
|
I updated the repo with modifications to the driver. You can just copy the code and paste it into the driver file you have locally.. No need to clone the repo again. This should do the trick for ya... |
Beta Was this translation helpful? Give feedback.
-
|
Once we get the touch and the display all squared away for ya which I believe we are getting close to that point I can walk you through how to keep the memory use as low as possible and get everything to work how you want it. |
Beta Was this translation helpful? Give feedback.
-
Is the ISR the strategy I was using before? I was expecting I could just do this again: I will just avoid doing it if it's gonna be a hassle, I can wait until it's a problem before I decide I need to figure it out. My current solution is a webui on my phone, so this will be a much better experience even if there's some latency still. I apologize but I think I've gotta go eat something before I compile and try things again, I might be a couple hours but I'll reply once I try it out. Thanks again for all your help, couldn't have stumbled across a more helpful person. |
Beta Was this translation helpful? Give feedback.
-
|
Actually I'll just compile while I eat, and try it while we're both still around. |
Beta Was this translation helpful? Give feedback.
-
|
Back to this error again: |
Beta Was this translation helpful? Give feedback.
-
|
Ah, seems like you removed the "not", so it's returning a runtime error whenever the chip ID matches, rather than when it doesn't match.: ↓ |
Beta Was this translation helpful? Give feedback.
-
|
You're right that the error occurs ~13 seconds after I stop touching the screen, not 13 seconds after starting. But after compiling the firmware with the new driver, it still times out after ~13 seconds. |
Beta Was this translation helpful? Give feedback.
-
|
For context, here's the script I'm running: |
Beta Was this translation helpful? Give feedback.
-
|
it's OK for it to time out. the question is does it come back on when you touch it. Is the driver able to handle the device disappearing? does the touch work properly or is something different happening? I know there is another way to poke it to wake it up. Personally I do not care for it because it requires pulsing the reset wire for < 1 ms which will wake the thing up. The reason why I don't want to go that route is because a lot of displays that have MCU's integrated use IO expanders and those IO expanders are where they connect the reset wire to. So it's not as straight forward to pulse the thing. |
Beta Was this translation helpful? Give feedback.
-
|
get rid of the whole subclass thing. You don't need it anymore. Run the script without that and use the driver as it is in the repo.. |
Beta Was this translation helpful? Give feedback.
-
The touchscreen doesn't come back on if I touch after the error, it locks up and won't continue execution; when I use interrupts the touchscreen still works after the error, but that's presumably because it's pulling it out of whatever error state it's in. I compiled again with the unedited ft6x36 driver and I get: |
Beta Was this translation helpful? Give feedback.
-
|
When I run the code without subclassing; I get some error from the pointer framework: I am compiling again now and will install the ft6x36 driver straight from the repo. This is the script I've been running, after removing subclassing: |
Beta Was this translation helpful? Give feedback.
-
|
you need to remove the 14 from the constructor for the touch screen. |
Beta Was this translation helpful? Give feedback.
-
|
should be
|
Beta Was this translation helpful? Give feedback.
-
|
When I run the driver without my change, I get the runtime error either way; so I need to go make that change and recompile, but I'll try in just a sec. |
Beta Was this translation helpful? Give feedback.
-
|
Success! With Thanks so much for all your help so far, I'm not sure if the missing Thanks again for all your help! You've really allowed this project to get off the ground. |
Beta Was this translation helpful? Give feedback.
-
|
For context, here's the script I am running now that works: |
Beta Was this translation helpful? Give feedback.
-
|
I will fix the |
Beta Was this translation helpful? Give feedback.
-
|
I did spend a week or so trying to get the official LVGL bindings to work, both from lv_bindings and lv_micropython. I saw this project and thought "this is exactly what I need"; little did I realize that you also provide input device and display drivers as well. It's exciting that you're putting so much work into this; I bet I will make use of your work here for other projects in the future. |
Beta Was this translation helpful? Give feedback.
-
|
There is a lot of stuff on my github account. You should spend a little bit of time and wander through the list of repos I have. Most I made and some are spinoffs of others work. and some are just forks |
Beta Was this translation helpful? Give feedback.
-
So much stuff; the samsung TV control stuff coulda been useful to me a while ago, but they dropped steamlink support so now I don't let the samsung TV connect to the internet anymore anyway. |
Beta Was this translation helpful? Give feedback.
-
|
The Samsung stuff only works for their older TV's. At one point I had reverse engineered so much of the TV's that my library offered more control then using their app. The problem with Samsung is changes get made causing things to break because the department that made the change didn't let the department that writes the firmware for the TV's know that they made a change. It could be months before it got fixed if at all. They also drop support for models after only a few years of it being released. They did this with my washing machine and dryer that have the ability to be remotely controlled. The annoyance is the fact that they used certificated to allow access to the devices and that is only able to be done using their cloud service. So when they drop a model from the service the remote functions of the device become unusable. They don't updated the firmware for the devices to remove the authentication so it can be controlled by a 3rd party application when this happens. It intentionally breaks a portion of the device in an attempt to get the person to go out and buy a new machine. I will never buy another Samsung product because of this kind of behavior. My washing machine broke after only owning it for 4 years. I paid 1500 for the washer and 1500 for the dryer. Part of the drive system broke which has a 10 year manufacturers warranty. I called them and they told me that the parts were discontinued so they wouldn't be able to repair it, but they would give me 100 dollars off a new machine.. WHAT!?!?!?!... well as it turns out Samsung discontinued the parts in their system but the company that actually manufactured the parts for Samsung still made them. That's how they get out of fixing machines under warranty. Never again will I buy Samsung anything. |
Beta Was this translation helpful? Give feedback.
-
|
That's horrible, unfortunately it seems to be a common story with Samsung. I'm on the same page, I won't buy Samsung anything ever again; tbh for the most part, I'd much rather a cheap Chinese appliance fucks me over, rather than an expensive one from Samsung or Sony. My Haier dishwasher broke and I'm poor so transporting it to get it worked on was out of the question. While their support wasn't amazing, they kept trying and escalating till I got to someone who could help me figure out the issue. They told me how much the part would cost and he didn't even get offended when I said I'd be sticking a toothpick in the switch instead of ordering a new part, even warned me that it might stop running randomly if the toothpick fell out. |
Beta Was this translation helpful? Give feedback.
-
|
you see this. Firefox using up almost 16GB of ram!!!
|
Beta Was this translation helpful? Give feedback.
-
|
end the task and restart it, all the same tabs open up and here is the memory use..
Talk about a massive memory leak.... |
Beta Was this translation helpful? Give feedback.
-
|
You had mentioned earlier that when I'm using the rotary encoder, I shouldn't control things from the ISR. Upon doing some research; I gather you mean that I should do something similar to what I did before, where I used a flag to control a condition in the loop. Is this what you mean? |
Beta Was this translation helpful? Give feedback.
-
|
seeing as how you want the control to be pretty responsive I would recommend using interrupts. You should be able to change the state of say an output pin which is pretty straight forward to do and there is no memory that is allocated for something like that. I don't know what you are trying to control with the rotary encoder.. A stepper motor comes to mind. The question of the day is what kind of a rotary encoder are you talking about. Is it a continuous movement or is it more like a jog/shuttle knob which is a spring return encoder that has 3 positions. left right and center. It automatically springs back to the center on release. There are several variations of these. Simple ones have an in wire and 3 out wires. others use resistance to multiplex the signals. More advanced ones will have a pwm type logic to the signal wire and that signal will ramp up to a faster pulse the longer the knob is held. The last one is the best if using it for a stepper motor control. If you do not mind me asking, what are you making? Check out some things that I have made.. https://www.youtube.com/watch?v=35j4p78OJAs https://www.youtube.com/watch?v=Yiq3RKSpnZo https://www.youtube.com/watch?v=3Knze9cjU-0 |
Beta Was this translation helpful? Give feedback.
-
|
The rotary encoder is continuous and built into a collar around the screen, you rotate the collar to use the rotary encoder. Between those UIs is probably all the functionality I will need, from a UI perspective anyway. At first I will probably just use labels to display the machine position, but would like to have a rotary slider(like your example with the loading screen or your third example), this would allow me to add visualisations for the axis limits or coordinate system limits to the UI. Essentially what I'm making will be a CNC pendant/controller, there will be a few different UIs, for different tasks but the quintessential interface will be for jogging the toolhead around. My current idea for the jogging UI is there will be a button in the middle(maybe a drop down box or something) that you press to select the axis you want to move, as well as the feedrate at which to move it and the amount to move per detent. Say you select "X" and set the feedrate to "200" and the movement per detent to 1mm, every notch on the rotary encoder will move the X axis by 1mm at 200mm/minute. To do this the pendant just writes a gcode command to the serial interface with the CNC mainboard, this command would look something like: "G1 X1 F200". The rotary encoder needs to achieve a certain level of responsiveness to be useful, if there's too much delay I'll overshoot and break things, but it's also very nice to have the screen update the machine coordinates responsively, so balancing these two things is somewhat important. To get the machine coordinates, the pendant sends a gcode command something similar to "G409 axis" and it responds with the current machine position (or whatever info you want from the mainboard). Being able to slow things down arbitrarily, so I can jog in 0.1mm or 0.01mm increments is a big part of why I think using the rotary encoder in this way makes sense; by mapping each detent to a configurable displacement, the movement can be very controlled and predictable. The other UIs will mostly be very similar to the jogging UI; they will send some gcode commands and potentially receive some data back to display. Apologies if I've been a bit too verbose, I want to err on the side of overexplaining, because I might not realise whether some piece of information is important or not. |
Beta Was this translation helpful? Give feedback.
-
|
What you can do for the encoder is if it sees pulses within set periods of time it will automatically increase the increment and if the dial moves in the opposite direction it resets the increment back to the smallest amount. If there is a pause in the dial movement that will also reset the increment. As an example. This code is pseudo code. It has not been tested. It is to show a general idea of how to deal with the encoder. import time
import machine
import _thread
# thread lock
encoder_lock = _thread.allocate_lock()
left_pin = machine.Pin(22, machine.Pin.IN, machine.Pin.PULL_DOWN)
right_pin = machine.Pin(23, machine.Pin.IN, machine.Pin.PULL_DOWN)
# to test the time between encoder movements
start_time = time.ticks_ms()
# the current index for the increments
curr_increment = 0
# the current encoder pin that is being timed
curr_pin = None
# number of clicks the encoder has moved
count = 0
# increments that can be changed
increments = (
0.001,
0.01,
0.1,
)
# variable that stores the movement direction/increment
# so the thread knows what to do
move = 0
def pin_cb(p):
global curr_pin
global start_time
global count
global curr_increment
global move
end_time = time.ticks_ms()
if (
p != curr_pin or
time.ticks_diff(end_time, start_time) >= 250
):
count = 1
curr_increment = 0
curr_pin = p
else:
count += 1
if count == 10:
if curr_increment < 2:
curr_increment += 1
count = 0
if curr_pin == left_pin:
# values less than zero is to move left
move = -increments[curr_increment]
else:
# values greater than zero is to move right
move = increments[curr_increment]
# reset the start time
start_time = end_time
# release the thread lock so we can move the axis
encoder_lock.release()
# we only want to call the interrupt callback on the falling edge so when
# there is a change from positive to negative... This is if the state changes
# from a low state to a high state when the encoder is moved.
# if the pin rests at a high state and it pulled low when the encoder moved
# then we set this to rising.
# we always want to catch the state change on the back side. so if the state
# changes for the opposite direction we don't get a bumping of heads.
# in the callback.
left_pin.irq(trigger=machine.Pin.IRQ_FALLING, handler=pin_cb)
right_pin.irq(trigger=machine.Pin.IRQ_FALLING, handler=pin_cb)
ui_encoder_value = 0.0
def encoder_loop():
global move
global ui_encoder_value
encoder_lock.acquire()
while True:
# by calling acquire a second time will cause the thread to stop.
# The only time we want the thread doing anything is when
# an interrupt comes in. The release happens in the interrupt callback
encoder_lock.acquire()
# we check for values that are non zero before moving anything
# this is more of a sanity check then anything else
if move < 0:
# code to move to the left
pass
elif move > 0:
# code to move to the right
pass
ui_encoder_value = move
move = 0
_thread.start_new_thread(encoder_loop, ())
# we are able to manipulate the task_handler so we can perform some tasks
# every time lvgl's task handler is supposed to run.
# This callback will get called from the main thread every 33 milliseconds.
def task_handler_cb(event, user_data):
global ui_encoder_value
# we double check to see if the timer has expired. If it has then we set
# the displayed value to zero.
end_time = time.ticks_ms()
if time.ticks_diff(end_time, start_time) >= 250:
ui_encoder_value = 0.0
# set UI text element with the encoder direction value
# encoder_value.set_text(str(ui_encoder_value))
# we return True so that the task_handler will update the display.
# If we return False the display doesn't get updated
return True
import task_handler
th = task_handler.TaskHandler()
# add the callback to get called before the screen gets updated
th.add_event_cb(task_handler_cb, task_handler.TASK_HANDLER_STARTED, None)
|
Beta Was this translation helpful? Give feedback.
-
|
The nice thing about the code above is it doesn't block the main thread at all. What this means is the REPL will still be available when you connect using serial. The importance of this is debugging output and /or the ability to type in python code while the program is running. It allows you to test and or turn debugging output on and off or upload new python source files. If updating the source files you would simply press the reset button once they are uploaded so the new code runs. Or you could perform a hard reset using |
Beta Was this translation helpful? Give feedback.
-
|
Having the REPL available is definitely appealing to me; I will probably start using the pendant before it's fully done, so there will probably be lots of updates. Being that I'm still learning; there's bound to be plenty of debugging over time as well. I've had a read through your pseudocode and loosely understand, though I'll have to get some assignments done before I can spend any real time learning about threading and testing/implementing it. I have been meaning to ask, but don't feel obligated to answer; do you work as a software engineer or developer or something similar? You mentioned that you're self taught but I wonder how finding work in such a technical field works when you're self taught, though I guess being self taught doesn't mean you haven't got qualifications. |
Beta Was this translation helpful? Give feedback.
-
I've been using this script to create firmware for my ESP32_S3, all goes perfectly smoothly. But once I flash the firmware onto the board, I get some PSRAM errors and a non-functional REPL. I've been banging my head against compiling my own fork with LVGL bindings so am very motivated to make this work, but really don't know where to go from here. The readme doesn't mention an option to choose 0 PSRAM, but perhaps it's just undocumented and exists.
Here's the make.py commands I use:
python3 make.py esp32 clean submodules mpy_cross BOARD=ESP32_GENERIC_S3And here's the flashing commands I use:
/python_env/idf5.2_py3.11_env/bin/python -m esptool --chip esp32s3 -p /dev/ttyACM0 -b 460800 --before default_reset --after no_reset write_flash --flash_mode dio --flash_size 8MB --flash_freq 80m --erase-all 0x0 /Documents/Project/PythonFiles/lvgl_micropython/build/lvgl_micropy_ESP32_GENERIC_S3-8.binHere's the error I get after I flash the firmware:
<0x1b>[0;31mE (422) quad_psram: PSRAM ID read error: 0x00ffffff, PSRAESP-ROM:esp32s3-20210327 Build:Mar 27 2021 rst:0x15 (USB_UART_CHIP_RESET),boot:0x8 (SPI_FAST_FLASH_BOOT) Saved PC:0x40382ba2 SPIWP:0xee mode:DIO, clock div:1 load:0x3fce3820,len:0x105c load:0x403c9700,len:0x4 load:0x403c9704,len:0xbd8 load:0x403cc700,len:0x2e30 entry 0x403c989c <0x1b>[0;31mE (422) quad_psram: PSRAM ID read error: 0x00ffffff, PSRAM chip not found or not supported, or wrong PSRAM line mode<0x1b>[0m <0x1b>[0;31mE (423) esp_psram: PSRAM enabled but initialization failed. Bailing out.<0x1b>[0mBeta Was this translation helpful? Give feedback.
All reactions