Changes between Version 2 and Version 3 of 802.11/wlan_exp/app_notes/tutorial_token_mac/CPU_HIGH

Timestamp:

Jul 8, 2015, 11:56:01 AM (9 years ago)

Author:

chunter

Comment:

--

802.11/wlan_exp/app_notes/tutorial_token_mac/CPU_HIGH

@@ -18 +18 @@
 Changes should be made to [browser:ReferenceDesigns/w3_802.11/c/wlan_mac_high_ap/wlan_mac_ap.c wlan_mac_ap.c].
 
-----
-1. We need to create a function that, when called, knows how to issue a new token for a reservation period to a device on the network. Note: the AP itself needs to be able to transmit, so it should include itself as one of the devices that get issued a token. Add the following function to the AP code:
+---- 
+We need to create a function that, when called, knows how to issue a new token for a reservation period to a device on the network. Note: the AP itself needs to be able to transmit, so it should include itself as one of the devices that get issued a token. Add the following function to the AP code:
 
 {{{
@@ -99 +99 @@
 }}}
 
-Take a minute and read through what that code snippet is doing. Every time it is called, it will move on to the next member of the association table doubly-linked list and send an IPC message to CPU_LOW indicating the address of that member along with a duration of time the token reservation for that member should last. After every loop through of the association table, it will issue an IPC message to CPU_LOW using its own BSSID as the address in the IPC payload. This indicates that the medium is now reserved for the AP itself.
+Take a minute and read through what that code snippet is doing. Every time it is called, it will move on to the next member of the association table doubly-linked list and send an IPC message to CPU_LOW indicating the address of that member along with a duration of time the token reservation for that member should last. The #define for {{{DEFAULT_RESERVATION_DURATION_USEC}}} indicates this duration. After every loop through of the association table, it will issue an IPC message to CPU_LOW using its own BSSID as the address in the IPC payload. This indicates that the medium is now reserved for the AP itself.
 
+---- 
+
+The next thing we need to do is figure out when we should call our new {{{set_new_reservation()}}} function. We should definitely call it once at boot in {{{main()}}} to get the process started (at which point, no stations will be associated and that function would simply formally start the first token reservation period for the AP). But when should we call it next? We should call it whenever the current reservation period is complete. We'd expect this time to come {{{DEFAULT_RESERVATION_DURATION_USEC}}} microseconds after the previous call, so we could set up a periodic schedule and call our function at regular intervals. However, its entirely possible that a station is unable to accept a token for a reservation period, so we may wish to terminate the current reservation period early and move on to the next station's reservation. The AP itself has no idea when this even occurs since it is within the domain of CPU_LOW. So, rather than worry about scheduling the next call of {{{set_new_reservation()}}}, we can instead teach the MAC High Framework how to call that function when it receives an IPC message from CPU_LOW indicating that the current reservation period is over. We'll do this with a simple function callback. Add the following two lines to the {{{main()}}} function of the AP:
+
+{{{
+#!c
+        wlan_mac_high_set_token_new_reservation_callback((function_ptr_t)set_new_reservation);
+        set_new_reservation();
+}}}
+
+The safest place to add these lines is just before the {{{while(1)}}} clause at the end of the {{{main()}}} function. {{{wlan_mac_high_set_token_new_reservation_callback}}} does not exist yet; we will add it in the next section with our changes to the MAC High Framework. Basically, this line of code lets the AP delegate responsibility for calling {{{set_new_reservation}}} to the MAC High Framework.
 
 
 ----
+
+=== Code Common to CPU_HIGH and CPU_LOW ===
+Changes should be made to [browser:ReferenceDesigns/w3_802.11/c/wlan_mac_common/include/wlan_mac_ipc_util.h wlan_mac_ipc_util.h].
+
+---- 
+We need to define two new types of IPC messages between CPU_LOW and CPU_HIGH. The first, which we will call {{{TOKEN_NEW_RESERVATION}}}, will primarily be used by an AP when it decrees that a token reservation period now belongs to one of the devices on its network. The second, which we will call {{{TOKEN_END_RESERVATION}}}, will primarily be used by an AP's CPU_LOW project to indicate to the AP that the current reservation period has ended and it should move on to the next device in its association table. Add the following snippet of code to [browser:ReferenceDesigns/w3_802.11/c/wlan_mac_common/include/wlan_mac_ipc_util.h wlan_mac_ipc_util.h]:
+
+{{{
+#!c
+
+#define IPC_MBOX_TOKEN_NEW_RESERVATION  20
+#define IPC_MBOX_TOKEN_END_RESERVATION  21
+
+typedef struct{
+        u32 res_duration;
+        u8      addr[6];
+        u16 reserved;
+} ipc_token_new_reservation;
+
+typedef enum {TOKEN_DURATION_COMPLETE, TOKEN_TIMEOUT, TOKEN_OFFER_REJECTION} token_end_reservation_reason_t;
+
+typedef struct{
+        token_end_reservation_reason_t reason;
+        wlan_mac_low_tx_details low_tx_details;
+} ipc_token_end_reservation;
+}}}
+
+The values of 20 and 21 are arbitrary. The key part is that you choose numbers that do not overlap with any of the other definitions that are prepended by {{{IPC_MBOX_}}}. It is these definitions that the processors use to determine what type of IPC message is currently being received. Next, {{{ipc_token_new_reservation}}} and {{{ipc_token_end_reservation}}} are structs that we will use to more easily fill in and process IPC payloads.