FlexSEA Wiki

A WEARABLE ROBOTICS TOOLKIT

User Tools

Site Tools


dev:fxplanstackdoc

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
dev:fxplanstackdoc [2019/07/05 15:49]
flabelle [Board adresses]
dev:fxplanstackdoc [2019/07/05 15:52] (current)
flabelle
Line 76: Line 76:
 Message Types: There are two types of packets used by Dephy'​s devices. Both send the same payload, the defining difference is the number of packets which can be sent. The single packet mode can, surprisingly,​ send only one while multi-packet can send up to 4 Message Types: There are two types of packets used by Dephy'​s devices. Both send the same payload, the defining difference is the number of packets which can be sent. The single packet mode can, surprisingly,​ send only one while multi-packet can send up to 4
 ===== Current stack ===== ===== Current stack =====
- 
-==== PlanStack ==== 
- 
-PlanStack has two categories of issues: 
-1. Organizational issues 
-2. Threading issues 
- 
-PlanStack keeps a centralized list of serial devices (the ports list) and associates them with a valid device. Ports are serviced through the methods of the SerialDriver class, which is inherited by the FlexseaSerial class. It also inherits from the FlexseaDeviceProvider which is responsible for managing a list of devices and their status. It returns an object of the FlexseaDevice class. It handles the reception of data and setting the active fields used by each device. ​ 
- 
-In turn, the FlexseaSerial class is inherited by the CommManager class. CommManager uses the PeriodicTask class inherited by FlexSeaSerial to service ports (get data from devices), open connections (send whoAmi), close connections and send commands. CommManger serves as the API for higher level code (either directly or through the CommWrapper file) to start connections with Dephy devices. Below is a UML diagram of the CommManager class and it's underlying classes. 
- 
-{{:​dev:​planstackrework-currentplanstack.png?​600|}} 
- 
-The way functionalities are split through these functions presents no clear advantage and just winds up scattering all the functionalities of a device across 6+ files. The way these functionalities are split often requires the exchange of low level information (such as the port number) in high level functions (commManager). Devices and serial ports are stored in large mostly unused structures and it is on send time that messages are sent to the correct device. In fact, all messages are put together in a common queue. Grouping together all the variables also presents another issue, a large amount of shared memory. When multiple threads are used, which both have read write access to the same data structure (the command Queue) this poses a major issue. 
- 
-There some mutexes, however their use is sparing. Some parts of the code, such as the periodic task are protected, but most of the shared memory was not locked. Until recently, the shared queue had no mutexes which lead to page faults when the command queue was "​doubly accessed"​. There is also use of recursive mutexes, which IMHO is an odd choice. I suspect it was used to handle the case of overlapping calls to the periodic function by the same thread, however that should not be happening. If that is the case, this could be fixed by reorganizing the layout of the PlanStack. 
- 
-To illustrate the complexity of the PlanStack, the following images partially describe what happens when a commands is sent. The first describes the asynchronous part while the seconds shows the threads role in sending the data. 
- 
-{{:​dev:​planstackrework-cmdflowdiagram.png?​600|}} 
- 
- 
-{{:​dev:​planstackrework-threadflowdiagram.png?​600|}} 
- 
  
 ==== Packet format ==== ==== Packet format ====
-<color #ed1c24> 
-Some of that section is very good. I'd still move it up in the new section I created. Ok?</​color>​ 
  
 The PlanStack and the embedded device both use FlexSEA-comm and FlexSEA-system submodules to send and recieve messages. FlexSEA-comm takes care of the reception and processing of messages. FlexSEA-system defines the transmission functions which act on the inputs recieved and prepares data for the messages. FlexSEA-comm defines two distinct communication protocols, single and multipacket. Payloads are the lowest level unit. They contain a destination,​ receiver, number of commands (always 1), command type, command and data packets. These are in turn wrapped using the single packet and either sent directly or again wrapped in the multipacket code. See the image below The PlanStack and the embedded device both use FlexSEA-comm and FlexSEA-system submodules to send and recieve messages. FlexSEA-comm takes care of the reception and processing of messages. FlexSEA-system defines the transmission functions which act on the inputs recieved and prepares data for the messages. FlexSEA-comm defines two distinct communication protocols, single and multipacket. Payloads are the lowest level unit. They contain a destination,​ receiver, number of commands (always 1), command type, command and data packets. These are in turn wrapped using the single packet and either sent directly or again wrapped in the multipacket code. See the image below
Line 185: Line 159:
 Strain: from 70 to 79 Strain: from 70 to 79
 Gossip: from 80 to 89 Gossip: from 80 to 89
 +
 +==== PlanStack ====
 +
 +PlanStack has two categories of issues:
 +1. Organizational issues
 +2. Threading issues
 +
 +PlanStack keeps a centralized list of serial devices (the ports list) and associates them with a valid device. Ports are serviced through the methods of the SerialDriver class, which is inherited by the FlexseaSerial class. It also inherits from the FlexseaDeviceProvider which is responsible for managing a list of devices and their status. It returns an object of the FlexseaDevice class. It handles the reception of data and setting the active fields used by each device. ​
 +
 +In turn, the FlexseaSerial class is inherited by the CommManager class. CommManager uses the PeriodicTask class inherited by FlexSeaSerial to service ports (get data from devices), open connections (send whoAmi), close connections and send commands. CommManger serves as the API for higher level code (either directly or through the CommWrapper file) to start connections with Dephy devices. Below is a UML diagram of the CommManager class and it's underlying classes.
 +
 +{{:​dev:​planstackrework-currentplanstack.png?​600|}}
 +
 +The way functionalities are split through these functions presents no clear advantage and just winds up scattering all the functionalities of a device across 6+ files. The way these functionalities are split often requires the exchange of low level information (such as the port number) in high level functions (commManager). Devices and serial ports are stored in large mostly unused structures and it is on send time that messages are sent to the correct device. In fact, all messages are put together in a common queue. Grouping together all the variables also presents another issue, a large amount of shared memory. When multiple threads are used, which both have read write access to the same data structure (the command Queue) this poses a major issue.
 +
 +There some mutexes, however their use is sparing. Some parts of the code, such as the periodic task are protected, but most of the shared memory was not locked. Until recently, the shared queue had no mutexes which lead to page faults when the command queue was "​doubly accessed"​. There is also use of recursive mutexes, which IMHO is an odd choice. I suspect it was used to handle the case of overlapping calls to the periodic function by the same thread, however that should not be happening. If that is the case, this could be fixed by reorganizing the layout of the PlanStack.
 +
 +To illustrate the complexity of the PlanStack, the following images partially describe what happens when a commands is sent. The first describes the asynchronous part while the seconds shows the threads role in sending the data.
 +
 +{{:​dev:​planstackrework-cmdflowdiagram.png?​600|}}
 +
 +
 +{{:​dev:​planstackrework-threadflowdiagram.png?​600|}}
 +
 +
 +
  
 ===== Proposed communication stack ===== ===== Proposed communication stack =====
dev/fxplanstackdoc.txt ยท Last modified: 2019/07/05 15:52 by flabelle