Symbian OS Communications (779884), страница 30
Текст из файла (страница 30)
For a full list of the control channel data,consult the IrCOMM specification.The 9-wire variant builds on the 3-wire control set by adding supportfor changing and querying the RS-232 flow control lines – specificallyDTR, DTS, CTS, DSR, RI and CD. Obviously which of these signals arevalid depends on whether you are in DTE or DCE mode. It should benoted that as these lines are sent as TinyTP data interleaved with theIrCOMM level data, precise timing should not be relied upon.
Someimplementations may also choose to ignore the RS-232 level lines, andrely instead on TinyTP’s credit-based flow control. As such it is notpossible to assume that having asserted a ‘flow off’ signal line, the remotestation will stop sending data.Centronics support adds still more control channel data to carry theextended set of signal lines, mainly various IEEE1284-defined signal lines.5.3 IrDA in Symbian OS5.3.1 IrCOMMAlthough IrCOMM is the highest level protocol in the IrDA protocol stack,it is worth mentioning first as the Symbian implementation takes care ofall of the IrDA-specific behaviour.To use IrCOMM, open an RComm instance with port name IrCOMM::0.Remote stations may now connect into the local device, using any ofthe IrCOMM variants.
Writing to the port will attempt to discover andconnect to the first remote station that is found. User applications have nocontrol over the variant of IrCOMM used – the highest variant supportedby the remote machine is used (starting with 9-wire cooked). IrCOMMalso supports encapsulating serial data directly in TinyTP packets – aprotocol often referred to as IrNET or IrDIAL. This TinyTP encapsulation will be used in preference to any of the pure IrCOMM variants130INFRAREDwhere possible. Just as there is no way to select which variant to use,there is equally no way to interrogate an established link and discoverthe type.As a result of this automatic negotiation, the RS-232 flow control linesexported by IrCOMM must not be relied upon to be sent to the remotestation, or to reflect what the remote station is attempting to assert.
Forthe 3-wire protocols, signals are looped back, so, for example, assertingRTS locally causes the local CTS signal to be asserted.Another point to note is the use of port configurations. None of thebaud rate or similar parameters will affect the real IrDA link, but may bepassed to the remote station on a cooked link. Of greater importance isthe iSIREnable flag.
This flag is used to enable IrDA framing on theserial line, which initially sounds relevant to IrCOMM. In fact, as this isan electrical level issue, attempting to set this on an IrCOMM RComminstance will lead to SetConfig() returning an error, and none of theother parameters supplied being changed.For applications using IrCOMM, the fact that they are running over theIrDA protocols should be fairly transparent. As a result, the remainder ofthis chapter is unlikely to be relevant – although monitoring of link status,described in section 5.3.13, may be of interest.5.3.2 Protocol Constants and API DefinitionsAs described in chapter 2, the IrDA protocols are implemented on Symbian OS as an ESOCK plug-in.
This allows the use of standard RSocketinterfaces, coupled with the associated framework classes. RSocket isdefined in es_sock.h, and the IrDA-specific classes and constants aredefined in ir_sock.h.The most important constants defined in ir_sock.h are those relating to the address family and protocol. These constants are requiredto open any class from es_sock.h, and associate it with the IrDAimplementation.const TUint KIrdaAddrFamilyconst TUint KIrmuxconst TUint KIrTinyTP= 0x100;= 88;= 89;//////IrDA protocol familyProtocol number for IrmuxProtocol number for IrTinyTP5.3.3 Device Discoveryclass CIrDeviceDiscoverer : public CActive{public:...void DiscoverDevicesL();virtual void RunL();// DoCancel would also need implementing for real applications...IRDA IN SYMBIAN OS131private:RSocketServ iSs;RHostResolver iDevices;TNameEntry iResult;};_LIT(KAllDevices, "*");void CIrDeviceDiscoverer::DiscoverDevicesL(){// Open a connection to socket serverUser::LeaveIfError(iSs.Open()); // this could be done in ConstructL// Open an IrDA host resolverUser::LeaveIfError(iDevices.Open(ss, KIrdaAddrFamily, KIrTinyTP));// Run a discovery sequenceTInt err = iDevices.GetByName(KAllDevices, iResult, iStatus);SetActive();}void CIrDeviceDiscoverer::RunL(){if (iStatus.Int() == KErrNone){// Do something with the discovered deviceTIrdaSockAddr addr(result().iAddr);// on v9.2 only, you could start searching for the next device here}else{// Discovery failed.User::Leave(err);}}Looking through this snippet illustrates a number of important points.RHostResolver::Open() takes three parameters – the socket serverhandle, the address family and the protocol number.
In the case of IrDAonly the address family is important, although ESOCK will enforce thatthe protocol number is one that the IrDA stack claims to know about. Inother words, it does not matter whether IrMUX or TinyTP is specified inthis call. However, for the sake of clarity it is suggested that the protocolwhich will eventually be used be specified.The call to GetByName() is shown here using the asynchronousversion of the call, as it can take up to around two seconds to complete.If a synchronous call is required in a real application, it would be betterto use the two-argument version of GetByName() – but as with mostSymbian OS programming, it is preferable to use an active object asthis means infrared functionality is usable from threads that are alsoperforming UI tasks without causing the UI to freeze.The other point to note in the GetByName() call is the first parameter.This descriptor is passed to the host resolver to tell it which name theprogrammer is interested in.
In the case of IrDA, however, the highly132INFRAREDdynamic behaviour is such that the name makes little sense, and so isignored by the stack. For the sake of clarity, it is recommended that theasterisk wildcard be used, as is suggested in this code snippet. Using thiswildcard will also protect your code should this behaviour change infuture releases.This code snippet only illustrates retrieving the first discovered device.RHostResolver provides the function Next() to retrieve additionalmatches, but it should be used with caution on the IrDA protocols. Onversions of the stack shipped in Symbian OS v9.1, Next() always returnsthe first discovered device and no error.
This has changed in v9.2, whichwill return additional devices, and complete with an error code whenall devices have been found. If you wish to allow your code to handlediscovering multiple devices, call Next() and verify that the deviceaddress returned is new. Due to the lack of an error return value in v9.1,the only way to reliably tell when the discovery sequence is complete isto check whether the address has already been seen.5.3.4 Making a Device VisibleAs long as the stack is loaded, it will respond to discovery requestsreceived from a remote station. Although there are a number of possibleways to load the stack, the most appropriate will be to open a listeningsocket – without a service listening and ready to accept connections,there is little point in allowing other stations to discover the local device.It is, however, also possible to open a host resolver, a service resolver(RNetDatabase), or simply use RSocketServ to force loading of thestack.
Often services provided over infrared are time-limited – that is tosay that a specific action needs to be taken in the UI to activate a listeningservice, then the service is only active for a limited period – one to twominutes, for example. This is controlled at the service level – the stackwill remain running for as long as the service is listening. It is thereforerecommended that you include code in your service that limits the periodfor which it listens for incoming connections.When visible, the stack responds to discovery requests with the devicenickname.
The nickname is a short user-friendly name, which may bepresented to users if multiple devices are discovered. The nickname hasa maximum length of 20 bytes, and is always sent in ASCII encoding. TheIrDA specification does allow different character sets to be used, but forinteroperability reasons, Symbian OS only allows ASCII.To set the device nickname, use the SetLocalName() function onRHostResolver attached to the IR stack. This operation should only beperformed by the device manufacturer, and as such, is protected by theNetworkControl capability.There may also be times when suppressing of discovery responses is ofuse.
This may be the case when connecting to an OS such as Windows,where as soon as a device is discovered it is connected to, in order toIRDA IN SYMBIAN OS133interrogate its supported features. Currently the only way to do this iswith a socket option (KDiscoveryResponseDisableOpt), which isdescribed in more detail in section 5.3.11. Using this option requires asocket – which corresponds to the stack being loaded.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
