What is *your* most needed feature in Developer Studio?

Dear Developer Studio users,

we’d like to have your feedback on the following question:
what is the most needed feature you need in Developer Studio to speedup your application development?

We believe that Developer Studio is going more and more mature, year after year, but maybe either we missed something important for you, or you should have many great (or even crazy :slight_smile:) ideas to improve it again and again!
So please feel free to answer to this post with all your suggestions for new features and ideas!
(Please just don’t report bugs here: in such cases, just start a new thread, thanks :wink:)

Thanks in advance for your feedback.

As I’m not full time modem developer, mostly here and there, so my opinion should have very little weight, but there’s one thing that made me drop the target management altogether and instead write my own terminal with xmodem support: can’t make the communication console stick to the modem, it always resets to build log or some other stuff and I have to go switch it again and again, driving me crazy. For that matter, can’t seems to have 2 of these, one only following the modem and make it in all perspectives.
While on the topic, I’m trying the on device debug from time to time, but can’t really make it to show global variables’ values and resorting to printing to console, which defeats the purpose of having the debug. Also, when you stop the debug, the program just restarts in the modem and starts running doing all kind of bad things till it is in more useful state, would prefer when the debug session is killed the app to not be in running state till next debug.

Well, my post turned out to be wishlist, but can’t really pick one from these to label it most needed :slight_smile:

Indeed: It's the Wrong Console, Gromit!

:angry:

How about a way to export projects as makefiles? This will enable us to build the applications together with the rest of our source tree on a build server. I know there is a headless build available, but I’ve never been able to get that to work properly.

Working RTE debugging.
We have a large project (500+files) with binary size > 1.5Mreg. At the moment we are forced to use TRACEs (300+instances) and debug by watching in target. This is because the RTE debug just freezes in wip_netInit() (problem supposedly fixed in earlier F/Ws).
As it stands, the development effort has tied up one developer just to try to coax the required functionality out of the Q26EX001 modems. Needless to say, it is a very expensive process. Embedded debugging is out of question as we have had no success in trying to get it working and Sierra support has been unresponsive on the issue for 9 months now.

Downloading the application faster, less checks. That would speed up my debugging.

Not failing to switch the device into development mode, reliable USB communication. Working RTE debugging would be also very nice.

Connection-Managment to the device seems to be sort of bad.

it would be n1, if the dev studio wouldn´t just close, when i want to start my code via “run”, while the dev studio is connecting to a device.

Also it would be n1, if the dev studio would try to automaticly reconnect to the device, when the connection is broken. Every 2nd-3rd time i want to execute new code, it gives me an error, that the connection isn´t established… and i have to deconnect and (re-)connect to the device manually.

otherwise the day will come, where i destroy something, that is near enough to grab and throw it, in rage, due to the combination of those 2 errors… :laughing:

edit:
and like allready said in this thread: Debugging

yes, yes, there is a workaround, but i would like to have:
the capability of using %f in sprintf :smiley:

Was there any workaround for the %f issue that does not require you to write to a temporary string instead of using %f directly?

(We’ve been using the ADS compiler so far, but since that’s been deprecated we need to decide if we should upgrade to RVDS or change to GCC)

Actually, is the %f issue only with ARM ELF GCC and no problem with ARM EABI GCC?

Yes, it is occurring only on ARM ELF GCC toolchain.

But why is it still occurring at all after all these years?!

It was a binding issue inside the C library between the sprintf and the memory allocation functions. As this integrated toolchain was not maintained anymore by the supplier, and because we were putting our efforts to the “new” GCC, we didn’t focused on the problem.

Some documentation probably needs to be updated to reflect that it doesn’t affect the EABI toolchains.

Knowing this will make it easier for me when I start porting some of our products to SL808xT.