SPRACINGH7EXTREME - Disable requirement for custom gyro alignment and
dual gyro.
Requires custom gyro rotation code to be merged first, see:
https://github.com/betaflight/betaflight/pull/7845https://github.com/betaflight/betaflight/pull/8474
SPRACINGH7EXTREME - Add boards documentation and images.
Add SPRacingH7EXTREME to the list of official targets.
SPRACINGH7EXTREME - Add unified target config.
Note: untested as no unified target exists for STM32H750+EXST yet.
SPRACINGH7EXTREME - Use correct gyro settings now that #8474 is merged.
SPRACINGH7EXTREME - Combine target files.
SPRACINGH7EXTREME - Update unified target config.
The original implementation:
* removed the old 'alignment' variable
* did not require 'ALIGN_CUSTOM'
* always used rotation matrix
* had no additional per-pid-loop conditional logic.
Extract currently unused code into tests.
In preparation for either deleting or re-using in validateAndFixConfig.
Fix code style of some old boardalignment code.
De-duplicate vector rotation code.
Now that rotation code is exacted from `alignBoard` and now doesn't use
`boardRotation` some if it was similar to the code in `rotateV` in
maths.c
Use DECIDEGREES for mag and gyro/acc custom alignments.
Use unnamed structure instead of `values`.
Redefine what 'custom' orientation means.
Move alignment test-only code into the tests.
Ensure gyro/mag custom alignment settings follow the enum variations.
This can't be applied to ALIGN_DEFAULT because, in the case of the MAG,
the default isn't actually known until the gyro is detected, see
`compassDetect`.
OMNIBUSF4/F7 - Don't use ALIGN_DEFAULT in target.h,
common_defaults_post.h does this now.
Comment cleanup.
Delete unused alignment code left from various tests/refactoring
efforts.
* Please do not squash this commit.
Fix SITL build by avoiding structure assignment with anonymous inner
struct.
The error from the build server was as follows:
```./src/main/common/sensor_alignment.c:49:5: error: missing initializer
for field ‘yaw’ of ‘struct <anonymous>’
[-Werror=missing-field-initializers]
*sensorAlignment = CUSTOM_ALIGN_CW0_DEG;
^
In file included from ./src/main/common/sensor_alignment.c:27:0:
./src/main/common/sensor_alignment.h:80:17: note: ‘yaw’ declared here
int16_t yaw;
^
```
Cleanup sensor_alignment API.
Allows fine tuning of the voltage divider resistance values for each button to account for slight variances amongst cameras. Also allows manual configuration for non-standard cameras. Resistance values are in 100ohm steps.
- VRef and Temperature sensor calibration constants defined in "stm32h7xx_ll_adc.h" are now included via “stm32h7xx_hal_adc.h”.
- Boostmode is now handled by HAL_ADC_Init using clock configuration parameters to cope with Rev.V.
- Channel specifier (ADC_CHANNEL_x) was a simple integer with V1.3.0, is now an bit field encoded value.
adcTagMap had this value, but adcChannel field in adcOperationConfig was not big enough to store it.
The adcChannel field is modified to hold 32-bit value.
- Rank for channel configuration was a integer, now a bit field encoded value (ADC_RANK_x).
adcRegularRankMap array was added to translate rank number to rank value.
- Other Rev.V changes also seem to be handled within HAL.
Application of
Use union to access access size sensitive registers (7a0d3e7)
to V1.4.0
----
Note from "Use union to access access size sensitive registers (7a0d3e7)":
----
Use union to access access size sensitive registers
As described in RM0433 section 49.4.13 "Data packing", STM32H7's SPI data register supports data packing and it is sensitive to actual access width.
The original code used pointer casting to obtain a code to access the register in a desired size.
However, these operation results in strict aliasing warnings (deferencing punned pointer) and are not desirable.
Here, we declare a union that allow access to a 32-bit register in 8, 16 or 32-bit width and cast pointer to the original RXDR and TXDR data registers and then access the portion of the register through an appropriate union member.
XXX FIXME Only handled 16-bit access case, as 32-bit (original declaration) and 8-bit (allowed) cases do not generate warnings, but these should be handled similarly for correctness and consistency of the code.
