diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/ap-ec-comm.md | 14 | ||||
| -rw-r--r-- | docs/core_runtime.md | 2 | ||||
| -rw-r--r-- | docs/ec_terms.md | 2 | ||||
| -rw-r--r-- | docs/usb_updater.md | 2 |
4 files changed, 10 insertions, 10 deletions
diff --git a/docs/ap-ec-comm.md b/docs/ap-ec-comm.md index 0fc31b6822..27d5349ca4 100644 --- a/docs/ap-ec-comm.md +++ b/docs/ap-ec-comm.md @@ -112,15 +112,15 @@ the filler byte. ### SPI The SPI bus is similar to I<sup>2</sup>C, but with two major exceptions. First, -there's a minimum speed on the SPI bus. If slave devices don't respond quickly -enough, the master will assume they're broken and give up. Second, every -transaction is bidirectional. When bits are being clocked from master to slave -on the MOSI line, the master will simultaneously read bits in the other -direction on the MISO line. +there's a minimum speed on the SPI bus. If peripheral devices don't respond +quickly enough, the controller will assume they're broken and give up. Second, +every transaction is bidirectional. When bits are being clocked from controller +to peripheral on the MOSI line, the controller will simultaneously read bits in +the other direction on the MISO line. Hardware devices can usually handle this, and often some hardware-based flow -control used to "stretch" the transaction by a bit or byte if the slave device -needs a little extra time to respond to the master's demands. +control used to "stretch" the transaction by a bit or byte if the peripheral +device needs a little extra time to respond to the controller's demands. When exchanging messages with the EC on the SPI bus, the EC's host commands are communicated using our own software flow-control scheme, because most of the diff --git a/docs/core_runtime.md b/docs/core_runtime.md index 9d81b807be..680e5e4928 100644 --- a/docs/core_runtime.md +++ b/docs/core_runtime.md @@ -52,7 +52,7 @@ where you need to avoid it. The hardware interrupt requests are connected to the interruption handling *C* routines declared by the `DECLARE_IRQ` macros, through some chip/core specific mechanisms (e.g. depending whether we have a vectored interrupt -controller, slave interrupt controllers...) +controller, peripheral interrupt controllers...) The interrupts can be nested (ie interrupted by a higher priority interrupt). All the interrupt vectors are assigned a priority as defined in their diff --git a/docs/ec_terms.md b/docs/ec_terms.md index 3242302940..bd16635368 100644 --- a/docs/ec_terms.md +++ b/docs/ec_terms.md @@ -156,7 +156,7 @@ Communication involves a SPI frame, consisting of the assertion of chip select, transmitting one or more bytes on the MOSI signal, receiving zero or more bytes on the MISO signal, and de-assertion of the chip select. The - contents of a SPI frame varies based on the SPI slave type. + contents of a SPI frame varies based on the SPI peripheral type. * **UART - Universal Asynchronous Receiver Transceiver**{#uart} diff --git a/docs/usb_updater.md b/docs/usb_updater.md index 476b50f316..cd4be9f881 100644 --- a/docs/usb_updater.md +++ b/docs/usb_updater.md @@ -44,7 +44,7 @@ will use `hammerd` (in `src/platform/hammerd`) to update the device. Update protocol --------------- -The host (either a local AP or a workstation) is the master of the firmware +The host (either a local AP or a workstation) is the controller of the firmware update protocol, it sends data to the Cr50 device, which processes it and responds. |