Docs: minor fixes.

Author: peterhinch

FASTPOLL.md

@@ -1,8 +1,8 @@
-# fast_io: An experimental modified version of uasyncio
+# fast_io: A modified version of uasyncio
 
 MicroPython firmware now enables device drivers for stream devices to be
 written in Python, via `uio.IOBase`. This mechanism can be applied to any
-situation where a piece of hardware or an aysnchronously set flag needs to be
+situation where a piece of hardware or an asynchronously set flag needs to be
 polled. Such polling is efficient because it is handled in C using
 `select.poll`, and because the coroutine accessing the device is descheduled
 until polling succeeds.
@@ -16,7 +16,7 @@ This version has the following changes:
  [PR287](https://github.com/micropython/micropython-lib/pull/287).
  * The bug with read/write device drivers is fixed (forthcoming PR).
  * An assertion failure is produced if `create_task` or `run_until_complete`
- is called with a generator function [PR292](https://github.com/micropython/micropython-lib/pull/292)
+ is called with a generator function [PR292](https://github.com/micropython/micropython-lib/pull/292).
 
 A key advantage of this version is that priority device drivers are written
 entirely by using the officially-supported technique for writing stream I/O
@@ -25,32 +25,28 @@ means than by these proposals, application code changes are likely to be
 minimal. Using the priority mechanism in this version requires a change to just
 one line of code compared to an application running under the official version.
 
-The high priority mechanism in `asyncio_priority.py` is replaced with a faster
-and more efficient way of handling asynchronous events with minimum latency.
-Consequently `asyncio_priority.py` is obsolete and should be deleted from your
-system. The facility for low priority coros is currently unavailable.
+The high priority mechanism formerly provided in `asyncio_priority.py` is
+replaced with a faster and more efficient way of handling asynchronous events
+with minimum latency. Consequently `asyncio_priority.py` is obsolete and should
+be deleted from your system. The facility for low priority coros is currently
+unavailable but will be reinstated.
+
+This modified version also provides for ultra low power consumption using a
+module documented [here](./lowpower/README.md).
 
 ###### [Main README](./README.md)
 
 # Contents
 
- 1. [Installation](./FASTPOLL.md#1-installation)
-
-  1.1 [Benchmarks](./FASTPOLL.md#11-benchmarks) Benchmark and demo programs.
-
- 2. [Rationale](./FASTPOLL.md#2-rationale)
-
-  2.1 [Latency](./FASTPOLL.md#21-latency)
-
-  2.2 [Timing accuracy](./FASTPOLL.md#22-timing-accuracy)
-
-  2.3 [Polling in uasyncio](./FASTPOLL.md#23-polling-in-usayncio)
-
- 3. [The modified version](./FASTPOLL.md#3-the-modified-version)
-
- 4. [ESP Platforms](./FASTPOLL.md#4-esp-platforms)
-
- 5. [Background](./FASTPOLL.md#4-background)
+ 1. [Installation](./FASTPOLL.md#1-installation)  
+  1.1 [Benchmarks](./FASTPOLL.md#11-benchmarks) Benchmark and demo programs.  
+ 2. [Rationale](./FASTPOLL.md#2-rationale)  
+  2.1 [Latency](./FASTPOLL.md#21-latency)  
+  2.2 [Timing accuracy](./FASTPOLL.md#22-timing-accuracy)  
+  2.3 [Polling in uasyncio](./FASTPOLL.md#23-polling-in-usayncio)  
+ 3. [The modified version](./FASTPOLL.md#3-the-modified-version)  
+ 4. [ESP Platforms](./FASTPOLL.md#4-esp-platforms)  
+ 5. [Background](./FASTPOLL.md#4-background)  
 
 # 1. Installation
 
@@ -69,7 +65,7 @@ The benchmarks directory contains files demonstrating the performance gains
 offered by prioritisation. They also offer illustrations of the use of these
 features. Documentation is in the code.
 
- * ``benchmarks/rate.py` Shows the frequency with which uasyncio schedules
+ * `benchmarks/rate.py` Shows the frequency with which uasyncio schedules
  minimal coroutines (coros).
  * `benchmarks/rate_esp.py` As above for ESP32 and ESP8266.
  * `benchmarks/rate_fastio.py` Measures the rate at which coros can be scheduled
@@ -126,7 +122,7 @@ have ten instances of `foo()` and one instance of `handle_isr()`. When
 `handle_isr()` issues `yield`, its execution will pause for 40ms while each
 instance of `foo()` is scheduled and performs one iteration. This may be
 unacceptable: it may be necessary to poll and respond to the flag at a rate
-suficient to avoid overruns.
+sufficient to avoid overruns.
 
 In this version `handle_isr()` would be rewritten as a stream device driver
 which could be expected to run with latency of just over 4ms.
@@ -225,7 +221,7 @@ This behaviour may be desired where short bursts of fast data are handled.
 Otherwise drivers of such hardware should be designed to avoid hogging, using
 techniques like buffering or timing.
 
-The version also supports an `version` variable containing 'fast_io'. This
+The version also supports a `version` variable containing 'fast_io'. This
 enables the presence of this version to be determined at runtime.
 
 It also supports a `got_event_loop()` function returning a `bool`: `True` if

TUTORIAL.md

@@ -38,7 +38,7 @@ asyncio and includes a section for complete beginners.
  5. [Interfacing hardware](./TUTORIAL.md#5-interfacing-hardware)  
   5.1 [Timing issues](./TUTORIAL.md#51-timing-issues)  
   5.2 [Polling hardware with a coroutine](./TUTORIAL.md#52-polling-hardware-with-a-coroutine)  
-  5.3 [Using the stream mechnanism](./TUTORIAL.md#53-using-the-stream-mechanism)  
+  5.3 [Using the stream mechanism](./TUTORIAL.md#53-using-the-stream-mechanism)  
    5.3.1 [A UART driver example](./TUTORIAL.md#531-a-uart-driver-example)  
   5.4 [Writing streaming device drivers](./TUTORIAL.md#54-writing-streaming-device-drivers)  
   5.5 [A complete example: aremote.py](./TUTORIAL.md#55-a-complete-example-aremotepy)
@@ -86,8 +86,8 @@ Except where detailed below, `asyncio` features of versions >3.4 are
 unsupported. As stated above it is a subset; this document identifies supported
 features.
 
-This tutoial advocates a consistent programming style with good compatibility
-with CPython V3.5 and above.
+This tutorial aims to present a consistent programming style compatible with
+CPython V3.5 and above.
 
 ## 0.1 Installing uasyncio on bare metal
 
@@ -101,7 +101,7 @@ Libraries to be installed are:
 The `queues` and `synchro` modules are optional, but are required to run all
 the examples below.
 
-The oficial approach is to use the `upip` utility as described
+The official approach is to use the `upip` utility as described
 [here](https://github.com/micropython/micropython-lib). Network enabled
 hardware has this included in the firmware so it can be run locally. This is
 the preferred approach.
@@ -114,7 +114,7 @@ then copying the library to the target.
 The need for Linux and the Unix build may be avoided by using
 [micropip.py](https://github.com/peterhinch/micropython-samples/tree/master/micropip).
 This runs under Python 3.2 or above. Create a temporary directory on your PC
-and install to that. Then copy the contents of the temporary direcory to the
+and install to that. Then copy the contents of the temporary directory to the
 device. The following assume Linux and a temporary directory named `~/syn` -
 adapt to suit your OS. The first option requires that `micropip.py` has
 executable permission.
@@ -374,7 +374,7 @@ offers "micro" implementations of `Event`, `Barrier`, `Semaphore` and
 `Condition` primitives. These are for use only with asyncio. They are not
 thread safe and should not be used with the `_thread` module or from an
 interrupt handler except where mentioned. A `Lock` primitive is provided which
-is an alterantive to the official implementation.
+is an alternative to the official implementation.
 
 Another synchronisation issue arises with producer and consumer coros. The
 producer generates data which the consumer uses. Asyncio provides the `Queue`
@@ -474,7 +474,7 @@ async def foo(event):
         event.set()
 ```
 
-Where multiple coros wait on a single event synchronisationcan be achieved by
+Where multiple coros wait on a single event synchronisation can be achieved by
 means of an acknowledge event. Each coro needs a separate event.
 
 ```python
@@ -619,7 +619,7 @@ no mechanism for verifying when cancellation has actually occurred. The `asyn`
 library provides verification via the following classes:
 
  1. `Cancellable` This allows one or more tasks to be assigned to a group. A
- coro can cancel all tasks in the group, pausing until this has been acheived.
+ coro can cancel all tasks in the group, pausing until this has been achieved.
  Documentation may be found [here](./PRIMITIVES.md#42-class-cancellable).
  2. `NamedTask` This enables a coro to be associated with a user-defined name.
  The running status of named coros may be checked. For advanced usage more
@@ -1095,7 +1095,7 @@ class RecordOrientedUart():
     def __iter__(self):  # Not __await__ issue #2678
         data = b''
         while not data.endswith(self.DELIMITER):
-            yield from asyncio.sleep(0) # Neccessary because:
+            yield from asyncio.sleep(0) # Necessary because:
             while not self.uart.any():
                 yield from asyncio.sleep(0) # timing may mean this is never called
             data = b''.join((data, self.uart.read(self.uart.any())))
@@ -1152,7 +1152,7 @@ async def receiver():
     sreader = asyncio.StreamReader(uart)
     while True:
         res = await sreader.readline()
-        print('Recieved', res)
+        print('Received', res)
 
 loop = asyncio.get_event_loop()
 loop.create_task(sender())
@@ -1357,7 +1357,7 @@ application design the [fast_io](./FASTPOLL.md) version can greatly reduce
 this.
 
 The demo program `iorw.py` illustrates a complete example. Note that, at the
-time of writing there is a bug in `uasyncio` which prevents this from woking.
+time of writing there is a bug in `uasyncio` which prevents this from working.
 See [this GitHub thread](https://github.com/micropython/micropython/pull/3836#issuecomment-397317408).
 There are two solutions. A workround is to write two separate drivers, one
 read-only and the other write-only. Alternatively the
@@ -1406,7 +1406,7 @@ run while acquisition is in progress.
 
 Hanging usually occurs because a task has blocked without yielding: this will
 hang the entire system. When developing it is useful to have a coro which
-periodically toggles an onboard LED. This provides confirmtion that the
+periodically toggles an onboard LED. This provides confirmation that the
 scheduler is running.
 
 ###### [Contents](./TUTORIAL.md#contents)
@@ -1470,7 +1470,7 @@ the outer loop:
     def __await__(self):
         data = b''
         while not data.endswith(self.DELIMITER):
-            yield from asyncio.sleep(0) # Neccessary because:
+            yield from asyncio.sleep(0) # Necessary because:
             while not self.uart.any():
                 yield from asyncio.sleep(0) # timing may mean this is never called
             data = b''.join((data, self.uart.read(self.uart.any())))
@@ -1630,7 +1630,7 @@ def event_loop():
             # handle UART input
 ```
 
-This works for simple examples but event loops rapidly become unweildy as the
+This works for simple examples but event loops rapidly become unwieldy as the
 number of events increases. They also violate the principles of object oriented
 programming by lumping much of the program logic in one place rather than
 associating code with the object being controlled. We want to design a class
@@ -1800,7 +1800,7 @@ overrun the specified time. This is because while the delay is in progress
 other tasks will run. When the delay period completes, execution will not
 resume until the running task issues `await` or terminates. A well-behaved coro
 will always issue `await` at regular intervals. Where a precise delay is
-required, especially one below a few ms, it may be neccessary to use
+required, especially one below a few ms, it may be necessary to use
 `utime.sleep_us(us)`.
 
 ###### [Contents](./TUTORIAL.md#contents)
@@ -1812,7 +1812,7 @@ often one of disappointment. Surely pre-emptive is better? Why should I have to
 explicitly yield control when the Python virtual machine can do it for me?
 
 When it comes to embedded systems the cooperative model has two advantages.
-Fistly, it is lightweight. It is possible to have large numbers of coroutines
+Firstly, it is lightweight. It is possible to have large numbers of coroutines
 because unlike descheduled threads, paused coroutines contain little state.
 Secondly it avoids some of the subtle problems associated with pre-emptive
 scheduling. In practice cooperative multi-tasking is widely used, notably in