S60 Open to new features

Another build issue we addressed in Carbide 1.3 was a performance issue concerning compile times when compared to CodeWarrior. CodeWarrior has an option to run compiles concurrently, which reduced overall build time signficantly. Make has a similar feature which can be enabled with the -j switch. When specified it will run the make rules concurrently in multiple jobs and thus the compilation time will be faster. This works on multi-core and hyper-threaded machines.

I hadn't realized that the latest N95 firmware didn't work with older TRK versions until I read this. Many developers don't know about the TRK version checker with Carbide 1.3.1, but if you are using TRK you should.

Next time you load TRK on your device and are connected select Help > On-Device Setup... Then you will know if you have the latest available TRK version for your device. If you don't, the On-Device Setup wizard can install the latest TRK for you.

Eric at NewLC writes that Sony-Ericsson just released a new (UIQ 3) SDK Synchronizer plug-in. Since it just compares an existing file system with a zip archive I didn't think it was only specific to UIQ3, so I gave it a quick go on the S60 3rd FP2 SDK.

The Carbide.c++ 1.3 builder depends on the underlying Symbian OS command line. But the Symbian command line system had some limitations and problems that were addressed to improve performance and make it simpler for the user to build his project. What were some of these improvements we did to make a better build system? Let's talk about them now.

Have you ever wondered how to get training on Carbide C++ besides reading the online manuals or contacting our support personnel? If you are the small firm that doesn't have many developers who develop Symbian applications your choices are limited to the online training videos on forum Nokia wiki, reading the built-in Carbide Help manuals and this blog.

We do a really cool thing with our launch configuration for the emulator that some developers seem to overllook when they want to debug their application. it wasn't very obvious to users in Carbide 1.3 but it can save users development time. When the user wants to debug their application with Carbide the Symbian OS Emulator launch configuration does not launch the emulator by default but instead launches the executable built by the project.

The main reason we did this was because many users complained about how slow the emulator was to start before they could even launch their application! Also, there can be other problems when keeping the emulator running while creating an application. For example, the emulator locks resource files for some time after exiting out of the application. So if the user changed a resource file he would have to wait for the emulator to release all resources before the user could rebuild his.

This has worked very well for any kits based on Symbian OS developement kit version 9.2 or above.

Remember the first time you launched Carbide and it came up with this nifty screen full of useful information? You closed it and never looked at it again, didn't you?

Well if you want to recapture the thrill of launching Carbide for the first time, this week's screencast is a brief overview of the contents of the Welcome screen.

For this quick tip I thought it might be helpful to point out where customers can set their own build options in Carbide that take place after our build process. This can be useful for things like running a batch file after the build, but customers haven't always known where to find the option for this. In Carbide.c++ v1.3, with the project highlighted choose the "Project" and "Properties" option from the menu bar.

You may have noticed the Refactoring menu option in the context menus while using Carbide.c++. Under Carbide 1.3.x all it does is basic renaming of objects and variables. However, there is a project underway (from HSR) that adds a lot of new C++ refactoring functionality to the eclipse C/C++ tool set. You can even give it a test drive by visiting the CDT Refactoring Project website and downloading the update site and installing the plug-ins into Carbide!

In a previous blog entry I gave a quick overview of some of the basic Carbide.c++ SDK APIs and managers. This topic I'll quickly show how you can read the MMP data for any build configuration (ICarbideBuildConfiguration). The main interface for retrieving MMP data is "com.nokia.carbide.cpp.epoc.engine.model.mmp.IMMPData". Once you get access to this interface you can learn anything you want to about a particular MMP file.

Recently a Carbide developer requested some additional help with the Carbide.c++ Plug-in Developer Guide in the form of examples. The specific request, bug #6751, asks for assistance with "how to do builds using [the] Carbide APIs". It seemed a reasonable request and one we are now looking at doing in the near future.

If you are building scalable (SVG) icons for your S60 application, chances are you are using makefiles without dependency tracking. I've noticed quite a few large projects that contain several icon makefiles without proper dependency tracking which can vastly degrage rebuild performance. For example, taking 15 minutes to rebuild instead of 10 seconds for a dependency check. This is typically due to header files that are always generated under \epoc32\include (e.g. MBG files) and causing subsequent CPP files to be unnecessarily re-compiled and the project re-linked.

The feedback that we are getting from users when they try to debug with TRK over Bluetooth is rather unsatisfactory. One requirement is to have a serial port service over the Bluetooth is confusing, since by default it doesn't come with many Bluetooth enabled devices and users have to go to manufacturers sites to get it. The second one is to specify "Port" number on device to connect to. This is not really a port but rather service index on the host PC.

As we begin working on the next version of Carbide we're moving up to a new version of Eclipse and CDT. Lots of new things you'll end up seeing in Carbide come from the Eclipse platform so I wanted to let our people know that they can check out the latest milestone build of Eclipse 3.4 here.

The release notes cover the new stuff added in each milestone. Some of these features are mostly of interest to Java or Eclipse plug-in developers but the platform features will be reflected in Carbide when we move up to Eclipse 3.4.

One of the more ambitious ideas I have for the next release of Carbide is to throw all of the public Carbide docs onto a website using the Eclipse Infocenter. One of the drivers to do this is to make the information available to Google searches. Most people, including myself, have developed the habit of simply doing a Google search for anything we want and simply ignoring our local resources. In many cases I believe that people sometimes actually forget that they have product documentation on their machine. And let's face it, searching the web has become both a habit and the way things are done.

In Carbide 1.3 we now display information when a panic has occurred when doing on-device debugging.

The user will now see the stack crawl display that a panic has occurred. The panic number is shown in the StackCrawl-Thread information at the top. The top frame will be the User::Panic() code. It will have source if Euser has symbolics and disassembly otherwise. The next frame will be the caller of User::Panic() only if symbolics exist for that location. Otherwise it will be in disassembly. The application will exit and the debug session will terminate when the user resumes.

A basic overview of the Carbide C/C++ and Debugger perspectives has been posted:

You can find this and other videos at:
http://wiki.forum.nokia.com/index.php/Carbide_Training_Videos

This is pretty basic stuff; we're trying to put down a solid foundation of the fundamentals first, and then we'll start working on the more exotic stuff. We're always looking for screencast ideas, though, so speak up if you have any ideas.

So I'm sitting in a meeting today discussing how we can improve the UI for Performance Investigator (PI) in future releases. We have a lot of issues to address to improve the usability, clarity, and usefulness of the tool and are working hard to define the changes and when they can be delivered. One of the items to look at struck me by surprise. I didn't know that PI did that and I had actually documented the main feature over a year ago for Carbide 1.2 or so.

Needless to say I was a bit verklempt about the whole issue. Then I realized if I, who worked across the room from the developers didn't know of these features, it was a pretty good bet that the vast Carbide audience hadn't stumbled upon them either.

So, let's talk about them.

We used to get a lot of complaints about Carbide performance with the first releases. Slow to launch, slow to import a project, slow to launch a debug session, slow to launch the emulator, slow to build, to step, etc. We always try to improve the performance of the toolset. Here are some areas that were addressed in releases 1.3 and 1.3.1

CodeWarrior has a great feature in the debugger view to display the program under debugging in 'Source' mode, 'Disassembly' mode and "Mixed" mode. When your breakpoints are not hit or when the stepping in your program seems bogus (stepping causes program counter to jump up or down in the source file under debugging) it is invaluable to switch to debugging in 'Mixed' mode and see if the C++ sources match the ARM disassembly code. Sometimes the code is optimized and program counter will jump up and down then you can verify whether the debugger is doing the right thing by looking into the ARM code to determine the root of the problem.

We always try to improve and/or simplify debugging experience for our users and there was quite a few entries about this subject already. But the topic of ROM vs RAM debugging wasn't covered yet.
You will get the most benefits when debugging with TRK by downloading your program in RAM or installing .sis file onto the phone. This is because the typical development cycle - modify code, build project, download binaries to the phone via TRK - is very short. Some power users however prefer to debug their binaries from ROM. Usually this is only available to OEM developers and contractors - people who can flash their phone with the OS image. In this case the development cycle is longer, since after modifying and building their program users need to build the phone image as well as flash it on the phone, not to mention make sure that the symbolics files on the PC is matching the binary that they are going to flash on the phone.

Today I did a presentation of our tools at our large Boston customer and got a great positive feedback about Code Scanner feature. Developers say that it is so easy, intuitive to use and gives such a great suggestions about the fixes that they don't fix the code scanner errors themselves but rather let testers who aspire to become developers do it!

To investigate the performance of Code Scanner we ran it on the whole common Symbian/s60 sources directory and the scan completed in ~4 hours on a fairly recent PC. There was a big bunch of errors/warnings. The amount of errors is going down gradually though. We illuminated all the Code Scanner errors in TRK and PI sources last year. It is a good practice to run it every time you modify/fix something in your s60/Symbian code!

There has been a flurry of recent support questions on creating projects, debugging, and a host of other minor issues that doesn't include enough information to actually solve the problem. Upon further investigation it's discovered that the person is still using Carbide 1.2 or GASP, 1.1 as their development environment.

So the question is, why haven't you upgraded to Carbide 1.3 yet?

Carbide 1.3 includes support for Eclipse 3.3 and CDT 4.0, a host of build system improvements for large projects and indexing, a new System search capability, new debugger improvements like the Executables view and improved on-device debugger stability, new tool plug-ins like CodeScanner, Capability Scanner, Epocwind.out, and lots of bug fixes.

Carbide 1.1 and even parts of 1.2 really pale in comparison to what Carbide 1.3 offers. If this small message has struck a chord somewhere, go download the latest version here. Especially you Carbide 1.1 users as I'm sure you'll be pleasantly surprised at the improvements.

The real answer?

There is no excuse!

In Carbide 1.3.1 we've addressed a couple of major TRK issues that have always caused users problems. The first issue was determining which COM port is actually communicating with the target device running TRK. The second being that once TRK was installed on a device most users never updated it, thus missing out any improvements that later releases contained.

We've addressed both of these issues by creating the On-Device Setup dialog which can be found under the Help menu in Carbide. Use the On-Device Setup dialog to verify and update Carbide software services on a device. The first service supported is TRK.

While I spent most of my time when I visited Symbian working with their engineers, I also worked with the team that is putting together their new internal Carbide support team. In my two years as Symbian's primary support contact at Nokia over 400 of their defects and feature requests have gone through my hands, so I was happy to give them what advice I could on ways to make the transition to their new team go smoothly.

One of the things that came out of my meetings with their support team manager was an agreement to share training materials. There is no reason why Symbian and Nokia should develop separate tracks of Carbide training material covering the same ground, so we're looking into ways to coordinate training topics between our two companies and will probably share all of the material we create via the Symbian Developer Network wiki. This means that new training content should appear much more quickly and in greater quantity.

Watch this space for further announcements!