Article: NuttX RTOS for PinePhone: Feature Phone UI in LVGL, Zig and WebAssembly

[WhiteHexagon]

I understand, thanks, I have to return to that when I understand more

I am trying to do the same with the LCD startup sequence still. I think I finally found my problem with it. The A31 user manual talks about the TX register byte order being 3,2,1,0, 7,6,5,4, etc but I think it is actually the other way around! ie sequential. I had some confusion because to check the []u8 being written, I was pulling pack u32 so that I could use my handy GUI register debug panel, but seems like Zig might have been doing some Endianess tricks reading the u32, still not quite sure, but feel like I am getting closer! Also the CMD_CTL register seems to be mis-documented, possibly 1 bit out, not sure yet. So very slow days at the moment, but as a result my debug tool collection increases

I hope you are making better progress with the PineTab-V

[WhiteHexagon]

Well it involved quite a few calls from Nuttx up into my Zig layer to debug and get things working. It also involved learning about Zig slice of slice '''[]const []const u8''' which was a bit painful given the current state of Zig documentation. And I stored some intermediate calculated LCD init commands in the end, vs implementing the CRC and packaging headers etc. It feels fragile, but works!

Anyway onwards to your Framebuffer article

[WhiteHexagon]

So framebuffer is kinda decoded, I have to pass the fb pointers up to Zig to get it to work, since I am not sure how LVGL is accessing them yet, seems to be via a driver? Ideally I want to allocate the fb on the Zig side and have LVGL access that directly. Anyway, all good fun still. I also want to clean up my dev environment and have a test with new Zig

[Kevin Kofler]

A frame buffer is normally a buffer provided by the hardware (using memory-mapped I/O (MMIO) or DMA) or by the driver where the userspace can just write to the predetermined address. So yes, using the pointer returned by the driver is how you use it. If you want to allocate your own buffer, that would be double-buffering, so then you need to "blit" (copy) your double buffer into the real frame buffer regularly (usually in some interrupt handler, synchronized to the screen refresh to avoid flickering). It can make sense on some hardware, not so much on other hardware. I do not know the internals of the PinePhone display hardware well enough to be able to tell you whether it makes sense here. (Well, technically, some hardware also allows you to remap its DMA to a different address, provided by you, usually under some constraints such as a minimum alignment, but I do not know whether this is possible on the PinePhone.)

[WhiteHexagon]

(Well, technically, some hardware also allows you to remap its DMA to a different address, provided by you, usually under some constraints such as a minimum alignment, but I do not know whether this is possible on the PinePhone.)

Thanks Kevin, yes, this is what I try to do, DMA accessed, direct memory without a driver, and no blit. I hope this will allow me eventually some hardware GPU acceleration, if I ever find documentation for the openVG, or if not just access to the 3 planes and mixers for some UI effects.  Lets see   Currently my USB micro SD card adapter broke, so testing is on hold for a few days, and it has prompted me that I really should have an extension cable for the PP card slot to avoid too much ware n tear during development, but struggling to find one locally.

After that I might have another go with the audio routing, now that I have so much of the SoC working in Zig I feel a bit more confident to try again.  Unless the PineTab-V comes back in stock before then!

btw I did see mention of some kind of recovery mode, 'FEL Mode' that sounds useful for development, but no way to switch the PP into this mode?