Msp #2
Open
Msp #2
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This should be able to be overridden by targets. e.g. ones that use octospi IO lines 4-7 instead of 0-3.
…change (betaflight#13623) battery - fix BATTERY_NOT_PRESENT detection, detection logic change (betaflight#13599) * battery - fix BATTERY_NOT_PRESENT detection, detection logic change Detection logic is refactored - battery voltage delta is tested each 50ms, voltage is considered stable when difference of last 10 samples is smaller than 100mV This makes stable threshold more forgiving than betaflight#13350 (time for comparison is 50 instead of 500ms). * battery - improve stable voltage detection - voltageStablePrevFiltered every time delta is exceeded - voltage within range is ANDed over 100ms periods - voltage is stable if it was within range for 10 out of 11 periods - slowly changing voltage will update threshold, but voltage will be considered stable - 1 update/s (100mV/s) is tolerated * battery - fuix typos, improve comments Co-authored-by: Petr Ledvina <[email protected]>
…#13706) (betaflight#13713) Set next state expected time on per element basis (betaflight#13706) * Set next state expected time on per element basis * Rename osdNextElement to be clearer Co-authored-by: Steve Evans <[email protected]>
…etaflight#13695) (betaflight#13726) FIX: make: Circular configs <- configs dependency dropped. (betaflight#13695) (cherry picked from commit 660018b)
…13764) (betaflight#13771) fix at32 serial bidir pp od init and smart audio (betaflight#13764) include fix for F4 and G4 as well Co-authored-by: Benedikt Kleiner <[email protected]> Co-authored-by: Eike Ahmels <[email protected]>
…ht#13820) Fix telemetry for Spektrum/SRXL (betaflight#13814) * Fix telemetry for Spektrum/SRXL * Update after ledvinap review * Update comments
…ight#13769) (betaflight#13827) Modify STM32F405 UID Address for MSC Enumeration (betaflight#13769) Update usbd_msc_desc.c Co-authored-by: ainosukii <[email protected]>
…aflight#13813) (betaflight#13839) Split OSD element rendering into draw and display states (betaflight#13813) Co-authored-by: Steve Evans <[email protected]>
Fix sbufReadData not advancing src pointer
OSD background rendering (betaflight#13897) * Ensure display severity attribute is set to defaults for background items * MAX7456 doesn't have a background layer Co-authored-by: Steve Evans <[email protected]>
Fixes betaflight#13220: Fix kiss esc passthrough, Fix castle (escprog cc) command. (betaflight#13911) * Fix kiss esc passthrough, Fix castle (escprog cc) command. * Update src/main/drivers/serial_escserial.c Thank you. --------- Co-authored-by: Kiss Ultra <[email protected]> Co-authored-by: Alex Fedorov <[email protected]>
betaflight#13917) (betaflight#13918) Don't consider a prior I2C NACK to indicate the bus to be busy (betaflight#13917) Co-authored-by: Steve Evans <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Important considerations when opening a pull request:
Make sure you do not make the changes you want to open a pull request for on the
masterbranch of your fork, or open the pull request from themasterbranch of your fork. Some of our integrations will fail if you do this, resulting in your pull request not being accepted. If this is your first pull request, it is probably a good idea to first read up on how opening pull requests work (https://opensource.com/article/19/7/create-pull-request-github is a good introduction);Pull requests will only be accepted if they are opened against the
masterbranch of our repository. Pull requests opened against other branches without prior consent from the maintainers will be closed;Please follow the coding style guidelines: https://github.com/betaflight/betaflight/blob/master/docs/development/CodingStyle.md
Keep your pull requests as small and concise as possible. One pull request should only ever add / update one feature. If the change that you are proposing has a wider scope, consider splitting it over multiple pull requests. In particular, pull requests that combine changes to features and one or more new targets are not acceptable.
Ideally, a pull request should contain only one commit, with a descriptive message. If your changes use more than one commit, rebase / squash them into one commit before submitting a pull request. If you need to amend your pull request, make sure that the additional commit has a descriptive message, or - even better - use
git commit --amendto amend your original commit.All pull requests are reviewed. Be ready to receive constructive criticism, and to learn and improve your coding style. Also, be ready to clarify anything that isn't already sufficiently explained in the code and text of the pull request, and to defend your ideas.
If your pull request is for a new target or an update to an existing target, please be aware that all targets have to be submitted as Unified Target configurations if a Unified Target for the MCU type is available. Read and follow these instructions.
We use continuous integration (CI) with Azure Pipelines to build all targets and run the test suite for every pull request. Pull requests that fail any of the builds or fail tests will most likely not be reviewed before they are fixed to build successfully and pass the tests. In order to get a quick idea if there are things that need fixing before opening a pull request or pushing an update into an existing pull request, run
make pre-pushto run a representative subset of the CI build. Note: This is not an exhaustive test (which will take hours to run on any desktop type system), so even if this passes the CI build might still fail.If your pull request is a fix for one or more issues that are open in GitHub, add a comment to your pull request, and add the issue numbers of the issues that are fixed in the form
Fixes #<issue number>. This will cause the issues to be closed when the pull request is merged;If your pull request contains a change that can be tested by other users, please build a set of test firmware files for all Unified Targets and attach them to the pull request. The required firmware files can be built in zipped form ready for upload to GitHub with
make unified_zip. When attaching test firmware files, you can point users to this video for instructions on how to install the test firmware: https://youtu.be/I1uN9CN30gwRemove this Text :).