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
The FMU Communications Board is designed as a component of the Flight Management System. The FMU Communications Board is a Microchip PIC32 based module with the primary function of managing communications between the FMU Processing Board and the rest of the Flight Management System. The Ethernet and CAN communication protocols are detailed in file [UMN FMU Communication Protocol](/doc/UMN%20FMU%20Communication%20Protocol.docx).
9
9
@@ -59,6 +59,19 @@ The hardware contains the following physical interfaces:
59
59
60
60
*Note: Power for the FMU Communications Board must be in the range of 3.6V to 36V.*
The above picture shows a constructed hardware stackup. The boards on the stackup (from bottom to top) are:
66
+
67
+
1. FMU Processing Board (Beaglebone Black)
68
+
2. Beaglebone Cape - with IMU
69
+
3. GPS receiver
70
+
4. Sentera Comms Board
71
+
5. uHard Datalink
72
+
73
+
Additional hardware photos can be found on the University of Minnesota [media page](http://www.uav.aem.umn.edu/wiki/Media).
74
+
62
75
## Software Overview
63
76
Source code is commented using Doxygen style formatting. Therefore, Doxygen can be used to generate an easily navigable document which provides greater detail into the software's operation than the overview which is provided here.
64
77
@@ -81,10 +94,10 @@ The software implements a preemptive, cyclic executive using eight threads. The
81
94
82
95
4.**Default**: Thread is executed if any unexpected interrupts occur.
83
96
84
-
All main software processing is performed in the 'Reset' thread. All other threads have a higher priority (i.e. can preempt the 'Reset' thread) and purely handle servicing of the hardware. The 'Reset' thread implement cooperative multitasking, where tasks are performed continuously, with the execution time of individual tasks being in the micro-second order of magnitude. This allows for immediate response to system inputs and a small jitter in system output timing.
97
+
All main software processing is performed in the 'Reset' thread. All other threads have a higher priority (i.e. can preempt the 'Reset' thread) and purely handle servicing of the hardware. The 'Reset' thread implements cooperative multitasking, where tasks are performed continuously, with the execution time of individual tasks being in the micro-second order of magnitude. This allows for immediate response to system inputs and a small jitter in system output timing.
85
98
86
99
### Software Modules
87
-
The software is a modular design. The software modules are explained below, and map directly to [source code](/src) file names:
100
+
The software is a modular design. The software modules are explained below, and map directly to [source code](/src) file or folder names:
88
101
89
102
>**adc**: Analog to Digital Converter (ADC) driver.
0 commit comments