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

From PINE64
Revision as of 00:37, 26 January 2020 by Darnel (talk | contribs) (Moving general questions to FAQ)
Jump to navigation Jump to search
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