rooty/LibrePilot
1
0
Fork 0
mirror of https://bitbucket.org/librepilot/librepilot.git synced 2025-03-16 08:29:15 +01:00
Code Issues Releases Activity

LP-536 Timeout parameter for PIOS_COM_ReceiveBuffer() should be in milliseconds. No need to convert to ticks.

Browse Source 
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.
This commit is contained in:
Jan NIJS 2017-06-10 18:30:21 +02:00
parent 6f3fefd650
commit a6aeb11a56
1 changed files with 26 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

38
flight/modules/GPS/GPS.c
View File

@ -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);