A couple of typos

Author: jamesmunns

src/peripherals/a-first-attempt.md

@@ -65,7 +65,7 @@ fn do_something() {
 }
 ```
 
-But the problem with this is that our `SerialPort` struct could be created anywhere. By creating multiple instances if `SerialPort`, we would create aliased mutable pointers, which are typically avoided in Rust.
+But the problem with this is that our `SerialPort` struct could be created anywhere. By creating multiple instances of `SerialPort`, we would create aliased mutable pointers, which are typically avoided in Rust.
 
 Consider the following example:
 

src/peripherals/borrowck.md

@@ -7,7 +7,7 @@ Unfortunately, hardware is basically nothing but mutable global state, which can
 How can we reliably interact with these peripherals?
 
 1. Always use `volatile` methods to read or write to peripheral memory, as it can change at any time
-2. In software, ee should be able to share any number of read-only accesses to these peripherals
+2. In software, we should be able to share any number of read-only accesses to these peripherals
 3. If some software should have read-write access to a peripheral, it should hold the only reference to that peripheral
 
 ## The Borrow Checker
@@ -16,4 +16,4 @@ The last two of these rules sound suspiciously exactly like what the Borrow Chec
 
 Imagine if we could pass around ownership of these peripherals, or offer immutable or mutable references to them?
 
-Well, we can, but for the Borrow Checker, we need to have exactly one instance of each peripheral, so Rust can handle this correctly. Well, luckliy in the hardware, there is only one instance of any given peripheral, but how can we expose that in the structure of our code?
+Well, we can, but for the Borrow Checker, we need to have exactly one instance of each peripheral, so Rust can handle this correctly. Well, luckliy in the hardware, there is only one instance of any given peripheral, but how can we expose that in the structure of our code?