Jake Goulding

> AVRd does have the pins afaik It appears it has *access* to the pins (`bitfield`), but isn't currently making use of them.

> What do you mean? The README indicates that you can use them like you would using the arduino library: Yes, but this library currently also [relies on the pins...

Just because it was in my head, I wonder what kinds of type safety and structuring we could employ. For example: ```rust struct PORTB; impl PORTB { const PORTB7: u8...

> Another option might be to extract most of avrd to a library. That seems like it might be the appropriate path. A rough idea would be that the `arduino`...

> I remember there also being some sort of special IO register that 1 can be written to which will toggle the pin, regardless of its current state. Yep, that...

> if the interrupt vector symbol name depends on the assembly code chosen for the IVT table. Yes, it certainly does. The one shown comes from [my custom assembly](https://github.com/shepmaster/rust-arduino-blink-led-no-core-with-cargo/blob/596ac4d69513c6701ee08b8e3f2d909f9ed2a2ca/interrupt_vector.S), which...

> Is this designed to be a low level library? > > Are there plans to make it higher level I think there are *many* kinds of "lower" and "higher"...

> and to be honest a lot of the "unsafe" code is really quite safe Remember that the `unsafe` keyword means "the code inside this block upholds all of Rust's...

> Say, I wouldn't go around setting arbitrary memory values on my PC You certainly might, if [you](https://github.com/redox-os/redox) were [writing](https://os.phil-opp.com/) an [OS in Rust](https://intermezzos.github.io/). I'd say that in many cases,...

> renaming this to something like avr-hardware-utils or avr-hardware? I think renaming might have to happen for copyright concerns, but I think we can fly under the radar for a...