Creating Carbide C++

Seeking input on Carbide API examples

Mon, 12 May 2008 14:30:55 -0600

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.

S60 Build Performance: Don't Forget to Update Your Makefiles

Mon, 12 May 2008 08:20:05 -0600

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.

Simplifying debugging with TRK over the Bluetooth

Sat, 10 May 2008 14:56:52 -0600

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.

Eclipse 3.4M7

Fri, 09 May 2008 17:49:23 -0600

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.

Online Carbide documentation push

Fri, 09 May 2008 10:27:48 -0600

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.

Panic Debugging

Thu, 08 May 2008 19:27:02 -0600

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.

Screencast: Carbide Perspectives

Thu, 08 May 2008 08:45:10 -0600

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.

Event secrets in PI

Tue, 06 May 2008 15:00:12 -0600

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.

Performance

Fri, 02 May 2008 22:32:06 -0600

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

Disassembly view in Carbide C++

Fri, 02 May 2008 22:27:13 -0600

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.

Further deciphering of debugging with TRK for advanced users

Fri, 02 May 2008 21:46:51 -0600

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.

Code Scanner is a champ!

Thu, 01 May 2008 21:33:30 -0600

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!

What's your excuse?

Thu, 01 May 2008 11:15:03 -0600

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!

Making the connection with TRK

Thu, 01 May 2008 10:22:01 -0600

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.

Screencast Collaboration

Thu, 01 May 2008 09:24:07 -0600

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!