Enum bluenrg::event::BlueNRGEvent[−][src]

pub enum BlueNRGEvent {
    HalInitialized(ResetReason),
    EventsLost(EventFlags),
    CrashReport(FaultData),
    GapLimitedDiscoverableTimeout,
    GapPairingComplete(GapPairingComplete),
    GapPassKeyRequest(ConnectionHandle),
    GapAuthorizationRequest(ConnectionHandle),
    GapPeripheralSecurityInitiated,
    GapBondLost,
    GapDeviceFound(GapDeviceFound),
    GapProcedureComplete(GapProcedureComplete),
    GapAddressNotResolved(ConnectionHandle),
    L2CapConnectionUpdateResponse(L2CapConnectionUpdateResponse),
    L2CapProcedureTimeout(ConnectionHandle),
    L2CapConnectionUpdateRequest(L2CapConnectionUpdateRequest),
    GattAttributeModified(GattAttributeModified),
    GattProcedureTimeout(ConnectionHandle),
    AttExchangeMtuResponse(AttExchangeMtuResponse),
    AttFindInformationResponse(AttFindInformationResponse),
    AttFindByTypeValueResponse(AttFindByTypeValueResponse),
    AttReadByTypeResponse(AttReadByTypeResponse),
    AttReadResponse(AttReadResponse),
    AttReadBlobResponse(AttReadResponse),
    AttReadMultipleResponse(AttReadResponse),
    AttReadByGroupTypeResponse(AttReadByGroupTypeResponse),
    AttPrepareWriteResponse(AttPrepareWriteResponse),
    AttExecuteWriteResponse(ConnectionHandle),
    GattIndication(AttributeValue),
    GattNotification(AttributeValue),
    GattProcedureComplete(GattProcedureComplete),
    AttErrorResponse(AttErrorResponse),
    GattDiscoverOrReadCharacteristicByUuidResponse(AttributeValue),
    AttWritePermitRequest(AttributeValue),
    AttReadPermitRequest(AttReadPermitRequest),
    AttReadMultiplePermitRequest(AttReadMultiplePermitRequest),
    GattTxPoolAvailable(GattTxPoolAvailable),
    GattServerConfirmation(ConnectionHandle),
    AttPrepareWritePermitRequest(AttPrepareWritePermitRequest),
}

Vendor-specific events for the BlueNRG-MS controllers.

Variants

When the BlueNRG-MS firmware is started normally, it gives this event to the user to indicate the system has started.

If the host fails to read events from the controller quickly enough, the controller will generate this event. This event is never lost; it is inserted as soon as space is available in the Tx queue.

The fault data event is automatically sent after the HalInitialized event in case of NMI or Hard fault.

This event is generated by the controller when the limited discoverable mode ends due to timeout (180 seconds).

This event is generated when the pairing process has completed successfully or a pairing procedure timeout has occurred or the pairing has failed. This is to notify the application that we have paired with a remote device so that it can take further actions or to notify that a timeout has occurred so that the upper layer can decide to disconnect the link.

This event is generated by the Security manager to the application when a pass key is required for pairing. When this event is received, the application has to respond with the gap_pass_key_response command.

This event is generated by the Security manager to the application when the application has set that authorization is required for reading/writing of attributes. This event will be generated as soon as the pairing is complete. When this event is received, gap_authorization_response command should be used by the application.

This event is generated when the peripheral security request is successfully sent to the central device.

This event is generated on the peripheral when a gap_peripheral_security_request is called to reestablish the bond with the central device but the central device has lost the bond. When this event is received, the upper layer has to issue the command gap_allow_rebond in order to allow the peripheral to continue the pairing process with the central device. On the central device, this event is raised when gap_send_pairing_request is called to reestablish a bond with a peripheral but the peripheral has lost the bond. In order to create a new bond the central device has to launch gap_send_pairing_request with force_rebond set to true.

The event is given by the GAP layer to the upper layers when a device is discovered during scanning as a consequence of one of the GAP procedures started by the upper layers.

This event is sent by the GAP to the upper layers when a procedure previously started has been terminated by the upper layer or has completed for any other reason

This event is sent only by a privacy enabled peripheral. The event is sent to the upper layers when the peripheral is unsuccessful in resolving the resolvable address of the peer device after connecting to it.

This event is generated when the central device responds to the L2CAP connection update request packet. For more info see ConnectionParameterUpdateResponse and CommandReject in Bluetooth Core v4.0 spec.

This event is generated when the central device does not respond to the connection update request within 30 seconds.

The event is given by the L2CAP layer when a connection update request is received from the peripheral. The application has to respond by calling l2cap_connection_parameter_update_response.

This event is generated to the application by the ATT server when a client modifies any attribute on the server, as consequence of one of the following ATT procedures:

  • write without response
  • signed write without response
  • write characteristic value
  • write long characteristic value
  • reliable write

This event is generated when a ATT client procedure completes either with error or successfully.

This event is generated in response to an Exchange MTU request.

This event is generated in response to a Find Information Request. See Find Information Response in Bluetooth Core v4.0 spec.

This event is generated in response to a Find By Type Value Request.

This event is generated in response to a Read by Type Request.

This event is generated in response to a Read Request.

This event is generated in response to a Read Blob Request. The value in the response is the partial value starting from the offset in the request. See the Bluetooth Core v4.1 spec, Vol 3, section 3.4.4.5 and 3.4.4.6.

This event is generated in response to a Read Multiple Request. The value in the response is the set of values requested from the request. See the Bluetooth Core v4.1 spec, Vol 3, section 3.4.4.7 and 3.4.4.8.

This event is generated in response to a Read By Group Type Request. See the Bluetooth Core v4.1 spec, Vol 3, section 3.4.4.9 and 3.4.4.10.

This event is generated in response to a Prepare Write Request. See the Bluetooth Core v4.1 spec, Vol 3, Part F, section 3.4.6.1 and 3.4.6.2

This event is generated in response to an Execute Write Request. See the Bluetooth Core v4.1 spec, Vol 3, Part F, section 3.4.6.3 and 3.4.6.4

This event is generated when an indication is received from the server.

This event is generated when an notification is received from the server.

This event is generated when a GATT client procedure completes either with error or successfully.

This event is generated when an Error Response is received from the server. The error response can be given by the server at the end of one of the GATT discovery procedures. This does not mean that the procedure ended with an error, but this error event is part of the procedure itself.

This event can be generated during a "Discover Characteristics by UUID" procedure or a "Read using Characteristic UUID" procedure. The attribute value will be a service declaration as defined in Bluetooth Core v4.0 spec, Vol 3, Part G, section 3.3.1), when a "Discover Characteristics By UUID" has been started. It will be the value of the Characteristic if a "Read using Characteristic UUID" has been performed.

See the Bluetooth Core v4.1 spec, Vol 3, Part G, section 4.6.2 (discover characteristics by UUID), and section 4.8.2 (read using characteristic using UUID).

This event is given to the application when a write request, write command or signed write command is received by the server from the client. This event will be given to the application only if the event bit for this event generation is set when the characteristic was added. When this event is received, the application has to check whether the value being requested for write is allowed to be written and respond with a GATT Write Response. If the write is rejected by the application, then the value of the attribute will not be modified. In case of a write request, an error response will be sent to the client, with the error code as specified by the application. In case of write/signed write commands, no response is sent to the client but the attribute is not modified.

See the Bluetooth Core v4.1 spec, Vol 3, Part F, section 3.4.5.

This event is given to the application when a read request or read blob request is received by the server from the client. This event will be given to the application only if the event bit for this event generation is set when the characteristic was added. On receiving this event, the application can update the value of the handle if it desires and when done it has to use the allow_read command to indicate to the stack that it can send the response to the client.

See the Bluetooth Core v4.1 spec, Vol 3, Part F, section 3.4.4.

This event is given to the application when a read multiple request or read by type request is received by the server from the client. This event will be given to the application only if the event bit for this event generation is set when the characteristic was added. On receiving this event, the application can update the values of the handles if it desires and when done it has to send the allow_read command to indicate to the stack that it can send the response to the client.

See the Bluetooth Core v4.1 spec, Vol 3, Part F, section 3.4.4.

This event is raised when the number of available TX buffers is above a threshold TH (TH = 2). The event will be given only if a previous ACI command returned with InsufficientResources. On receiving this event, the application can continue to send notifications by calling gatt_update_char_value.

This event is raised on the server when the client confirms the reception of an indication.

This event is given to the application when a prepare write request is received by the server from the client. This event will be given to the application only if the event bit for this event generation is set when the characteristic was added. When this event is received, the application has to check whether the value being requested for write is allowed to be written and respond with the command gatt_write_response. Based on the response from the application, the attribute value will be modified by the stack. If the write is rejected by the application, then the value of the attribute will not be modified and an error response will be sent to the client, with the error code as specified by the application.

Trait Implementations

impl Clone for BlueNRGEvent
[src]

Returns a copy of the value. Read more

Performs copy-assignment from source. Read more

impl Copy for BlueNRGEvent
[src]

impl Debug for BlueNRGEvent
[src]

Formats the value using the given formatter. Read more

impl VendorEvent for BlueNRGEvent
[src]

Enumeration of vendor-specific errors that may occur when deserializing events. Generally, this means some values in the buffer are out of range for the event. Read more

Enumeration of return parameters for vendor-specific commands.

Enumeration of vendor-specific status codes.

Creates a new vendor-specific event from the contents of buffer. The buffer contains only the payload of the event, which does not include the BLE event type (which must be 0xFF) or the parameter length (which is provided by buffer.len()). Read more

Auto Trait Implementations