Enable battx_options for periphs if useful.
Enable the options parameter for the battery monitor on AP_Periph devices if they could be useful - ie, battery summing is enabled and in use on a node with more than one source for battery inputs.
Only define options in a single place
Single definition for non periph builds or if AP_BATTERY_SUM_ENABLED
we want the lua garbage collector to be used to re-use memory where
possible. This implements a suggestion from Thomas to avoid heap
expansion unless the last allocation failed
* remove unnecessary nullptr check, these are always called from an
initialized AP_DroneCAN so if it's nullptr something has gone
horrifically wrong
* pass in driver index instead of repeatedly calling function to get it
* simplify error handling; knowing exactly which allocation failed is not
super helpful and one failing likely means subsequent ones will too,
as it can only fail due to being out of memory
* remove unnecessary nullptr check, these are always called from an
initialized AP_DroneCAN so if it's nullptr something has gone
horrifically wrong
* pass in driver index instead of repeatedly calling function to get it
* simplify error handling; knowing exactly which allocation failed is not
super helpful and one failing likely means subsequent ones will too,
as it can only fail due to being out of memory
* remove unnecessary nullptr check, these are always called from an
initialized AP_DroneCAN so if it's nullptr something has gone
horrifically wrong
* pass in driver index instead of repeatedly calling function to get it
* simplify error handling; knowing exactly which allocation failed is not
super helpful and one failing likely means subsequent ones will too,
as it can only fail due to being out of memory
* remove unnecessary nullptr check, these are always called from an
initialized AP_DroneCAN so if it's nullptr something has gone
horrifically wrong
* pass in driver index instead of repeatedly calling function to get it
* simplify error handling; knowing exactly which allocation failed is not
super helpful and one failing likely means subsequent ones will too,
as it can only fail due to being out of memory
* remove unnecessary nullptr check, these are always called from an
initialized AP_DroneCAN so if it's nullptr something has gone
horrifically wrong
* pass in driver index instead of repeatedly calling function to get it
* simplify error handling; knowing exactly which allocation failed is not
super helpful and one failing likely means subsequent ones will too,
as it can only fail due to being out of memory
* remove unnecessary nullptr check, these are always called from an
initialized AP_DroneCAN so if it's nullptr something has gone
horrifically wrong
* pass in driver index instead of repeatedly calling function to get it
* simplify error handling; knowing exactly which allocation failed is not
super helpful and one failing likely means subsequent ones will too,
as it can only fail due to being out of memory
* remove unnecessary nullptr check, these are always called from an
initialized AP_DroneCAN so if it's nullptr something has gone
horrifically wrong
* pass in driver index instead of repeatedly calling function to get it
* simplify error handling; knowing exactly which allocation failed is not
super helpful and one failing likely means subsequent ones will too,
as it can only fail due to being out of memory
* remove unnecessary nullptr check, these are always called from an
initialized AP_DroneCAN so if it's nullptr something has gone
horrifically wrong
* pass in driver index instead of repeatedly calling function to get it
* simplify error handling; knowing exactly which allocation failed is not
super helpful and one failing likely means subsequent ones will too,
as it can only fail due to being out of memory
* remove unnecessary nullptr check, these are always called from an
initialized AP_DroneCAN so if it's nullptr something has gone
horrifically wrong
* pass in driver index instead of repeatedly calling function to get it
* simplify error handling; knowing exactly which allocation failed is not
super helpful and one failing likely means subsequent ones will too,
as it can only fail due to being out of memory
* remove unnecessary nullptr check, these are always called from an
initialized AP_DroneCAN so if it's nullptr something has gone
horrifically wrong
* pass in driver index instead of repeatedly calling function to get it
* simplify error handling; knowing exactly which allocation failed is not
super helpful and one failing likely means subsequent ones will too,
as it can only fail due to being out of memory
* remove unnecessary nullptr check, these are always called from an
initialized AP_DroneCAN so if it's nullptr something has gone
horrifically wrong
* pass in driver index instead of repeatedly calling function to get it
* simplify error handling; knowing exactly which allocation failed is not
super helpful and one failing likely means subsequent ones will too,
as it can only fail due to being out of memory
* remove unnecessary nullptr check, these are always called from an
initialized AP_DroneCAN so if it's nullptr something has gone
horrifically wrong
* pass in driver index instead of repeatedly calling function to get it
* simplify error handling; knowing exactly which allocation failed is not
super helpful and one failing likely means subsequent ones will too,
as it can only fail due to being out of memory
* remove unnecessary nullptr check, these are always called from an
initialized AP_DroneCAN so if it's nullptr something has gone
horrifically wrong
* pass in driver index instead of repeatedly calling function to get it
* simplify error handling; knowing exactly which allocation failed is not
super helpful and one failing likely means subsequent ones will too,
as it can only fail due to being out of memory
* remove unnecessary nullptr check, these are always called from an
initialized AP_DroneCAN so if it's nullptr something has gone
horrifically wrong
* pass in driver index instead of repeatedly calling function to get it
* simplify error handling; knowing exactly which allocation failed is not
super helpful and one failing likely means subsequent ones will too,
as it can only fail due to being out of memory
this is the loop which ensures the amount of data sent to the mavlink client (usually Python) is limited - if we don't do this then we lose vast amounts of data when running at large speedups.
By attempting to process inbound data we may realise that the TCP connection has been dropped, and in that case we will start to listen for another connection.
This allows you to terminate the sim_vehicle.py MAVProxy and have it automagically restart (when running under GDB). This is very useful for testing MAVProxy patches with SITL; it's a different workflow to opening an output and connecting a new version of MAVProxy to that outout.
