STM32H7 LTDC + board family: would a contribution series be welcome, and what's the preferred architecture?

[nuraci]

Hi @kdschlosser, hi everyone,

I've spent the last several months building LVGL+MicroPython support for a family of affordable STM32H743 boards (DEV190806042, FK743M5-XIH6, STM32H7_CORE). They share the same recipe: external SDRAM, QSPI flash, and an RGB TFT panel driven by the H7's hardware LTDC peripheral. Working end-to-end on real hardware, I currently have:

• Three MicroPython board definitions (mpconfigboard, QSPI block device, linker with heap in SDRAM, USB FS dual CDC + MSC).
• A C MicroPython module that drives LTDC with double buffering, VSYNC-synced flush, DMA2D-accelerated partial updates, framebuffer write-through via the MPU, and AXI QoS tuned to avoid LTDC underrun.
• A GT911 I2C touch driver and a small Python layer for auto board/panel selection.
• A working LVGL demo.

I originally pushed this upstream as lvgl/lv_micropython#104, #105 and lvgl/lv_binding_micropython#407, but that side of the project is effectively unmaintained: the STM32 CI workflow is disabled, the runner-update PR has been open since Aug 2025, my PRs are sitting untouched. I'd rather invest the migration effort once and land it where the project is actually moving — i.e. here.

Before I start cutting code I'd like to align on architecture. To keep this thread focused I'll lead with the one question that drives everything else.

LTDC doesn't really fit the lcd_bus "push pixels" model — it's a hardware scan-out from SDRAM, conceptually closer to the ESP32 RGBBus. Would you prefer:

(a) an LTDCBus as a subclass of lcd_bus, symmetric with RGBBus;
(b) a standalone driver under api_drivers/common_api_drivers/display/ behind a CONFIG_STM32 / port guard;
(c) something built on top of the existing generic rgb_display driver?

I have follow-on questions — board routing (direct PR to micropython/micropython vs micropy_updates/), alignment with the existing GT911 driver, and how STM32 SoC-specific drivers should be wired into make.py — but they all depend on (a)/(b)/(c), so let's start there.

One practical note: you've mentioned on the LVGL forum that lack of STM32 hardware is a blocker. I have these three boards on my bench and I'm willing to do the debugging and ongoing maintenance for them. If a self-hosted GitHub Actions runner wired to one of the boards would help close the CI loop, I can set that up.

Refs:

• Stalled PRs: Add STM32H743 board support: DEV190806042, FK743M5-XIH6, STM32H7_CORE lvgl/lv_micropython#104, No picture appears on the ili9341 display #105 — Add LTDC display and GT911 touch drivers for STM32H7 boards lvgl/lv_binding_micropython#407
• Boards docs/photos/videos: https://github.com/Copper-And-Code/stm32h7-boards-docs

Thanks!
— Nuraci (@nuraci)

[nuraci]

demo_auto.mp4

[kdschlosser]

what exactly do you need to know? I will give you whatever information you need an if the API needs to change in order for the STM bus drivers to work with the current design between the bus drivers and the display drivers then I am OK with doing that.

nothing gets changed in libs/micropython. If the code in micropython needs to be changed then changes needs to be hot patched and written in python scripts to handle that. That's of the change is not for a specific port. If the change is port specific then a copy of the existing file need to be placed in the micropy_updates folder retaining the directory structure from the port folder to the file. then that file needs to have the modifications made to it as needed.

The bus drivers need to be written in a manner that allows them to be a runtime choice. as an example. If using an I8080 display either 8 pins or 16 pins should be able to be selected when the bus driver starts, The use of DMA memory should also be a runtime choice if a choice is available to make.

[nuraci]

Thanks @kdschlosser. Reading your reply, my takeaways are:

1. Boards routing: anything port-specific lives in micropy_updates/ports/stm32/boards/... mirroring the upstream tree. lib/micropython/ stays untouched. I'll also submit the three boards to micropython/micropython upstream in parallel, so the patches in micropy_updates/ can be dropped at a later submodule bump.
2. LTDC architecture: from your "STM bus drivers" wording I'm reading option (a) — LTDC as a subclass of lcd_bus, i.e. LTDCBus. Tell me if I'm misreading.
3. Runtime configurability: no compile-time pinning. All hardware choices (pin width, DMA, framebuffer count, pixel format, panel timings) become constructor arguments. Understood.

With that, here's where I'll likely need to extend the existing bus API. Push back where any of these conflicts with your intent:

• Framebuffer allocation. Today bus.allocate_framebuffer on ESP32 maps to heap_caps_malloc(SPIRAM | DMA). On STM32H7 the framebuffer must live in external SDRAM at a fixed mapped address (not on the heap), cacheline-aligned, with the MPU region set to write-through. I'd add a per-port backend behind the same signature — invisible to display drivers.
• Continuous scan-out vs push. LTDC isn't a "push pixels" peripheral; it continuously scans the framebuffer at the panel refresh rate. The current tx_color / flush_ready contract would mean "DMA2D blit from staging to active framebuffer complete and next VSYNC reached" rather than "bytes shifted out". I'd drive the callback from the LTDC line-interrupt. Callback semantics from the display driver's point of view stay the same.
• LTDCBus constructor parameters (all runtime): panel timings (HSYNC/VSYNC/back+front porch/pixel clock), pixel format (RGB565 / RGB888 / ARGB8888 / L8), framebuffer count (1 or 2), DMA2D enable, optional second LTDC layer for cursor/OSD.
• DMA2D as a sibling module. DMA2D is used by the bus for partial flushes but is also useful to user code for blits and color conversion. I'd expose it as a small standalone module rather than hiding it inside LTDCBus.

Proposed PR sequence, smallest-first to keep reviews tractable:

1. PR1 — scaffolding: LTDCBus skeleton + one board (STM32H7_CORE) + minimal demo. Single framebuffer, RGB565, no DMA2D yet. Goal: validate the architecture before scaling.
2. PR2: DMA2D + double buffering + VSYNC sync.
3. PR3: the other two boards (FK743M5-XIH6, DEV190806042) + per-panel timing tables.
4. PR4 (only if needed): adjustments to the existing GT911 driver and make.py wiring for STM32 SoC-specific drivers.

Two small things deferred until PR1 lands, so we don't fragment this thread:

• Existing GT911 driver in api_drivers/common_api_drivers/indev/ — happy to use it as-is on the three boards; any known issues I should pre-empt?
• Self-hosted runner offer still stands once the architecture is stable and there's something worth keeping green.

Will start on PR1 unless you flag any of the above as off-track.

— Nuraci

[kdschlosser]

You really cannot stage the bus drivers. They need to be an all or none for each driver. Meaning if you are writing the driver for the I8080 bus it needs to support 8 lanes, 18 lanes and DMA buffers out of the box.

Look at the drivers for the ESP32. that is basically how they need to be done. I am not familiar with the STM SDK or to what extent they provide helper functions and structures for getting a display up and running.

There are 2 libraries that I looked at the code for to see what the STM32 code looks like and it appears like it is a lot of macros based on the MCU that is being used.

https://github.com/RobertoBenjami/stm32_hal_graphics_display_drivers
https://github.com/RobertoBenjami/stm32_graphics_display_drivers

While those drivers could not be used directly because the display bus is a compile time choice and not runtime the information in it can be used as a reference to write the drivers for this project. They would need to be written in the same manner that is seen with the ESP32 drivers.

[kdschlosser]

I am also unfamiliar with the terms LTDC and FSMC etc... the display bus types conform to MIPI naming which is RGB, SPI, I8080, DSI and I2C.

[nuraci]

Thanks @kdschlosser, this clarifies a lot — three things land:

1. LTDC = STM32 backend of RGBBus. Got it. Hardware scan-out from a framebuffer to a parallel TFT panel is exactly the RGB / MIPI DPI model. The st_ltdc.LTDC from my original PR becomes the STM32 implementation of the existing RGBBus, not a new class.
2. No staging. Understood. The bus driver lands complete: all relevant pixel formats, single/double buffer runtime selectable, full panel timing parameters, the lot. Boards remain separate PRs since they're not bus driver work.
3. Benjami repos as study material, not basis. Agreed — useful for LTDC register sequences and panel init patterns, not for the API shape.

Before I start cutting code I'd appreciate three quick pointers to avoid going sideways:

• Which file in this repo do you consider the canonical reference for RGBBus? I want to read it end-to-end against the API I'll need to match.
• Multi-layer support. LTDC has 2 hardware layers with alpha blending. Your preference: hide it as an internal optimization (single visible layer to Python), or extend the RGBBus API to optionally expose layers across backends?
• Framebuffer allocation for fixed-mapped memory. On STM32H7 the SDRAM lives at a known physical address (0xC0000000), not allocatable from a heap. Is there an existing precedent in the codebase for this pattern, or should I propose an allocate_framebuffer extension that accepts a pre-mapped region?

Will start reading code and come back with a concrete proposal once those are settled.

— Nuraci

[kdschlosser]

i don't know if the STM32 line of MCU's are dual core or not. If there are any that are dual core then you can use the esp32 rgb bus driver as an example of what would need to be done. Instead of duplicating code there are things like the rotation handling that would need to be peeled out and made available across all MCU's You may still want to do that because RGB displays only support software rotation.

I have tried to make the bus classes in a manner that was a close as possible to each other except for the class constructors obviously. This is done to make the display drivers largely unaware of the type of bus being used. This allows the same driver code to be used with more than one bus type.

There is no need to use anything more than a single "layer". LVGL handles all of the blending.

I don't know how buffer allocation occurs with the STM32 line of MCU's or how it handles DMA transfers. The ESP32 has specific areas of memory that can be used in DMA transfers so if wanting to perform a DMA transfer the buffer needs to be allocated in those specific areas of memory. Some MCU's don't have specific areas and all memory is able to be used for DMA transfers with no additional work needing to be done when allocating. If that is the case then you would need to create the flags for the buffer allocation for DMA and set them to a zero value. This keeps code portable by doing that. The memory allocation should not occur on the heap when allocating the frame buffers. They need to be explicitly allocated and freed. The reason why is memoryviews are used when passing the frame buffers between python and LVGL. a memoryview is basically a pointer to the location in memory. very similar to a C pointer. While the memoryview itself is reference counted once it hits the LVGL layer the C pointer gets extracted from the memoryview object and tat is where the reference counting ends. If the buffer is allocated on the stack it would end up getting garbage collected which we do not want to have happen. If it was allocated on the stack and then the frame buffer goes out of scope the program would crash.

[nuraci]

Thanks Kevin, that settles the design. One readback on the part I don't want to get subtly wrong, then one question.

Framebuffers — my understanding: explicitly allocated and freed (never heap, never stack), handed to LVGL as a memoryview whose backing memory outlives the memoryview itself, since LVGL extracts the raw C pointer and the reference counting ends there. I'll keep the caps-flag allocation signature identical to the ESP32 one and just define STM32's DMA caps as zero — all SDRAM here is reachable by LTDC/DMA2D, so no special region is needed. On STM32 the backing memory comes from a reserved SDRAM region outside the GC heap, cacheline-aligned with the MPU set appropriately, but that's an STM32-internal detail behind the same signature, invisible to the display driver. Correct me if I've misread the allocation model.

Single layer, ESP32 RGB backend as the reference, bus class identical except the constructor — all clear, no questions.

Rotation. Since RGB/LTDC is software-rotation only and you'd rather it not be duplicated, I'll peel it out of the ESP32 RGB backend into a shared module usable by any RGB-type backend. One question: do you want that as a separate commit inside the LTDC PR, or as a small preliminary PR landed first, so the refactor is reviewable on its own before the STM32 code arrives? I'm fine either way — your call on what's easier to review.

Starting on reading the ESP32 RGB backend now; I'll come back with a concrete plan rather than guesses.

— Nuraci

[kdschlosser]

If you can peel the rotation out of the ESP32 RGB that would be awesome. A separate PR for that. Also name is "software rotation" because it will be made available to all bus types at some point. it's not going to be specific to only the RGB bus. There are some I8080 and SPI displays that do not support hardware rotation or they only support one other direction. It will be nice to be able to rotate those properly.

Take a look at the memory allocation flags for the ESP32. All of those need to be implemented with the STM32 even if they are set to 0 and have no meaning. I want to keep a common API for everything across MCU's this makes it easier for portability even if something is not used. If there are special parameters that need to be passed to a bus constructor let me know what it is and what it does. we might be able to hide it behind the scenes or add a function that deals with it this way the user can use sys.platform to check the MCU being used and use that extra function of it is an STM32 MCU. I know that pin definitions are going to be a snag point because of how STM32 handles pin definitions because ports need to be known. Tell me if my assumption on this is correct or not. a GPIO port on an STM32 is really the identifier that needs to be passed to the constructor of the bus. The pins need to have an alignment so the buffer data aligns with them so there really isn't a choice of pins that can be used. The port is what is going to define the pins. passing the pin numbers would be more of a formality to determine if the connected display is using an 8 lane or a 16 lane connection. Am I right in that?

[nuraci]

Thanks, this all makes sense. Point by point:

Rotation — agreed, separate preliminary PR, and I'll build it as a generic software rotation service that operates on a framebuffer independent of bus type, not something RGB-specific. I'll design it so SPI and I8080 backends can adopt it later for the cases where the panel has no (or partial) hardware rotation. I'll keep its naming and location neutral (not under an rgb/ path).

Memory allocation flags — understood. I'll implement the full ESP32 flag set on STM32, including the ones that are meaningless here, set to 0. Common API across MCUs, no divergence.

STM32-specific constructor parameters — good news first: most of what my old standalone LTDC code took is NOT actually STM32-specific. width, height, hsync, hbp, hfp, vsync, vbp, vfp, and signal polarity are standard RGB/DPI panel parameters — the ESP32 RGB bus needs the same porch/sync timings, so I'll map them 1:1 onto the existing constructor rather than inventing anything.

Two things from my old code that I'm dropping/relocating to fit your model:

• fb_addr (a raw framebuffer base address the user passed in) — gone. It becomes an internal detail of the STM32 allocate_framebuffer (it lands in reserved SDRAM at a fixed mapped address). The user never passes an address; they get a memoryview, exactly as on ESP32.
• Backlight and reset pins — I'll follow wherever the ESP32 side puts these (display driver vs bus). I won't keep them in the bus constructor unless that's where ESP32 keeps them.

So the only genuinely STM32-specific constructor input is the pin set — which brings me to your question.

On the pins/port assumption — you're right for a parallel GPIO bus, but LTDC works differently. Your reasoning is exactly correct for an I8080-style parallel bus where a whole GPIO port is latched and the data bits align to the port pins. LTDC is not that. It's a dedicated display controller with its own internal pixel-to-signal mapping, so:

• LTDC has dedicated signals (R0–R7, G0–G7, B0–B7, HSYNC, VSYNC, DE, CLK — up to 28 lines). Each signal can only come out on a small fixed set of pins, chosen at silicon design time via alternate-function muxing.
• These pins are NOT one port. On a real H743 board they're scattered across 4–5 different GPIO ports (PA, PB, PG, PH, PI…). There is no single "port" that defines the bus.
• There's also no data-to-pin bit alignment requirement: the framebuffer holds pixels (RGB565/ARGB8888/…) and LTDC's hardware maps them to the color lines internally. So the lane count (e.g. RGB565 = 16 color lines, RGB888 = 24) follows from the pixel format, but it doesn't come from "how many pins of a port" — it comes from which color-line signals the board actually wired up.

Practical consequence: the STM32 constructor needs the explicit list of all wired LTDC pins (one per signal), not a port + lane count. There are ~28 of them and they're board-fixed, so — per your sys.platform idea — the user never types them: a per-board Python helper (one per board) holds the pin map and panel timings and constructs the RGB bus internally. sys.platform == 'stm32' selects that path. The AF number per pin is fixed in silicon, so I resolve it inside the C driver via a lookup table; it never surfaces in Python.

If that per-board-helper approach matches how you'd like the platform-specific bits hidden, I'll build it that way. Reading the ESP32 RGB backend now to lock the exact API I need to match.

— Nuraci

[kdschlosser]

the sys.platform can still be used it would just happen to define the pins as module level variables or in the case of the ESP32 a module level constant. The STM33 pins definitions in MicroPython are done as strings and not integers which is why constant is not use unless MicroPython has coded in the ability to pass an integer representation of the pin instead of a string representation. This is where I am going to have to change up some of the ESP32 code and use the build in port specific GPIO handling instead if simply passing integers. an integer would be able to be passed but also a machine.Pin instance for the ESP32 and for the STM32 using the GPIO functions in micropython would allow for passing a string or a machine.Pin instance and an int if that can be done for the STM32 MCU's

While I know that duplicate code is not ideal to have I\ think the constructor code eve if duplicated should be expressly written for each port to keep it clean and east to follow without using helper functions and wrapper code which makes it hard to understand what is going on. I do want to remove some of that kind of code that I have done in the ESP32 port of the bus drivers. I did it the way that I did it thinking it would make it easier when porting but after looking at the code it makes it harder to understand what exactly is going on.

What are you thought on those things?

[nuraci]

Two good questions. My take on each.

Pin representation. I'd make machine.Pin the common canonical form across both ports. It's especially clean for STM32: a Pin object already carries the GPIO port pointer and pin number internally, so the C side extracts the hardware identity directly — no string lookup, no ambiguity. And since the LTDC driver has to set a per-pin alternate function anyway, it can do that from the Pin object plus a (signal, pin)→AF table.

On the int question specifically: a bare int doesn't work cleanly for STM32. On ESP32 an int is the pin identity (GPIO 0..48), but on STM32 "5" is ambiguous — PA5? PB5? PI5? There's no canonical int→pin mapping the way ESP32 has. So I'd do:

• ESP32: accept int or machine.Pin (int is idiomatic there).
• STM32: accept string ("PI10", idiomatic in the stm32 port) or machine.Pin.
• Common denominator behaving identically on both: machine.Pin.

That gives you the common API without forcing an int representation onto STM32 where it doesn't fit. Document machine.Pin as the canonical form; let each port additionally accept its native idiom.

Worth noting: my STM32 backend can accept machine.Pin (and string) regardless of how/when you rework the ESP32 pin handling, so we're not blocked on each other's changes.

Duplicated-but-explicit constructors. I agree, and I think the apparent tension with "common API" dissolves once you separate two things:

• The API — public parameter names, semantics, behavior the display driver sees — stays common. That's what keeps drivers bus-agnostic.
• The implementation inside each constructor — the actual hardware setup — is fine to duplicate per port, written straight-line and explicit. Hardware differs enough that a shared wrapper tends to leak and obscure more than it saves.

So removing the plumbing/wrapper abstraction in the ESP32 constructor sounds right. The one discipline I'd keep: for concepts that exist on both ports (width, height, timings, pixel format, framebuffer count), keep the public parameter names and meaning identical, so a driver written against one bus works against the other. Only genuinely port-specific inputs — the scattered LTDC pin list on STM32 — differ.

One distinction so we don't accidentally undo the rotation decision: the wrapper code you want to remove is plumbing. The software-rotation we agreed to pull out is an algorithm that's genuinely identical across ports — sharing that is clarity-positive, not the kind of abstraction that obscures. So "duplicate the constructors" and "share the rotation service" aren't in conflict; they sit on opposite sides of the right line.

— Nuraci

[kdschlosser]

the reason why I want to provide an option is because we are working on a memory constrained device and if we can avoid constructing that many machine.Pin instances I would like to give the user the option not to if they want. A string or an int is going to be a lot smaller of a memory footprint than a machine.Pin instance.

[kdschlosser]

and there actually is an int value that represents each and every single GPIO on an STM MCU. It's all about memory locations which is how the hardware gets accessed. I don't know if MicroPython is set up to use those values if they are passed. They might be and even it it's not we can make it so that you can pass the register and do the breakdown to get the port and pin number on the back side.

[kdschlosser]

the rotation code, dithering and byte swapping code should be able to run on any MCU. The task stuff needs to stay.

where it gets a bit hairy is there are other MCU's that are mutli-core and they are not going to use espressif's version of FreeRTOS. they might not use FreeRTOS at all. I do need to come up with a base set of structures that will hold task related handles and such. IDK if that would apply to STM32 or not.

[kdschlosser]

also with the rotation, dithering and byte swap code. we don't need to duplicate anything. Create a header file that holds all of the declarations and then create the source files to hold the actual running code. Put it in a location where any port is able to include the header file and also compile the source file. no duplication is needed ta all. You will want to change the names of some of the stuff to remove all of the RGB and rgb from it.

[nuraci]

Pins / memory footprint. Agreed on the priority — on a constrained device the lightweight form should win, and the string already gives you that on STM32: it's small, transient, and freed by the GC once the constructor resolves it to (port, pin, AF). No machine.Pin instances need to exist at all.

On the int-as-register-address: you're right that every STM32 GPIO maps to a register address, so an int could encode a pin. But I'd still pick the string for STM32, because the register-address int buys nothing over the string on memory while adding two costs:

• Not portable across STM32 families. GPIO base addresses differ (GPIOA is 0x58020000 on H7 but 0x40020000 on F4), so a register-address int ties user code to one family. The string "PI10" is abstract and valid on any STM32.
• It needs the breakdown logic you mentioned (int → port + pin), which is new code to solve a problem pin_find() already solves for free from a string.

If you ever want the absolute-minimum-RAM path (no transient string alloc at all), the clean version isn't a raw register address but a packed int — port index in the high nibble, pin number in the low (e.g. PC10 = (2<<4)|10): small, unambiguous, family-independent. I'd keep that as a future "last byte" option, not the default. For now: string or machine.Pin on STM32, int or machine.Pin on ESP32.

Shared module — a thought on who does the peel-out. This is your ESP32 code, and you know exactly where rotation, dither and byte-swap live and how they're wired in. You'd almost certainly be faster doing the extraction and the renaming yourself than I would be reverse-engineering it. So one option: you do the peel-out into the shared header/source, and I just consume that shared header from the LTDC backend. That keeps each of us on the code we know best — you on the ESP32 internals, me on the STM32 hardware where I'm the one with the boards and the datasheets.

I'm genuinely happy to do the move myself if you'd rather hand it off — it's mechanical enough — but on your own code you'd be quicker, and it keeps me focused on the part only I can do. Either way works for me.

On scope, whoever does it: the clean split is the three pure algorithms (rotation / dither / byte-swap) move into the shared header/source, and the task infrastructure stays put — you flagged it needs to stay, and it's the part entangled with the RTOS/multi-core question below.

Task stuff / multi-core — answering your STM32 question. The model doesn't transport to STM32 the way it does on ESP32. My H743 is single-core, and MicroPython's stm32 port doesn't run a preemptive RTOS — there's no FreeRTOS task to offload the refresh onto. The LTDC peripheral scans the framebuffer out to the panel autonomously via its own DMA; synchronization happens through the LTDC reload/VSYNC interrupt, not through an RTOS task. So the STM32 "frame done" equivalent is that ISR firing.

Practically: if you define a base set of task-handle structures for the common API, STM32 will populate them degenerately (or leave them unused) and signal frame-done from the reload ISR. That's fine as long as the common API doesn't require a real task/RTOS to exist. Multi-core STM32 parts (H745/H747, M7+M4) do exist but they're out of scope here and I wouldn't design for them now.

Reading the ESP32 backend now to understand the RGBBus API I need to match and how the shared functions get consumed — useful either way, whoever ends up doing the peel-out.

-Nuraci

[kdschlosser]

I hear ya with me working on my own code being faster. I know this is something you want to get done and I am really tied up into another project hat will hopefully fund my retirement so it is rather important thing to keep working on as much as possible. Time is one of those things that you can never buy more of ya know? That's the reason why I mentioned it to you so if you wanted to do the work to peel it out you could.

Give me a few days and I will make a hole in order to do some work on the library. What time of day are you typically available to put some coding time in? I don't know where in the world you are. I am UTC-7/UTC-6. it would make it easier if we could work at the same time to make sure things get done in a manner that we can both agree upon. we have a good starting point and we can go from there but there will be some bumps in the road that will need to be addressed I am sure and it would be best to have the conversations to fix those things right away instead of having to wait for the back and forth spread over a week to get them handled.

Let me know what you schedule looks like and get some time set up.

[nuraci]

Totally understand — the other project comes first, and time is exactly the thing you can't get more of. No rush on the peel-out; whenever you make that hole works for me, and in the meantime I'll keep moving on the parts that don't depend on it.

Quick context on my side so we schedule something realistic: this porting is a hobby for me. My day job is in a company doing electronic measurements in a lab, so my weekday daytime is taken. That rules out the window I'd have otherwise suggested (it lands right in my work hours).

Here's what actually works, given I'm in Italy (UTC+2 right now) and you're UTC-6/-7, ~8–9 hours apart:

• Weekday evenings my side = your late morning. My 19:00–22:00 is roughly your 11:00–14:00 (UTC-6) / 10:00–13:00 (UTC-7). This is the cleanest regular slot — I'm done with work, you're mid-morning.
• Weekends are much more flexible on my end; we can do longer blocks, still landing on your morning / early afternoon.

So a typical session would be a weekday evening my time / your late morning, 2–3 hours. Tell me which day suits you and I'll be there. If a weekend works better for a longer first session to get rolling, I'm open to that too.

One thought on making the most of the limited overlap: since we'll only share a few hours at a time, I'd reserve the synchronous sessions for the hard nodes — the design calls and the "bumps" you mentioned — and do the bulk of the coding async on either side of them. The shared hours go to the decisions that need both of us live, not to watching each other type boilerplate. Hit a bump, thrash it out, peel off and implement.

On the channel: I'd prefer text-based real-time over voice — my written English is solid but my spoken English is slower, and for dense technical work a chat keeps things precise and gives us a written trail of what we decide. Something like a Discord text channel (or a shared screen with chat alongside) would be ideal. Happy to use whatever you already live in, as long as we can type.

Good starting point. Tell me a day and a channel and let's set the first one up.

[kdschlosser]

I believe that every programmer should learn how to write code for an MCU before moving to writing anything that runs on a desktop machine. If I ever went into teaching programming the final for my class would be to write a program to perform a specific task and it has to run on something like an Arduino Uno. There would be a very small number of ways the code would be able to be written for the program to be able to run and the person would really need to think hard about the resource management aspects of it. It teaches to never be wasteful of the resources and to also do what you are doing and to check where performance bottlenecks are and to come up with ways to improve it. When I first started to write code some 10 years ago I started working on an Uno and I didn't have anyone to help me or teach me. I am 100% self taught, Asking for help in forums most times is a waste because of the god like complex a lot of programmers have when they are on a forum. It's more frustrating to deal with people like that then it is to keep trying and failing over and over again which is how I learned.

This is the reason why I am able to write that harness designer application where it is able to render more than 10 million triangles in 3D at a frame rate of 175 frames per second at a resolution of 1920 x 1080 where as a CAD style program called Chief Architect chokes when rendering a mere 3 million triangles on the exact same hardware. What the insult to injury is with that one is my code is written in Python which is some 200 times slower than C code because of the GIL and only being able to actually do a single thing at a time no matter how many threads are used. The RAM consumption of my app is very small for the kind of app it is. The use sits around 1.2GB of ram which is actually a very small amount for a 3D CAD style application.

[nuraci]

I completely agree with you on learning to write code for an MCU before moving to desktop programming. Working with constrained resources forces you to actually think about what you're doing, instead of just throwing more RAM or CPU at the problem. That discipline really does carry over to everything else you write afterward.

And that 175 fps result with 10+ million triangles in Python is honestly impressive, especially next to a commercial CAD app choking on a third of that on the same hardware. It says a lot about how much careful resource management matters more than the language itself.

I too taught myself programming many years ago. My degree is related to general electronics, but as a hobby and passion, I've delved deeper into various aspects of digital electronics and embedded systems programming. I've designed and programmed various things, and creating systems from scratch remains one of my main passions.

For example, with that board (32 MB of SDRAM) and that display (1024x600), using MicroPython, I'd like to refine the prototype (already partially functional) of a kind of PC running a Unix-style terminal, which I'd like to be able to run both MicroPython programs and binary executables.

Another fairly ambitious project I'm working on with the help of AI is a MicroPython + LVGL code generator starting from a GUI. These are very ambitious projects, and I'm not sure I'll ever finish them... :)

https://www.linkedin.com/in/nunzioraciti/

[nuraci]

I've pushed the STM32 LTDC RGBBus work to my fork if you want to look it over when you have time — no rush, it's still WIP and not a PR yet.

Compare: main...Copper-And-Code:lvgl_micropython:stm32-ltdc-rgbbus

Where to look:

• the LTDC RGBBus backend and the PARTIAL pipeline are the main pieces (rgb_bus.c / the stm32 lcd_bus sources)
• dma2d_hw.c is the DMA2D M2M copy layer (partial→framebuffer + the dirty-area resync)
• sw_rotate_interim.c is a faithful, bus-agnostic copy of your ESP32 rotate routines, clearly marked to be DELETED once your shared sw_rotate module lands — that's the piece I'd consume instead of duplicating, whenever you get to extracting it

Status: brings up the display on all four of my boards in RGB565 and RGB888, GT911 touch working in PARTIAL at all four rotation angles, USB CDC+MSC. The bus driver has no LVGL awareness (neutral rotation values, callback as a plain function pointer), per what we agreed.

No action needed from you right now — mainly wanted you to be able to see the shape of it, and the interim rotation copy, before we sort out the shared-module split.

[kdschlosser]

I will take a look see at how things are going with it later on today. This up coming weekend I will spend some time working on this project. I am going to have claude AI take a look at the generated code from the binding and write up a static binding that doesn't use the code generator so I we can upgrade to the latest version of LVGL. the latest version broke the build system in a way that is not easily repaired so it is going to require an overhaul of the code generation and I am thinking the best way it to remove it entirely due to it being overly fragile anyhow.

[nuraci]

Sounds good, thanks for taking a look. The static-binding move makes sense to me — dropping the code generator for something hand-written (with the AI doing the heavy lifting on the generated code) should be a lot less fragile, and being able to track the latest LVGL is worth the overhaul. If it also clears up some of the LVGL-v9 binding issues I ran into (the custom-theme hard-fault, for one), even better.

One more thing — I've got four physical STM32H743 boards here and I test everything on hardware with a scope. If the overhaul lands somewhere that needs validating on real STM32 hardware (the binding rebuild, a new LVGL version, anything), I'm happy to be the test bench for that side. Just say the word.

[kdschlosser]

when you get some time you should take a look at this project... It will possibly be useful for you in the future. That is the project I am working on that will hopefully fund my retirement. I am currently at more than 500 Python source files totaling over 135,000 lines of code and getting larger each day... I think it will probably be somewhere around 250K lines of code when complete. That's code that I have personally written and not total number of lines.