User:Darnel/Lup Yuen Lee Q&A about PineTime

Why can't you use ST-Link to remove nRF52 Flash Protection?

Because ST-Link is a High Level Adapter. It doesn't really implement all SWD functions, just a subset. For performance I think. More details in the section "Why Visual Studio Code with ST-Link (instead of nRFgo Studio with J-LINK)" in the article "Coding nRF52 with Rust and Apache Mynewt on Visual Studio Code" here: https://medium.com/@ly.lee/coding-nrf52-with-rust-and-apache-mynewt-on-visual-studio-code-9521bcba6004?source=friends_link&sk=bb4e2523b922d0870259ab3fa696c7da

Since we need a low level SWD adapter like Raspberry Pi anyway, that inspired me... Can we do EVERYTHING on a Pi instead of ST-Link + Windows?

And I'm glad it turned out very well

Here's my current progress with Pi and PineTime... https://medium.com/@ly.lee/debug-rust-mynewt-firmware-for-pinetime-on-raspberry-pi-4b9ac2d093a9?source=friends_link&sk=edb508c31e43d3ec40ecd8554f3405f6

Do I have something against JLink, the official Nordic tools, and Nordic SoftDevice?

Not really... I'm targeting the mass audience of new IoT learners trying PineTime for the very first time... Because Arduino and BBC micro:bit not so realistic in IoT any more. I think new learners would be more comfortable connecting a Raspberry Pi to PineTime, and using open source tools like VSCode. And if they wish to dig deep into the Bluetooth stack, they can with the open-source NimBLE Bluetooth stack.(edited)

Why Rust? Not C or C++?

Because I'm tired of teaching Pointers... and how to get out of trouble with Pointers It's 2020, we should move to something more modern and safer. And if it helps to create more secure IoT gadgets... All the better!

Why Mynewt? Not FreeRTOS or Zephyr?

I first tried Rust on FreeRTOS (I have an article on that)... The complexity and naming in FreeRTOS really scared me, and I don't think it's good for learners. Mynewt is a tiny, modern, modular embedded OS that's easier to pick up. It doesn't seem to have as much support as Zephyr, but that also means I get free reign to do interesting things... like run Rust! I'm keen to see how Rust on Zephyr turns out... And I wonder how soon that will happen if so many microcontroller companies have vested interest in Zephyr

Why not Bare Metal, without an OS? Why not Rust Embedded?

My response... Why reinvent the wheel? Eventually we will be forced to do some multitasking, like any IoT gadget: reading + sending sensor data concurrently, even downloading firmware in the background. Without multitasking support we'll run into a dead end... Just like Arduino and BBC micro:bit! I learnt that the hard way (I have an article on Arduino State Machines!), so I'll always start with an embedded OS that handles multitasking for me.

How do we deal with a 64k framebuffer when we need 240x240x2?

Without a full framebuffer in RAM I think we can do with smaller chunks of framebuffers. Let's say we got a logo in the centre of a black screen. The logo will make up one rectangular chunk, the rest of the black screen can be rendered as separate rectangular chunks too. Not sure if it makes sense, but it's similar to the chunking in my article... https://medium.com/@ly.lee/optimising-pinetimes-display-driver-with-rust-and-mynewt-3ba269ea2f5c?source=friends_link&sk=4d2cbd2e6cd2343eed62d214814f7b81

What is #![no_std]?

In the Rust world there's desktop Rust, which uses the Standard Rust Library... all the glorious malloc heap stuff. Growing vectors! Growing Strings! But on embedded we can't sign blank cheques to grow things on demand, so we use no_std: The Core Rust Library

No heap, no growing vectors, no Strings (well limited)

there are workarounds, which is what I have done to port the druid library

Aren't we glad that Rust actually makes a distinction between desktop and embedded programs? We dont see that in C

What is Arm Semihosting?

So we know that we use the SWD (Single Wire Debug) protocol created by Arm for flashing and debugging Arm embedded CPUs. SWD being derived from standard JTAG, but with fewer wires

With Arm CPUs you can trigger an software interrupt, and allow the debugger (OpenOCD) to do something really nifty

Display a message, read console input, dump out a file, even read a file! Thats called Arm Semihosting http://www.keil.com/support/man/docs/armcc/armcc_pge1358787046598.htm

What is OpenOCD?

OpenOCD is not for obsessive-compulsive disorder (it's Open On-Chip Debugger)... But it's the software that drives your microcontroller debugger/flasher. We need it for running any kind of flashing and debugging with Pi or ST-Link. gdb talks to OpenOCD for debugging firmware. And VSCode talks to gdb for debugging firmware visually. Phew http://openocd.org/doc-release/html/About.html#What-is-OpenOCD_003f

Do you know that OpenOCD is not officially maintained any more?

And this is especially scary because it's a core part of the open source ecosystem! There have been no official updates for years, the closest one is by ntfreak: https://github.com/ntfreak/openocd (My SPI fork is based on this)

Arm Embedded Toolchain for Pinebook Pro

Arm Embedded Toolchain for Pinebook Pro is here, if anyone needs it. It's linked with dynamic libraries, so I fear it might not work on your Pinebook Pro. Hoping to save you 7 hours of painful toolchain building... https://github.com/lupyuen/pinetime-rust-mynewt/releases/tag/v1.0.5

I'll save lesson for Arm Embedded Toolchain another day... And why it's called arm-none-eabi!