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

[PineFone]

For those of us who aren't python proficient, will there be an OS Image like for how there are for Arch, Manjaro, etc.?

Or is this intended for skilled programmers only to play around with?

[WhiteHexagon]

I hope this will get you started :-)

Indeed that should keep me quiet for a good while, many thanks!  Amazing documentation!  And good the see the MIC is already through ADC and PCM, I was suspecting analogue, so that already is a huge time save.  Now I just need my 1990's A3 plotter and 50m of wall space

Abbreviations link for future me:

https://wiki.pine64.org/wiki/PinePhone_component_list

[lupyuen]

For those of us who aren't python proficient, will there be an OS Image like for how there are for Arch, Manjaro, etc.?

Hihi: Sorry NuttX for PinePhone is still in active development, not quite ready for use yet. If we're keen to try, here are the instructions to boot NuttX on microSD (without touching the eMMC storage):

https://lupyuen.codeberg.page/articles/w...boot-nuttx

[WhiteHexagon]

I hope this will get you started :-)

Indeed, a fun week was had   I decided to start simple.  At first I was looking for the RGB LEDs (a green one triggers when the demo boots) but I couldnt find it, so maybe they are hardware controlled. 

Anyway I decided to try the VOL +/- buttons, since I wanted something very simple to see how the nuttx layer interacts with the Zig layer. The C include on the Zig side was a bit of a pain, until I remembered you mentioned somewhere only to include C stuff once, after that fix it was easier, although my include is deep into the nuttx layer, since I added the ADC logic under the src/a64 folder. 

Polling the ADC was defaulting to high value, not zero, maybe that is a pull-up? resister on the schematic (page 12).  And my microelectronics knowledge is poor and 30 years old hehe but it looks like the two resistors are designed to generate two different voltages for the ADC.  I tried to calculate the voltages there, 3V in, but ADC expecting 2V, and I think the signals work with the ADC default config of 1.7V, although then I was suspecting the pull-up acts in parallel...  as I said, very rusty old brain.  The KEYADC_DATA_REG (page 277 A64 user manual) produced some different values when I finally realised I needed to enable the CTRL register (KEYADC_EN).

I was expecting something like + at 1.64V and - at 1.8V, but with a 6 bit resolution, and assuming 2V spread, I see .35V and .16V, and assuming these pull down from 2V, that would give 1.65V and 1.84V, close enough... and either side of the configured 1.7V.  Phew, I am sure I am totally wrong with all that but it works! ie value 5 for VOL+ and value 11 for VOL-, but since this is ADC I suspect I should be doing a +-2 range check... oh and I somehow expected both buttons together would generate a different value, but they dont.

Not quite the simple start I expected but good fun.

I didn't try the IRQ approach so far... since that would mean calling from C to Zig, gulp!  My next challenge

PS congrats on your article re RISC-V, it was no. 12 on HN when I spotted it

[lupyuen]

Haha thanks @WhiteHexagon you're doing great! :-)

I'm making great progress with NuttX on RISC-V Star64 SBC, I just figured out how to boot a tiny bit of NuttX on Star64...

Boot NuttX on Star64

[WhiteHexagon]

@lupyuen

Thanks! Looks like you are also having fun well done! and a fun read.

My last assembly was 68000 era and I really fancy having a play with RISC-V at some point. But I am waiting for the dust to settle with the new product roll-outs here. I dont read outside of the forum, but it has gone strangely quiet. Did you get the PineTabV as well to test? I think that is what I'll eventually order.

Anyway I have plenty to keep me busy with the PP! I spent the day going through a lot of your display panel code, looking at GIC, and trying to track down the 'xcpt_t' definition, and 'irq_attach' (still not found them). I am tempted to try and delete anything non PP based from nuttx to help my struggling old MBP/manjaro install trying to run slow electron app... and I miss an IDE with 'goto definition' type functionality.

Anyway I got a bit distracted looking at the way you got the touch panel working, nice but it tricked me at first thinking PIO was interrupt related hehe. And the concept of file based devices was a surprise for me, although I know unix/linux takes this approach, I have never seen driver code before, so inode priv counter guards was a fun exploration. I think my first steps will be a bit more hacky until I understand the concepts better

---

PS okay so my misunderstanding, so as you mention below, PIO does in fact generate A64 interrupt, in response to the panel touch interrupt signalling on the PIO pin. phew, step-by-step

https://lupyuen.github.io/articles/touch...pt-handler

[WhiteHexagon]

Yay! first interrupt is working, now to understand how

btw Do you possibly know how the memory guards work between Zig and C for what we are doing? ie I assume there is an event thread running for LVGL somewhere... and I also assume that nuttx has its own threads running somewhere. Which means that my call upon a touch screen button event, down into the C layer, is probably on a different thread to the one generating IRQ events within the C layer. I made the shared int volatile for now, but I would like to better understand if my assumption are correct and if there is a better memory synchronization approach to be used? And I also seem to recall we are single CPU at the moment...

[lupyuen]

I assume there is an event thread running for LVGL somewhere

Actually there isn't an Event Thread for LVGL :-)

If you remember our WebAssembly Article, our LVGL App calls LVGL periodically to execute Background Tasks (lv_timer_handler).

For PinePhone, lv_timer_handler is called by the Main Function of lvgldemo:

https://github.com/apache/nuttx-apps/blo...#L240-L249

lv_timer_handler will trigger a callback to read a Touch Sample:

https://lupyuen.codeberg.page/articles/t...our-driver

So no worries about clashing threads! LVGL looks really simplistic because it's meant to run on Bare Metal Hardware without threading. Which makes things easier for us :-)

[WhiteHexagon]

Perfectly explained as always, thanks

I had a funny moment of enlightenment after a couple more days re-learning C. The whole point of this was to exercise my Zig skills, so then I had some fun porting my KEYADC code back up to the Zig layer. Some inspiration for Register handling from link below, but using a packed struct(u32) for bool bit flags. Looks like Zig are currently adding some builtins to improve this usecase.

https://www.scattered-thoughts.net/writing/mmio-in-zig/

My interrupt code is working, but I seem to miss the occasional KEYUP event, so next job is looking at that in more detail. I got some debug back on the display now, and found a bigger font that my eyes can read

PS the missing interrupts are regardless of C or Zig, so maybe something GIC layer, next learning exercise

[lupyuen]

Thanks @WhiteHexagon you're on the right track! :-)

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)

Brainstorming some Education ideas for PinePhone... Perhaps a team of 4-5 students could work on a PinePhone Project on Apache NuttX RTOS:

(1) Turn PinePhone into a Feature Phone: We have a Feature Phone UI for NuttX, now we need to write the code (AT Commands) to make phone calls (or send SMS):

https://lupyuen.codeberg.page/articles/lvgl4.html

The UI is currently in Zig, which is great for Education because of the Runtime Checks (array out of bounds, integer overflow, null pointers). But we can adapt the code for C or Rust.

(2) Accelerometer Experiments: We have a working Accelerometer / Gyroscope / Temperature Sensor on NuttX for PinePhone. We might turn it into a Touchscreen Game maybe?

https://www.hackster.io/lupyuen/inside-a...tos-b92b58

(3) Contribute Drivers for NuttX: Advanced students could build the NuttX drivers for the PinePhone Sensors: Magnetometer, Light and Proximity Sensors.

https://lupyuen.codeberg.page/articles/p...ne-sensors

This might be a good opportunity to experience the Open Source contribution process. (The NuttX folks are very friendly) And they might see their contribution captured in NuttX RTOS for posterity!

https://lupyuen.codeberg.page/articles/pr.html

(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 :-)