Release 30 is a major update to the impOS™;. It addresses a number of reliability and compatibility issues, in particularly around WiFi which also benefits from being brought right up to date with with the latest Broadcom firmware. For example, WiFi module crashes are now managed behind the scenes so they are now invisible to the user, imps are happier connecting to multi-access point networks, and transient captive portal pages — for example, “the Internet is not available” — are now dealt with correctly.
Once again, we’ve made a number of under-the-hood improvements to BlinkUp™ to ensure the process is even more robust on Android-based devices. The technology now supports the widest-ever range of Android phones and tables.
For developers and manufacturers connecting imps to external components, we have considerably enhanced the imp’s support for SPI, I²C and UART buses, and augmented its GPIO options. A number of these changes will make it much easier — and, in some cases, possible — to implement less mainstream buses, such as DMX and RS485.
Release 30 also marks the first version of the imp OS to support the new imp003 (Murata LBWA1ZV1CD) module.
hardware.pin1.configure(DIGITAL_OUT, 1)
or hardware.pin1.configure(DIGITAL_OUT, 0)
.In addition to a variety of new features and enhanced or updated functionality, imp OS release 30 addresses a number of bugs.
base
as a variable name are now correctly reported as an error and no longer cause Squirrel to crash.false
, BlinkUp is now correctly disabled in all circumstances. Note that BlinkUp is always enabled for the first 60 seconds after a cold boot.A key development incorporated into imp OS release 30 is the addition of support for the new imp003 module, Murata part number LBWA1ZV1CD. The imp003 — you can view more information about this component by taking a look at its datasheet — gives hardware developers a much-expanded array of GPIO options: five separate UART, two I²C and two SPI buses.
To accommodate these options, it has been necessary to adopt an alternative nomenclature for the imp003’s pins; release 30 is the first public version of the imp OS to support this new pin naming scheme, full details of which can be found on the pin mux page. imp001 and imp002 pins will continue to be addressed as they were before.
The imp003 also gives developers the opportunity to use space in the system’s SPI flash storage, which in imp003-based devices is separate from the module itself. Release 30 therefore includes a new API extension to read data from and write data to the SPI storage, and to perform sector-level erasure of the storage as required by NOR flash’s write architecture. These and other methods are made available through a new imp API class, Spiflash, which is instantiated at start-up as the object hardware.spiflash.
The imp003 is designed to be accompanied by between 512KB and 16MB of SPI flash. However much flash is connected to the module, the first 448KB are always reserved for the system, giving each imp003 at least 64KB of flash for the developer to use, typically for information to be accessed by the device software, such as device configuration data.
For manufacturers of imp-based products, the imp003’s WiFi radio can be set at blessing with the regulatory region in which it is going to be sold, in turn specifying the number of of 2.4GHz WiFi channels it can use. This allows manufacturers to develop a single, ‘worldwide’ product and tailor it during production for a given market. The region can’t be changed after the unit has left the factory; this facility is only available to factory firmware. Manufacturers who have worked directly with the WiFi silicon vendor can also install custom WiFi NVRAM settings at blessing time.
An issue with a third-party library used by impOS causes imp.scanwifinetworks() to leak memory. Repeated use of imp.scanwifinetworks() will drain the imp of available memory even though calls to imp.getmemoryfree() show that there is plenty of memory free for use. When the imp runs out of available RAM, it will reboot and log ‘out of memory’ as its wake reason. The leaked memory can only be made accessible again by forcing the imp to restart: either power-cycling the device physically or by calling imp.deepsleepfor() with 0
as its parameter.
The issue has been fixed and will be implemented in a future release of impOS.
WiFi networks with a 32-character SSID are known to prevent impOS 30 (and earlier) from connecting. A fix for this issue will be implemented in a future impOS release.