Add Kroneum

[azasypkin]

Hey,

I'd like to showcase my Kroneum device. It's an experimental (yet), minimalist, accessible (no GUI) and fully open source (both in code and hardware) time tracker device.

• Source code: https://github.com/azasypkin/kroneum
• License: https://github.com/azasypkin/kroneum/blob/master/LICENSE
• Software: https://github.com/azasypkin/kroneum/tree/master/sw (firmware + CLI tool)
• Hardware: https://github.com/azasypkin/kroneum/tree/master/hw/pcb/Rev_0.5

NOTE: I've linked to the rendered photo even though repository contains photo of real assembled device (it just looks better than the photo taken with my not-the-best-in-class phone camera).

Would be happy to hear any improvement suggestions even if it's not accepted, thanks!

---

Evaluation guidelines

Hard requirements

• It's an application (binary crate) that runs on embedded hardware (Single Board Computer, development board or custom PCB). - YES (custom PCB + custom enclosure)

• The main logic of the application must be written in Rust. - YES (including USB CLI tool)

• The source code must be public. Licensing terms are unimportant. - YES (including PCB and enclosure design files)

Bonus points

• The project is unlike the projects currently on display. - YES (it seems)
• The documentation includes instructions on how to build the program, or the firmware can be built with just cargo build. - YES
• The repository has a CI setup. - YES (very basic one though)
• The application compiles on stable. - YES
• The application code is free from unsafe code and all unsafe code has been pushed to libraries that only expose a safe API. - NO (still have a bunch of cases where I couldn't find a good way to get rid of unsafe)
• Code that's not target specific, if any, has unit tests. - YES and NO (target agnostic api crate has a number of unit tests, but not everything is covered)
• Support code, if any, is documented. - YES (via code comments)

Penalties

• The application contains potential soundness issues. For example, using
  mem::transmute, unchecked creation of singletons and unchecked use of
  static mut variables are huge red flags. - YES and NO (still have one root static Mutex<RefCell>, cannot migrate to and not really happy about cortex-m-rtfm 🤷‍♂️ )

• Explicit panicking (e.g. unwrap) is used instead of proper error handling.
  However, note that unreachable! is OK if properly used. - YES (have a few .expect(..) at the main during device bootstrap stage)

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @ryankurte (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[adamgreig]

This looks like a great project, thanks for submitting it!

bors r+

[bors]

Build succeeded

• continuous-integration/travis-ci/push

[azasypkin]

Thanks for the quick review!