You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 27, 2021. It is now read-only.
Describe the feature
To enable us to use mocks of classes we create in unit tests, we create virtual classes such as OsInterface, which two classes inherit from: 1) a class that actually calls the hardware API functions (OsInterfaceImpl) and 2) a mock class MockOsInterface which is used in unit tests see (Common/tests/OsInterface_test.cpp).
These classes have function signatures which match function signatures of the underlying hardware API (return value and parameters at least) (e.g. osSemaphoreWait() in cmsis_os.h and OsInterface::OS_osSemaphoreWait() in our virtual class, and use the same types defined in the underlying hardware API. E.g., cmsis_os.h defines osSemaphoreId which the virtual function we defined OS_osSemaphoreWait() returns. Because of the matching signatures and types, virtual interface classes like OsInterface are closely tied to the hardware API, which is cmsis_os.h in OsInterface's case.
The process of writing out the function declarations for the virtual classes is quite mechanical, and can take some time if there are a lot of function calls we need to virtualize. We should try and automate generation of the interface class definition for a given hardware API. This would look like the following for a single function call:
This might take the form of a script (e.g. in Python) that parses function declarations in the original driver file
stm32f4xx_hal_uart.h, and writes the new declaration in the hal::UartInterface class in UartInterface.h.
Reason for request
Save time writing out function parameters and return values for virtual classes that we only ever use as a bridge between hardware code and mock code in unit tests.
Timeline
Not urgent - no timeline.
Additional information
It's expected that we might want to make our own manual adjustments, e.g. changing the generated transmit function to transmitPoll for better clarity (like we have done already). Automating the bulk of the writing out parameters and return values would still save a lot of time.
Possibly extend this to generate the Impl class like OsInterfaceImpl too.
The text was updated successfully, but these errors were encountered:
rfairley
changed the title
Automate generation of hardware API interface classes
Automate generation of Interface classes from hardware API functions
Feb 16, 2019
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Describe the feature
To enable us to use mocks of classes we create in unit tests, we create virtual classes such as
OsInterface
, which two classes inherit from: 1) a class that actually calls the hardware API functions (OsInterfaceImpl
) and 2) a mock classMockOsInterface
which is used in unit tests see (Common/tests/OsInterface_test.cpp
).These classes have function signatures which match function signatures of the underlying hardware API (return value and parameters at least) (e.g.
osSemaphoreWait()
incmsis_os.h
andOsInterface::OS_osSemaphoreWait()
in our virtual class, and use the same types defined in the underlying hardware API. E.g.,cmsis_os.h
definesosSemaphoreId
which the virtual function we definedOS_osSemaphoreWait()
returns. Because of the matching signatures and types, virtual interface classes likeOsInterface
are closely tied to the hardware API, which iscmsis_os.h
inOsInterface
's case.The process of writing out the function declarations for the virtual classes is quite mechanical, and can take some time if there are a lot of function calls we need to virtualize. We should try and automate generation of the interface class definition for a given hardware API. This would look like the following for a single function call:
stm32f4xx_hal_uart.h
↓
UartInterface.h
This might take the form of a script (e.g. in Python) that parses function declarations in the original driver file
stm32f4xx_hal_uart.h, and writes the new declaration in the hal::UartInterface class in UartInterface.h.
Reason for request
Save time writing out function parameters and return values for virtual classes that we only ever use as a bridge between hardware code and mock code in unit tests.
Timeline
Not urgent - no timeline.
Additional information
It's expected that we might want to make our own manual adjustments, e.g. changing the generated
transmit
function totransmitPoll
for better clarity (like we have done already). Automating the bulk of the writing out parameters and return values would still save a lot of time.Possibly extend this to generate the
Impl
class likeOsInterfaceImpl
too.The text was updated successfully, but these errors were encountered: