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

[WhiteHexagon]

I got stuck with the audio again, and decided to look for other simple bits of the phone, I was thinking flash light LED and only just now came across your nice article on the RGB LEDs, and I felt silly I missed that, since everything was already in there, including PIO explanation the backwards schematic hehe. I added the link here again before I lose it, but there are so many articles I wonder now what else I missed 

https://lupyuen.github.io/articles/pio

[lupyuen]

Haha @WhiteHexagon you're going great! I hit the same roadblocks that you mentioned, sometimes it helps to check out the source code from Linux / FreeBSD / U-Boot and see how they do it :-)

[WhiteHexagon]

@lupyuen hehe easier said than done, that's why I gave up on the OpenGL ES / LIMA for now, its like navigating a new city with a mostly compatible map, and a guide book listing possible alternative street name signs, but then also not knowing how to drive

Anyway I read your informative article about the LCD backlight, nice work figuring out the missing register for the PWM! although it didnt stop me from trying to use the wrong one at first but at least now I can dim the screen, although not sure what limits the values have.

btw I like your approach listening to how other software touches the registers, great idea!

I found the motor control, but then reaslised I needed something asynchronous to switch it off again...

So I have been playing with the Timer registers, thinking a 200ms delay and callback to switch it off would work. So that involved trying to move some interrupt code up into Zig, although I didnt get far.

First I couldnt work out how to pass a Zig function handle down to the 'C' layer for the interrupt callback. So instead I tried a single call from C to Zig for all interrupts. That worked perfect for the first interrupt, but when I ported my VOL button code to use the same approach, I found my export fn within a struct ended up as a duplicate symbol on the zig side So back to the drawing board but at least I got the timer working! now I need to understand it better hehe. It looks like nuttx stores stack state whilst the interrupt is called, so shouldnt be any threading/memory guard issues here either right?

[WhiteHexagon]

Code:

pub const I2S_PCM0 = IRQ(45);
pub const I2S_PCM1 = IRQ(46);
pub const I2S_PCM2 = IRQ(47);
pub const PG_EINT = IRQ(49);
pub const TIMER0 = IRQ(50);
pub const TIMER1 = IRQ(51);

fn IRQ(comptime irq: u8) type {
    const cache = struct {
        var lookup: [IRQ_LIMIT]*const fn () void = undefined;

        pub export fn zigInterruptHandler(id: c_int) void {
            const handler = lookup[@intCast(u8, id)];
            handler();
            debug.green(true);
        }
    };
    return struct {
        const irqNo: u8 = irq;
        var enabled: bool = false;

        pub fn enable(handler: *const fn () void) void {
            if (!enabled) {
                c.enableIRQ(irqNo);
                cache.lookup[irqNo] = handler;
                enabled = true;
            }
        }
    };
}

Oh and the code if you are interested.  It works if I move the exported fn and lookup table up to the file level, but since that is also just a 'struct' in Zig, I thought this might work.

[WhiteHexagon]

@lupyuen
I got a bit stuck.  I am trying to add a gesture event handler to your LVGL featurephone Zig code.  I think it is a similar problem that I hit trying to pass the fn() for my interrupt handler over to C.  The magic zig spell doesn't seem to be documented, but then what is these days

This code complains the function handle is optional but I dont understand why, or how to fix it.  If I pass null for the 'event_cb' param it compiles, so I think that is where the issue is...  any ideas please?

Code:

const handle: ?*c._lv_event_dsc_t = c.lv_obj_add_event_cb(c.lv_scr_act(), eventHandler, c.LV_EVENT_GESTURE, null);
    _ = handle;
...

pub fn eventHandler(event: ?*c.lv_event_t) callconv(.C) void {}

error:

Code:

eature-phone.zig:98:1: error: expected type
'*.home....cimport.struct__lv_obj_t'
, found
'?*.home....cimport.struct__lv_obj_t'

[WhiteHexagon]

I copied your button event handler, and now it compiles but not sure if it runs... I dont see Gesture events being generated for the Screen.
I had a look into lv_indev.c, specifically around where it tries to calculate the velocity of the movement, and I can see that 'act_point' and 'last_point' are generating the same value, hence no velocity. I'm investigating on the WASM side and see if I can work out what's going on.

[WhiteHexagon]

Hi professor! so the best way to learn is to do, right? so this week I am studying your display driver article, and trying to recreate the steps in Zig, also based on the p-boot logs you analysed. This week has been all about tcon, and I am almost ready to test that... before hopefully starting on DE, but once again I am impressed with how much work you have put into this project! I hope I can return to the Audio stuff soon and return some knowledge. Although I spent some time just trying to understand the phrase 'deassert' so still lots to learn here, but I dont recall my Amiga 68000 assembly days being as hard or complicated, must be my age Anyway I noticed a new Zig version, so hopefully I dont have to change OS again to test that but this 'packed struct' register approach has saved me numerous times, so I look forward to seeing what other goodies they added, but hopefully it slows down now, feels very complete already. Well done on the RISC-V milestone btw

[lupyuen]

Hihi @WhiteHexagon sorry the past week has been very stressful for me while merging Star64 into NuttX Mainline, but I'm so glad it's finally done! :-)

So how can I help you now? Yeah getting Zig into LVGL / NuttX Kernel can be tricky, I might have some useful tricks :-)

[WhiteHexagon]

Hi @lupyuen , congratulations on the milestone! You raced through that one   In the meantime I only just finished testing my 'tcon' and 'de' implementations in Zig.  Last 'gotcha' was SRAM_CTRL_REG1 having a default value, meaning undocumented, that needed to be zeroed.  I find all these undocumented hacks really unsettling.  For example on the tcon side I removed the delay after PLL_VIDEO0 and instead looped waiting for the LOCK bit, no idea if that is valid, but seems to work and removes one mystery delay() call (which anyway I could not work out how to implement in Zig), but it would be nice to have confirmation on all these small tweaks that seem to be needed.  I guess all the developers moved onto new shinny PineTab toys   Although it seems to have gone very quiet regarding blog news etc, 4 months? did I miss some other news regarding the community?  Anyway I think I continue a while longer, since this is good for exercising my Zig skills.

So what is next for you? the educational plans? or LVGL on star64?

Code:

    //step 1 - configure PLL
    var pll = ccu.PLL_VIDEO0_CTRL_REG.peek();
    pll.PLL_ENABLE = true;
    ccu.PLL_VIDEO0_CTRL_REG.poke(pll);
    //wait PLL stable
    while (ccu.PLL_VIDEO0_CTRL_REG.peek().LOCK == false) {
        lockWaitCntr += 1;
        if (lockWaitCntr > 10000) {
            debug.red(true);
            return;
        }
    }

[lupyuen]

Yep @WhiteHexagon, Zig is a really cool way to experiment with PinePhone Hardware!

I'm so happy that some folks have started porting NuttX to PinePhone Pro! I'm helping to review their code.

Also I'm now exploring NuttX for PineTab-V. So things are getting very interesting :-)