Several traditional platform objects have changed for the WM2000, and an entirely new object was also created. The changes and addition are summarized below.
beep.play — Functionality remains exactly as in previous implementations, with beep.frequency now defining the frequency to be used
All properties and methods of the bt. object function exactly as they did in previous implementations, with the exception of bt.mac, which is now read-only.
There is also no longer a need to call wln.boot to initialize the Bluetooth hardware if wln.autoconnect is enabled.
The sole addition is the bt.disconnect method, which can be used to forcibly break a Bluetooth connection.
All properties and methods of the fd. object function exactly as they did in previous implementations. However, raw sector size now totals 528 bytes, compared with 264 bytes previously, while the total amount of storage has increased to 4MB (4,096KB).
It's important to note that all files stored on the WM2000 must be 4KB-aligned. This means that when using methods like fd.copyfirmware, you must calculate the next 4KB block when adding files. For example, if APP0 occupies 126KB of storage, APP1 should begin at the 128KB block.
For your convenience, we have updated BinMerger to support multi-app systems such as the WM2000. The updated web app allows you to merge TiOS, APP0, and APP1 into a single binary file that you can use for firmware updates, vastly simplifying the upgrade process. The older BinMerger utility for Windows, however, does not support multi-app systems.
pwm. Object (NEW)
The WM2000 is the first Tibbo embedded module to feature native pulse-width modulation (PWM) capabilities.
The pwm. object allows you to map and enable PWM functionality to specific GPIO lines, define the duty cycle and frequency of the modulation, and update the PWM channels' state. On the WM2000, PWM functionality can be enabled on GPIO lines 0 through 8 (pins 1 through 9).
All properties and methods of the ser. object function exactly as they did in previous implementations. However, supported baudrates are now defined as 110, 300, 1,200, 2,400, 4,800, 9,600, 19,200, 38,400, 57,600, 115,200, 230,400, 460,800, and 921,600. The default baud rate, 9,600, is used if a supported rate is not specified.
On the WM2000, the sys. object has two new methods and three new properties.
The sys.reboottoapp method is a single-use reboot of the system to the specified app space. It takes one parameter, an enum that can be either PL_APP0 or PL_APP1.
The sys.sleep method "wakes" the device from a low-power state at a specified date and time, which is provided via three word parameters for days, minutes, and seconds in relative terms (see the rtc. object). If improperly configured, the device might not wake up at the desired time.
The above diagram illustrates the circuitry for the low-power state, with the squares representing either MOSFETs or power distribution switches (Tibbo's design uses the SIP32408). When the LP line is HIGH, supply to the VCC line is ongoing and the system operates normally. When the LP line is pulled LOW, supply to the VCC line is interrupted and the system enters a low power state. The WM2000 will wake from this state after receiving input from sys.sleep to pull the LP line HIGH and restart the system. Note that waking from the low-power state does not "resume" operations, but is instead a full reset of the system.
The sys.debugmode property determines whether the device uses the serial or wireless interface for debugging. It takes one parameter, the enum pl_sys_debug_mode. Note that you will be unable to debug if you set this property to PL_SYS_DBG_NET without enabling wln.autoconnect. In such a case, you will likely need to reset settings or use the Monitor/Loader (M/L) console to enable wln.autoconnect.
The sys.defaultapp property sets the default application binary that the device should load when booting up. It takes one parameter, the enum pl_app_num.
The sys.timercountmse read-only property returns the amount of time (in milliseconds) that has elapsed since the device was powered on.
As the WM2000 is the first Tibbo embedded module with integrated wireless capabilities, the wln. object saw significant changes. While the functions of many properties and methods remain the same, their use is now situational.
On the WM2000, the wln. object has five new properties. The most important addition by far is wln.autoconnect, which significantly simplifies the configuration, management, and implementation of Wi-Fi connectivity for devices. This property is read at boot and determines whether the Wi-Fi module is to power on. When wln.autoconnect is enabled, the module will automatically attempt to associate with a designated Wi-Fi network, maintain the connection, and reconnect if disconnected. Note that wln.autoconnect must be enabled to enter Wi-Fi debugging mode.
The wln.autoconnectssid and wln.autoconnectpassword properties are needed to provide the desired Wi-Fi network SSID and password, respectively. After altering either property, the device must be rebooted for the changes to take effect.
The wln.dhcp property replaces the functions of the DHCP Library and is enabled automatically by wln.autodhcp, which still requires handling of DHCP callbacks and is mostly backwards-compatible with the DHCP library, but is more specific about parameters.
When wln.autoconnect is disabled, wln.dhcp must be called before wln.boot to enable DHCP functionality in the traditional Wi-Fi operating mode.
On the WM2000, two methods and two properties of the wln. object have changed from previous implementations. The wln.networkstart and wln.networkstop methods are not available if wln.autoconnect is enabled. Even then, wln.networkstart is only available at boot and requires that wln.dhcp be enabled to function.
The wln.domain property is now a setting and requires a reboot for changes to take effect. The list of values has increased to accommodate most major regions and countries.
The wln.mac property is now read-only — it only returns the device's MAC address. The MAC address can now only be changed in Device Explorer like an Ethernet device, meaning that Wi-Fi debugging is required.
These properties and methods of the wln. object function mostly as they did in previous implementations:
wln.getmoduletype — now immediately returns the module type
These properties and methods of the wln. object are not available or unnecessary if wln.autoconnect is enabled — attempting to call them will result in a return of REJECTED. If wln.autoconnect is disabled, then these properties and methods will function exactly as they did in previous implementations.
These properties and methods of the wln. object are not available on the WM2000: