Does anyone have already implemented zeroMQ as reliable message solution on cortexM3 nodes? I'm trying to understand if it is possible and to have a memory footprint idea of this. I will have freeRTOS OS maybe.
Thanks for ideas and suggestions.
Nicola
See this thread on the zeromq-dev list. It seems the 0MQ source makes extensive use of POSIX API, so would take some porting to be supported on a non POSIX OS. Moreover it requires a TCP/IP stack which may have a larger footprint that 0MQ itself.
For a port FreeRTOS may not be a good starting point - you'd either have to implement a porting layer to map the POSIX API calls to your RTOS and network stack, or modify the 0MQ source directly (which would make accepting updates problematic).
There are a number of RTOS with POSIX or POSIX-like APIs. Amongst free/open-source RTOS NuttX may be a better bet. It has a POSIX like API and a BSD sockets API stack.
Related
due to the discontinuation of the SL-Thread stack by Silicon Labs, we are considering migrating to OT for a new device in a system that is already based on EFR32s.
The device would be a relatively simple, mains powered FTD (think "range extender").
I am trying to estimate what the effort would be and in particular I am a bit worried about OTA firmware updates.
Looking at the EFR directory in the GitHub repo, I see:
no trace of the Gecko bootloader. Does this imply that we should use a regular Gecko bootloader build from the SL SDK? Or is there a OT-specific bootloader that I'm missing?
no trace of an OTA protocol (in SL'Thread there used to be a TFTP implementation and an dotdot implementation)
Is there any plan to have a OpenThread specific OTA method? Or is the official advice to use the GeckoBootloader and implement your own transfer protocol?
Thanks in advance,
Matteo
Jonathan Hui, tech lead for OpenThread, replied in the Google Group.
Quoting him: "The primary goal of the OpenThread project is to implement the Thread protocol. Given that Thread is a network-layer technology, it does not specify a protocol for OTA. Similarly, the OpenThread project does not include bootloaders and OTA in its scope."
I have lots of experience with the efr32 line of microcontrollers and, incidentally, I'm also attempting to port our Silicon Labs Thread implementations to OpenThread. So I think I can help you here...
If you only need a powered (assuming non-sleepy) full thread device this may not be too much of a problem. You can build the demo projects from the command line (either in Linux or Windows Subsystem for Linux) and just change one of the demo projects to meet your needs.
If you need an IDE build for advanced debugging functionality or just general usability this is much more of a challenge.
The bootloader may be a bit of an issue though. OpenThread is only designed to implement the Thread protocol and is generic so it can be used in a myriad of applications. You won't see any of the Gecko Bootloader stuff there, or any bootloader stuff for that matter.
The Gecko bootloader is essentially an application that runs after a microcontroller reset which looks for a Gecko bootloader image (.gbl) either in external flash or internal flash. If it finds an image it will overwrite the existing application and boot into it. If it doesn't find an image it will just jump to the application. So you're bootloader challenge is 2-fold.
1) The application has to put the .gbl image into the memory location the Gecko bootloader expects. There isn't a standard way to to this as far as I know, it's up to the application. My application, for instance, repeatedly polls a CoAP endpoint to grab chunks of the .gbl image to put in external flash (which is where my bootloader expects the image). Then when it gets the whole image it reboots.
The demo project for the efr32 boards in openthread use a linker script that doesn't include space for the Gecko Bootloader. You'll have to reverse engineer the linking process used in the Simplicity Studio build. It uses 2 linker files as well as some #defines to put the application in the correct location. Depending on your comfort level with the build process this may or may not be difficult.
A note of caution: If you need an migrate an existing Silicon Labs Thread stack based project to an OpenThread project you're in for a beast of a project. The Silicon Labs Thread stack integrates a simple non-rtos based scheduler and sleep functionality. OpenThread, even the efr32 demo projects, contain none of this. Because the Silicon Labs Thread stack is closed source, it makes this much much more difficult. I'm attempting to do this right now an it is very unpleasant. I wouldn't wish it on my worse enemy.
I was looking for workable options available in NS-3 to use and modify light-weight implementation of the TCP/IP (LWIP) protocol suite. So far I have found network simulations cradle (https://www.nsnam.org/docs/models/html/tcp.html#network-simulation-cradle) installation as the only option but I can only see executable stacks for linux2.6.18 and linux2.6.26. There is no executable stack for lwip. I am also having a hard time finding any tutorial online on the usage of lwip in NS-3.
Is there any way to execute lwip stack in NS-3? If not, does anyone know of any other light-weight tcp variant (with limited functionality and small footprint) that can be simulated in NS-3?
Can boringssl work on ARMv8 bare metal platform? I tried build boringssl with aarch64-elf-gcc, but it refused to build.
If it does, any porting guide or suggestions?
Probably not out of the box. But you should probably not even try using it, mainly because, according to Google itself, it is not intended for general use.
This is never good to be on your own when using a library, more specifically a cryptographic one. This is usually synonym for no bug fixes, no support, no user forums among other things.
You could rather consider a library that was designed for this purpose, such as mbedtls (formerly known as PolarSSL).
It is being used on a wide range of systems, from bare-metal systems (FreeRTOS) to Linux (The Hiawhata web server does use it for example).
Update: Even if support for Armv8-a hardware crypto extensions is needed, you could still reuse BoringSSL Armv8-a optimized routines (ISC license) or the Cavium armv8_crypto library (BSD license), to replace mbedtls (Apache 2.0 lisense) equivalent routines: cryptographic functions usually have clean and small interfaces.
From my experience, this may still be faster than porting a library targeting a general purpose operating system if your target is a bare-metal one, but you ultimately have to evaluate the costs for both options in your specific case.
My guess would be that there is far less work involved for adding support for Armv8-a crypto extensions to mbedtls using already existing, supported code under the proper license, than attempting to strip-down openssl or boringssl for use on a bare-metal target.
There is a very good piece of documentation explaining how to add support for hardware-accelerated crypto to mbedtls here, this may help you evaluating your options.
I would like to work on Weave but I noticed that Nest has open sourced Openthread instead. I would like to get my hands dirty with Openthread but if someone can answer these questions for me I would really appreciate that.
Is one preferred over the other for certain applications. If so, what are they?
Will devices running Openthread be directly compatible with ones running Weave?
Will these devices be able to communicate with Android devices as is or is future support in Android being planned?
What soc's or emulators can I test Openthread on?
Thanks in advance!
First Question
Succinctly, in terms of the OSI model:
Thread is a network technology that defines layer 2 (link-layer) and layer 3 (network-layer). Thread gives your embedded device IPv6 interface with some nifty capabilities, such as fault-tolerance, mesh networking, and low power consumption.
Weave is (for the most part) a layer 6 protocol, like CoAP or HTTP. It is a protocol that applications running on embedded devices can use to communicate with each other. It requires an IPv6 network interface, which could be provided by ethernet, Wi-Fi, or Thread.
It is important to differentiate OpenThread and Thread. OpenThread is an open-source implementation of the Thread standard.
Both technologies are designed to be used (albeit in different ways) in residential settings on the following loose categories of embedded devices:
Embedded devices that need to be able to reliably communicate with each other under adverse conditions, like a power outage or a fire.
Battery-operated embedded devices that need to be able to last for many years without changing or recharging the battery.
Sensor networks for monitoring things like temperature, motion, humidity, etc.
Second Question
The implication of your question is that the two technologies are mutually exclusive, or that they somehow solve similar problems. As the cute naming implies, Thread and Weave are complementary technologies. Weave needs a network interface to communicate with other devices, and Thread provides one.
Thread is like Wi-Fi in this way. Wi-Fi doesn't define the protocols that run over it. For example, just because a smart thermostat and a smart light switch have Wi-Fi radios doesn't mean that they can communicate with each other. It will be a similar situation with devices that have Thread-compatible radios.
Third Question
While there is no particular reason why you would not be able to use Thread or Weave (or both!) to communicate with devices running Android (or any other operating system), the the devil is in the details: there is no one-size-fits-all solution.
That being said, one way is to use IPv6 routing: Thread is based on IPv6, so if you have a Thread border router, you can allow devices on a Wi-Fi network to directly communicate (via IPv6) with devices on the Thread network.
Fourth Question
In addition to the POSIX simulator, the CC2538 is now an officially supported hardware platform. Support for Dialog's SmartBond™ SoC family of chips is currently provided directly by Dialog.
it might help to first better understand Thread and what it is trying to solve. Designed for the home, Thread is an IPv6 networking protocol built on open standards for low-power 802.15.4 mesh networks that can easily and securely connect hundreds of devices to each other and the cloud. This is different than Weave, which is an application protocol. Multiple application protocols can be developed on top of Thread, including Nest Weave. The Thread Group has a nice technical overview of Thread on their site.
Now to your specific questions:
You should use OpenThread if you're looking for an open source low-power, ipv6-based mesh networking protocol to build upon for your home connectivity application protocol
That really depends on what you mean. Any application protocol built on Thread should be compatible at the network layer with OpenThread, assuming they are targeting compatible versions of Thread.
One of the key design goals of Thread is being able to allow the Home Area Network to reliably communicate to the cloud through Border Routers. We demonstrated an Android app controlling a Thread end device from a Android. Here is a video.
You can find a CLI simulator in the /examples folder. At the time of this writing, OpenThread is still rather new - however we expect to see various SoCs officially supported from our silicon launch partners. Watch the repo for more updates.
I'm writing software for a new hardware device which I want any kind of new third-party application to be able to access if they want to.
The software will be a native process (C++) that should be pollable by 3rd party games and applications that want to support the hardware device. Those 3rd party apps should also be able to receive events from the native process, on a subscribe basis. So aside from the native process, I'll also supply "connector" libraries to the 3rd party developers, for all platforms/languages that they might choose (Java, C++, Python etc.) to embed in their apps so they can easily connect to the device with hardly any extra code needing to be written by them. I want to target all desktop/laptop OS platforms, and have a pretty good idea of what functions I want to expose, but ideally I don't want to be too stuck (i.e. I want it to be elegantly scalable from both client and server perspectives).
I'm looking for reliability going forward, performance, maintainability going forward, and cross-platform/language flexibility going forward, and ease of development, in that order.
What should I use?
CORBA, MessagePack-RPC, Thrift, or something else entirely?
(I've omitted ICE because of it's licensing)
Thrift or Message Pack is the best option going forward. Both are sleek, light weight and do not add much latencies to your process. They have support for most of the common languages, and are in Active Development. At the current stage I would prefer thrift personally but message pack does seem to promise a lot of features.
Thought thrift might not be as windows friendly as we want but people are using it on windows.
This is a starter guide for thrift on windows.
http://wiki.apache.org/thrift/ThriftInstallationWin32
Only installing and getting the Thrift compiler can be troublesome on windows. Using the generated files depend on the language you choose and lot of the languages have good support to run the files by importing thrift libraries. (Java it is very easy, MAVEN artifact)
There is a discussion on the RPC frameworks available at RPC frameworks available?
CORBA according to me is old cumbersome and very heavyweight.
If ancient and heavyweight don't put you off, obsolete definitely should. Regardless, I can tell you what we've been using Google Protocol Buffers at work recently, and they're pretty easy to use.
From the developer's perspective, all you need to do is have a build of GPB (which really isn't that difficult), and then it will generate source files for you. The end result is a cross-platform binary message transport message passing interface (think XML and limited RMI, not MPI-like functionality).
We use it on Windows to talk to an Arm-based Linux system (TS-7200's from embedded arm) running the same software. to my knowledge, it is compatible with many languages.
CORBA is the only free "RPC" thing that would work for my system right now, even though it scales very badly. Thrift isn't Windows-friendly yet. Neither is MessagePack-RPC yet available in all languages and OSs, even though it's still in development. If CORBA was elegantly scalable it probably wouldn't have become obsolete at all.
Protocol Buffers and messaging would work, I'd have to develop a both a client and service implementation for every platform/language. It would also be very scalable. I've decided on this.
I'm currently using Apache Thrift for a Hospital Manager project. It is better than CORBA in many areas, not to mention it is lightweight and much easier to implement and understand. The learning curve for Thrift is definitely subtle compared to CORBA, but the documentation for Thrift is the worst thing.
I'm using a Ruby Thrift server to which Obj-C and Java clients connect. The Thrift parser or "compiler" does a pretty good job generating source files for the languages you want, although it is far too verbose. I would definitely look into implementing Thrift, or Google ProtoBuffs if I was starting a new project, since CORBA is really outdated, and might not implement new technologies in the future, not to mention that there are many vulnerabilities and exploits targeting CORBA that will not get patched since it's not in development anymore, presenting some serious security holes on your new project.
Thrift supports many programming languages: C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Objective-C, JavaScript, Node.js, Smalltalk, OCaml and Delphi as of this writing. Supporting multiple languages is key, I think, for the purpose of your project.