I would like to ask you guys for difference between these two terms. I will show below my understanding:
ATT defines term "attribute" and the way to exchange this data.
GATT is built on top of ATT and defines procedures to handle ATT and additionaly terms "services" and "characteristics".
Am I right with it?
There comes one more question: I know that ATT and GATT are part of Bluetooth Stack, but what is that? Is it piece of software or theoritical way of handling BLE communication? I can't understand concept of layers of BLE stack. What are the inputs and outputs of these layers?
I would really appreciate your help.
You can read the ATT and GATT chapters in the Bluetooth Core specification. That should make everything clear.
ATT is the protocol how attributes are transferred. GATT is more of a set of rules how this ATT standard should be used to build the concept of Services, Characteristics and Descriptors, as well of defining which ATT protocol messages should be used in which circumstances. In my opinion these two should have been merged into one single standard.
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 need to develop device libraries like uBlox, IMUs, BLE, ecc.. from scratch (almost). Is there any doc or tutorial that can help me?
Question is, how to write a device library using C/C++ (Arduino style if you want) given a datasheet and a platform like STM32 or other ARMs?
Thanks so much
I've tried to read device libraries from Arduino library and various Github, but I would like to have a guide/template to follow (general rules) to write proper device libraries from a given datasheet.
I'm not asking a full definitive guide, just where to start, docs, methods approach.
I've found this one below, but is very basic and quite lite for my targets.
http://blog.atollic.com/device-driver-development-the-ultimate-guide-for-embedded-system-developers
I don't think that you can actually write libraries for STM32 in Arduino style. Most Arduino libraries you can find in the wild promote ease of usage rather than performance. For example, a simple library designed for a specific sensor works well if reading the sensor and reporting the results via serial port is the only thing that firmware must do. When you work on more complex projects where uC has lots to do and satisfy some real time constraints, the general Arduino approach doesn't solve your problems.
The problem with STM32 library development is the complex connection between peripherals, DMA and interrupts. I code them in register level without using the Cube framework and I often find myself digging the reference manual for tables that shows the connections between DMA channels or things like timer master-slave relations. Some peripherals (timers mostly) work similar but each one of them has small differences. It makes development of a hardware library that fits all scenarios practically impossible.
The tasks you need to accomplish are also more complex in STM32 projects. For example, in one of my projects, I fool SPI with a dummy/fake DMA transfer triggered by a timer, so that it can generate periodic 8-pulse trains from its clock pin (data pins are unused). No library can provide you this kind of flexibility.
Still, I believe not all is lost. I think it may be possible to build an hardware abstraction layer (HAL, but not The HAL by ST). So, it's possible to create useful libraries if you can abstract them from the hardware. A USB library can be a good example for this approach, as the STM32 devices have ~3 different USB peripheral hardware variations and it makes sense to write a separate HAL for each one of them. The upper application layer however can be the same.
Maybe that was the reason why ST created Cube framework. But as you know, Cube relies on external code generation tools which are aware of the hardware of each device. So, some of the work can be avoided in runtime. You can't achieve the same result when you write your own libraries unless you also design a similar external code generation tool. And also, the code Cube generates is bloated in most cases. You trade development time for runtime performance and code space.
I assume you will be using a cross toolchain on some platform like Linux, and that the cross toolchain is compatible with some method to load object code on the target CPU. I also assume that you already have a working STM32 board that is documented well enough to figure out how the sensors will connect to the board or to the CPU.
First, you should define what your library is supposed to provide. This part is usually surprisingly difficult. It’s a bit hard to know what it can provide, without knowing a bit about what the hardware sensors are capable of providing. Some iteration on the requirements is expected.
You will need to have access to the documentation for the sensors, usually in the form of the manufacturer’s data sheets. Using the datasheet, and knowing how the device is connected to the target CPU/board, you will need to access the STM32 peripherals that comprise the interface to the sensors. Back to the datasheets, this time for the STM32, to see how to access its peripheral interfaces. That might be simple GPIO bits and bytes, or might be how to use built-in peripherals such as SPI or I2C.
The datasheets for the sensors will detail a bunch of registers, describing the meaning of each, including the meanings of each bit, or group of bits, in certain registers. You will write code in C that accesses the STM32 peripherals, and those peripherals will access the sensors across the electrical interface that is part of the STM32 board.
The workflow usually starts out by writing to a register or three to see if there is some identifiable effect. For example, if you are exercising a digital IO port, you might wire up an LED to see if you can turn it on or off, or a switch to see if you can correctly read its state. This establishes that your code can poke or peek at IO using register level access. There may be existing helper functions to do this work as part of the cross toolchain. Or you might have to develop your own, using pointer indirection to access memory mapped IO. Or there might be specially instructions needed that can only be accessed from inline assembler code. This answer is generic as I don’t know the specifics of the STM32 processor or its typical ecosystem.
Then you move on to more complex operations that might involve sequences of operations, like cycling a bit or two to effect some communication with the device. Or it might be as simple as finding the proper sequence of registers to access for operation of a SPI interface. Often, you will find small chunks of code are complete enough to be re-used by your driver; like how to read or write an individual byte. You can then make that a reusable function to simplify the rest of the work, like accessing certain registers in sequence and printing the contents of register that you read to see if they make sense. Ultimately, you will have two important pieces of information: and understanding of the low-level register accesses needed to create a formal driver, and an understanding of what components and capabilities make up the hardware (ie, you know how the device(s) work).
Now, throw away most of what you’ve done, and develop a formal spec. Use what you now know to include everything that can be useful. Use what you now know to develop a spec that includes an appropriate interface API that your application code can use. Rewrite the driver, armed with the knowledge of how are the pieces work, and taking advantage of the blank canvas afforded you by the fresh rewrite of the spec. Only reuse code that you are completely confident is optimal and appropriate to the format dictated by the spec. Write test code for all of the modules, and use the test code to actually test that the code works and that it conforms to the spec. Re-use the test code every time you modify anything it tests.
I've done many projects that include a PC & an arduino / PLC / some kind of other microcontroller / processor, and in every project we had a different protocol used for communication between the PC application and the embedded one. Usually the hardware / controller developer invents a simple protocol which always changes throughout the project, and goes into the form of
Barker | Size | Data | Checksum
This time I'm implementing both sides, so I figured - This has been done a million times before. There must be a base protocol for these things with implementations in C, C#, Java, and such.
What I'm looking for is a lightweight layer that transfers stream based serial communication into a message based one.
I've been looking around for one for a while, but I couldn't find anything on my own.
Do you happen to know one?
I had exactly the same requirements for a recent project and I found nothing simple enough for low-end 8-bit microcontrollers. So I designed MIN (Microcontroller Interconnect Network) to do the job (inspired by CAN and LIN).
The code is on github here: https://github.com/min-protocol/min (check out the wiki there).
I defined a layer 0 (the UART settings) and layer 1 (the frame layer, with checksums, etc.) plus a C API.
I'm also working on a higher layer that formally defines how sensor data (temperature, pressure, voltage, etc.) are packed, with a JSON representation and a tool to autogenerate the embedded code to pack/unpack them from frames. The end goal is to create a Wireshark dissector that can be clipped on to the serial line and when fed with the JSON will display the signals in human-readable form.
I wrote a blog post showing a Hello World app running on an Arduino board (with an FTDI UART-USB breakout board carrying the data up to my host PC):
https://kentindell.wordpress.com/2015/02/18/micrcontroller-interconnect-network-min-version-1-0/
This serial problem occurs so often that it would be nice if we as a community just nailed it rather than keep re-coding it for every project.
Check Open Source HDLC
I recently came across MIN - never used this one though
Also check this
Simple serial point-to-point communication protocol
Using X/Y/Z MODEM protocol must be a good choice to solve your problem. It's easy to implement and ready-to-use. I use X-MODEM on an ISP tool communicates with our cortex-m0 powered MCU, and it works pretty well.
I have project to do. Which requires that I use FPGA. The theme is, that I need to create a circuit in FPGA using VHDL which would perform some task like multiplication or division. And then I need to send the input data from PowerPC(Built in Microcontroller in Virtex 4) to that circuit and then collect the data from output of FPGA circuit using PowerPC. I have tried looking at the manuals but failed to understand the communication between FPGA circuit and Microcontroller.
Google didn't help too..
Please let me know, if there is a book or a better tutorial which can help me in this project. Thanks in advance for your concern.
Note: I am using Virtex-4 ml403 FPGA board.
Thanks Again.
Take a look at Xapp717 from Xilinx.
http://www.xilinx.com/support/documentation/application_notes/xapp717.pdf
In the introduction it specifically mentions what you are trying to do. The APU in this context refers to the PowerPC.
This application note introduces the APU and describes the main features of an APU-enhanced
system. Included examples illustrate how the APU transfers data between the processor and
the FPGA. The two examples are:
• A simple system that moves data from memory through the processor and APU, into
registers in the FPGA, and back into memory
Source code is included (Xilinx login required)
http://www.xilinx.com/bvdocs/appnotes/xapp717.zip
Our software Impulse C will automatically make the bus connection to the PPC. You're welcome to try it for free. If you are interested send your Ethernet MAC to me or to info at ImpulseC and we'll get you started.
Best,
Brian
Do you need to implement a multiplier/divider to accelerate computing using FPGA? If so, you should design a multiplier/divider with VHDL code. Maybe using Xilinx IP core is the most convenient way. All you need to do is specify the parameter you want (e.g. input numbers are 32-bit). Synthesize your design and assign input/output pins. Then you can transfer data between PowerPC and FPGA through these pins.
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.