You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
NFC EEPROM provides low level operations needed to create an NFC TAG. The device usually allows for reading and writing into a shared memory by one device at a time through one of two channels. One is the radio channel used by external devices interacting with the device. The other is wired to the MCU. Either device needs to obtain a session before performing its operations. Session is released as the last step or through a timeout.
3
+
NFC EEPROM provides low level operations needed to create an NFC TAG. The device usually allows one device at a time to read and write into a shared memory through one of two channels. One is the radio channel that external devices interacting with the device use. The other is wired to the MCU. Either device needs to obtain a session before performing its operations. The session is released as the last step or through a timeout.
4
4
5
5
### Class hierarchy
6
6
7
-
The `NFCTarget` uses an implementation of `NFCEEPROMDriver` as the backend that delivers the fundamental operations needed to access and modify the memory containing the NDEF messages. The instance of the class is created by the target implementation of `NFCTarget`.
7
+
The `NFCTarget` uses an implementation of `NFCEEPROMDriver` as the backend that delivers the fundamental operations needed to access and modify the memory containing the NDEF messages. The target implementation of `NFCTarget` creates the instance of the class.
8
8
9
-
Your implementation will inherit from `NFCEEPROMDriver` and implement all the public methods therein.
9
+
Your implementation inherits from `NFCEEPROMDriver` and implements all the public methods therein.
10
10
11
11
### Required methods
12
12
13
13
`NFCEEPROMDriver` defines the following pure virtual methods.
14
14
15
15
These must return synchronously:
16
-
-`void reset()`
17
-
-`size_t read_max_size()`
16
+
17
+
-`void reset()`.
18
+
-`size_t read_max_size()`.
18
19
19
20
These must return their results through calling methods in the `Delegate`:
This will be called during initialisation and may be called repeatedly. This must be safe to be called at any time and should return when the device is ready for operation.
32
+
`reset` is called during initialization and may be called repeatedly. This must be safe to be called at any time and should return when the device is ready for operation.
31
33
32
34
#### Implementing `read_max_size`
33
35
34
36
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).
35
37
36
38
#### Implementing `start_session` and `end_session`
37
39
38
-
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.
40
+
`start_session` and `end_session`open and close the communication with the device. `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`triggers the `on_session_opened` with the parameter set to false (failure) if an RF session is already opened.
39
41
40
42
#### Implementing `read_bytes` and `write_bytes`
41
43
42
-
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.
44
+
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. You must account for any headers 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.
43
45
44
46
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.
45
47
46
48
#### Implementing `read_size` and `write_size`
47
49
48
-
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.
50
+
`read_size` and `write_size`read and write the limits the write and read operations use. Writing or reading beyond the set size must be truncated to the current size.
49
51
50
52
#### Implementing `erase_bytes`
51
53
52
-
This is the equivalent of calling `write_bytes` with a buffer filled with `0`. Like `write_bytes` it must return the number of bytes successfully set to `0`.
54
+
This is the equivalent of calling `write_bytes` with a buffer filled with `0`. Like `write_bytes`, it must return the number of bytes successfully set to `0`.
53
55
54
56
### Asynchronous operation
55
57
56
-
Depending on your hardware you may support synchronous or asynchronous operation.
58
+
Depending on your hardware, you may support synchronous or asynchronous operation.
59
+
60
+
We designed the `NFCEEPROMDriver` with asynchronous operation, and the results of long operations are communicated through events. You must use these events, even if your implementation is synchronous.
57
61
58
-
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.
62
+
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:
59
63
60
-
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:
61
64
`EventQueue* event_queue()`
62
65
63
66
You may initiate your event processing by calling `call()` on the event queue.
64
67
65
68
For example:
66
69
67
-
if your event management is done in a function called `manage_event` then you should call:
68
-
`event_queue()->call(&manage_event);`.
69
-
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.
70
+
If your event management occurs in a function called `manage_event`, you should call:
71
+
72
+
`event_queue()->call(&manage_event);`
73
+
74
+
The `EventQueue` also accepts passed in parameters and objects for nonstatic method calls. Please see the `EventQueue` documentation for details on calling functions on the queue.
70
75
71
76
#### Communicating events back to the NFCTarget
72
77
73
-
All events shall call methods in the `Delegate` class object that has been set by the `NFCTarget`. Delegate is accessible through:
78
+
All events call methods in the `Delegate` class object that has been set by the `NFCTarget`. Delegate is accessible through:
74
79
`Delegate* delegate()`
75
80
76
81
It implements the following methods:
@@ -83,11 +88,11 @@ It implements the following methods:
83
88
-`void on_size_read(bool success, size_t size)`
84
89
-`void on_bytes_erased(size_t count)`
85
90
86
-
These must be used to communicate the results of all asynchronous calls.
91
+
You must use these to communicate the results of all asynchronous calls.
87
92
88
93
### Testing
89
94
90
-
A macro `NFCEEPROM` is required for the test to be built. The module containing your driver should comtain`mbed_lib.json`. Add a configuration option for the build system to convert into a macro. Your `mbed_lib.json` could look like this:
95
+
A macro `NFCEEPROM` is required for the test to build. The module containing your driver should contain`mbed_lib.json`. Add a configuration option for the build system to convert into a macro. Your `mbed_lib.json` could look like this:
91
96
92
97
```javascript
93
98
{
@@ -103,4 +108,5 @@ A macro `NFCEEPROM` is required for the test to be built. The module containing
103
108
```
104
109
105
110
Run the tests with:
111
+
106
112
`mbed test -m [mcu] -t [toolchain] -n tests-nfc-eeprom*`.
0 commit comments