From a6aeb11a56b7737f83c2bbbdcc8e835d5bd0a439 Mon Sep 17 00:00:00 2001 From: Jan NIJS Date: Sat, 10 Jun 2017 18:30:21 +0200 Subject: [PATCH] LP-536 Timeout parameter for PIOS_COM_ReceiveBuffer() should be in milliseconds. No need to convert to ticks. Changed the int xDelay to a define and put the define next to the other major delay in the GPS task. Increased the time we wait for PIOS_COM_ReceiveBuffer from 5 to 20 ms. --- flight/modules/GPS/GPS.c | 38 ++++++++++++++++++++++++++------------ 1 file changed, 26 insertions(+), 12 deletions(-) diff --git a/flight/modules/GPS/GPS.c b/flight/modules/GPS/GPS.c index c894c59c4..5bd2c9061 100644 --- a/flight/modules/GPS/GPS.c +++ b/flight/modules/GPS/GPS.c @@ -105,7 +105,27 @@ void updateGpsSettings(__attribute__((unused)) UAVObjEvent *ev); // the new location with Set = true. #define GPS_HOMELOCATION_SET_DELAY 5000 -#define GPS_LOOP_DELAY_MS 6 +// PIOS serial port receive buffer for GPS is set to 32 bytes for the minimal and 128 bytes for the full version. +// GPS_READ_BUFFER is defined a few lines below in this file. +// +// 57600 bps = 5760 bytes per second +// For 32 bytes buffer: this is a maximum of 5760/32 = 180 buffers per second +// that is 1/180 = 0.0056 seconds per packet +// We must never wait more than 5ms since packet was last drained or it may overflow +// For 128 bytes buffer: this is a maximum of 5760/128 = 45 buffers per second +// that is 1/45 = 0.022 seconds per packet +// We must never wait more than 22ms since packet was last drained or it may overflow + +// There are two delays in play for the GPS task: +// - GPS_BLOCK_ON_NO_DATA_MS is the time to block while waiting to receive serial data from the GPS +// - GPS_LOOP_DELAY_MS is used for a context switch initiated by calling vTaskDelayUntil() to let other tasks run +// +// The delayMs time is not that critical. It should not be too high so that maintenance actions within this task +// are run often enough. +// GPS_LOOP_DELAY_MS on the other hand, should be less then 5.55 ms. A value set too high will cause data to be dropped. + +#define GPS_LOOP_DELAY_MS 5 +#define GPS_BLOCK_ON_NO_DATA_MS 20 #ifdef PIOS_GPS_SETS_HOMELOCATION // Unfortunately need a good size stack for the WMM calculation @@ -116,10 +136,10 @@ void updateGpsSettings(__attribute__((unused)) UAVObjEvent *ev); #ifdef PIOS_INCLUDE_GPS_NMEA_PARSER #define STACK_SIZE_BYTES 580 // NMEA -#else +#else // PIOS_INCLUDE_GPS_NMEA_PARSER #define STACK_SIZE_BYTES 440 // UBX #endif // PIOS_INCLUDE_GPS_NMEA_PARSER -#else +#else // PIOS_GPS_MINIMAL #define STACK_SIZE_BYTES 650 #endif // PIOS_GPS_MINIMAL #endif // PIOS_GPS_SETS_HOMELOCATION @@ -284,13 +304,7 @@ MODULE_INITCALL(GPSInitialize, GPSStart); static void gpsTask(__attribute__((unused)) void *parameters) { - // 57600 baud = 5760 bytes per second - // PIOS serial buffers appear to be 32 bytes long - // that is a maximum of 5760/32 = 180 buffers per second - // that is 1/180 = 0.005555556 seconds per packet - // we must never wait more than 5ms since packet was last drained or it may overflow - // 100ms is way slow too, considering we do everything possible to make the sensor data as contemporary as possible - portTickType xDelay = 5 / portTICK_RATE_MS; + uint32_t timeNowMs = xTaskGetTickCount() * portTICK_RATE_MS; #ifdef PIOS_GPS_SETS_HOMELOCATION @@ -353,8 +367,8 @@ static void gpsTask(__attribute__((unused)) void *parameters) uint16_t cnt; int res; - // This blocks the task until there is something on the buffer (or 100ms? passes) - cnt = PIOS_COM_ReceiveBuffer(gpsPort, c, GPS_READ_BUFFER, xDelay); + // This blocks the task until there is something in the buffer (or GPS_BLOCK_ON_NO_DATA_MS passes) + cnt = PIOS_COM_ReceiveBuffer(gpsPort, c, GPS_READ_BUFFER, GPS_BLOCK_ON_NO_DATA_MS); res = PARSER_INCOMPLETE; if (cnt > 0) { PERF_TIMED_SECTION_START(counterParse);