embedded systems ppt and Smart Phone full report
computer science topics|
Active In SP
Joined: Jun 2010
09-06-2010, 04:50 PM
embeded systems.docx (Size: 515.36 KB / Downloads: 674)
embeded systems ppt.ppt (Size: 428.5 KB / Downloads: 1,078)
NAME: T.V.SAMRAT GUPTA
NAME OF THE INISTITUTION: RAJEEV GANDHI MEMORIAL
COLLEGE OF ENGG,
Smart Phone: An Embedded System for Universal Interactions
In this paper, we present a system architecture that allows users to interact with embedded systems acted in their proximity using Smart Phones. We have identified four models of interaction between a Smart Phone and the surrounding environment: universal remote control, dual connectivity, gateway connectivity, and peer-to-peer. Although each of these models has different characteristics, our architecture provides a unique framework for all of the models. Central to our architecture are the hybrid communication capabilities incorporated in the Smart Phones. These phones have the unique feature of incorporating short-range wireless connectivity (e.g., Bluetooth) and Internet connectivity (e.g., GPRS) in the same personal mobile device. This feature together with significant processing power and memory can turn a Smart Phone into the only mobile device that people will carry wherever they go.
Recent advances in technology make it feasible to incorporate significant processing power in almost every device that we encounter in our daily life. These embedded systems are heterogeneous, distributed everywhere in the surrounding environment, and capable of communicating through wired or wireless interfaces. For a number of years, visionary papers [21, 18] have presented a picturesque computerized physical world with which we can potentially interact faster and in a simpler fashion. People, however, are not yet taking advantage of this ubiquitous computing world. Despite all the computing power lying around, most of our daily interactions with the surrounding environment are still primitive and far from the ubiquitous computing vision. Our pockets and bags are still jammed with a bunch of keys for the doors we have to open/close daily (they did not change much since the Middle Ages), the car key or remote, access cards, credit cards, and money to pay for goods. Any of these forgotten at home can turn the day into a nightmare. If we travel, we also need maps and travel guides, coins to pay the parking in the city, and tickets to take the train or subway. In addition, we are always carrying our mobile phone, which for some mysterious reason is the least likely to be left at home. When we finally arrive home or at the hotel, we are greeted by several remote controls eager to test our intelligence. All these items are absolutely necessary for us to properly interact with our environment. The problem is that there are too many of them, they are sometimes heavy, and we will likely accumulate more and more of them as our life go on, requiring much larger pockets. For this problem, the community does not lack innovative solutions that address some of its aspects (e.g., wireless micro servers, electronic payment methods, and digitaldoor keys). What is missing is a simple, universal solution, which end-users are likely to accept easily. Ideally, we would like to have a single device that acts as both personal server and personal assistant for remote interaction with embedded systems located in proximity of the user. This device should be programmable and support dynamic software extensions for interaction with newly encountered embedded systems (i.e., dynamically loading new interfaces). To simplify its acceptance by society, it should be a device that is already carried by people wherever they go.
We believe that Smart Phones are the devices that have the greatest chance of successfully becoming universal remote controls for people to interact with various devices from their surrounding environment; they will also replace all the different items we currently carry in our pockets. Smart Phone is an emerging mobile phone technology that supports Java program execution and provides both short range wireless connectivity (Bluetooth) and cellular network connectivity through which the Internet can be accessed.
In this paper, we present a system architecture that allows users to interact with embedded systems located in their proximity using a Smart Phone. We have identified four models of interaction between a Smart Phone and the surrounding environment: universal remote control, dual connectivity, gateway connectivity, and peer-to-peer. Although each of these models has different characteristics, our architecture provides a unique framework for all the models. Central to our architecture are the hybrid communication capabilities incorporated in the Smart Phones which allow them to interact with the close-by environment through short-range wireless networking and with the rest of the world through the Internet over cellular links. This feature together with significant processing power and memory can turn a Smart Phone into the long awaited universal personal assistant that can make our daily life much simpler.
An Embedded System:
The embedded system is a combination of computer hardware, software and, perhaps, additional mechanical parts design to perform a specific function. A good example is an automatic washing machine or microwave oven. Such a system is in direct contrast to a personal computer, which not designed to do only a specific task. The PC aids you in drafting a letter, in computing at a faster rate in chatting with friends, and so on, but an embedded system is designed to do a specific task with in a given time frame, repeatedly, endlessly, with or without human interaction. A PC is made up of numerous embedded systems, such as a keyboard, hard drive etc. The function of a simple modem is to convert analogue signals to digital signals, and vice versa. This means it must have a certain amount of logic to perform that process in time and again endlessly.
It is important to note that all embedded systems all embedded systems do not have same hardware and software, which is why these systems perform varied tasks. Itâ„¢s even possible to have an embedded system that does not contain any processor and corresponding software to run through it. In such system, called hardwired systems, the hardware and software is replaced with integrated circuitry that performs a same function. However, a lot of flexibility is lost when applications are implemented this way. It is much easier to change the software code than to redevelop the hardware, for bringing about the small changes in application for which the system has been designed.
All embedded systems need a microprocessor, and the kinds of microprocessors using them are quite varied. A list of some of the common microprocessor families is ZILOG Z8 family, INTEL 8051/80188/X86 family. An embedded system also needs memory for two purposes â€œ to store its program, and to store its data. Embedded systems store data and programs in different memories .This is simply because embedded system does not have an hard drive and the program must be stored in memory, even when the power is turned off .This special memory that remembers program even without power, is called ROM Very often this systems have a serial port I/O interfaces, or hard ware to interact with sensors.
So an embedded system has a microprocessor or micro controller for processing information, memory for storing embedded software programs and data and I/O interfaces for external interfaces. The functional diagram is given above. The processor uses the address bus to select a specific memory location within the memory sub system or a specific peripheral chip. The data base is used to transfer data between the processor and memory sub system or peripheral devices the control bus provides timing signals to synchronize the flow of data between the processor and memory sub system or peripheral devices.
Any source code written in C or C++ or assembly must be converted into an executable image that can be loaded onto a ROM chip. The process of converting the source code representation of your embedded software into an executable image involves three distinct steps, and the system or computer on which these processes are executed is called Host computer.
First, each of the source files that make an embedded application must be compiled or assembled into distinct object files. Second, all of the object files that result first step must be linked into a final object file called the relocatable program. Finally physical memory address must be assigned to relocatable program. The result of the third step is a file that contains an executable image that is ported on to the ROM chip. This ROM chip, along with the processor and other devices and interfaces, makes an embedded system run There are some very basic differences between conventional programming and embedded programming. First, each target platform is unique. Even if the processor architecture is the same, the I/O interfaces or sensors or activators may differ. Second, there is a difference in the development and debugging of applications.
Smart Phones Technology:
With more than a billion mobile phones being carried around by consumers of all ages, the mobile phone has become the most pervasive pocket-carried device. We are beginning to see the introduction of Smart Phones, such as Sony Ericsson P800/P900 and Motorola A760 , as a result of the convergence of mobile phones and PDA devices. Unlike traditional mobile phones, which have limited processing power and act merely as dumb conduits for passing voice or data between the cellular network and end users, Smart Phones combine significant computing power with memory, short-range wireless interfaces (e.g., Bluetooth), Internet connectivity (over GPRS), and various input-output components (e.g., high- resolution color touch screens, digital cameras, and MP3 players). Sony Ericsson P800/P900 runs Symbian OS , an operating system specifically designed for resource constrained devices such as mobile phones. It also comes equipped with two versions of Java technology: Personal Java and J2ME CLDC/MIDP . Additionally, it supports C++ which provides low level access to the operating system and the Bluetooth driver. The phone has 16MB of internal memory and up to 128MB external flash memory. Motorola A760 has a Motorola i250 chip for communication, Intelâ„¢s 200 MHz PXA262 chip for computation, and 256MB of RAM memory. It runs a version of MontaVista Linux and comes with Java J2ME support .Bluetooth is a low-cost, low-power standard for wireless connectivity. Today, we can find Bluetooth chips embedded in PCs, laptops, digital cameras, GPS devices, Smart Phones, and a whole range of other electronic devices. Bluetooth supports point-to-point and point-to- multipoint connections. We can actively connect a Bluetooth device to up to seven devices simultaneously. Together, they form an ad hoc network, called Piconet. Several piconets can be linked to form a Scatter net. Another important development for the mobile phone technology is the introduction of General Packet Radio Service (GPRS) , a packet switching technology over the current GSM cellular networks. GPRS is offered as a no voice value-added service that allows data to be sent and received across GSM cellular networks at a rate of up to 171.2kbps, and its goal is to supplement todayâ„¢s Circuit Example of Smart Phones: Sony Ericsson P800 (Left) and Motorola A760 (Right)
Smart Phone Interaction Models:
A Smart Phone can be used to interact with the surrounding environment in different ways. We have identified four interaction models: universal remote control, dual connectivity, gateway connectivity, and peer-to-peer. With these models, a Smart Phone can be used to execute applications from as simple as remotely adjusting various controls of home appliances or opening smart locks to complex applications such as automatically booking a cab or ordering/paying in a restaurant using an ad hoc network of mobile phones to connect to the cashierâ„¢s computer.
Universal Remote Control Interaction Model.
Peer-to-Peer Interaction Model
Universal Remote Control Model :
The Smart Phone can act as a universal remote control for interaction with embedded systems located in its proximity. To support proximity-aware interactions, both the Smart Phone and the embedded systems with which the user interacts must have short-range wireless communication capabilities. Figure 2 illustrates such interactions using Bluetooth. Due to its low- power, low- cost features; Bluetooth is the primary candidate for the short-range wireless technology that will enable proximity-aware communication.
Since embedded systems with different functionalities can be scattered everywhere, a discovery protocol will allow Smart Phones to learn the identity and the description of the embedded systems located in their proximity. This protocol can work either automatically or on- demand, but the information about the devices currently located in userâ„¢s proximity is displayed only upon userâ„¢s request. Each embedded system should be able to provide its identity information (unique to a device or to a class of devices) and a description of its basic functionality in a human- understandable format. This model works well as long as the user has the interfaces for interacting with the embedded systems preinstalled on the phone. An alternative, more flexible, solution is to define a protocol that allows a Smart Phone to learn the interfaces from the embedded systems themselves. The problem with this idea is that many embedded systems may not be powerful enough to run complex software that implements such protocols. In the following, we describe a second model of interaction that solves this problem.
Gateway Connectivity Model :
Many pervasive applications assume wireless communication through the IEEE 802.11 family of protocols. These protocols allow for a significant increase in the communication distance and bandwidth compared to Bluetooth. Using these protocols, the communication range is 250m or more, while Bluetooth reaches only 10m. The bandwidth is also larger, 11-54Mbps compared to less than 1Mbps for Bluetooth. Additionally, many routing protocols for mobile adhoc networks based 802.11 already exist [19, 16]. The disadvantage of 802.11 is that it consumes too much energy, and consequently, it drains out the mobile devicesâ„¢ batteries in a very short period of time. With the current state of the art, we do not expect to have 802.11 network interfaces embedded in Smart Phones or other resource constrained embedded systems that need to run on batteries for a significant period of time (e.g., several hours or even days). More powerful systems, however, can take advantage of the 802.11 benefits and create mobile ad hoc networks. In such a situation, a user would like to access data and services provided by these networks from its Smart Phone.
The Gateway Connectivity Interaction Model.
To succeed, a gateway device has to perform a change of protocol from Bluetooth to 802.11 and vice-versa. Many places in a city (e.g., stores, theaters, restaurants) can provide such gateway stations together with 802.11 hotspots. Figure 4 illustrates this communication model and also presents an application that can be built on top of it. Let us assume a scenario where people want to book nearby cabs using their Smart Phones. Instead of calling a taxi company or gesturing to book a cab, a client can start an application on her Smart Phone that seamlessly achieves the same goal. Hence, the client is just one-click away from booking a cab. In this scenario, each cab is equipped with 802.11 wireless networking and GPS devices, and the entire booking process is completely decentralized. To join the mobile adhoc network created by the cabs, a Smart Phone needs to connect to a gateway station that performs a translation of protocols from Bluetooth to 802.11 and vice-versa.
Peer-to-Peer Model :
The Smart Phones can also communicate among themselves (or with other Bluetooth-enabled devices) in a multihop, peer-to-peer fashion, similar to mobile ad hoc networks. For instance, this model allows people to share music and pictures with others even if they are not in the proximity of each other. Figure depicts yet another example of this model. A group of friends having dinner in a restaurant can use their Smart Phones to execute a program that shares the check. One phone initiates this process, an ad hoc network of Smart Phones is created, and finally the payment message arrives at the cashier.
The Peer-to-Peer Interaction Model.
Our system architecture for universal interaction consists of a common Smart Phone software architecture and an interaction protocol. This protocol allows Smart Phones to interact with the surrounding environment and the Internet. Figure shows the Smart Phone software architecture. In the following, we briefly describe the components of the software architecture.
Smart Phone Software Architecture.
Bluetooth Engine is responsible for communicating with the Bluetooth-enabled embedded systems. It is composed of sub-components for device discovery and sending/receiving data. The Bluetooth Engine is a layer above the Bluetooth stack and provides a convenient Java API for accessing the Bluetooth stack.
Internet Access Module carries out the communication between the Smart Phone and various Internet servers. It provides a well-defined API that supports operations specific to our architecture (e.g., downloading an interface). The protocol of communication is HTTP on top of GPRS.
Proximity Engine is responsible for discovering the embedded systems located within the Bluetooth communication range. Each time the user wants to interact with one of these systems, and an interface for this system is not available locally (i.e., a miss in the Interface Cache), the Proximity Engine is responsible from downloading such an interface. If the embedded system has enough computing power and memory, the interface can be downloaded directly from it. Otherwise, the Proximity Engine invokes the Internet Access Module to connect to a web server and download the interface. The downloaded interface is stored in the Interface Cache for later reuse. Once this is done, the Proximity Engine informs the Execution Engine to dispatch the downloaded interface for execution. All further communication between the Smart Phone and the embedded system happens as a result of executing this interface.
Execution Engine is invoked by the Proximity Engine and is responsible for dispatching interface programs for execution over the Java virtual machine. These programs interact with the Bluetooth Engine to communicate with the embedded systems or with other Smart Phones They may also interact with the Internet Access Module to communicate with Internet servers. For instance, the interface programs may need to contact a server for security related actions or to download necessary data in case of a miss in the Personal Data Storage.
Interface Cache stores the code of the downloaded interfaces. This cache avoids downloading an interface every time it is needed. An interface can be shared by an entire class of embedded systems (e.g., Smart Locks, or Microwaves). Every interface has an ID (which can be the ID of the embedded system or the class of embedded systems it is associated with). This ID helps in recognizing the cached interface each time it needs to be looked up in the cache. Additionally, each interface has an associated access handler that is executed before any subsequent execution of the interface. This handler may define the time period for which the interface should be cached, how and when the interface can be reused, or the permissions to access local resources. The user can set the access handlerâ„¢s parameters before the first execution of the interface.
Personal Data Storage acts as a cache for active data, similar to Active Cache . It stores data that needs to be used during the interactions with various embedded systems. Examples of such data include digital door keys and electronic cash. Each data item stored in this cache has three associated handlers: access handler, miss handler, and eviction handler. Each time an interface needs some data, it checks the Personal Data Storage. If the data is available locally (i.e., hit), the access handler is executed, and the program goes ahead. For instance, the access handler may check if this data can be shared among different interfaces. If the data is not available locally (i.e., miss), the miss handler instructs the Internet Access Module to download the data from the corresponding Internet server. The eviction handler defines the actions to be taken when data is evicted from the cache. For instance, electronic cash can be sent back to the bank at eviction time. Below figure shows the interaction protocol that takes place when a Smart Phone needs to interact with an embedded system. We consider that any embedded system is registered with a trusted web server (this web server can be physically distributed on multiple computers). At registration, the web server assigns a unique ID and a URL to the device. All the information necessary to interact with the device along with a user interface is stored at that URL. This URL may be common for an entire class of embedded systems. The user invokes the Proximity Engine each time she needs to interact with a device located in the proximity. Once the embedded systems in the proximity have been identified, the user can choose the one she wants to interact with. Consequently, a request is sent to the embedded system to provide its ID and URL. Upon receiving the ID and URL of the embedded system, the Smart Phone executes the access control handler, and then, loads and executes the interface. In case of a miss in the Interface Cache, the interface needs to be downloaded on the phone either from the web server or from the embedded system itself. An inter face downloaded from an embedded system is untrusted and is not allowed to access local resources (i.e., this is a sandbox model of execution, where the interface can only execute safe instructions on the phone). The interfaces downloaded from the web server are trusted; they are assumed to be verified before being distributed by the server. Each time a Smart Phone requests an interface from the web server, it has to send the interface ID and the URL provided by the embedded system. It also sends itâ„¢s ID (stored in the Personal Data Storage). The permission to download an interface is subject to access control enforced based on the Smart Phone ID and, potentially, other credentials presented by the user. Once the access is granted, the web server responds with the interface code.
Smart Phone Interaction Protocol
Status and Future Work:
In this section, we briefly outline the current status and several open issues that we have to overcome in order to implement our system architecture. We are in the process of building the system architecture on top of Ericssonâ„¢s P800/900 phones. Our first step consists of implementing the basic architecture for the universal remote control interaction model. The architecture components to be developed for this model are the Bluetooth Engine and Proximity Engine along with a simple Execution engine over Java. We have partially implemented the Bluetooth Engine and have written and tested a few sample programs to test the feasibility of connecting a phone to another phone or to a Bluetooth-enabled laptop. Besides directly connecting to Bluetooth-enabled devices, a phone can also connect to a LAN. We are in the process of investigating the feasibility of using the Bluetooth LAN profile to connect the phone to a LAN through a Bluetooth access point. Until recently, the commercially available Bluetooth chips have been working well for one- hop communication, but their scatter net capabilities have not been mature enough to support multi- hop communication as needed in our peer-to-peer interaction model. Currently, there are products , however, whose scatter net capabilities have been successfully tested. We envision that multi- hop communication in ad hoc networks will take place either over Bluetooth or over 802.11 depending on the trade-offs between the battery power consumption and communication range. Our system architecture supports both situations through the peer-to-peer model and the gateway model, respectively. To connect a Smart Phone to the Internet over GPRS, we can use HTTP or TCP. A decision regarding the protocol used for Internet access needs to consider the trade-offs between the simplicity provided by HTTP and the flexibility and efficiency provided by TCP. Although our architecture provides a level of security by obtaining interface code and confidential data from a trusted web server, many issues related to security and privacy still need to be addressed. For instance, we need to investigate different lightweight encryption algorithms that work on resource constrained devices to counter eavesdropping without a serious overhead. So far we have assumed that the personal information of the user, including confidential data, would be stored on the Smart Phone. In such a situation, losing the Smart Phone could pose a serious security threat to the owner. The data stored on the phone should be made inaccessible to anyone but the phone owner. A simple password scheme is insufficient because entering a password every time confidential data is accessed could be a major turn off for the users. We plan to investigate both software protection mechanisms and hardware solutions.
Personal Server is a small-size mobile device that stores userâ„¢s data on a removable Compact Flash and wirelessly utilizes any I/O interface available in its proximity (e.g., display, keyboard). Its main goal is to provide the user with a virtual personal computer wherever the user goes. Our goal is to provide a simple method of interaction with systems embedded in the surrounding environment. Unlike Personal Server which cannot connect directly to the Internet, Smart Phones do not have to carry every possible data or code that the user may need; they can download on demand data and code for interfaces from the Internet. Cool Town proposes web presence as a basis for bridging the physical world with the World Wide Web. For example, entities in the physical world are embedded with URL-emitting devices (beacons) which advertise the URL for the corresponding entities. Our model is more flexible as we allow code and data to be downloaded to mobile devices, either from the physical environment via short-range wireless connection, or from the Internet via the GPRS connection. Micro servers share one of our goals of turning a handheld device into a universal remote control. Their approach consists of embedding web servers in Bluetooth enabled devices and using WAP over Bluetooth to communicate between the handheld and these devices. Our approach is more practical since it does not require any complex software to be installed on resource constrained embedded systems.
In this paper, we have argued for turning the Smart Phone into the only device that people carry in their pockets wherever they go. The Smart Phone can be used as both personal server that stores or downloads data that its user needs and personal assistant for remote interaction with embedded systems located in the userâ„¢s proximity. To achieve this vision, we have presented unified system architecture for different models of interaction between a Smart Phone and the surrounding environment. Central to this universal interaction architecture is the dual connectivity feature of Smart Phones, which allows them to interact with the close-by environment through short-range wireless networking and with the rest of the world through the Internet over cellular links.
Use Search at http://topicideas.net/search.php wisely To Get Information About Project Topic and Seminar ideas with report/source code along pdf and ppt presenaion
Active In SP
Joined: Sep 2010
11-01-2011, 01:37 PM
seminar rep.docx (Size: 242.36 KB / Downloads: 178)
A smartphone is a mobile phone offering advanced capabilities, often with PC-like functionality (PC-mobile handset convergence). There is no industry standard definition of a smartphone. For some, a smartphone is a phone that runs complete operating system software providing a standardized interface and platform for application developers. For others, a smartphone is simply a phone with advanced features like e-mail, Internet and e-book reader capabilities, and/or a built-in full keyboard or external USB keyboard and VGA connector. In other words, it is a miniature computer that has phone capability.
Growth in demand for advanced mobile devices boasting powerful processors, abundant memory, larger screens and open operating systems has outpaced the rest of the mobile phone market for several years. Smartphones these days are powerful beasts. Their specification sheets almost read like what you’d find for a computer, and these devices are now capable of tasks that one would have done on a computer in the past, such as browsing desktop-class webpages, watching Flash videos, running multiple apps at once, grabbing email and even doing simple photo and video editing.
The first smartphone was called Simon; it was designed by IBM in 1992 and shown as a concept product that year at COMDEX, the computer industry trade show held in Las Vegas, Nevada. It was released to the public in 1993 and sold by BellSouth. Besides being a mobile phone, it also contained a calendar, address book, world clock, calculator, note pad, e-mail, send and receive fax, and games. It had no physical buttons to dial with. Instead customers used a touch-screen to select phone numbers with a finger or create facsimiles and memos with an optional stylus. Text was entered with a unique on-screen "predictive" keyboard. By today's standards, the Simon would be a fairly low-end product; however, its feature set at the time was incredibly advanced.
The Nokia Communicator line was the first of Nokia's smartphones starting with the Nokia 9000, released in 1996. This distinctive palmtop computer style smartphone was the result of a collaborative effort of an early successful and expensive Personal digital assistant (PDA) by Hewlett Packard combined with Nokia's bestselling phone around that time and early prototype models had the two devices fixed via a hinge; the Nokia 9210 as the first color screen Communicator model which was the first true smartphone with an open operating system; the 9500 Communicator that was also Nokia's first cameraphone Communicator and Nokia's first WiFiphone; the 9300 Communicator was the third dimensional shift into a smaller form factor; and the latest E90 Communicator includesGPS. The Nokia Communicator model is remarkable also having been the most expensive phone model sold by a major brand for almost the full lifespan of the model series, easily 20% and sometimes 40% more expensive than the next most expensive smartphone by any major manufacturer.
The Ericsson R380, released in 2000, was the first phone sold as a 'smartphone'. It was the world's first touch screen phone. The R380 had the usual PDA functions and the large touch screen was combined with an innovative flip so it could also be used as a normal phone. It was the first commercially available Symbian OS phone, however it could not run native third-party applications. Although the Nokia 9210 was arguably the first true smartphone with an open operating system, Nokia continued to refer to it and the following models as Communicator; only Ericsson referred to its product as 'smartphone' at this time.
In early 2002 Handspring released the Palm OS Treo smartphone, utilizing a full keyboard that combined wireless web browsing, email, calendar and contact organizer, with mobile third-party applications that could be downloaded or synced with a computer.
In 2002 the new joint venture Sony Ericsson released the P800 smartphone, originally developed by Ericsson. It was based onSymbian OS and had full PDA functionality plus a range of features not commonly seen in mobile phones at that time: color touch screen, camera, polyphonic ring tones, email attachment viewers, video playback and an MP3 player with a standard 2.5 mmheadset jack. In 2002 RIM released the first BlackBerry which was the first smartphone optimized for wireless email use and has achieved a total customer base of 32 million subscribers by December 2009. Although the Nokia 7650, announced in 2001, was referred to as a 'smart phone' in the media, and is now called a 'smartphone' on the Nokia support site, the press release referred to it as an 'imaging phone'. Handspring delivered the first widely popular smartphone devices in the US market by marrying its Palm OS based Visor PDA together with a piggybacked GSM phone module, the VisorPhone. By 2002, Handspring was marketing an integrated smartphone called the Treo; the company subsequently merged with Palm primarily because the PDA market was dying but the Treo smartphone was quickly becoming popular as a phone with extended PDA organizer features. That same year, Microsoft announced its Windows CE Pocket PC OS would be offered as "Microsoft Windows Powered Smartphone 2002". Microsoft originally defined its Windows Smartphone products as lacking a touchscreen and offering a lower screen resolution compared to its sibling Pocket PC devices. Palm then introduced a few Windows Mobile smartphones alongside the existing Palm OS smartphones, and has now abandoned both platforms in favor of its new Palm webOS.
In 2005 Nokia launched its N-Series of 3G smartphones which Nokia started to market not as mobile phones but as multimedia computers. Out of 1 billion camera phones to be shipped in 2008, smartphones, the higher end of the market with full email support, will represent about 10% of the market or about 100 million units.
The Smartphone Summit semi-annual conference details smartphone industry market data, trends, and updates among smartphone related hardware, software, and accessories. Android, a cross platform OS for smartphones was released in 2008. Android is an Open Source platform backed by Google, along with major hardware and software developers (such as Intel, HTC, ARM, Motorola and eBay, to name a few), that form the Open Handset Alliance.
Smartphones these days are powerful beasts. Their specification sheets almost read like what you’d find for a computer, and these devices are now capable of tasks that one would have done on a computer in the past, such as browsing desktop-class webpages, watching Flash videos, running multiple apps at once, grabbing email and even doing simple photo and video editing. Since these mobile devices are able to accomplish so many tasks, the hardware specifications of a smartphone have gradually become a more important factor.
1. Processor : Processor speed is of somewhat less importance than the rest of the specifications, simply because these megahertz numbers are not capable of accurately reflecting the actual performance of a smartphone. More often than not, the everyday performance and speed of operation of a particular device are more dependent on software optimizations and the efficiency of the OS rather than purely based on processor speeds. At present, the ARM Cortex A8 is one of the most powerful mobile processors, being used in TI’s OMAP 3430 and Qualcomm Snapdragon platforms. For most of us, these names aren’t as important since the arguably most effective way of knowing a smartphone’s performance is by testing it in a store, but at the moment, devices like the iPhone 3GS, HTC Touch HD2 and Nokia N900 are three of the most powerful smartphones around. That said, most devices released in the past year do manage to offer plenty of performance that will satisfy all except the most demanding phone geeks; even a lowly Nokia 5800 which I’m using right now is already able to offer a decent amount of processing power, with the UI operating at a comfortable speed despite its average 434MHz ARM 11 processor that’s also present in the N97(mini).
2. Internal memory (also known as RAM) : This is an important figure to look at when selecting a new smartphone, especially for devices capable of multitasking out of the box (sorry iPhone) as having more RAM means being able to run more apps at one time without suffering from apps closing unexpectedly, system slowdowns and freezes. RAM size varies from 64MB to 128MB.
3. Display size, resolution and technology : Today’s devices come with a huge variety of displays with different sizes, resolution and utilize different technologies. Let’s get the obvious out of the way – the number of colours supported by a display doesn’t really matter because 65K-colour screens can look just as good as a 16 million-colour screen. Screen sizes typically range from 2.2-inches to 2.8 inches, with most screen resolutions being 240×320 pixels in either portrait or landscape. Most displays are based on TFT LCD technology with a transflective layer which uses a backlight to illuminate the pixels on the screen and has great visibility in direct sunlight. OLED screens are starting to be adopted in mobile devices. Touchscreen-operated smartphones typically have larger, higher-resolution displays than their non-touch counterparts.
4. Hardware 3D graphics acceleration : Having 3D graphics acceleration onboard results in better-looking games (those that take advantage of the added hardware) and smoother high-resolution video playback in addition to a overall-speedier user interface.
5. External Connectors : Standard external connectors refer to the use of non-proprietary connections for audio output and data transfers in a device. Most smartphones have a combination of 3.5mm standard headphone jack and micro USB port for audio and data respectively. At this point, micro USB charging is also starting to be implemented in newer devices.
6. Camera & LED/XENON FLASH : The same rules that govern megapixel counts on standalone digital cameras do apply to smartphones too; more megapixels isn’t always better. At the present moment, the two best camera-phones in the world are the Nokia N86 and Sony Ericsson Satio. One of the largest debates of all time with regards to smartphone imaging is whether Xenon or LED flash units should be used in smartphones . Xenon flash are always better than LED flash.
7. Battery : Battery has capability ranging from 850mAh to 1500mAh.
8. Internal sensors : Fundamentally, there are four internal sensors you should look out for; an accelerometer handles auto-rotation of your device’s display, detecting whether you’re trying to capture a photo in portrait or landscape mode, as well as for special features such as silencing calls and alarms when the device is turned over. A magnetometer is otherwise known as a digital compass; this is used in GPS navigation apps where the map is aligned to the direction you’re facing, as well as in “augmented reality” apps such as Layar on the Android platform; these apps make use of the digital compass in your device and your camera in order to point out certain points of interest relative to their actual location. A light sensor automatically adjusts your screen’s backlight and keypad lighting based on ambient lighting conditions; your screen would dim in dark conditions so as not to dazzle you and increase in brightness in sunlight to boost outdoor visibility. Lastly, a proximity sensor turns off the display during phone calls on touchscreen handsets so as to prevent accidental touches when the device is taped to the side of your face.
9. Wireless technologies : Fundamentally, at present, there are three types of wireless technologies in smartphones; cellular, Bluetooth and location services (GPS). Most devices released in the last year are what we call 3.5G devices; these are equipped with HSDPA (high-speed downlink packet access) and sometimes HSUPA (high-speed uplink packet access) which provide even faster data transfer rates than standard 3G, which is termed as UMTS (universal mobile telecommunications system). EDGE and GPRS are 2.5G and 2G technologies respectively; all 3G phones continue to support these technologies in order to maintain connections when out of 3G coverage. Bluetooth has evolved over the years, with data transfer speeds and the reliability of wireless connections continuously increasing. The latest version that most devices released in the past year would come equipped with is known as Bluetooth 2.1 with EDR (enhanced data rate) which will probably provide speeds of up to 100kbps in most situations. AGPS is probably one of the most misunderstood technologies in recent times. AGPS stands for Assisted Global Positioning System, and it depends on a bunch of satellites in the sky in order to pinpoint your location in a navigation app when activated. For standard GPS systems, it might take quite a bit of time to get a fix on exactly where you are, especially in urban areas, but if your device has AGPS capability onboard, it is able to make use of cell tower data in order to narrow down your location, speeding up the process of acquiring a fix.
Active In SP
Joined: Mar 2011
26-03-2011, 07:28 PM
CAN I GET MORE PPT FOR THE SMART PHONE AN EMBEDDED SYSTEM APPLICATION.
Joined: Jul 2011
16-01-2012, 10:52 AM
to get information about the topic embedded systems full report,ppt and related topic refer the link bellow page
http://seminar and presentationproject and implimentations.com/attachment.php
http://topicideas.org/how-to-embedded-sy...es-seminar and presentation-report
http://topicideas.org/how-to-embedded-systems-project and implimentations
http://topicideas.org/how-to-linux-in-em...ll-seminar and presentation-report
Active In SP
Joined: Feb 2012
25-02-2012, 12:41 PM
to get information about the topic communication+embeded system full report ppt and related topic refer the link bellow
http://topicideas.org/how-to-robotics-em...ms-project and implimentations-list