Symbian Developer Network C++ Code Clinic

Jo Stichbury opens the code clinic to dispense more advice about Symbian C++.



A new Code Clinic will be published on the first Friday of every month.



In this month’s clinic she examines the cause of two panics that occur when the cleanup stack is used with classes that use mixin inheritance.



Got a Symbian C++ problem? Send it to the Code Doctor at sdn@symbian.com.



Problems used will receive a complementary copy of the Symbian Press book Developing Software for Symbian OS, Second Edition.



visit http://developer.symbian.com/main/learning/code_clinic/

Read More......

Interfacing UART in Symbian

Accessing any port in symbian needs the following steps

1. Load physical DD
2. Load logical DD
3. Connect to RCommServer
4. Connect RComm client to Server
5. Load the specific port module (.CSY file)
6. Configure and Open
7. Do the operation
   

Here is a piece of code explains how to interface with UART in symbian





TInt err = User::LoadPhysicalDevice(PDD_NAME);




if (err != KErrNone && err != KErrAlreadyExists)


{


RDebug::Printf("Loading of Physical drive failed\n");


User::Leave(err);


}





// Load the logical device driver.


err = User::LoadLogicalDevice(LDD_NAME);


if (err != KErrNone && err != KErrAlreadyExists)


{


RDebug::Printf("Loading of Logical drive failed\n");


User::Leave(err);


}








#if 1 //!defined (__WINS__)


// Start the comms server process


err = StartC32();


if (err != KErrNone && err != KErrAlreadyExists)


{


RDebug::Printf("StartC32 failed\n");


User::Leave(err);


}


#endif



// Connect to the Serial comms server.


User::LeaveIfError(iCommServer.Connect());


RDebug::Printf("Success: CommServer connect\n");


// Load the CSY module.


User::LeaveIfError(iCommServer.LoadCommModule(RS232));


RDebug::Printf("Success: CommServer RS232 Loading\n");





TInt numPorts;


User::LeaveIfError(iCommServer.NumPorts (numPorts));


RDebug::Printf("Success: CommServer returned number of ports & the number of ports = %d", numPorts);



//we are really only interested in using the CSY that we've


// just loaded up ourselves. We could find out its portInfo by


// comparing the moduleName returned by the version of GetPortInfo we


// just used to the name of the CSY we loaded, but there's a better


// version of GetPortInfo we can use, which just takes the name of a CSY


// as a parameter. We'd expect to find this informtion is an exact


// duplicate of the indexed portInfo for the last loaded CSY


// Our example code will use the lowest possible port (why not?)



TSerialInfo portInfo;





TBuf16 <> moduleName;



for (TInt index=0 ; index <>
{


User::LeaveIfError(iCommServer.GetPortInfo (index, moduleName, portInfo));


RDebug::Print(_L("module name = %S"), &moduleName);


RDebug::Print(_L("Port name = %S"), &(portInfo.iName));


RDebug::Print(_L("Port Description = %S"), &(portInfo.iDescription));


RDebug::Printf("Port high unit = %d", portInfo.iHighUnit);


RDebug::Printf("Port Low unit = %d", portInfo.iLowUnit);


}




User::LeaveIfError(iCommServer.GetPortInfo (RS232, portInfo));


RDebug::Printf("Success: CommServer returned port information \n");





RDebug::Print(_L("Port name = %S"), &(portInfo.iName));


RDebug::Print(_L("Port Description = %S"), &(portInfo.iDescription));


RDebug::Printf("Port high unit = %d", portInfo.iHighUnit);


RDebug::Printf("Port Low unit = %d", portInfo.iLowUnit);








// Now let's use a few Symbian OS functions to construct a descriptor for the


// name of the lowest port our CSY supports -


// The name can be as long as a TSerialInfo.iName plus a


// couple of colons and digits



TBuf16 <> portName; // declare an empty descriptor buffer


portName.Num (portInfo.iLowUnit); // put in the port number in ASCII


portName.Insert (0, KColons); // stick in a couple of colons


portName.Insert (0, portInfo.iName); // and lead off with the iName



// and at last we can open the first serial port,which we do here in exclusive mode



RComm commPort;


User::LeaveIfError(commPort.Open (iCommServer, portName, ECommExclusive));


RDebug::Printf("Success: Commport Open\n");



// Now we can configure our serial port


// we want to run it at 115200 bps 8 bits no parity (why not?)


// so maybe we ought to get of its capabilities and check it can


// do what we want before going ahead



TCommCaps ourCapabilities;


commPort.Caps (ourCapabilities);



if (((ourCapabilities ().iRate & KCapsBps115200) == 0) ||


((ourCapabilities ().iDataBits & KCapsData8) == 0) ||


((ourCapabilities ().iStopBits & KCapsStop1) == 0) ||


((ourCapabilities ().iParity & KCapsParityNone) == 0))


User::Leave (KErrNotSupported);




TCommConfig portSettings;


commPort.Config (portSettings);


portSettings ().iRate = EBps115200;


portSettings ().iParity = EParityNone;


portSettings ().iDataBits = EData8;


portSettings ().iStopBits = EStop1;



// as well as the physical characteristics, we need to set various logical ones


// to do with handshaking, behaviour of reads and writes and so so



portSettings ().iFifo = EFifoEnable;





//portSettings ().iHandshake = (KConfigObeyCTS | KConfigFreeRTS); // for cts/rts





portSettings ().iHandshake = (KConfigObeyXoff | KConfigSendXoff); // for xon/xoff





// portSettings ().iHandshake = KConfigFailDSR;





portSettings ().iTerminator[0] = 10;


portSettings ().iTerminatorCount = 1; // so that we terminate a read on each line feed arrives



User::LeaveIfError(commPort.SetConfig (portSettings));


RDebug::Printf("Success: Commport Config\n");



// now turn on DTR and RTS, and set our buffer size



commPort.SetSignals (KSignalDTR, 0);


commPort.SetSignals (KSignalRTS, 0);


TInt curlenth = commPort.ReceiveBufferLength ();


commPort.SetReceiveBufferLength (4096);


curlenth = commPort.ReceiveBufferLength ();





const TTimeIntervalMicroSeconds32 KTimeOut(4000000);


TRequestStatus stat;


commPort.Write (stat, KTimeOut, (TDesC8&)KFileName);


User::WaitForRequest (stat);


err = stat.Int ();


if (err != KErrNone) // Write has failed for some reason


{


RDebug::Printf("Failure: Commport Write and the reason is %d\n", err);


//Failed


}





RDebug::Printf("Success: Commport Write\n");



TBuf8 <> localInputBuffer;


localInputBuffer.FillZ();


TRequestStatus readStat;



//Reading the written buffer


commPort.Read (readStat, localInputBuffer, 20);


User::WaitForRequest(readStat);


User::LeaveIfError (readStat.Int ());


RDebug::Printf("Success: Commport Read\n");





RDebug::Print(_L("Read buffer is %S"), &localInputBuffer);



commPort.Close ();


iCommServer.Close ();

Read More......

Enabling Logs for Emulator

Quite Simple !!!

1. Open \epoc32\data\epoc.ini
2. make LogToDebugger to 1 & save
3. You can find your log file epocwind.out in windows temproary directory
4. you can type %temp% in the address bar of explorer to reach the temproary directory.

Read More......

Self signing your symbian application

Target Apps:

Application doesn't require other than basic capabilities, include LocalServices, NetworkServices, ReadUserData, UserEnvironment and WriteUserData



Creating Certificates:

"makekeys -cert -password World123 -len 1024 -dname "CN=World User OU=Development OR=WorldCompany CO=FI EM=World@test.com" WorldKey.key WorldCert.cer" - Execute this command in windows command prompt from sis directory



Signing Application

signsis HelloWorld_unsigned.sis HelloWorld_signed.sis WorldCert.cer WorldKey.key World123

Read More......

Symbian OS Stacks

Symbian OS stacks are fixed in size. They are allocated during the creation of a thread and they do not grow. Once the stack is exhausted there is no dynamic capability for extension

Symbian OS stacks exist both User and Kernel side.

User-side stack:
They are used as temporary scratch storage inside functions or methods. The stack typically grows and shrinks wildly as the thread executes instructions.

Kernal-side Stack:

In EKA2, each thread also has a kernel-side stack, called the supervisor stack. This stack is used for:

a)executive calls

b)if a hardware interrupt occurs whilst the thread is running and the interrupt queues IDFCs and/or DFCs

c)rescheduling. A reschedule always occurs as a result of the current thread calling the scheduler. Inside the scheduler, the current thread’s register state is saved on its supervisor stack and the final stack pointer value is saved in the thread control block. Then the stack pointer is loaded using the new thread’s saved stack pointer value and its register state is restored from the stack (which is now the new thread’s supervisor stack).


Chunk Size:

The minimum amount of RAM required by a stack for a given thread is one page (4kb)

Currently, the default amount of RAM allocated for the thread’s stack is 8kb. Can be changed using EPOCSTACKSIZE keyword in mmp file

But the maximum size for a thread is 64 KB

And maximum size for a process is 2 MB

stacks are seperated using guard with in a chunck

Read More......

Symbian OS Heaps

Each Symbian application the default Symbian OS RHeap implementation.



Symbian OS heaps are implemented using a chunk. A chunk is a wrapper around a collection of pages of memory. The minimum size for a chunk is one page of RAM and this is typically 4 KB.



When a process is created, a default heap is created for the main thread of execution within that process. And this heap has maximum size that a process is allowed to grow in the usage of RAM. If it goes beyond that upper limit, memory allocation will fail with KErrNoMemory.



Process Startup:


When the main thread starts, Symbian OS E32 Process startup framework creates a chunk in which the heap for the process will live.



if your process is called “ProA”, your thread is called “Thr1”, then full name associated with your heap chunk is “ProA::Thr1::$HEAP.”



Once the chunk is created by the kernel and is mapped into the process , an RHeap object is then allocated in-place at the start of the chunk. Then the heap object is configured with the sizing information from the E32 image header. This object is used to find out the sizes of allocated and unallocated in a chunk / Heap.

Symbian OS process heaps can be extended using some slack spaces by adding some free cells at the end of the chunk.

Read More......

TTL ( Time-To-Live)

Time-to-live (TTL) is a value in an Internet Protocol (IP) packet that tells a network router whether or not the packet has been in the network too long and should be discarded.

For a number of reasons, packets may not get delivered to their destination in a reasonable length of time. For example, a combination of incorrect routing tables could cause a packet to loop endlessly. A solution is to discard the packet after a certain time and send a message to the originator, who can decide whether to resend the packet.

The initial TTL value is set, usually by a system default, in an 8-binary digit field of the packet header. The original idea of TTL was that it would specify a certain time span in seconds that, when exhausted, would cause the packet to be discarded. Since each router is required to subtract at least one count from the TTL field, the count is usually used to mean the number of router hops the packet is allowed before it must be discarded. Each router that receives a packet subtracts one from the count in the TTL field. When the count reaches zero, the router detecting it discards the packet and sends an Internet Control Message Protocol (ICMP) message back to the originating host.

The default Windows 95/98 TTL value is 32 hops. Some users recommend changing this to 128 if you have difficulty reaching certain sites.

The ping and the traceroute utilities both make use of the TTL value to attempt to reach a given host computer or to trace a route to that host. Traceroute intentionally sends a packet with a low TTL value so that it will be discarded by each successive router in the destination path. The time between sending the packet and receiving back the ICMP message that it was discarded is used to calculate each successive hop travel time.

Using the multicast IP protocol, the TTL value indicates the scope or range in which a packet may be forwarded. By convention:

0 is restricted to the same host

1 is restricted to the same subnet

32 is restricted to the same site

64 is restricted to the same region

128 is restricted to the same continent

255 is unrestricted

Courtesy: searchnetworking.techtarget.com

Read More......

RFC's

SDP: Session Description Protocol
http://www.faqs.org/rfcs/rfc4566.html

Read More......

APP_REGISTRATION_INFO

The registration file

All applications must provide a registration file.

A registration file is a standard Symbian OS compiled resource file (.rsc). The .rss file used to build the registration file should be named AppName_reg.rss and contain at least the following lines:

#include appinfo.rh
UID2 KUidAppRegistrationResourceFile
UID3 0x01000000 // application UID
RESOURCE APP_REGISTRATION_INFO
{
app_file="AppName"; // filename of application binary (minus extension)
}

To build the registration file, add the following lines to the application's MMP file:

START RESOURCE AppName_reg.rss
TARGETPATH \private\10003a3f\apps //Dont think 10003a3f is the uid of the app.
END

The _reg filename suffix is used as a naming convention only and is not mandatory.

Note that any lines in the MMP file that are used to build an AIF file should be removed.

Read More......