Wiley.Developing.Software.for.Symbian.OS.2nd.Edition.Dec.2007 (779887), страница 18
Текст из файла (страница 18)
So in real-time systems not only must80SYMBIAN OS ARCHITECTUREall computations be correct, they must also be performed within timeconstraints required by the software. Deviations in this expected timingare considered failures. Real-time systems don’t necessarily have torespond fast, they just have to respond within a known amount of time(although slower responding systems may not be suitable for certainapplications).Real-time processing was introduced in EKA2. Why is real-time supportdesired in Symbian OS? The primary reason is so that a smartphone’slow-level telephony radio software (known as baseband functionality)can be run on the same processor as the Symbian OS applications inorder to save costs.
I’ll discuss more in the next few sections. The GSMsignaling stack is an example of baseband functionality.Two-processor smartphone modelTypically, a smartphone contains two processors: a baseband processorand an application processor (sometimes known as the radio and PDAprocessors). Figure 3.5 shows a typical high-level view of a two-processorsystem.The baseband processor runs the low-level radio telephony protocols,like the GSM signaling stack mentioned before. Baseband software istime-critical and requires a real-time operating system (RTOS). The RTOScan be proprietary, or a commercial one such as Nucleus, OSE, or VRTX.The application processor runs Symbian OS and its applications.
An IPC(inter-processor communication) mechanism is supplied to communicatebetween the two processors when needed.Why the need for two processors? The main reason is because SymbianOS (EKA1) does not provide the real-time response needed for thebaseband software, thus requiring a dedicated processor running anRTOS. With EKA2, however, this is no longer a restriction, as shown inthe next section.Telephony basebandsoftwareSymbian OSapplicationsReal-Time OperatingSystem (e.g. Nucleus)Symbian OS kernelIPCBaseband processorApplication processorFigure 3.5 Software on Two ProcessorsACTIVE OBJECTS AND ASYNCHRONOUS FUNCTIONSTelephony basebandsoftwareSymbian OSapplicationsPersonality (RTOSinterface)Symbian OS kernel81NanokernelProcessorFigure 3.6 Software on One Processor Using EKA2One processor using the real-time nanokernelFigure 3.6 shows all the software running on a single processor in thesmartphone using EKA2.Since the nanokernel of EKA2 has real-time processing capability, it’sused as the base for both the baseband and application software, thusallowing all software to run on a single processor.Since it would be a major investment to rewrite baseband software to adifferent RTOS, Symbian supports a layer on top of the nanokernel, knownas a personality.
A personality is used to abstract the nanokernel interfaceto make it match the API of another RTOS. In this way, the nanokernelappears like that RTOS to applications that run on it. Personalities can bewritten for the different RTOSs that baseband software runs on, so thatexisting baseband software does not have to be rewritten to the nanokernelAPI. For example, if a smartphone manufacturer wants to reuse existingbaseband software written for OSE RTOS to run on the nanokernel, itwould use an OSE RTOS personality, and thus not have to modify theexisting baseband software, which could be a time-consuming and errorprone task. New personalities can be written as needed, including onesto mimic proprietary operating systems.Note that baseband functionality and EKA2’s real-time functionalityis transparent to the application programmer, so you will not need tobe concerned at all with it when writing typical applications – unless ofcourse you are implementing or integrating baseband functionality for amanufacturer (for example).3.7 Active Objects and Asynchronous FunctionsAlthough Symbian OS has support for multiple threads within a process, multithreading is not often used by application programmers.
In82SYMBIAN OS ARCHITECTUREfact, it is discouraged. One reason is performance – lots of threads canbog down a system due to context switches. Another reason is thatwhen a system object is created, it can usually be directly accessedonly by the thread that created it, making managing multiple threadsmore difficult. The correct way to handle concurrency is through activeobjects.To understand active objects, consider how threads are normally usedin an application.
Usually, code is put in a separate thread when it needsto wait for an event and then process the event when it occurs – perhapseven in a continuous fashion. It is put in its own thread so that the wholeprogram does not block waiting for that event, and other productivethings can occur during the wait.Active objects simulate multiple threads of a single process, but in factare executed in a single thread. The thread consists of what is knownas an active scheduler, which contains two main elements: an eventdispatcher and a list of attached active objects.
The active scheduler loopwaits for an event (at a semaphore) and then invokes the event handlerof the active object that is expecting the event. The active scheduler thenwaits for the next event.Active objects (i.e., a class derived from CActive) will invoke asynchronous functions that, unlike traditional functions, return immediatelyafter being called and run in parallel with the calling thread. When anasynchronous function completes, a signal is sent to the active scheduler, which in turn calls the command handler of the active object thatinvoked the asynchronous function.
Since the asynchronous functiondoes not block the thread, other active objects can be called to invokemore asynchronous functions while waiting for the others to complete. Inthis way, a single program thread can have multiple asynchronous functions in progress at one time. So although the asynchronous functionsthemselves execute in their own thread, the combination of asynchronousfunctions and active objects allows you to process multiple operations inparallel without actually implementing threads in your program. But howdo you handle the situation when a function you call blocks from withinan active object? Won’t it still block the entire program?Yes, if a function blocks within an active object, the entire program (andits other active objects) stops, which is clearly not desirable.
Asynchronousfunctions execute without blocking the program and you should usethem. Most of the Symbian OS APIs that involve any sort of waiting areimplemented as asynchronous functions.It’s very important to have a solid understanding of active objects andasynchronous functions when programming in Symbian OS, since theyare used extensively. I provide more information on them in Chapter 8and show you how to develop and use them.GUI ARCHITECTURE833.8 GUI ArchitectureSymbian OS has a powerful and flexible GUI architecture.
This sectionpresents a high-level overview of its features. The details of the architecture as it pertains to application development are discussed in Chapter 12.3.8.1Customizing the UIIn Chapter 1, I discussed the importance of product differentiation inmarketing smartphone devices, and how Symbian addresses this byproviding a flexible user interface architecture. I also introduced themajor UI customizations, including those found in UIQ and S60.To understand the architecture rationale further, consider the twoextremes an OEM can choose in selecting software for their smartphone.At one extreme, the OEM can create its own OS for maximum differentiation. However, this results in extensive up-front development costs andhaving little to no third-party application support.
At the other extreme,the OEM can choose an OS with a complete, built-in GUI. The advantagesof this include the low development cost in implementing the phone,and having more applications that run on it. The disadvantage is thatthere is little product differentiation since it will be very similar to otherphones using that OS (although it’s possible that some could see this asan advantage since they would not have to refamiliarize themselves withnew interfaces if they switched phones).The GUI architecture in Symbian OS is a good balance betweenthese extremes, and is well suited for the smartphone market.
This isaccomplished by having a powerful, common GUI core that is customizedfor a specific smartphone product (or product series) via vendor GUIlayers. Although some customization work is required by the OEM, theyget a full-featured OS (they do not have to implement their own) andhave flexibility in differentiating their product.3.8.2 Introducing the GUI FrameworkThe main components of the GUI architecture and their relation to eachother are shown in Figure 3.7.Near the bottom of the diagram, we see the window server, whichprovides centralized access to the screen and user input devices acrossall applications. As the name implies, the window server is a serverprocess – applications act as calling clients to this server by linking to itsclient-side library ws32.dll.The window server handles the details of drawing window and controlobjects to the screen, as well as keeping track of which windows belong84SYMBIAN OS ARCHITECTUREApplicationsVendor GUI(UIQ, S60, etc.)LAFUIKONApplicationArchitectureUI Control framework (CONE)ClientServerThreadBoundaryWindow ServerUser InputScreenFigure 3.7 GUI Architectureto which applications.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
