Difference between revisions of "User:Darnel/Lup Yuen Lee Q&A about PineTime"

From PINE64
Jump to navigation Jump to search
(Created page with ";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 perfo...")
 
(Moving general questions to FAQ)
Line 1: Line 1:
;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?
;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)
: 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)
Line 26: Line 19:
: there are workarounds, which is what I have done to port the druid library  
: 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
: 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!

Revision as of 00:37, 26 January 2020

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
Retrieved from "https://wiki.pine64.org/index.php?title=User:Darnel/Lup_Yuen_Lee_Q%26A_about_PineTime&oldid=4807"