Updated Platform Objects
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.frequency — This property — which supersedes beep.divider — defines the frequency that should be used, from 30Hz to 20KHz
- 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, except for 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 only 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.
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 (pwm.num and pwm.enabled), define the duty cycle and frequency of the modulation for each channel (pwm.dutycycle and pwm.frequency), and update their state (pwm.update and pwm.updateall).
All properties and methods of the ser. object function exactly as they did in previous implementations. However, supported baudrates are now:
The default baudrate — 9,600 — is used if a supported rate is not specified.
On the WM2000, the sys. object has two new methods, three new properties, and two new event handler.
The sys.reboottoapp method is a single-use reboot of the system to the specified compiled Tibbo BASIC/C application binary.
The sys.sleep method "wakes" the device from a low-power state at a specified date and time, which is provided via three parameters for days, minutes, and seconds since 1-JAN-2000 (see the rtc. object). If improperly configured, the device might not wake up at the desired time. 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 BLE console of the Monitor/Loader (M/L) or the companion app to enable wln.autoconnect.
The sys.defaultapp property sets the default application binary that the device should load when booting up.
The sys.timercountmse read-only property returns the amount of time (in milliseconds) that has elapsed since the device was powered on.
Due to a new and improved implementation of DHCP on the WM2000 (see below), the on_sys_dhcp_ok and on_sys_dhcp_failure event handlers replace the various callbacks used by the DHCP Library. Note that while the new DHCP implementation is the preferred method of automatically acquiring an IP address on the WM2000, the DHCP Library remains compatible with the platform.
As the WM2000 is the first Tibbo embedded module with integrated wireless capabilities, the wln. object naturally saw significant changes. Likewise, 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, when enabled, the module will automatically attempt to associate with a preconfigured Wi-Fi network, maintain the connection, and reconnect if disconnected.
wln.autoconnect must be enabled for wireless debugging to be possible.
The wln.autoconnectssid and wln.autoconnectpassword properties provide the desired Wi-Fi network's SSID and password, respectively. The device must be rebooted after altering either property for the changes to take effect.
Prior to the WM2000, Tibbo devices implemented a DHCP client through the DHCP Library. The WM2000 allows you to delegate DHCP operations to the internal process of TiOS, significantly speeding up the procurement of an IP address. The wln.dhcp property enables this "internal DHCP," replacing the functions of the library.
When wln.dhcp is enabled, the module starts the DHCP process before your app launches, helping your device acquire a valid IP address and shaving additional milliseconds off the wait for IP address procurement. This means that your app will be ready to perform its network-related tasks even sooner!
If not already enabled, wln.dhcp will be enabled automatically by calling wln.autodhcp, which still requires handling DHCP callbacks and is mostly backwards-compatible with the 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.
Alternatively, the DHCP Library can still be used with the WM2000, but wln.dhcp and wln.autodhcp must be disabled.
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 when wln.autoconnect is disabled, wln.networkstart — which also turns on DHCP — is only available after wln.boot has been called.
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.
Unchanged Properties and Methods
These properties and methods of the wln. object function mostly as they did in previous implementations:
- wln.getmoduletype — now immediately returns the module type
Properties and Methods Made Unavailable or Unnecessary by wln.autoconnect
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.
Unavailable Properties and Methods
These properties and methods of the wln. object are not available on the WM2000: