randomskk | 4 years ago | on: Oxide on My Wrist: Hubris on PineTime was the best worst idea
randomskk's comments
randomskk | 4 years ago | on: Is Rust Used Safely by Software Developers?
The exclusivity/atomicity in that case is ensured because the method is called on "p.SIO", an object that can't be accessed from both ISRs and the main code at the same time in safe Rust (because it doesn't "implement Sync"). If both an interrupt and the main thread need to access that peripheral, you need to provide some way of sharing it - either using `unsafe`, or in safe code by using a synchronisation primitive such as a critical-section based Mutex that provides that guarantee.
The book chapter you've linked to starts out by demonstrating what is essentially how you'd write this in C and thus requires unsafe, but it builds towards a safe solution - when using either the Atomic* variables (in the Atomic Access section) or mutexes (in the Mutex section), `unsafe` isn't required any more; the user's code is only safe Rust which provides synchronised access to the shared state between the main thread and the ISR.
In other words, the benefit over C is that it _is_ now possible to use only safe Rust to access memory and peripherals from both interrupts and the main thread, and that safe Rust is itself ensuring you can't cause race conditions. The unsafe option is there as a building block for those safe abstractions.
> So at the end of the day it's just C with different syntax, and a lot more hoopla. You've made everything mutable and unsafe.
Perhaps that chapter isn't getting the right message across then. The goal is to completely avoid applicaton code having to make things mutable and unsafe by providing the right abstractions that allow safe Rust to get the same work done while ensuring there are no races.
randomskk | 5 years ago | on: Designing a RISC-V CPU, Part 1: Learning hardware design as a software engineer
nMigen is a pretty fledgling project so there aren't a ton of big projects in it yet, but for example Luna[0] (from the makers of the HackRF) implements a full USB stack including USB3 support, with enough abstraction that you can create a USB-serial converter inside your FPGA using two I/Os for full-speed USB and wire it into the rest of your project in about ten lines of Python[1].
[0]: https://github.com/greatscottgadgets/luna [1]: https://github.com/greatscottgadgets/luna/blob/master/exampl...
Migen, the Python-based project nMigen is based off, has been around for longer and has some large projects, such as LiteX[2] which uses Migen to glue together entire SoCs, including peripheral cores such as GigE, DDR3/4, SATA, PCIe, etc, all written in Migen, and is pretty widely used. It also pulls in Verilog/VHDL designs (such as many of its CPU core choices) since it's easy to pull in those from the Python side.