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

[WhiteHexagon]

Hi @lupyuen   yes I can picture you teaching this topic, just by the quality and fun approach of your articles   I think it could be a great idea! there is certainly plenty of stuff still to work on, it has taken me a week to get VOL+/- working, and that is just the buttons hehe.  btw here is the Zig code I ended up with using the Register approach I mentioned.  I am not keen of uppercase naming and KEYADC prefixing everywhere, but at the same time I like that the code can be easily cross referenced to the A64 User Manual.  Anyway I am sure the corporate paid influencers will spoil Zig before I make it to the next level but I like the enum that doesnt impact the packed struct size.  The Zig compiler is also keeping an eye on the packed struct size matching u32, nice.

Code:

pub const CTRL_REG = packed struct(u32) {
    KEYADC_EN: bool = false,
    _1: u1 = 0,
    KEYADC_SAMPLE_RATE: u2 = 0,
    LEVELB_VOL: u2 = 0,
    KEYADC_HOLD_EN: bool = false,
    KEYADC_HOLD_KEY_EN: bool = false,
    LEVELA_B_CNT: u4 = 0,
    KEY_MODE_SELECT: Mode = Mode.NORMAL,
    _2: u2 = 0,
    CONTINUE_TIME_SELECT: u4 = 0,
    _3: u2 = 0,
    _4: u2 = 0,
    FIRST_CONVERT_DLY: u8 = 0,

    pub const Mode = enum(u2) {
        NORMAL = 0b00,
        SINGLE = 0b01,
        CONTINUE = 0b10,
    };

    pub fn asU32(self: CTRL_REG) u32 {
        return @bitCast(u32, self);
    }
    pub fn fromU32(v: u32) CTRL_REG {
        return @bitCast(CTRL_REG, v);
    }
};

pub fn enable() void {
    //enable KEYADC
    var ctrl = CTRL_REG.fromU32(KEYADC_CTRL.read());
    ctrl.KEYADC_EN = true;
    ctrl.KEY_MODE_SELECT = CTRL_REG.Mode.SINGLE;
    KEYADC_CTRL.write(ctrl.asU32());

    //enable all interrupts
    KEYADC_INTC.write(INTC_FlagsAll.asU32());
}

and the Reg32:

Code:

pub const Reg32 = struct {
    ptr: *volatile u32,

    pub fn init(addr: usize) Reg32 {
        return Reg32{ .ptr = @intToPtr(*volatile u32, addr) };
    }

    pub fn read(self: Reg32) u32 {
        return self.ptr.*;
    }

    pub fn write(self: Reg32, v: u32) void {
        self.ptr.* = v;
    }
};

[tllim]

BTW We might have a chance to teach this in school! I'm chatting (remotely) with a High School Teacher, we're trying to figure out how PinePhone might work for Education.

I think PinePhone (with NuttX) might be a good tool for students to appreciate the internals of a Modern Smartphone. (Without the complexity of a huge OS like Linux)

(4) I'll chat with Pine64, see if they might have Educational Discount for Bulk Purchase of PinePhone.

I used to teach Operating Systems at the Pre-University Level, and I found it incredibly frustrating that we couldn't use our phones as a teaching tool. I think we have a great opportunity today, I'm totally open to ideas how we can teach better :-)

Awesome, for sure I will support this education project

[lupyuen]

Thanks @tllim and @WhiteHexagon, I'll keep you updated :-)

[WhiteHexagon]

@lupyuen So today I started looking at connecting the volume buttons to some chip feature.. So I am going through 200+ audio registers and already found around 9 that mention Volume oh and an interesting reference to a register that doesnt seem to exist: Page 362 User Manual A 64 'AC_PR Configuration Register(AC_PR_CFG_REG)' Since that has a couple LINEOUT registers, and DAC that might be relevant. Anyway it is all good fun, but I was just laughing to myself that I should be signing up for your new course too

[WhiteHexagon]

PS and the chapter on I2S/PCM looks like a perfect starting point for actual audio stuff, thanks again!

[WhiteHexagon]

@lupyuen  So I am making slow but steady progress with the Audio stuff (page 625 / 7.6.5. A64 user manual).  I had a slight detour to improve the Zig Register concept, which allows me to generate quite readable code I think, eg.

Code:

    var pllCtrl = ccu.PLL_AUDIO_CTRL.peek();
    pllCtrl.PLL_ENABLE = true;
    ccu.PLL_AUDIO_CTRL.poke(pllCtrl);

I have most of the five step process in place (around 11 registers to configure), although some are a little vague, and I spotted some typos in the document.  But the challenge sounds like Step 3 (section: 7.6.5.2).  Here it all gets very vague, referring to I2C and I2S configuration, external documents, and not much actual info on what is required.  Have you come across extra documentation in this area at all please?

[lupyuen]

Here it all gets very vague, referring to I2C and I2S configuration, external documents, and not much actual info on what is required.  Have you come across extra documentation in this area at all please?

Hmmm sorry, I think we might need to hunt for the Linux Drivers and understand the code. The PinePhone Device Tree might tell us where to find the Linux Driver:

https://lupyuen.codeberg.page/articles/p...evice-tree

[WhiteHexagon]

OK Thanks. I started down that path yesterday, but got lost in the woods Given that the PinePhone is geared towards developers, I am a bit surprised that there is not a much bigger documentation pack / knowledge base. Curious to know if everyone that comes along solves all these basic problems again? I dont mind at the moment, because I am having fun with some real programming very close to the metal but still I was a bit surprised reading some of your detailed articles how hard you had to work to get all the information into one place for the nuttx work. So well done again for that effort!, and your first student lesson can be teaching them to document their research methodology as well as you do

I also thought about looking into using the mali OpenVG to accelerate the LVGL, but again the 'user manual' gives next to no information. Online I got as far as there is a patched version of a mesa library somewhere around that probably got dropped by linux,... and then there is 'Lima'? open source replacement, but no mention of openVG.

Maybe I should stick with buttons and track down the Power button next

[lupyuen]

Curious to know if everyone that comes along solves all these basic problems again? 

Haha yeah the docs are all over the place. If I understand correctly, Allwinner contributed a huge chunk of Linux Code at the beginning, but they probably weren't well-documented. That's why I chose to re-document everything that I touched :-)

[WhiteHexagon]

ok it seems like hardware OpenVG acceleration is going to involve the binary blob mali driver Not sure if OpenGL is another option because the documentation is still hiding from me. I found a 5GB lichee_BSP4.9 something or other linux bundle, thinking there must be docs and examples there, but nothing so far.

So I turned my attention to something 'simple' again The RGB LEDs, since I start to understand the GPIO, or at least I thought I did. Seems like they should just be switchable on pins PD18,PD19,PD20. I configured those pins as 'output', set the Data pins high, and even tried enabling the pio gating register. No luck so far... I am wondering about the pull up/down resistors, or maybe they are multiplexed for something else?

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. I am very gentle swapping the SDCard, but it feels like a risk in the long term. I even though about trying to get an old A64? board to experiment with, but then I would not have the same volume buttons and LEDs to challenge me

[Edit 1] Silly me, I had the LED registers copied as per doc, instead of my packed struct with MSB at the bottom hehe. LEDs working
[Edit 2] And the gating was not required.