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

[lupyuen]

btw I saw you got a nice deployment option setup to save SDCard switching for your RISC-V work, very nice!  Any chance something similar would work for the PP. 

Hmmm we need the network to be up for the U-Boot Bootloader to fetch the boot files over TFTP. Wonder if we can connect an Ethernet Dongle over USB?

Or maybe we use this PinePhone microSD Extender?

https://pine64.com/product/pinephone-microsd-extender/

[WhiteHexagon]

yeah the networking looks like another binary blob fun and games.
I was waiting for the pinetab2 wifi dust to settle before doing another order, although I think it would still mean 2 separate orders. Maybe when the EU store has more bits I look into that option. I saw one project with two connectors and a switch, but I dont need more challenges

btw yesterday I was messing around with LVGL. A couple interesting discoveries:

Fonts: am I limited to 1 font at a time? only changing the default seems to work. I followed your post, and I see them being linked into my binary, but using them doesnt seem to override the default.

Colors: There is a mysterious difference between the canvas2d and PP, possibly just the red and blue reversed. It was late so I investigate more today, I thought it was RGBA, but I saw nuttx 32 bit color mode might be different, but that wouldnt explain the canvas2d, unless there is a byte order change on the memory blit into the screen buffer.

oh and just a minor point, I noticed the phone is a bit taller than we have been using 1440 vs 1280, since I was trying to add an extra debug area at the bottom

[Kevin Kofler]

Yes, the display size is 720×1440.

[lupyuen]

Colors: There is a mysterious difference between the canvas2d and PP, possibly just the red and blue reversed.

Yep the colours for PinePhone vs JavaScript Canvas are swapped, probably ARGB vs RGBA. We should swap the colour bytes here:

https://github.com/lupyuen/pinephone-lvg...js#L41-L50

Code:

// Load the WebAssembly Pointer into a JavaScript Image Data
const imageDataArray = new Uint8Array(memory.buffer, ptr, len)
imageData.data.set(imageDataArray);

// TODO: Swap the Colour Bytes (ARGB vs RGBA)

// Render the Image Data to the HTML Canvas
context.clearRect(0, 0, canvas.width, canvas.height);
context.putImageData(imageData, 0, 0);

To use multiple fonts, check out the LVGL Widgets Demo:

https://github.com/lupyuen2/wip-pinephon...#L172-L187

[WhiteHexagon]

https://github.com/lupyuen/pinephone-lvg...js#L41-L50

Probably going to have a performance impact? I attempted instead to change the color order in the union (lv_color32_t) in lv_color.h but no luck.  Changing the macro LV_COLOR_MAKE32 and swapping the R+B did work...  but is clearly not the solution

Today got wasted with trying to understand optionals between Zig and C.  I wasnt expecting a C pointer to become a Zig optional, and now I see why you wrapped some of the GUI objects into Zig structs   I was only trying to wrap my GUI code in a nice generics struct hehe.

Anyway I made a nice little panel so that I can better debug Register values, it just shows hex and binary values so that I can check flags, masks etc.

---

First attempt at attachments ...    

[lupyuen]

That's really cool @WhiteHexagon ! I'm preparing a presentation on NuttX for PinePhone at the Apache Community Conference, I'll share more details later :-)

Video Presentation: https://drive.google.com/file/d/1WL-6HVj...authuser=0

Presentation Slides: https://codeberg.org/lupyuen/pages/src/b...n/nuttx.md

[WhiteHexagon]

Wow, great work! I never use youtube, so thank you for the direct video link. The education idea is already really taking off with a start like that, well done! I hadn't quite realised how long you had been working on this project, since I only just got my PP. You have done well considering the lack of hard information out there! I have been feeling a bit of that frustration already. So I gave up on Lima driver for now.

Here I reorganised my Zig code into 'hardware' layer and 'api' layer. So trying to present a nice public API for interacting with my zig hardware layer. Since the audio work touches a lot of hardware, I now have in Zig minimal hardware coverage for CCU, GPIO, I2SPCM, KAYADC and the start of audio codec. The funny thing is that in the big shuffle my RGB LED code seems to also have a switched color scheme to GRB hehe or maybe the schematic is wrong and it was always like that, since it already has a conflict in the diagram

At my API level I have Volume and Led so far, the easy ones back on Audio now... I thought about rather than routing the modem audio, first of all I just try and play back a PCM sample through the speaker. Should be easy, right? Right?

[WhiteHexagon]

ok, so I found some info in the lichee sources, it seems like a whole linux, not just pinephone specific, so no wonder I was getting lost Plus I hadnt got my head around drivers/everything being file based, which made searching even harder. Maybe now I get some answers and I should have realised sooner, because I know for sure one of your articles talks about the device tree and locating drivers

[WhiteHexagon]

Well I ended up with a tight loop waiting for a Audio register lock in Zig. Seems the only approach, but it got me thinking about CPU temperatures. Looks like nothing is enabled on the SoC by default, which was quite a surprise! and worry... so switched focus again to look at that

[WhiteHexagon]

I think I got some kind of CPU thermal value, counting backwards just need to work out what value to use for CPU temperature shutdown, not that I am stressing the device too much yet

---

PS being able to do this in Zig is really nice, I get type safety on the poke() (saved me twice) and errors every time I miscount the bit flags in the registers, which saves me at least 3 times a day

Code:

pub const THS_FILT_CTRL_ADDR = Reg32(THS_FILT_CTRL_REG, THS_BASE_ADDR + THS_FILTER);
pub const THS_FILT_CTRL_REG = packed struct(u32) {
    FILTER_TYPE: Filter = Filter.TYPE4,
    FILTER_EN: bool = false,
    _3: u29 = 0,

    pub const Filter = enum(u2) {
        TYPE2 = 0b00,
        TYPE4 = 0b01,
        TYPE8 = 0b10,
        TYPE16 = 0b11,
    };
};

I am still not sure on the naming scheme still, since the ADDR and REG are pretty much the same thing, but the usage below reads okay I think, and I want to be easily searchable for the register names in the 'User Manual'.  Although probably I change the _ADDR to be _REG, and the _REG to be _VAL or _TYPE, not sure yet, will do some more work on the audio side and see what reads best   It is not very linux like, but I am still trying to get my head around linux abstractions, device trees, file based drivers, etc etc.  Just having some fun for now!   Will also probably break down the CCU chapter into smaller manageable units, it's huge as I am sure you noticed!

Code:

    var fltr = thermals.THS_FILT_CTRL_ADDR.peek();
    fltr.FILTER_TYPE = thermals.THS_FILT_CTRL_REG.Filter.TYPE8;
    fltr.FILTER_EN = true;
    thermals.THS_FILT_CTRL_ADDR.poke(fltr);