You can see that the variable that begins with the _ when using const doesn’t get set into a variable. the code gets read and all instances found in the code that have _? get replaced with the value passed to const. That is exactly what happens in C code when using #define MACRO_NAME 10 No allocation occurs for MACRO_NAME. The trigger there is having the underscore when using const in micropython.
I would have to make some tweaks to the code in order to utilize a double display connected to the same bus. specifically in the area of the frame buffers. If both displays are being connected to the same I8080 bus the CS line is what would handle which display is receiving and that would be the responsibility of the display driver to set the CS line to low in order to transmit to that display and then switch it back to high when finished. It would be the responsibility of the driver to also check and see if a second display that is attached needs to wait because of data being sent. That would be outside of the scope of what the bus driver handles. The thing that I have to change in the code for the bus driver is the handling of the frame buffer to allow more of them to be created.
The only thing the bus drivers do is they transmit the data. they are not responsible for anything else. so any display specific parameters that need to be sent would get sent through the bus driver but it is the display driver that would be responsible for telling the bus driver what to send. For the most part the same information gets sent to a display doesn’t matter how the display is connected to the MCU. a lot of displays support multiple ways of connecting to it and how that gets set depends on what pis are pulled high or low when the display get powered on. But no matter what the connection is the same initialization commands get sent to it. That is the reason why the display drivers doesn’t need to know anything about the connection there is no reason for it to know. The only thing it needs to know is what to send and when to send it.
well just to give everyone a heads up. I got it compiling as a user module with only a single change needing to be made to MicroPython and that is to add the esp_lcd component for the ESP32.
I do have a single issue I am not sure how to correct so for the time being I simply turned it off and that is the LV_ENABLE_GC
I am not proficient in C and did the best I could with it. This one thing has got me all kinds of hung up on how to fix it. I am sure it is not a big deal to correct it is just beyond my knowledge of how to correct it.
If @kisvegabor can make a new branch named update_micropython_1.21.0 in lv_binding_micropython and also in lv_micropython it would make it really helpful. I have to change the current submodule structure so the binding is not longer a dependancy of micropython but the other way around.
Technically speaking there is no longer going to be a need to have 2 separate repositories because micropython will be a submodule of the binding.
I am going to write a small python script to handle adding the esp_lcd component when compiling for the ESP32. That will only be needed until the ability to add components from a user module is added upstream in micropython
The code still needs to be written for the following busses for the rest of the MCU’s
I2C
SPI
RGB
I8080
I already wrote the code for the ESP32 and we can use that as the starting point API wise and make any needed changes from there. I also have already written a framework for the display drivers as well. The way I did it makes it a breeze for a user to write a driver for a display. we can also include drivers but they will not be compiled into the firmware, the user would have to upload them to the MCU once the firmware has been flashed. The drivers will be pretty small in size and I kept memory use down as low as possible when I wrote the framework.
That’s awesome progress @kdschlosser! I’m looking forward to trying it out.
As for having a chat, I’m still up for Tuesday, noon CET time (10pm AEDT). I’ve scheduled a zoom call. No account is required but zoom does have to be installed - if another service is preferred just let me know.
I’m sorry for the inconvenience, my child just got sick and we need to logistic a little bit between work and being at home. On Tuesday I need to be with my child until 1:15pm, so I wonder if we can shift the meeting by 1:15. I understand that it could too late in Australia, so we can shift it by a few days too.
No worries at all - family issues come first! That is getting late here so another day would be preferable, how about Thursday (noon CET, 10pm for me)?
Oh, of course, sorry! I forgot about Thanksgiving. No worries, how about we just push it to next Tuesday? (though I’m free Monday and Thursday evenings as well if they work better).
I am golden any day except for 10AM to 12PM UTC -7:00 Tomorrow and all day Thursday. after that I am open for anything. I am retired so I am pretty much a free bird as far as having to be any place at any specific times.
I DID IT… well partially. It compiles!!! I have yet to test it on a board tho.
This only works for the ESP32 for the time being. Need some folks to write bus drivers for the other boards. display drivers can then be written in Python. I did not include the display driver framework yet. It does include the bus drivers for the ESP32.
What I did is just a proof of concept to show my thoughts on how to go about organizing it. I am working on getting the unix port to work. I am trying to figure out where LVGL gets added into the build system currently. It has to be inside one of the makefiles in MicroPython it’s self and not in the unix port makefiles.
