add minutes of the first meeting

Author: japaric

README.md

@@ -9,13 +9,13 @@ a great choice for embedded development.
 
 ## Roster
 
-- [@dvc94ch][] (representative of the RISCV community)
-- [@dylanmckay][] (representative of the AVR community)
+- [@dvc94ch][] (all things RISCV)
+- [@dylanmckay][] (all things AVR)
 - [@hannobraun]
 - [@jamesmunns]
 - [@japaric][] (lead)
 - [@jcsoo]
-- [@pftbest][] (representative of the MSP430 community)
+- [@pftbest][] (all things MSP430)
 - [@thejpster]
 
 [@dvc94ch]: https://github.com/dvc94ch

minutes/2018-02-20.md

@@ -0,0 +1,245 @@
+# Agenda
+
+- How to best market embedded Rust on the website?
+
+- What needs to be done to get there? Tangible goals
+
+- What can be accomplished this year? Mind these dates:
+  - April - July. impl Period. "Little to no design or RFC work will happen during this time."
+  - August 2. Epoch in beta. Material for the website should be turned in by this date.
+  - September 13. The Epoch and the new website are released.
+
+- rust-lang-nursery/embedded-wg: Re-use (migrate) rust-embedded/rfcs or create a new repo.
+
+- IRC channel for meetings / coordination: re-use #rust-embedded or make a new one?
+
+- Meeting time and format for next meetings
+
+- Project ideas for the Increasing Rust's Reach program
+  - cf. https://blog.rust-lang.org/2017/06/27/Increasing-Rusts-Reach.html
+
+# Action items
+
+- @japaric migrate rust-embedded/rfcs to rust-lang-nursery/
+- @japaric make everyone a collaborator
+- @japaric open issues for further discussion
+
+---
+
+# Notes
+
+A few members shared their thoughts before the meeting
+
+## japaric
+
+Provide a consistent development experience for ARM Cortex-M, AVR, MSP430 and RISCV
+microcontrollers. This involves different levels:
+
+- Same tooling: ~~Xargo~~ Cargo, IDE support (VS Code + RLS), `cargo flash`, `cargo debug`
+
+- Same starting point: `*-rt` crates, Cargo templates, vanilla `main`, `memory.x` for memory layout.
+
+- Large set of reusable crates: `embedded-hal` drivers, other utilities like binary serialization,
+  framing, math, etc.
+
+- Ports of multitasking models: RTFM (reactive + cooperative), Tokio-like (fully cooperative),
+  threads (preemptive), etc.
+
+Demo that Rust makes embedded development more correct (less bug hunting) and productive. This
+could be a walkthrough that involves building a non trivial application that involves a
+communication component and uses off the shelf crates from crates.io. The development could be done
+in an IDE showcasing debugging, auto completion and tracing / logging functionality.
+
+Highlight production users and applications made by the community (hobbyists)
+
+## jcsoo
+
+What is it that we really want? At a broad level:
+
+- To improve the absolute quality (functionality, safety, performance) of embedded software in the wild.
+- To improve the productivity of embedded software development teams, by reducing the tangible and intangible costs of achieving a level of quality.
+- To improve the experience for programmers developing for embedded systems.
+- To make embedded systems programming more accessible for people that are not already embedded systems developers.
+
+### Competitors
+
+- Vendor toolchains
+- Arduino
+- Mbed
+- Platform.io
+- AdaCore
+- C + Static Analysis + Valgrind + MISRA C
+- C++?
+
+### What do existing toolchains provide, and what does Rust have / need?
+
+- One-step install
+    - Rustup
+    - GCC Toolchain for GDB / LD (replace with LLD / LLDB in 2018?)
+    - Xargo (integrate with Cargo in 2018?)
+    - OpenOCD / Debugger Tools (future Bobbin-CLI development)
+    - Rust Native Debugger Tools? (future Bobbin-CLI development)
+- Simplified project creation
+    - Cargo Templates?
+- Integrated Development Environment
+    - Single step build, deploy and debug (Bobbin-CLI)
+- Higher level system configuration / code generation tools like Processor Wizard / CubeMX
+    - No exact equivalent, some of this can be replaced by Cargo and smart use of the type system.
+    - System Definition Language as future extension to Bobbin-DSL?
+- Comprehensive HAL, BSP and Peripheral drivers
+    - (Bobbin development has been focused on this, need to split out for early release)
+    - Want peripheral drivers that can be used across multiple vendor MCUs
+    - Prefer single crate per vendor MCU model, with vendor-common and arch-common crates as dependencies
+    - Theoretically would like separate low-level and high-level crates per MCU but a big hassle
+    - Board-level crates include specific configuration and board-level peripheral drivers
+- RTOS
+    - IPC Primitives
+        - Some in crates.io but want something curated and equivalent in quality to std
+    - Cooperative and Preemptive Multitasking
+        - Long term - common traits, multiple implementations?
+        - Explicit Task Management vs. Futures
+        - Learn from difficulties with Tokio + Futures - embedded devs would rather have less magic
+    - Device Driver / Network Stack Architecture
+        - Good progress on high level traits for I/O, need more implementation experience
+        - Copy vs. Zero-Copy, Sync vs Async, different ownership models have different tradeoffs
+        - Maybe look towards Linux / BSD driver APIs rather than traditional RTOS APIs
+- Stacks
+    - USB
+    - Bluetooth
+    - Ethernet + TCP/IP
+    - IoT protocols
+    - Ideally, allow implementations of upper layers interoperate with lower level drivers. Need more implementation experience.
+- Specialized Libraries
+    - DSP
+    - Motor Control
+    - Write Rust wrappers for existing libraries until native implementations show up
+- Advanced Tools
+    - Advanced Tracing + Profiling
+        - Make sure that Rust interoperates well with existing tools
+    - Hardware Simulation / Emulation
+        - Integrate with Unicorn for MCU emulation, maybe create Rust framework for peripheral emulation.
+
+### Opportunities
+
+- Encryption
+    - Ensure that there is a curated ecosystem of no-std / no-allocator compatible crates
+- Robotics
+    - Development teams are typically smaller and more agile, complexity high enough so that Rust is competing primarily against C++ / Python rather than C
+    - Some areas (Autonomous Vehicle / Drones) have huge time-to-market concerns and younger teams that have been exposed to non-embedded systems development
+- IoT / Sensor Networks
+    - Many IoT devices are too simple and cost constrained to be a good target (vendors don’t care about security issues and unwilling to innovate in firmware development)
+    but there are more sophisticated devices that need to do analysis, particularly using deep learning
+- Safety-Critical / Mission-Critical
+    - Long term goal, aim first at non-regulatory markets, leave hard-core until after further standardization
+    - Focus especially on markets where embedded Linux is considered acceptable for deployment
+- Sandboxing / Application Distribution + Updates
+    - Working on a #[no\_std], zero-allocation WASM interpreter
+
+### Language and Tooling Improvements
+
+- Fix Linking Issues
+- Improve panic / debug / fmt bloat
+- Building and deploying C libraries
+    - How can we make building and deploying Rust code for use in C projects even easier?
+    - Is it possible to build a cargo like tool that will download and install a C header file and pre-compiled .a file from the main cargo.io index? Can we make it just as easy as installing a header-only C / C++ library?
+    - At least, better integration into existing build systems
+- Better c-like enum support ideas
+    - #[repr(contiguous)] and #[repr(T, exhaustive)] to disallow gaps and incomplete enums
+        - #[repr(T, exhaustive)] enables safe casting from T to enum
+    - Numeric matches on c-like enums
+    - discriminant-only enum items
+        - enum Prescale { disabled=0, 1, 2, 3, 4, 5, 6, 7 }
+    - ranges as enum items
+        - enum Prescale { disabled=0, divider = 1…7 }
+        - enum Nibble = { 0..16 }
+        - matching on ranges
+
+``` rust
+pub enum Hour { 0..24 }
+pub enum Minute { 0..60 }
+pub enum Second { 0..60 }
+
+pub struct Time {
+   h: Hour,
+   m: Minute,
+   s: Second
+}
+```
+
+
+- Bitfields
+    - Pack c-like enums within structs
+    - Focus on usefulness for HW, file format and network protocol developers rather than purely on C interop (which is broken for bitfields anyway)
+
+``` rust
+pub struct Device {
+   #[repr(u8)]
+   control: struct {
+      power: enum { off=0, on=1 }, // 1 bit
+      mode: enum { Shake = 0, Shimmy = 1, Squirm = 2, _Reserved = 3 } // 2 bits
+      speed: enum { 0..16 }, // 4 bits
+      rotate: enum { ccw=0, cw=1 }, // 1 bit
+   },
+   #[repr(u16)]
+   x_angle: enum { 0..360 }, // 16 bits
+   #[repr(u16)]
+   y_angle: enum { 0..360 }, // 16 bits
+}
+```
+
+# Minutes
+
+Consistent development experience
+
+- Tooling
+- Starting point: e.g. cortex-m-rt
+- Re-usablbe crates: embedded-hal drivers
+- Multitasking models: RTFM, Tokio-like, threads
+
+Customer profiles
+- early adopters: hobbyists, researchers, startups
+- regular firmware developers
+- safety critical market
+
+Focus on the first group, make progress towards the second group
+
+One step setup++
+
+Make it quickly for experienced users to get started
+
+Succesful approach in std Rust: replace one C component with a Rust one
+
+Big part of the crates.io ecosystem is not available on no_std -- Portability WG?
+
+Opportunity market: developers with domain specific knowledge (robotics, CV, etc.) may not be
+familiar with existing C frameworks and may want to look for other options
+
+Traditional RTOS: threads, tasks over them, well defined interfaces for communication
+
+Vendor SDKs: "rubbish", carry too much legacy (makefiles), huge installers
+
+Building state machines for embedded systems? -- generators
+
+website: who's the audience? beginners in embedded dev? seasoned developers?
+
+how Rust compares to C, MicroPython, JS on micros? What are the advantages? tooling, etc.
+
+embedded development on stable
+- compete against stable vendor provided toolchains
+- may not be achievable, but try to reduce breakage: run tests in rust-lang/rust
+
+check for code size regressions
+
+remove panic strings
+
+OpenOCD doesn't support RISCV because of incomplete debug spec
+
+One RISCV silicon implementation; Rust works on it but needs polish
+
+## Increasing Rust's Reach
+
+- Expanding the ecosystem. Join embedded-hal, writing examples
+
+- CI for embedded
+
+- CLI for testing (HIL?)