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.
Related
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 noticed that there's a recent released apps that enables Raspberry Pi to run a deployed LabVIEW program all by itself and to set the program run as RPi boots. Since I was planning to remotely control the LabVIEW program through the internet using a Web UI, is it possible to setup a webservice of the program on the RPi? By the way, I'm currently planning to use RPi 2 for my project.
If I am getting you right you are about LINX at Makers hub: https://www.labviewmakerhub.com/doku.php?id=blog:users:makerhub:2016-04-07-linx-3
It is open source, free tool. You are free to modify and it and add custom command on LINX Firmware as I understand. After that, you can call LabVIEW Custom Command vi which is part of the API.
You can have a look on all API VIs here: https://www.labviewmakerhub.com/doku.php?id=learn:libraries:linx:reference:labview:start
From the discussion thread here:
We're running the LabVIEW Runtime on the target just like we do on our Linux based RIO devices. The great thing about using the full runtime is that you get the standard LabVIEW expereince with interactive mode, highlight execute, probes, startup executables, etc. This also means that all of the core LabVIEW functionality will work. One way to think about it is anything that works without explicitly installing it on the target from MAX should work on BBB/RPI. We actually don't plug into MAX at all. We currently do not support any toolkits or modules, but we've been experimenting with a couple to see what it would take to support things like web services.
So native LabVIEW web services aren't available yet, but may be coming soon - I'm sure development is responsive to what people ask for, so go to that discussion thread and let them know your interest.
You might be able to 'roll your own' simple web service using the TCP VI's, which as far as I can see should be available on the Raspberry Pi.
Note that deployment to Raspberry Pi or (BeagleBone Black) is only licensed for noncommercial use, as stated in the same thread.
I'm interested in PC firmware programming, and am just studying the UEFI spec. To my surprise, it seems like a spec for an entire OS which is embedded in firmware. You can even write UEFI "applications", which run directly using the UEFI boot services, without any other OS present.
I've found blog posts which show how to create a "Hello, world!" application which can run in the UEFI preboot environment. This is... interesting, and bizarre at the same time. I'll run my "Hello, world" programs on a regular OS, thank you.
What kind of use cases are UEFI applications actually good for? Fancy boot configuration screens? Does any "real", commercially available PC firmware use UEFI applications to implement anything more than just boot loaders and boot configuration utilities?
Anything that isn't PEI/DXE/SMM core or driver is an application, so any "real" PC have them, because BIOS Setup is actually an UEFI application. Some vendors include various other apps like firmware updaters, diagnostic and troubleshooting utilities, etc. UEFI 2.4 makes possible to add your own application with a properly filled BootXXXX/KeyXXXX variable pair and then run it by pressing a key combination during POST.
Most console applications written in C can be compiled as UEFI application by using StdLib package of current EFI Development Kit and then run in UEFI shell.
Major examples of useful UEFI apps (besides bootloaders, shell and Linux kernel, of course) are Intel ME System Tools, Read Universal, Python 2.7 and many more.
Eventually, when legacy boot will not be available anymore, all currently useful DOS utilities must either be made UEFI applications or go extinct.
Despite many valuable answers here, because I wrote couple UEFI applications myself I will try to add my 2 cents. First, what is UEFI application to just give ground what we talking about:
UEFI Specificatin v2.5:
Section 2.1.1
The major differences between image types are the memory type that the firmware
will load the image into, and the action taken when the image’s entry point exits or returns. An
application image is always unloaded when control is returned from the image’s entry point.
Section 2.1.2
When the application returns from
its entry point, or when it calls the Boot Service EFI_BOOT_SERVICES.Exit(), the application
is unloaded from memory and control is returned to the UEFI component that loaded the application.
Groups of applications that make sense in UEFI:
Configuration tools - Configuration interface for Option ROMs (ie. for storage controllers), out of band management (ie. AMT configuration tools), manufacturer performance tweaking tools
Provisioning tools - used by administrators to preload specific BIOS setting, manually setting all options in BIOS setup would be inefficient
Diagnostics tools - mostly for tests that cannot be performed in OS (DRAM tests, full storage scan, storage R/W tests, etc.). In some districts specific diagnostics tools are required in UEFI BIOS, so those can be sold to government.
Security applications - HDD encryption/decryption, antivirus scanner and anti thief applications
BIOS capability enhancement - Power Over Ethernet extensions, DRAM discovery, patching and modification of system tables (SMBIOS, ACPI)
Display tools - for displaying complex animations while running, splash screen displaying
Bootloaders - this is special type of application, which can call EFI_BOOT_SERVICES.ExitBootServices() causing termination of all memory management and passing control to Operating System.
Note that very important feature of UEFI application is that it can be added to boot order and be executed each boot time. Also UEFI application do not have to be delivered with BIOS image it can be stored in connected device memory, which is common for Option ROM configuration tools.
Here it is an example of a full blown UEFI Pre-boot Application;
There are SED SSD/HDD drives. As soon as SSD/HDD loses its power it goes into locked state (hardware-based encryption) There is no way you can get access to drive's data and all partitions on the drive are no longer even visible. Only small read-only partition (ShadowMBR) is available. UEFI firmware boots an UEFI application from that only available partition (UEFI app is written on that partition during the initialization process and when the ownership of an SED is taken). It securely authenticate user and if credentials are valid it unlocks the drive. When the drive is unlocked Shadow MBR disappears and all partitions on the drive becomes available. Then the App chain-boots the installed OS.
So if you don't have credentials you cannot even boot the OS and you cannot access the data on the drive by any means.
Here's a couple of examples:
https://github.com/NikolajSchlej/CrScreenshotDxe
UEFI DXE driver to take screenshots from GOP-compatible graphic console (yes, you can make PNG screenshots of your BIOS and save them)
http://ruexe.blogspot.com/
RU.EFI is quite an advanced tool for debugging the BIOS
Well, there are the OS loaders - both the more heavyweight ones (Windows, GRUB, BSD Loader) and the "present a menu" ones (rEFInd, Gummiboot). Shim, which enables UEFI Secure Boot for Linux platforms, consists of an application as well as installing a protocol for use by other applications.
Then you have things like the Linux kernel, which when compiled with CONFIG_EFI_STUB becomes a valid UEFI application, with the awareness of booting itself.
And firmware updates can also be shipped as UEFI applications.
The UEFI shell itself is an application.
Then there are things like factory production testing utilities, development diagnosis tools, ...
Windows 7 - 8 have UEFI installer. I'm not fully aware of the details, but I'm pretty sure this new environment gives a lot more flexibility to the developers than traditional boot environment on DVD.
Some motherboards have "instant on" features that allows you to get to a desktop screen within a few seconds. This is usually a stripped down flavor of some linux that allows you to access a web browser and play music/video. ASUS have such boards.
All,
I'm attempting to estimate the effort to port an app developed on Windows (.NET) to Linux (Mono). I came across the MoMA tool, which attempts to look through my .exe and find potential areas of incompatibility. Most of my issues appear to be centered around get/set of network settings, getting network info, etc. (Object ManagementBaseObject.get_Item and set_Item. etc).
In almost all of the cases, the Mono functionality is listed as "ToDo". For estimation purposes, is it safe to assume most/all of these have some kind of workaround? I would imagine this type of basic networking support must be included in the latest version of Mono. Or should I assume none of this is currently available and I would be stuck waiting for it to be implemented (or be forced to implement it myself)?
Thanks,
Dan
First,see Mono Compatible Networking/Socket Library. Also,take a look on Cross-Platform Network Applications with Mono. You can start with C# Network Library.
I have been tasked with writing a USB driver for our embedded software to send raw data to Host. This will be used to send some logging data to host. We are using iMX31 litekit for development.
From the documents that I have read on USB, my understanding is that the embedded device will be in device mode only. Also it will only be communicating with host machine.
So can any one guide me here? Any article, reference or code is welcome.
Some things to consider:
Is this a high bandwidth device like a camera or data recorder, or a low bandwidth device?
For low bandwidth, I would strongly consider making your device act as a USB HID class. This is the device class that supports keyboards, mice, joysticks, gamepads, and the like. It is relatively easy to send data to nearly any application, and it generally doesn't require that you write a custom device driver on the host side. That latter feature alone is often worth the cost of lightly contorting your data into the shape assumed by the HID class. All the desktop operating systems that do USB can use HID devices, so you get broad compatibility fairly easily.
For high bandwidth, you would still be better served if your device fits one of the well established device classes, where a stock device driver on the host end of the wire can be used. One approach that often works is to use the Mass Storage class, and emulate a disk drive containing one file. Then, your device simply mounts on the host as if it were a disk, and you communicate by reading and writing to one (or a few) file.
I would expect there to be a fair amount of sample code out there for any serious USB device chipset that implements either or both of HID and Mass Storage.
If you really must wander into fully custom device territory, then you will need to be building device drivers for each host platform. The open source libusb library can be of some help, if its license is compatible with your project. There are also ways in newer versions of Windows to develop USB drivers that run in user mode using the User Mode Driver Framework that have many of the same advantages of libusb, but are not portable off the Windows platform.
The last custom device I worked on was based on a Cypress device, and we were able to ship their driver and an associated DLL to make our application code easier to build. I don't know off the cuff if there is any equivalent available for your device.
For a really good overview, I recommend the USB FAQ, and the latest edition of Jan's book, USB Complete.