...
Code Block | ||
---|---|---|
| ||
class Gps { public: /** * Initialises internal parameters. * Should be called exactly once before anything is attempted to be done with the module. */ virtual void Init(void) = 0; /** * Begins the process of collecting the sensor's data. * This is a non blocking function that returns right away. */ virtual void BeginMeasuring(void) = 0; /** * Gets the information about the aircraft's position (See GpsData_t struct). * This is a non blocking function that returns right away, either with new data, * or with old data (in case of old data, the dataIsNew flag of the result struct will be cleared). * @param[out] Data pointer to the result struct. * @return AAQUAD_SUCCEEDED, AAQUAD_BUSY or AAQUAD_FAILED */ virtual void GetResult(GpsData_t *Data) = 0; }; |
-
...
The design is such that a "GPS" thread would periodically call BeginMeasuring, which would begin the process of collecting the data from the sensor. That data should be available by the time the appropriate state machine thread gets around to calling GetResult to collect it.
The Data struct that gets populated by the GetResult function will contain, along with the fields that store the sensor specific data, an "isDataNew" field that indicates whether the sensor data has indeed been refreshed since the last time the caller called GetResult, and a "sensorStatus" field that indicates any sensor specific failures.
None of the methods in the interface should be blocking. This means all communications with the sensor will be internally interrupt (and possibly DMA) based. As a result, we can guarantee the processor spends it's time doing meaningful work rather than polling sensors.
The interface is made up entirely of pure virtual methods. This allows many implementations of the module (for many different parts). This way, we would be able to easily select which part is available to us at the time of flight without having to modify any of he calling code.
Note: We might find it useful to add a 4th function to the interface: “Sensor_Calibrate” which might either load calibration values we stored earlier or execute a calibration or
...
something.
RTOS
The main autopilot systems are built on FreeRTOS, an open-source Real-Time Operating System. FreeRTOS gives us the ability to run multiple concurrent tasks on a single embedded system, each of which has a priority and can "block" for a period of time while they wait for data. At any given time, the highest priority task that is not blocking will be running.
...