My particular hardware target is a MinnoboardMax Turbot Dual-E, but I believe this question is generic to Intel Atom/BayTrail processors on other boards.
The SoC has a "multifunction serial port" (SSP) that can be used as a SPI bus interface. It can be attached by ACPI or by PCI (in the later case, the PCI id is 0x8086:0x0f0e). And within the Linux kernel, there is existing driver support (low_speed_spidev, spi_pxa2xx_pci, spi_pxa2xx_platform) which allows access to the hardware.
I would like to access the hardware from UEFI, and I'm finding very little documentation on how to access or program this hardware. I don't care very much whether I have to set it into ACPI or PCI mode in the BIOS, either one is OK for my purposes. I'd love to find an existing driver, but after half a day of searching I'm pretty convinced it's not out there. (Happy to be proven wrong on that.)
In lieu of that, can anyone point me to any code examples that would help to bootstrap this? I've tried looking at the Linux and BSD source code, but they both involve so many extra layers for generality/portability that I'm having trouble sorting out the portions that relate to this particular device, and the portions that simply support a generic driver model.
Edit: Post originally mistakenly said AHCI.
I study about IoT protocol CoAP, MQTT, LwM2M.
I was able to know a little about CoAP and MQTT.
But I do not know what LwM2M is.
I do not know what's different from CoAP.
I just thought that LwM2M is not a protocol with some format but a system structure using CoAP.
Is that correct?
What is LwM2M and How Can I know more information about LwM2M?
Please someone teach me.
LwM2M (specified by OMA) is a is a protocol group largely built on top of CoAP (specified by the IETF).
LwM2M uses a subset of CoAP's capabilities that fit into an architecture of many small devices registering at a large LwM2M server that manages the devices. It prescribes particular path structures (that numbers are used in paths, and what they mean) that represent the LwM2M object model to allow that unified management.
Compared to "plain CoAP", this limits the scope of what devices can do. Devices can still provide other CoAP functionality on the same server that is not covered by LwM2M. Those limitations allow different vendors to build devices that can interoperate with a different management servers, and LwM2M provides additional specifications for easy deployment (e.g. based on smart cards) that are out of scope for CoAP.
The direct answer can be obtained from the official sites:
CoAP "is a specialized web transfer protocol for use with constrained nodes and constrained networks in the Internet of Things.
The protocol is designed for machine-to-machine (M2M) applications such as smart energy and building automation."
LwM2M "is a device management protocol designed for sensor networks and the demands of a machine-to-machine (M2M) environment. With LwM2M, OMA SpecWorks has responded to demand in the market for a common standard for managing lightweight and low power devices on a variety of networks necessary to realize the potential of IoT."
Basically, we can simplify saying that CoAP was designed to communications between constrained IoT devices and it is very similar to HTTP protocol, which facilitates the developers work, while the LwM2M was designed mainly to manage constrained devices remotely, providing service enablement, for instance. Both protocols are commonly used together.
More information you can find in the following links:
- What is LwM2M? A device management solution for low power M2M
- CoAP functionality expected in a LwM2M system
I found Erlang's 'distribution protocol' outlining the handshake process between nodes here: http://erlang.org/doc/apps/erts/erl_dist_protocol.html
I'm writing my own toy platform and I'd like to make it compatible with others if possible. Is there a common protocol that is widely implemented or do most platforms take Erlang's approach and force you to implement their specific protocol?
I'm not familiar with any common protocols for distributed systems. I know Erlang only supports one 'distribution protocol' out of the box, but of course you can implement your own protocol in Erlang if necessary.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 2 years ago.
Improve this question
Is there any decent alternative to OPC-UA as a solution for accessing process data of a system composed of various PLCs? Something that is platform independent and can "speak" with products of different brands ?
I've heard of MQTT but it seems to be much more like a transport protocol, and only that. It does not have all the higher level stuff like the information modeling, etc.
Thanks for your help!
OPC is the only standard way for communicating with PLCs. OPC DA is the old alternative. OPC UA is the new one and recommended, nowadays. Before OPC there was just proprietary protocols and shared protocols like Modbus, but they are just lower level transport protocols as you've mentioned.
OPC UA is pretty unique with the Information Modeling, especially. With that feature it is enabling new communication possibilities for higher level systems and applications as well, in addition to plain PLC communication.
Note that some PLCs can also talk OPC UA natively, which makes it a standard in that way.
And OPC UA is really standardised as IEC 62541, ensuring that it's independent.
Update 17/07/19: OPC UA is now defined also as the Industry 4.0 Communication as I wrote in my recent article.
Update 20/05/05: OPC UA version 1.04 defines Pub/Sub alternatives, using UDP for secure data multicast in local networks and AMQP/MQTT for secure broker based data & event delivery to cloud systems. Version 1.04 also defines a WebSocket/JSON protocol alternative, which enable easier usage in web applications. None of these are broadly available, yet, but hopefully will become popular in 2020-21 time frame.
OPC-UA has some very interesting parts, especially concerning information modelling, interoperability and the publish/subscribe pattern.
However, even though it's a standard in the strictest of senses, I've found that to use it in a webapp you need to code a gateway server. Because it uses raw sockets and a binary (although fast) serialization protocol.
This is why we created an alternative protocol called Woopsa at my university. We decided to base it on HTTP + JSON. We tried to make a protocol that's similar to OPC-UA: it has Information Modelling, publish/subscribe, and even multi-requests. It's all completely open-source.
We've just released version 1.0 here: http://www.woopsa.org/
You can get the source code directly on our GitHub: https://github.com/woopsa-protocol/Woopsa
Basically, our protocol is just a standardized RESTful API using HTTP+JSON. For example, you can read a value by making a GET /woopsa/read/Temperature and it will reply you in JSON:
{"Value":24.2,"Type":"Real"}
You can also get the object tree by using the meta word, for example: GET /woopsa/meta/ which will give you something like that:
{
"Name":"WeatherStation",
"Properties": [
{"Name":"Temperature","Type":"Real"},
...
],
"Methods": { ... }
"Items": [
"Thermostat",
...
]
}
In a practical industrial application, MQTT is not an alternative to OPC-UA. The original goal of OPC, back in the '90s, was to provide a standard communication mechanism and data model that would provide interoperability among clients and servers that implemented the specification. OPC-UA expands and generalizes the data model and the communication without giving up on that core goal. In order to do this, the standard must specify things like the format of a time stamp, the encoding of data types, historical values, alarms, etc.
MQTT is a message transport layer that does not provide interoperability by design. It does not stipulate the format of the payload, does not specify how one transmits a particular data type, timestamp, value, hierarchy, or anything else that would allow an application to understand the data being transmitted. You can create a valid MQTT server that emits XML, JSON, or custom formatted data that is plain-text, encrypted, base-64 encoded, or anything else you like. The only way a client application can interact with your server is by knowing in advance what data format the server will produce and accept.
OPC-UA has recently introduced a publish/subscribe mechanism to improve bandwidth utilization, reducing a communication bandwidth advantage that MQTT currently offers. At the same time, the MQTT specification will need to grow to specify data formats in order to promote interoperability. Expect to see a convergence of functionality between MQTT and OPC-UA, mostly MQTT growing to meet OPC-UA.
MQTT is a much simpler implementation at the moment, which holds advantages for embedded and resource-constrained systems. The addition of a data modeling specification would act to reduce this advantage.
The bottom line is that OPC-UA is for interoperability and MQTT is for simple custom communication. MQTT needs to grow before it can be an alternative to OPC-UA.
MQTT is growing in popularity as the protocol of choice for I.o.T. It does have its short comings - however its simplicity is often seen as a strength whereas OPCUA carries the overhead of design by committee.
If you need to combine the two, you may like to consider trying our simple gateway mqtt2opcua
Unserver is a product designed to solve the exact problem described in this question.
It is capable of talking to different field devices and provide a unified HTTP API on
top of them.
It integrates with devices via Modbus RTU, but other common protocols will be added in the future.
In short, first you configure a data 'tag' like this:
{
"name": "tank1",
"device": "plc1",
"properties": [
{
"name": "level",
"address": "HR0",
"type": "numeric",
"raw": "int16"
}
]
}
Then you can work with the tag using an API endpoint created automatically:
GET http://localhost:9000/tags/tank1
{
data:{
level: 1
}
}
Check out the documentation for more info.
The product is free for evaluation and non-commercial use.
Disclaimer: I'm part of the team. Hope this is useful.
I just released another approach to this challenge. The project is called ELTRA IoT.
It's cloud service as mediator and end-user components that act as device representation or operator interface (https://www.eltra.ch/)
Primarily, it was created to simplify integration of CANopen devices with smartphone applications, but I quickly realized, that it can be used for any IoT project.
This project is inspired mainly by CANopen and FDT architecture.
The first idea was to deliver the solution, that allows bringing your device into internet using web standards like REST/JSON (avoid binary protocols, gateways, firewall, proxies issues and all this staff, that makes this whole process more complicated) within short time.
Web standard like HTTP/REST/JSON/WebSocket plays well with all operating systems and architectures and allows also easy end-user app integration in any modern language.
Main features:
Same API both sides (device and operator)
CANopen CiA-311 data model representation
Nodes, object dictionary, index, subindex, strong data typing, ranges etc. You know CANopen = you are at home
History data
RPC support - custom commands execution
Simple cloud service API https://eltra.ch/docs
Standard authentication scheme
SSL encryption
Cross-platform solution for Windows, Linux, Android, IPhone, Raspberry PI
SDK is available as open source on Github:
https://github.com/eltra-ch/eltra-sdk
At the moment, the library is implemented in .NET Standard and tested with Windows, Linux (x64 and ARM32), Android, IPhone.
Nuget package is available under:
https://www.nuget.org/packages/Eltra.Connector/
If the complexity of OPC UA is an overkill and Woopsa doesn't fit your design, then ELTRA could be an alternative.
disclaimer: This project is part of my masterthesis and eltra.ch service is my privately held website
While reading an article on LTE, I came across a term "LTE Stack Protocol Development". Sadly, there was no further explanation on the term and when I looked it up on google, it turned up all job openings in LTE protocol development.
So here is the question, what exactly is "LTE stack protocol development" and if possible I would like to learn more about it, could some one point me to some good reading material, it could be a book or website.
Basically, I would like to know "what and how" part for this. By "what" I mean, what all would be required to learn this development and by "how" I would like to know how it can be done/learnt or how it defers from product/application development in industry.
Thanks for your time to go through my question and I apologize if I sound too demanding in the question :).
Look up Protocol Stack on Wikipedia for a discussion of the basic concepts of a protocol stack. Also see the OSI model, which is a standard example.
LTE is a system defined by 3GPP, which is an international partnership of interested companies. There are diagrams of the LTE protocol stack here.
LTE protocols are divided into two sets: the Control Plane, which deals with what you can call "administrative tasks" like registering a phone on the network, tracking its location and setting up a data session. The User Plane contains the protocols that actually carry user data.
The website to which I linked is particularly useful because you can click on the names of each protocol to get links to its formal specification document on the 3GPP website.
To relate the LTE protocol stack roughly to the simple model given on the Wikipedia protocol stack page, look for IP, which corresponds to the Internet layer. Everything below IP corresponds to the LTE protocols for the data link and physical layers.
On Google, you can find books about LTE, which will give you a summary of the 3GPP specifications. These are useful for gaining an overall understanding. Protocol stack development is the process of creating these protocols in code. To do this, you must study the official 3GPP specifications themselves, which you can download from the website.
Not necessarily C, depends where you are going to use this. If it is terminal testing / simulator likes the ones of rhode and schwarz, qualcomm, better off with C++. You need to implement the specs on system level, then it is harware teams job to do the RTL syntehsis and bring it at the hardware level.
As a stack level implementation, is more like software development, if you go below the stack at physical layer, then comes more of an engineering perspective, dealing most things at hardware level.
So be good with C++, a degree in communication systems, electrical engineering, CS focus in Communications etc should be the preferable choice and go through some book related to LTE
Check if you are looking for this
http://www.queryhome.com/27610/protocol-architecture-of-lte-network
Telecom protocols are usually designed using SDL translated from specifications approved by specification committees. The SDL is converted to ASN.1 scripts and loaded in to case tools. The tools generate c code for a specific platform and compiler. A protocol design house usually have a asn.1 stack of the technology that acts as simulator and asn.1 for new protocol stacks.
By "what" I mean, what all would be required to learn this development
Its a big thing to learn the whole LTE protocol stack development and companies have big teams dedicated for this. I will suggest to pick a layer/module and then study the specific of that layer to be able to do anything meaningful.
www.3GPP.org is the site that everyone refers but its very cumbersome.
You can try www.sharedtechnote.com which is written by an engineer and is a good source for Access Stratum aspect of protocol stack.
by "how" I would like to know how it can be done/learnt or how it defers from product/application development in industry.
If you want to see an open source implementation you can goto https://github.com/srsLTE/srsLTE to get an idea about protocol stack development.
As others have mentioned its a big topic to go after "LTE Stack Protocol Development". I will suggest to go and compare the LTE protocol stack with OSI model and then pick and choose one layer e.g. Radio Resource Control(RRC),Radio Link Control(RLC) or MAC layer and then study more about it. Look for 3GPP specification for the same e.g. I will google "3GPP spec RLC" and then go and download relevant spec. Complex to begin but after getting basics right you will be able to develop something meaningful.