Remove WIP from 07

umanovskis · Feb 10, 2019 · 1ce3158 · 1ce3158
1 parent e0294ab
commit 1ce3158
Show file tree

Hide file tree

Showing 2 changed files with 2 additions and 2 deletions.
diff --git a/README.md b/README.md
@@ -15,7 +15,7 @@ This is still a work in progress. Currently available:
 * [Chapter 4](doc/04_cenv.md): Preparing a C environment. This chapter deals with the necessary work for getting from startup in assembly code to C code.
 * [Chapter 5](doc/05_cmake.md): Build & debug system. Here we show how the work can be streamlined by adding a CMake-based build system, and how the bare-metal program can be debugged.
 * [Chapter 6](doc/06_uart.md): UART driver development. In this chapter, a device driver for a UART gets written.
-* [Chapter 7](doc/07_interrupts.md): Interrupts. The chapter goes through setting up the ARM Generic Interrupt Controller, using it to receive and respond to interrupts. Also the UART driver gets adapted to use interrupts. The chapter is currently WIP.
+* [Chapter 7](doc/07_interrupts.md): Interrupts. The chapter goes through setting up the ARM Generic Interrupt Controller, using it to receive and respond to interrupts. Also the UART driver gets adapted to use interrupts.
 
 ## Repository structure
 

diff --git a/doc/06_uart.md b/doc/06_uart.md
@@ -462,7 +462,7 @@ We've written our first driver that interfaces with the hardware directly, and w
 
 Unsurprisingly, the driver written in this chapter is not perfect. Some possibilities for improvement:
 
-* Interrupt handling. Currently the driver is being used in polling mode, constantly asking it if new characters have been received. In most practical cases, polling is too inefficient and interrupts are desired.
+* Interrupt handling. Currently the driver is being used in polling mode, constantly asking it if new characters have been received. In most practical cases, polling is too inefficient and interrupts are desired. This is something that the next chapter handles.
 
 * More robustness. Error handling, sanity checks and other measures preventing the driver from being incorrectly are good! The driver could return different error codes for different types of receive errors instead of lumping them all together. The driver could keep track of its own status and prevent functions like `uart_write` from executing before the configuration has been done with `uart_configure`.