I am planning to build a micro controller (a switch will be attached to the embedded system which contains this micro controller) and this embedded system will be connected through a wire to mobile phone. My objective is to dial a particular number through the connected mobile phone network when the user presses the switch on the embedded system. ( planning to use AT commands for dialing). After extensive search, I have found that it is possible to do this above task. Some of the questions I have on this :
a) Do we have to install any drivers on the micro controller to communicate with mobile phone (for sending AT commands) i.e., is it sufficient if we simply code the related AT commands in the micro-controller (in C++) ?
b) Many people were using F-bus protocol for this above objective. Is there any other general protocol similar to this which can help for communicating with all mobiles (samsung,nokia,sony..)
I have read extensively in SO also. But, I have not found any question regarding the drivers. I would appreciate any kind of help
Thanks
A driver is nothing more than a software that allows your system to interact other devices, and is usually associated with Operating Systems (the driver might provide an abstraction layer for your communication). Do you plan to use an Operating System at all?
In any case, it is quite obvious that if you want to communicate to another device you need the software to do so. The question is if you write it your self or if you get an "off the shelf" solution.
In many cases, particularly when a device uses a proprietary communication protocol, you have no option but to get a driver to communicate with it, and that most likely will require you to have an Operating System.
If cellular communication is all you need, there are MUCH easier solutions available (particularly if you intend of turning your project into a product). Search for "embedded modems" or M2M solutions. There are lots of available modems to which you connect using RS232, and can send the AT commands directly. Telit and Multitech are two providers I've worked with and are really easy to interface with.
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.
On the DroneKit.io page, it mentions using DroneKit Python when creating Ground Control Stations for Windows. However, there appears to be no documentation for this.
Is it meant to simply simulate a com port and act as a proxy for other Ground Control Stations, which just makes it easier hijack the MAVLink?
Also, it mentions Python being used for low-latency processes. This seems to be oxymoronic. Is there a reason that it would be better than just using C/C++ for the purpose of hijacking the MAVLink?
Thanks!
DroneKit-Python can be used either to create a python-based ground station or it can be run on a companion computer. There is no practical difference between the two except how you set up the connection to the vehicle from the computer running the script. The different ways of starting MAVProxy for the different connections are covered in the Getting Started documentation.
The reason that there is no "specific" documentation on using DK-Python for GCS is primarily "marketing". The far bigger market for ground station GCS software is in tablets/phones that will use DK-Android or a future iOS port. DK-Python has been positioned solely as for use in the air interface. Even though there is no "specific" documentation, in fact all the existing documentation is relevant.
Is it meant to simply simulate a com port and act as a proxy for other Ground Control Stations, which just makes it easier hijack the MAVLink?
No. See above.
Also, it mentions Python being used for low-latency processes. This seems to be oxymoronic. Is there a reason that it would be better than just using C/C++ for the purpose of hijacking the MAVLink?
It doesn't mention low-latency processes, so the answer is "invalid question".
You're probably misreading the text "that require a low-latency link". The point here is that if you have dronekit-python running on a companion computer and connected by a fast link you can do real time handling of incoming sensor data. This allows computer vision control of the UAV. However if you run DK-Python on a ground control station you will have a much slower link. You can still control movement of the UAV but the latency will be much higher.
Hope that helps!
I have a requirement to have a cross-platform program --- intended for mobile devices such as Android, Brew, Bada, WinCE etc --- be able to communicate with other instances of itself via Bluetooth.
Unfortunately:
the Bluetooth APIs on such devices are all radically, radically different.
the terminology they use is also radically different.
what actually works is frequently radically different to what they say works.
So far I've discovered that Android will allow you to connect to or listen on RFCOMM services specified by a simple UUID, but does not allow more complicated manipulation of SDP records; Brew claims to support SPP but the API appears to allow arbitrary RFCOMM; Bada supports SPP but doesn't allow you to specify the UUID, so I have no idea how you're supposed to do service discovery or listen for two things at once...
Oh, and iOS doesn't allow Bluetooth communication at all to non-iOS devices.
So:
I can't be the first person to need to do this. Is there a known subset of Bluetooth functionality that I should be using in order to maximise portability?
Device makers usually implement some bluetooth profiles such as A2DP, OBEX, etc. Depending what you want to do, you should check that all your target devices implement the required profiles.
Note that even though a device can implement an specific profile, there may not be an API that will allow you to use it.
See http://en.wikipedia.org/wiki/Bluetooth_profile.
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.
How should I approach implementing a USB device driver for Windows? How should I take into account different versions of windows e.g:
- Windows XP
- Windows Vista
- Windows 7
Is there open source solutions which could be used as a starting point? I'm a total newbie to windows driver development.
We have an embedded device with USB device port and we would like to have as low latency communication from the application level to the device as possible without sacrificing the data throughput. The actual data transferred is ADC/DAC data. Basically there is a lot of data which we need to transfer to a Windows machine as fast as possible.
We need more information about the device to point you in the right direction, but here are a few steps to get you started:
register with Microsoft Connect so you can download the Windows Driver Kit
register with osr-online as you'll find great articles, plenty of information, and a newsgroup dediciated just to Windows drivers -- this place is a goldmine
buy Developing Drivers with WDF, which will help you make sense of driver development on Windows and give you a good foundation to read articles from OSR and Microsoft
Hope that you can use UMDF (user-mode drivers) as you can use C++ and just write COM code. If you're doing anything with USB that requires kernel-space....you've got a lot of reading and learning to do for the next year!
To answer your question on versions, the Driver Kit has tools that will help you manage creating different drivers. If you write a good driver, it should run on all three OS with no problems, and the differences will just be in the config area (not the binary)
Basically, it depends on how complex your device is. What type of driver are you trying to write? File system? MP3 player? Camera? Modem?
If you end up having to write a kernel mode driver, let me know and I can point you to some good articles and what not.
I should also add that for around US $5,000, you can buy a license for WinDriver, a tool that takes all of the hard stuff out of driver development. You can use C++ or C# user-mode code to communicate with their driver that is custom generated for your device. This is the way to go if you have a tight deadline.
You can take a look at windows variant of libusb *here*. There are wrappers for many programming languages on official libusb site and on the web.
Start here: Windows Driver Kit Introduction
If you have some form of control over the device side, have it implement an interface for which Windows already provides drivers. E.g. the USB HID class (literally Human Input Device, but neither the Human nor the Input is mandatory) already has Windows drivers, and there is a reasonable Win32 API on top. You're not going to get data rates anywhere near 480 Mbps, though.