-
-
Notifications
You must be signed in to change notification settings - Fork 921
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Better cloud build options #3315
Comments
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within a week. |
No one else thinks that this can be improved? |
You can add whatever you like, but radio, telemetry and motor protocol should be a single option. And yes we can improve here and there. However for your use case you can add to custom defines from this list:
|
Thanks for the info @haslinghuis But, I think it should be easier to use than having to edit custom defines. One note though. You said that "telemetry and motor protocol should be a single option.". But, the default telemetry is not a single option. It installs CRSF and GHST telemetry with the default settings. I don't really see why it needs to be singular either. Otherwise, if you change receiver, you could end up having to re-flash again, where as in 4.3 it would have just been changing an option. I also think the Install all option would be useful. If I don't use an F411 or F722, I really can't be bothered with all this just to flash firmware. |
Do you have more then once receiver installed on the flight controller and why? This is really an edge case. You still need to change settings etc. Yes the CRSF, GHST, SBUS option should already have been removed. |
I do need option 'Install all'. And newbies in community of South Korea(my country :)) sometimes asks 'how to change receivers of second hand drone.' I think classic way full build is still good and straight way, even cloud build is necessary for future. |
Point it with some chipsets you can’t build all because stuff already doesn’t fit. The bf system has on average 6000 builds a day going through the system so it seems people are adapting and using the system just fine |
It doesn’t fit because everything is just optimised for speed. There is loads of code that could be optimised for efficiency. That would have not needed any of the cloud stuff. INAV is no doubt a bigger firmware. But that can still fit on F411 due to how it’s compiled. |
Guess it's a trade off. Betaflight's main goal is flight performance. Having categories (race, freestyle, cinematic, long range) we could choose the optimization level for specific needs. The cloud API already allows addition of multiple radio and telemetry protocols using custom defines as I think this is still an edge case. |
my case, adding multiple protocols with custom defines not working. |
@blckmn After all the hard work to downsize the firmware should we consider a full build option for firmware size > 512KB ? |
This is available already for download from the releases itself. Anything with >512kb of flash space has everything compiled in. You will need a complete dump to make the target operational. You don't need cloud build. It is merely a convenience. Also, the original author has missed one of the big features of cloud building, which is the defaults for a target without reserving flash space for and needing to "download and set" defaults. This becomes apparent in 4.5.0. NOTE: Some targets with external flash for booting can only be provisioned by cloud build or local build. I think a better solution to the authors dislike of cloud build is to perhaps add in the ability to build locally within the configurator itself. |
As a manufacturer of flight controllers, I fully agree with this, as I mentioned today in the discord Currently there are five ways to build the firmware:
(Some information above gleaned from this comment: https://github.com/betaflight/betaflight/blob/master/src/main/target/common_pre.h#L28-L36) So given the above, it would be nice As a manufacturer of non-budget hardware, I want the user's experience to be as simple as possible, without them getting confused when they see and select an option in the UI which isn't compiled into the firmware. Seeing an option in the UI, e.g. a radio or motor protocol, creates the expectation that it will work when the user selects it. If the firmware flashed in the factory is a cloud-build, with no options selected, or not the ones the user needs, then the user will be confused an this generates support overhead and dis-satisfaction with the product, sometimes even leading to unwanted chargebacks or refund requests. As a user and manufacturer it would be nice if the UI showed the user exactly what features are going to be enabled, and what can be enabled, so the user knows what their build contains, secondly, and I know this is more difficult given the current code-base, it would be ideal if the UI could show the same information after the firmware has been created, installed and the user has connected to the FC, but likely that is out-of-scope of this issue, but very related. |
+1 for full-feature option (by any name -- full, baseline, ...). i mentioned in the past as well, specifically with vendors in mind. but have now become accustomed to cloud-building. |
naming wise, as a name, 'factory', 'default' or 'baseline' works for me, 'full' does not as it implies everything is included when some code is not included unless specific defines are used. I'm also not 100% convinced by the 'core' name, as it doesn't convey it's meaning or intent well since it's not really meant for end-users to use, same goes for 'cloud', perhaps 'custom' would have been better there IMHO, but that's a different story. |
Going back to the issue of users being confused by cloud builds, one major issue is that if they have a 'baseline'/'factory' firmware installed and try and add some 'non-baseline' feature, what happens is that they don't actually /add/ something, instead what happens is that they /remove/ loads of features and only add the additional feature they chose, so then all their other stuff that was working stops working until they figure out the exact features to add to the cloud build extra args input, which most users, in my experience, are not capable of doing, which leads to frustration and support requests. |
Is your feature request related to a problem? Please describe
Sorry, I don't like the cloud build at all. It will be especially confusing to new users. I also don't like that you will need to flash new firmware if you change some little hardware thing, like a receiver for example. I under stand it's there for F411 and F722 MCUs. But surely compiling some areas of the code for efficiency would have solved that problem, and not needed cloud build at all.
Anyway. I have a couple of suggestions which may make the process better.
Describe the solution you'd like
Describe alternatives you've considered
Pretty self explanatory in the last section
Other information
No response
The text was updated successfully, but these errors were encountered: