AP_FrSky_Telem: Don't retain the object if no ports were found #11612
Conversation
Saves 96 bytes of RAM
This saves 280 bytes of RAM
| @@ -2279,7 +2280,13 @@ void GCS::setup_uarts(AP_SerialManager &serial_manager) | |||
| chan(i).setup_uart(serial_manager, AP_SerialManager::SerialProtocol_MAVLink, i); | |||
| } | |||
|
|
|||
| frsky.init(); | |||
| if (frsky == nullptr) { | |||
There was a problem hiding this comment.
Shouldn't this be some sort of assert?
There was a problem hiding this comment.
I had the thought. It looks like we only ever call it once at the moment, but nothing strictly enforced that, and I didn't chase if setup_uart is actually fine a second time. But if you think it should be a sitl panic I can make it do that.
| @@ -33,12 +33,15 @@ | |||
|
|
|||
| extern const AP_HAL::HAL& hal; | |||
|
|
|||
| ObjectArray<mavlink_statustext_t> AP_Frsky_Telem::_statustext_queue(FRSKY_TELEM_PAYLOAD_STATUS_CAPACITY); | |||
| AP_Frsky_Telem::AP_Frsky_Telem(void) : | |||
There was a problem hiding this comment.
I wonder... could we eliminate this constructor altogether by using brace-initialisation of _statustext_queue within the header file?
Happy to merge this and do that as a future PR...
There was a problem hiding this comment.
I messed around a bit and got the syntax wrong, so I moved it out cause I knew the syntax for that :) Will come back to trying with braces.
|
tested on KakuteF4, works well |
This is something I've wanted to mess with for awhile now. The basic idea is that if we don't have a serial port for it, we can't possibly have a useful instance of the FrSky telem, so skipping updating it saves time and memory.
The overall RAM savings is 376 bytes, it's split between two commits:
I've tested this on a Cube (running Plane is where the numbers came from) without any FrSky setup, I have the hardware in a box to test with FrSky, but I've never actually gotten to setting it up, so if someone can help with validating that it would be appreciated.
Are there any objections to this path of removing stuff on startup that we don't need?
I'd like to extend this to also cover Devo, but only did FrSky as proof of concept.EDIT: Devo is maybe not worth the effort, it holds a uint32_t and pointer... For the 8 bytes of RAM I'd spend more in flash...