I keep having weird compiler warnings for months - so I just followed the guide to create the blinky demo with 5.15 - and still have these issues using the Mbed compiler, see below.
Why will an almost empty project with new and up-to-date libraries throw these warnings ?
Warning: ‘CallChain’ is deprecated: CallChain has been deprecated and will be removed. [-Wdeprecated-declarations] in “extras/mbed-os.lib/drivers/InterruptManager.h”, Line: 204, Col: 5
Warning: ‘get_ip_address’ is deprecated: String-based APIs are deprecated [since mbed-os-5.15] [-Wdeprecated-declarations] in “extras/mbed-os.lib/features/cellular/framework/AT/AT_CellularContext.cpp”, Line: 266, Col: 24
Warning: ‘stop’ is deprecated: Use CellularDevice::shutdown() instead. [since mbed-os-5.15] [-Wdeprecated-declarations] in “extras/mbed-os.lib/features/cellular/framework/AT/AT_CellularContext.cpp”, Line: 935, Col: 30
Warning: Implicit conversion from enumeration type ‘kmp_result_e’ to different enumeration type ‘sec_prot_result_e’ [-Wenum-conversion] in “extras/mbed-os.lib/features/nanostack/sal-stack-nanostack/source/Security/protocols/key_sec_prot/key_sec_prot.c”, Line: 321, Col: 44
Warning: ‘NVStore’ is deprecated: NVStore is deprecated in favor of KVStore [since mbed-os-5.15] [-Wdeprecated-declarations] in “extras/mbed-os.lib/features/storage/nvstore/source/nvstore.h”, Line: 92, Col: 24
Warning: ‘wait’ is deprecated: ‘wait’ is deprecated in favor of explicit sleep functions. To sleep, ‘wait’ should be replaced by ‘ThisThread::sleep_for’ (C++) or ‘thread_sleep_for’ (C). If you wish to wait (without sleeping), call ‘wait_us’. ‘wait_us’ is safe to call from ISR context. [since mbed-os-5.14] [-Wdeprecated-declarations] in “extras/mbed-os.lib/targets/TARGET_NXP/USBHAL_LPC17.cpp”, Line: 414, Col: 5
Warning: L3912W: Option ‘legacyalign’ is deprecated.
Warning: Unknown action post-build - xTest2.LPC1768
Mbed-os is and probably will be in a state of continuous development to keep up with ever changing technologies. To test the library changes, the users are pretty much like guinea pigs which is the best way to test any application. That way if a user experiences an anomaly, fault or simply an improvement mbed can make changes.
Many warnings are to advise that some previous library code will be changed or removed and no longer work in the future. By doing that the user has plenty of time to make changes to their own program code before it simply no longer compile.
Also some target and board vendors are not maintaining their platform’s as these changes occur and is creating some issues.
I’d say that if the issues refer to mbed-os files, you can safely ignore them, the mbed team will remove them at some point.
If the issues come from your own code, you should look into the work around referenced in the warning to silence them and make sure your code is ready for future evolutions. wait is a good example of that.
What I’m complaining about is the fact that even the “blinky” example does not compile without warnings - there were people in the forum 5 yrs ago reporting the same issues.
We have a small commercial product running on mbed, started that in 2010 - every time I want to work on the code (which happens 1-2 times per year) either the comiler won’t compile my “old” code or, when I upgrade, the new version will cause new issues.
For a new development, I hesitating to use mbed anymore because I can see no long-time continous support with the quality we need for an industrial application.
Forget all this IOT hype - real industry demands products with a life time of 15-20 years, how am I going to provide this to my customers ?
Matthias, for the moment you can always roll back your mbed library revisions and simply don’t update. I do this on a couple of ‘old’ projects I have with lib’s dating back to 2016. You can also export to another offline compiler. But ultimately you will need to update just like all other operating systems, Windows, Mac its the same old story. Love it or hate it and some call it progress, i’d sooner spend my time drinking beer
One thing that has changed from 5.12 onwards is that the underlying compiler we use is Arm Compiler 6. It is much “chattier” with its warnings than Arm Compiler 5, so it is likely that is the source of the warnings.
You can’t have your cake and eat it, if you want MBED to evolve and improve then there will be depreciating sections of code that will throw up warnings.
This issue can not go away completely.
I moved over to Mbed Studio, no problem after the initial compile, that can take a while depending of what MBED functions you are using.
However OS6.6 is working really good atm, again, I recommend using off line MBED-Studio, much, much faster on re-compiles and you have total control of the MBED-OS library if you want to tweak it.
