I've seen various command formats for Bluetooth operation in accordance with the HCI. Does the HCI commands of Bluetooth changes from Vendor to Vendor or constant to all vendors?
HCI commands are part of Bluetooth specifications. Those can be found on:
www.bluetooth.com
So basically all HCI commands specified there must be supported by vendor to be approved by the Bluetooth organization.
However, it's not prohibited for a vendor to add his own specific commands which are not part of the specification.
Related
I'm doing an embedded-system project now. From my view, AT commands can be sent to a device to retrieve 4G information, dial and so on. On the other hand, we can also do that by calling APIs provided by the 4G vendor.
My question is what's the relationship between them? Is the API a wrapper for the AT commands?
TL;DR
Vendor's API (not only C, but also C++, Java or Python depending to the vendor and the modem model) can both be wrappers for AT commands and a wider, more powerful set of API were the user can port complex applications.
It depends on the vendor and on the model.
A jungle of modems produced by different vendors
It is impossible to define a general "rule" about API provided by a Cellular Module (not necessarily a 4G module).
First of all every vendor usually implements standard AT Commands (both Hayes commands and extended standard commands for cellular devices). In the same way every vendor has it's own implementation of the user application area where the customers can store their own application to control the modem's functionalities and to use them according to their own application requirements.
AT commands remain the interface to be used when the modem needs to be connected (and driven) by an external host. When the user application area is used, instead, a wider set of API is usually provided. They may include:
A library exporting a subset of the OS capabilities (threads management, events, semaphores, mutexes, SW timers, FS access and so on)
A library offering the capability to manage the specific HW of the device (GPIOs, SPI, I2C, ADC, DAC and so on)
A library offering a programmatical way to perform action, related to connectivity, that would normally be executed through AT commands (registration status check, PIN code insertion, PDP context activation, SMS management, TCP/UDP/TLS sockets)
The latter usually access a base layer involving all the functionalities provided by the modem. Usually this is the same layer invoked by the AT commands sent through modem's serial interface.
Sending AT commands... from the vendor's API?
Of course it often happens that the library mentioned above provides just a subset of the functionalities usually exported with the AT commands set so, in order to "fill the gap", a further set of APIs is usually exported as well:
A set of functions that allow the simulation of AT commands sent to the modem's serial port. Sending them and parsering the responses they send in the vitual internal serial/USB interface allow the user to port in the internal user application area the the application they previously run on an external host processor (with obvious BOM benefits).
As an example, please check Telit Appzone here and here. It was the inspiration of my answer because I know it very well.
I don't know why you name the title that there's a relationship between AT command and Linux-C API.
Regarding AT command, you can take a look at this wiki article for general information.
Each module has a specified AT command sets. Normally, the module manufacture just offers AT command set and what return values are.
Is API a wrapper of AT command?
If you can use the API provided by the manufacturer, then yes, it's a wrapper of the AT command handler.
My question is what's the relationship between them? Is the API a wrapper for the AT commands?
It is impossible to be sure without having any details of the device, but probably any C API for it wraps the AT command set, either by communicating with the device directly over an internal serial interface or by going through a device driver that uses AT commands to communicate with it.
However, it is at least conceivable, albeit unlikely, that the 4G device offers an alternative control path that the C API uses (definitely via a driver in this case).
I'm not quite sure what the point of the question is, though. If you are programming the device and its 4G component in C, and the manufacturer has provided a C API, then use it! If you are programming in some other language then at least consider using the C API, which you should be able to access from most other languages in some language-specific way. You should not expend effort on rolling your own without a compelling reason to reject the API already provided to you.
I am trying to develop a bluetooth LE peripheral in intel-edison, by using C library. The device should be able to :
advertise (GAP)
accept connection (GAP)
support custom GATT service, simply read/write value of characteristic.
I try to use HCI and bluez to implement this. bluez-experiments, intel-edison-playground, which demonstrate how to advertise and scan, can be compiled and run on edison. BLE advertising and scanning do work.
But I have hard time to figure out how to accept connection and support GATT service. I try to search on goolge about the HCI document but have no luck. Can someone provide a snippet of code (c or pseudo or a description)?
Thank you so much!
Andrew
If you download the bluez source you'll find documentation on the hci protocol in /doc/mgmt-api.txt. I'm not using the hci interface myself, and I'm not sure if the developers intend for implementors to use this interface to implement peripherals, so I'm not sure how well this will work.
I went with the DBus API approach for my project, which is outlined in /doc/gatt-api.txt and /doc/advertising-api.txt. This approach involves writing a program which creates DBus objects which support specific org.bluez DBus interfaces (GattService1 which contains GattCharacteristic1 and GattDescriptor1) and the ObjectManager interface to expose everything to bluez. You then use LEAdvertisment1 to define what is advertised and register the advertisement using the LEAdvertisingManger1 interface on the adapter.
I used Qt to simplify the DBus communication parts.
The DBus API for BLE on bluez is still in heavy development, and not all features are supported (I still haven't found a way to start and stop advertising, for example). 5.31 contains a lot of added supported and some critical bug fixes for descriptors, but requires a newer kernel.
I am reading the QMI software API now since we will use QMI instead of AT commands. Based on the api, I know QMI imports C library to talk with device. My question is that how does it talk with device exactly?
Before I was using AT commands, I can use serialPort to send AT commands string to the device and get the response. But for now I will move into C library, like
ULONG QCWWAN2KConnect(CHAR * pDeviceID, CHAR * pDeviceKey);
How does this prototye work and how can I send this to the device? Using serialPort as well?
I really need some experts to give me an simple example for it. Thanks
It really depends on whether you're using the GobiNet kernel driver (i.e. the 'official' out-of-tree driver given by manufacturers) or the qmi_wwan kernel driver (i.e. the 'unofficial in-tree' driver). If you're targeting to use the GobiAPI library (or a vendor specific one, like the Sierra SDK) then you're likely going to use GobiNet. See this blogpost for more information about the differences.
GobiNet doesn't use serial ports; instead it will use either:
A non-serial character device exposed, named something like /dev/qcqmi0
shared memory to talk betwen kernel and userspace (e.g. in newer Android devices).
In your case, you'll likely see the qcqmi device, so the GobiAPI/SDK will use that character device to send QMI commands to the device.
If you instead want to use the upstream qmi_wwan driver, you can use it with the libqmi library and its helper qmicli tool.
I want to write a C program that can search Bonjour enabled devices on network.
Basically we have a Network IP Camera, it supports Bonjour protocol. I want to write API in C that can search these devices which have Bonjour enabled. Does anyone have sample code or suggestions on how should I do that?
The following links provide some code samples, as you requested:
mDNSResponder
Quotes from mDNSPosix/ReadMe.txt:
mDNSPosix is a port of Apple's Multicast DNS and DNS Service Discovery
code to Posix platforms.
Multicast DNS and DNS Service Discovery are technologies that allow
you to register IP-based services and browse the network for those
services.
Packing List:
The sample uses the following directories:
o mDNSCore -- A directory containing the core mDNS code. This code
is written in pure ANSI C and has proved to be very portable. Every
platform needs this core protocol engine code.
o mDNSShared -- A directory containing useful code that's not core to
the main protocol engine itself, but nonetheless useful, and used by
more than one (but not necessarily all) platforms.
o mDNSPosix -- The files that are specific to Posix platforms: Linux,
Solaris, FreeBSD, NetBSD, OpenBSD, etc. This code will also work on
OS X, though that's not its primary purpose.
o Clients -- Example client code showing how to use the API to the
services provided by the daemon.
Using the Sample
---------------- When you compile, you will get:
o Main products for general-purpose use (e.g. on a desktop computer):
- mdnsd
- libmdns
- nss_mdns (See nss_ReadMe.txt for important information about nss_mdns)
o Standalone products for dedicated devices (printer, network camera,
etc.)
- mDNSClientPosix
- mDNSResponderPosix
- mDNSProxyResponderPosix
o Testing and Debugging tools
- dns-sd command-line tool (from the "Clients" folder)
- mDNSNetMonitor
- mDNSIdentify
SDWrap
ReadMe:
Quite simple wrapper app to execute some command with Zeroconf
supplied addresses and ports. Uses wxWidgets and wxServDisc for
service discovery...
Good luck!
I have a dsPIC33 with ECAN and wish to establish a protocol (using SDO if possible) in such way that it communicate between terminal software and dsPIC33 where I can perform diagnostics within dsPIC33 and supporting ICs.
I do not know what is required, so what is a low cost way of doing this? I could use a CAN-to-USB device, but I am unsure if this will work. What kind of protocol inside CANUSB wraps around the ASCII-based message?
What hardware can I use? Can it be used to monitor the CAN bus as well? I do not wish to invest in an expensive setup as in Vector or similar heavy-weight solution.
When you purchase CAN interface hardware, it does not typically include software to work with specific upper-level CAN protocols (like CANopen). They do usually come with a set of DLL files that allow you to write custom PC applications to interface with your hardware.
If you do not want to purchase any third-party software, then you must:
Implement a basic CAN driver for the dsPIC33 (transmit and receive a basic frame).
Implement the CANopen SDO protocol on top of your basic driver on the dsPIC33.
Purchase a low-cost CAN<->USB interface (which should come with DLLs that allow you to develop in C, C++ or C#.
Write a PC application using the DLL files which implements the CANopen SDO protocol.
You may want to look for open-source implementations of the protocol. One such implementation is CanFestival. However, I have never used this library.
You can download an open source project for CANopen from DATALINK ENGINEERING as this seems to be just what you need.