Mirror/ardupilot
5
0
Fork 0
mirror of https://github.com/ArduPilot/ardupilot synced 2025-02-14 03:43:57 -04:00
Code Issues Packages Projects Releases Wiki Activity
0d932e8a54
ardupilot/libraries/AP_HAL/system.h

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

26 lines
391 B
C
Raw Normal View History

AP_HAL: create AP_HAL namespace and use for some HAL functionality For certain basic functionality, there aren't much benefit to be able to vary the implementation easily at runtime. So instead of using virtual functions, use regular functions that are "resolved" at link time. The implementation of such functions is provided per board/platform. Examples of functions that fit this include: getting the current time (since boot), panic'ing, getting system information, rebooting. These functions are less likely to benefit from the indirection provided by virtual interfaces. For more complex hardware access APIs the indirection makes more sense and ease the testing (when we have it!). The idea is that instead of calling hal.scheduler->panic("on the streets of london"); now use AP_HAL::panic("on the streets of london"); A less important side-effect is that call-site code gets smaller. Currently the compiler needs to get the hal, get the scheduler pointer, get the right function pointer in the vtable for that scheduler. And the call must include an extra parameter ("this"). Now it will be just a function call, with the address resolved at link time. This patch introduces the first functions that will be in the namespace, further patches will implementations for each board and then switch the call-sites. The extra init() function allow any initial setup needed for the functions to work.
2015-11-19 23:24:56 -04:00
#pragma once
#include <stdint.h>
#include <AP_Common/AP_Common.h>
#include "AP_HAL_Macros.h"
namespace AP_HAL {
void init();
Global: Rename printf format attribute As commented in 8218140 ("AP_Common: add scanf format macro"), "FORMAT" was a bad name for this macro since there's also the scanf. Rename to FMT_PRINTF to follow the scanf name.
2015-11-10 13:05:19 -04:00
void panic(const char *errormsg, ...) FMT_PRINTF(1, 2) NORETURN;
AP_HAL: create AP_HAL namespace and use for some HAL functionality For certain basic functionality, there aren't much benefit to be able to vary the implementation easily at runtime. So instead of using virtual functions, use regular functions that are "resolved" at link time. The implementation of such functions is provided per board/platform. Examples of functions that fit this include: getting the current time (since boot), panic'ing, getting system information, rebooting. These functions are less likely to benefit from the indirection provided by virtual interfaces. For more complex hardware access APIs the indirection makes more sense and ease the testing (when we have it!). The idea is that instead of calling hal.scheduler->panic("on the streets of london"); now use AP_HAL::panic("on the streets of london"); A less important side-effect is that call-site code gets smaller. Currently the compiler needs to get the hal, get the scheduler pointer, get the right function pointer in the vtable for that scheduler. And the call must include an extra parameter ("this"). Now it will be just a function call, with the address resolved at link time. This patch introduces the first functions that will be in the namespace, further patches will implementations for each board and then switch the call-sites. The extra init() function allow any initial setup needed for the functions to work.
2015-11-19 23:24:56 -04:00
AP_HAL: added micros16() method fast method for both 16 and 32 bit timers
2021-10-02 02:39:08 -03:00
uint16_t micros16();
AP_HAL: create AP_HAL namespace and use for some HAL functionality For certain basic functionality, there aren't much benefit to be able to vary the implementation easily at runtime. So instead of using virtual functions, use regular functions that are "resolved" at link time. The implementation of such functions is provided per board/platform. Examples of functions that fit this include: getting the current time (since boot), panic'ing, getting system information, rebooting. These functions are less likely to benefit from the indirection provided by virtual interfaces. For more complex hardware access APIs the indirection makes more sense and ease the testing (when we have it!). The idea is that instead of calling hal.scheduler->panic("on the streets of london"); now use AP_HAL::panic("on the streets of london"); A less important side-effect is that call-site code gets smaller. Currently the compiler needs to get the hal, get the scheduler pointer, get the right function pointer in the vtable for that scheduler. And the call must include an extra parameter ("this"). Now it will be just a function call, with the address resolved at link time. This patch introduces the first functions that will be in the namespace, further patches will implementations for each board and then switch the call-sites. The extra init() function allow any initial setup needed for the functions to work.
2015-11-19 23:24:56 -04:00
uint32_t micros();
uint32_t millis();
AP_HAL: add millis16 to HAL; provide weak implementation This wraps every minute or so - but if you only need to track intervals under ~65 seconds could save RAM
2018-08-08 01:55:14 -03:00
uint16_t millis16();
AP_HAL: create AP_HAL namespace and use for some HAL functionality For certain basic functionality, there aren't much benefit to be able to vary the implementation easily at runtime. So instead of using virtual functions, use regular functions that are "resolved" at link time. The implementation of such functions is provided per board/platform. Examples of functions that fit this include: getting the current time (since boot), panic'ing, getting system information, rebooting. These functions are less likely to benefit from the indirection provided by virtual interfaces. For more complex hardware access APIs the indirection makes more sense and ease the testing (when we have it!). The idea is that instead of calling hal.scheduler->panic("on the streets of london"); now use AP_HAL::panic("on the streets of london"); A less important side-effect is that call-site code gets smaller. Currently the compiler needs to get the hal, get the scheduler pointer, get the right function pointer in the vtable for that scheduler. And the call must include an extra parameter ("this"). Now it will be just a function call, with the address resolved at link time. This patch introduces the first functions that will be in the namespace, further patches will implementations for each board and then switch the call-sites. The extra init() function allow any initial setup needed for the functions to work.
2015-11-19 23:24:56 -04:00
uint64_t micros64();
uint64_t millis64();
AP_HAL: move dump_strack_trace into HAL Use a weak definition to allow subclasses to override
2019-06-10 23:14:01 -03:00
void dump_stack_trace();
AP_HAL: generate a core file for a given PID Similarly to dumpstack.sh, uses gdb to dump a core file
2021-07-06 02:32:24 -03:00
void dump_core_file();
AP_HAL: move dump_strack_trace into HAL Use a weak definition to allow subclasses to override
2019-06-10 23:14:01 -03:00
AP_HAL: create AP_HAL namespace and use for some HAL functionality For certain basic functionality, there aren't much benefit to be able to vary the implementation easily at runtime. So instead of using virtual functions, use regular functions that are "resolved" at link time. The implementation of such functions is provided per board/platform. Examples of functions that fit this include: getting the current time (since boot), panic'ing, getting system information, rebooting. These functions are less likely to benefit from the indirection provided by virtual interfaces. For more complex hardware access APIs the indirection makes more sense and ease the testing (when we have it!). The idea is that instead of calling hal.scheduler->panic("on the streets of london"); now use AP_HAL::panic("on the streets of london"); A less important side-effect is that call-site code gets smaller. Currently the compiler needs to get the hal, get the scheduler pointer, get the right function pointer in the vtable for that scheduler. And the call must include an extra parameter ("this"). Now it will be just a function call, with the address resolved at link time. This patch introduces the first functions that will be in the namespace, further patches will implementations for each board and then switch the call-sites. The extra init() function allow any initial setup needed for the functions to work.
2015-11-19 23:24:56 -04:00
} // namespace AP_HAL
Reference in New Issue Copy Permalink