proofreading

Author: paul-szczepanek-arm

docs/reference/contributing/connectivity/NFCEEPROMDriver.md

@@ -10,10 +10,13 @@ Your implementation will inherit from `NFCEEPROMDriver` and implement all the pu
 
 ### Required methods
 
-`NFCEEPROMDriver` defines the following pure virtual functions:
+`NFCEEPROMDriver` defines the following pure virtual methods.
 
+These must return synchronously:
 - `void reset()`
 - `size_t read_max_size()`
+
+These must return their results through calling methods in the `Delegate`:
 - `void start_session(bool force = false)`
 - `void end_session()`
 - `void read_bytes(uint32_t address, uint8_t* bytes, size_t count)`
@@ -28,21 +31,21 @@ This will be called during initialisation and may be called repeatedly. This mus
 
 #### Implementing `read_max_size`
 
-This must return synchronously the (effective) size of the EEPROM memory available to NDEF messages (not including the memory required by other files).
+This must synchronously return the (effective) size of the EEPROM memory available to NDEF messages (not including the memory required by other files or headers).
 
 #### Implementing `start_session` and `end_session`
 
-These open and close the communication wit the device. The `start_session` has an extra parameter that indicates the session should be started even if it would kill the RF session in the process if one is already opened. Otherwise the `open_session` should trigger the `on_session_opened` with the parameter set to false (failure) if an RF session is already opened. 
+These open and close the communication with the device. The `start_session` has an extra parameter that indicates the session should be started even if it would kill the RF session in the process. Otherwise the `open_session` should trigger the `on_session_opened` with the parameter set to false (failure) if an RF session is already opened. 
 
 #### Implementing `read_bytes` and `write_bytes`
 
 Both methods contain the `address` which is to be used as the starting offset in the file. This starts at the beginning of the body of the file where NDEF messages may be written. Any headers must be accounted for in the offset and size calculations. The `count` parameters are the maximum sizes of the operations but the operation may return less than the requested counts.
 
-The events `on_bytes_read` and `on_bytes_written` must return the number of bytes successfully read or written in case the maximum size of the operation the device allows is smaller than the request operation. It's up to the caller to call these function multiple times with appropriate offsets as required.
+The events `on_bytes_read` and `on_bytes_written` must return the number of bytes successfully read or written in case the maximum size of the operation the device allows is smaller than the request operation. It's up to the caller to call these methods multiple times with appropriate offsets as required.
 
 #### Implementing `read_size` and `write_size`
 
-These read and write the limits used by the write and read operations. Writing beyond the set size must be truncated to the set size.
+These read and write the limits used by the write and read operations. Writing or reading beyond the set size must be truncated to the current size.
 
 #### Implementing `erase_bytes`
 
@@ -52,7 +55,7 @@ This is the equivalent of calling `write_bytes` with a buffer filled with `0`. L
 
 Depending on your hardware you may support synchronous or asynchronous operation.
 
-The `NFCEEPROMDriver` is designed with asynchronous operation in mind and the results of long operation are communicated through events. These must be used even if your implementation is synchronous.
+The `NFCEEPROMDriver` is designed with asynchronous operation in mind and the results of long operations are communicated through events. These must be used even if your implementation is synchronous.
 
 In asynchronous implementations you may use an `EventQueue` to schedule processing caused by interrupts. The `NFCTarget` has set up your event queue which you can get by calling:
 `EventQueue* event_queue()`
@@ -61,11 +64,13 @@ You may initiate your event processing by calling `call()` on the event queue.
 
 For example:
 
-if your event management is done in a function called `manage_event` then you should call `event_queue()->call(&manage_event);`. The `EventQueue` also accepts passed in parameters and objects for non-static method calls - please see the `EventQueue` documentation for details on calling function on the queue.
+if your event management is done in a function called `manage_event` then you should call:
+`event_queue()->call(&manage_event);`.
+The `EventQueue` also accepts passed in parameters and objects for non-static method calls - please see the `EventQueue` documentation for details on calling functions on the queue.
 
 #### Communicating events back to the NFCTarget
 
-All events shall call function in the `Delegate` class object that has been set by the `NFCTarget`. Delegate is accessible through:
+All events shall call methods in the `Delegate` class object that has been set by the `NFCTarget`. Delegate is accessible through:
 `Delegate* delegate()`
 
 It implements the following methods:
@@ -78,6 +83,8 @@ It implements the following methods:
 - `void on_size_read(bool success, size_t size)`
 - `void on_bytes_erased(size_t count)`
 
+These must be used to communicate the results of all asynchronous calls.
+
 ### Testing
 
 Run tests with: