Electric Imp versions impOS™ releases as follows: odd-numbered major versions are pre-releases and even-numbered major versions are production-quality releases. As such, impOS 36 builds heavily on impOS 35, which was not released publicly. For information on changes and bug-fixes implemented in the various minor releases of impOS 35, please see the relevant release notes. This document will focus on changes made following the release of impOS 36, and upon new features introduced in impOS 35 but made public for the first time with impOS 36.
Current release is 36.14 (changes)
impOS 36 delivers public support for the imp004m, a new Murata-manufactured low-cost imp module that supersedes the now deprecated imp002. It incorporates full GPIO and peripheral bus support, an integrated WiFi antenna, and code compatibility with existing imp applications. For a fuller discussion of the imp004m’s capabilities, please see the guide ‘Designing Hardware with the imp004m’ and the imp004m pin mux.
The imp005 is able to support both wired and wireless connections. However, many customers require the flexibility to chose to support just one network mode, and impOS 36 supports their choice. It detects when either mode has been omitted from the hardware design — no Ethernet PHY or WiFi antenna included — and will only make use of the available mode. This ensures that WiFi-only products no longer check for an Ethernet connection, and Ethernet-only products do not cause unwanted radio emissions and will save power by shutting down the WiFi sub-system.
Note The latter requires specific NVRAM settings to be applied.
The imp005’s USB sub-system now supports Interrupt In endpoints, which provide a means for a connected device to signal the host that it needs attention. This allows customers to build more sophisticated USB support into their imp005-based applications. The imp005 can be set to poll the interrupt endpoint periodically at a rate set by a new parameter that can be passed into the existing imp API method hardware.usb.openendpoint().
The imp005’s GPIO pins E, F, G, S, U and V now provide PWM support.
impOS 36 adds to the device cryptography functions that were previously restricted to the agent, allowing applications to incorporate tougher security for directly connected peripherals. These functions are delivered by the new imp API crypto object, a property of the imp object. The crypto object includes methods to perform 256-bit SHA hashing and 256-bit HMAC-SHA hashing, plus a comparison method which allows two SHAs to be compared in constant time. This latter method allows a user to check a received HMAC without letting the correct value be deduced by timing the comparison operation.
Please note that there are some performance considerations that you should be aware of before deciding whether to implement these device-side imp API methods.
impOS 36 includes two new imp API methods to store and retrieve up to 4KB of user data within the host imp’s Flash, whether on-die (imp001 through imp004m) or encrypted off-die storage (imp005). This provides developers with more storage options, and enables them to better match applications’ data storage requirements to the available capacity and level of data persistence.
The data stored here will be retained until it is actively overwritten. It will persist across both warm and cold starts (unlike the nv table), and is not dependent on an Internet connection (unlike server.save()). The data is also retained across BlinkUp™, application changes and the blessing process. Methods such as imp.clearconfiguration() will not clear the user data.
While the imp Flash storage user data space is primarily intended to be run in the factory to save data for use by the device during its lifetime — Flash has a finite write capacity — impOS’ implementation of the Flash code provides a minimum lifespan of at least 60,000 writes though users should be able to make significantly more writes than this.
For customers building products which need to start up almost instantaneously, impOS 36 introduces a new ‘fast start’ mode. This overrides the standard cold-start behavior: the application starts immediately and no attempt is made to contact the server until the Squirrel code explicitly asks to do so. This is essential for products that need to respond immediately to end-users, such as lighting and physical security applications.
This mode is selected using the new imp API method imp.setrescuepin(), so named because the process requires you to nominate a pin to which a rescue button should be connected. This button, if pressed during a device restart, forces a temporary reversion (this boot only) to standard cold-start behavior: attempt to connect to WiFi and check for new application code, with a ten-second timeout. This ensures devices have a means to download essential application code updates which would otherwise be ‘hidden’ by the fast-start mode. If the button is not pressed, the device will fast start.
impOS 36 add a new method, configurewps() to the imp API net object, a property of the imp object. It activates WiFi Protected Setup (WPS) for all subsequent connection attempts, including those which take place after a cold boot. This supports customers who want to radically simplify product set-up: they can now pre-enroll their products to provide out-of-the-box automatic wireless access. Once the imp has contacted the target WiFi router and retrieved the wireless network’s credentials (SSID and password), WPS is disabled and the PIN, if present, cleared. The network’s credentials are stored for all future connections.
impOS’ WiFi connection management now takes place separately from Squirrel operations, with the result that attempts to initiate or restore network connections will not interfere with time-sensitive application operations, such as audio sampling via sampler().
The existing imp API method imp.scanwifinetworks() has been updated in impOS 36 to operate asynchronously: the scan can be made in the background, allowing Squirrel to continue with application operations in the meantime. A callback is executed when the scan is complete to return the results.
If an imp is connected to a WiFi network, imp.net.info() now reports the connected network’s SSID in addition to the SSID that is stored in the imp’s configuration page. These SSIDs may not be the same — for example, if the latter has been changed by the application code but the imp has not yet reconnected.
impOS 36 provides a simple call, imp.info(), to return a string identifying which specific type of imp is running the application code: "imp001", "imp002", "imp003", "imp004m" or "imp005". This helps customers more easily migrate products from one imp to another, by allowing them to create a single application codebase that adapts to imp on which it is running. The existing imp.environment() continues to indicate whether the code is running on device or agent.
Please see the central Known Issues page.
imp.clearconfiguration(CONFIG_WIFI) (regression in 36.11).