Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Functions
System functions (time, random numbers)
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Mono Wireless C++ Library for TWELITE.
Please refer to the Handling of Materials section. If you have any questions or concerns, please contact our support desk.
This page contains information that is still under development. The contents of this page may not yet be reflected in the public source code.
The MWX library is intended to simplify the code notation of the TWELITE radio module. a program created with MWX is called an act. There are two types of acts: descriptions by loops and descriptions by events (called BEHAVIOR).
This page introduces the main features of ACT.
Description by loop (setup()
, loop()
). Suitable for writing small-scale functions.
Event-driven application description. It is possible to define various event and interrupt handlers, as well as a state machine within a class that is suitable for describing complex behavior of the application, and write code with good visibility. This description is called BEHAVIOR.
Simplify peripheral procedures. Defines class objects to handle commonly used UART, I2C, SPI, ADC, DIO, timer, and pulse counter.
A simple relay network is defined. This relay network is implemented in the same way as the TWELITE standard application, and is characterized by the fact that individual addresses are managed by 8-bit logical IDs, and that wireless packets can be sent to the network immediately after power-on because there is no communication to build the network.
Although it does not allow for packet intercommunication with TWELITE standard applications, it does allow for more flexibility in the following areas
The logical ID is the same in that 0 is the parent device, but since 0x01..0xEF can be used as the child device address, the number of identifications can be 200 or more.
As a rule, the maximum number of times a packet can be relayed has been set to 64 times. (* If a packet returns after a certain period of time due to a detour, the duplicate packet management table will be cleared and the packet may have to be relayed again even if it has already been relayed. (Be careful when setting a large number of relays.
Board definition for PAL and MONOSTICK. Easy handling of sensors etc. on the board.
Minor corrections will not be listed in this revision history, but only in the revision on GitHub. Please cite corrections as necessary.
After the release of the TWELITE STAGE distribution package, fixes and additions are stored in the GitHub repository. Please replace the location of the distribution package if necessary.
Other updates to the MWSDK may be required. Please refer to the release description at the time of the update; see here for information on updating the MWSDK.
The source code of the library is available on GitHub (https://github.com/monowireless/mwx). To replace the source code of the library, please follow the steps below.
Click on the link for each release to clone the Git file or download the source code in zip format.
Replace the contents of the following folders.
Updated information prior to major releases may be posted on the above link.
changed Wire object that reserves memory in heap area.
changed function name from G_OCTET()
to G_BYTE()
](api-reference/funcs/utility/byte-array-utils.md to avoid name conflict in utils.h.
changed an order of vAHI_DioInterruptEnable()
in the attachIntDio()
for code efficiency.
added secondary network behavior the_twelite.network2 to support universal receiver (receive packets from NWK_LAYERED, NWK_SIMPLE or networkless packets in the same executable code.)
added NWK_LAYERED (At this time, only Parent Node reception is supported.)
introduced MWX_Set_Usder_App_Ver() function to set application version during MWX intitialization, mainly for interactive mode.
added mwx::pnew() to describe placement new simply.
added support of EASTL
added new[]
operators for EASTL
pre-compled most of source codes in MWX to quicker compile.
fixed: DIO events were being passed on to unrelated ports.
Added an internal procedure to allow output using Serial class objects in Interactive settings mode. (Serial._force_Serial_out_during_intaractive_mode()
)
Main revisions
Serial1
port and alternate port were not properly defined.
Enabled to change the baud rate of (Serial
UART0).
Added event callbacks to notify received packets (on_rx_packet()
) and completed transmission (on_tx_comp()
).
If you don't define a callback function, you can use the previous procedure.
Wrong definition ID for interactive mode setting<STG_STD>
and some default values.
Added support for changing the default values of channel and logical device IDs in addition to AppID in interactive mode settings<STG_STD>
.
added support for setting the_twelite and <NWK_SIMPLE>
objects in interactive mode <STG_STD>
object for some settings.
added support for setting the default value of the number of retransmissions in <NWK_SIMPLE>
.
Serial
(UART0) input and output from the application is not performed while the interactive mode screen<STG_STD>
is displayed.
added CUE::PIN_SET
, PAL???"":PIN_SET
(Since it is unnatural to use PIN_BTN
for CUEs without buttons)
Move namespace of random() to mwx::.
MONOSTICK watchdog setting is now done in 32ms units.
When sleep was performed using BRD_TWELITE
, the pins were not initialized correctly upon recovery.
Sorry. The following has not been translated.
Added board behavior (https://mwx.twelite.info/v/v0.1.7/boards/cue) for TWELITE CUE.
Added method to receive other packets (without network usage) that are not in NWK_SIMPLE format when using NWK_SIMPLE. Add NWK_SIMPLE::receive_nwkless_pkt()
to initialize NWK_SIMPLE. When using this packet information, use only the TWENET C library layer structure by .get_psRxDataApp()
and the data array obtained by .get_payload()
. Information obtained from other methods of the incoming packet (auto&& rx = the_twelite.receiver.read()
) is undefined.
Refine get_stream_helper()
code and read/write position API.
Add EEPROM class object. (https://mwx.twelite.info/v/v0.1.7/api-reference/predefined_objs/eeprom)
Fixed bugs in smplbuf::get_stream_helper()
.
Added pktparser class (https://mwx.twelite.info/v/v0.1.7/api-reference/classes/pktparser)
sample serparser/pktparser
so that it can be built on other platforms (https://github.com/monowireless/mwx/tree/master/stdio)
Modified so that div100()
, which calculates the quotient and remainder, can be output to Serial, etc.
Changed implementation of smplbuf<>
array class. The inheritance from mwx::stream
is removed to reduce memory consumption, and a helper class and an inheritance class are defined separately.
Added mwx_printf()
mwx_snprintf()` function.
added the_twelite.stop_watchdog()
and the_twelite.restart_watchdog()
functions.
mwx::stream
maintenance: operator bool()
is obsolete. Disable timeout when .set_timeout(0xff)
is set to 0xff in the read timeout setting. Add definition of <<
operator.
Added NOTICE PAL / PCA9632 support (Description https://mwx.twelite.info/v/latest/boards/pal/pal_notice, sample https://github.com/monowireless/Act_samples/tree/master/Unit_using_PAL_NOTICE)
Add scale functions between 8bit and 0..1000 with no division.
Added division by 10,100,1000 (quotient and remainder at the same time) div10()
, div100()
, div1000()
. Restricted the value range and composed mainly of multiplication and bit shift.
Added corresponding methods for encrypted packets.
packet_rx::is_secure_pkt()
: determine if received packet is encrypted or not.
STG_STD::u8encmode()
: Obtain encryption setting in interactive mode.
STG_STD::pu8enckeystr()
: Obtain encryption key byte sequence in interactive mode.
Serial1: Default port is DIO11(TxD), DIO9(RxD) because they are usually assigned to I2C, though DIO14,15 overlap with I2C in the semiconductor specification.
The calculation of the baud rate is omitted for the main baud rates.
Serial: The proxy functions for Serial: available()
and read()
are now held only by void*
, and the specification memory is reduced by 8 bytes.
Add typedef boolean
.
Network: added support for encryption.
The first parameter is the encryption key, and the second parameter is true
, so that plaintext packets are also received. packets are also received.
Added sensor support for SHT3x and BME280
Sensor: added a mechanism to exchange configuration parameters and status in legacy code (C library wrapper class).
Sensors: I2C address can be specified for SHT3x and BME280.
Configuration: added hide_items()
. Unnecessary items can be deleted.
Added `H/W UTIL menu' to display DI status, I2C probe, and PAL EEPROM contents.
Configuration: Add encryption related menus.
I2C related fixes (to improve compatibility with code implemented using TwoWire class)
Processing of requestFrom(false)
did not work correctly because there was no code to send the NO_STOP message when processing requestFrom(false)
.
Added TwoWire
class name alias.
Modified not to initialize multiply in begin()
process.
Added setClock()
method (but it is a dummy function and does nothing).
Added WIRE_CONF::WIRE_? KHZ
added. Added the main configuration values for the bus clock.
Channel Manager. Implement chmgr
Addition of delayMilliseconds()
function
Addition of digitalReadBitmap()
function
Improved accuracy of delay()
.
Fixed the problem that Serial1
instance was not defined
Fixed problem with Analogue
interrupt handler not being called
Support for MWSDK202020_05
Duplicate checker duplicate_checker was not removed as expected due to incomplete initialization, etc.
The implementation of format() was made less machine-dependent. If 64-bit arguments are included, the number of arguments is limited.
The fix assumes MWSDK2020_05.
Updates are recommended for this fix.
Support for MWSDK2020_04
Fixed initialization problem with Timer0..4
Changed internal processing of mwx::format()
Added experimental code to support interactive mode
This fix assumes MWSDK2020_04.
We recommend an update to this fix.
Fixed problems with handling of relay flags in packets
We recommend an update to this correction.
First release (included in SDL Dec 2019)
Library Name | Dependent version |
---|---|
Library Name | Dependent version |
---|---|
Library Name | Dependent version |
---|---|
Library Name | Dependent Version |
---|---|
Library Name | Dependent Version |
---|---|
Library Name | Dependent Version |
---|---|
Library Name | Dependent Version |
---|---|
mwx
twesettings
TWENET C
1.3.5
mwx
twesettings
TWENET C
1.3.5
mwx
twesettings
TWENET C
1.3.5
mwx
twesettings
TWENET C
1.3.4
mwx
twesettings
TWENET C
1.3.4
mwx
twesettings
TWENET C
1.3.4
mwx
twesettings
TWENET C
1.3.3
License
The Mono Wireless Software License Agreement (MW-SLA) applies to anything in this package that is not specifically described in the license.
This document is also handled under MW-SLA as a part of this library package part.
This software is not officially supported by Mono Wireless Ltd. Please note that we may not be able to respond to your inquiries. Please understand beforehand.
In response to reports of defects, Mono-Wireless, Inc. does not promise to fix or improve the problem.
There are also cases where the software may not work depending on the customer's environment, such as the package installed.
Install and Build
In order to write an application using the MWX library (called ACT in this document) and run it, you need to set up a development environment.
Building ACT
The application program written in the MWX library is called ACT. The first step is to build and write it.
About the build folder structure
About the build script
About building with Visual Studio Code (Described as VSCode)
This page describes several methods of building, all of which ultimately involve running the make command. Please refer to the Makefile description for details.
Depending on the OS environment, security warnings may appear when running each executable program (e.g. make
, build toolchain like gcc
). It is necessary to configure the settings to suppress the warning. (Please consult with yourself or your system administrator to determine if you wish to run the program with the warning suppressed.)
Open the folder MWSDK_ROOT
(e.g. C:\MWSDK
) where you have installed the MWSDK. It has the following structure
Tool act files such as compilers are stored under Act_samples
. (Some of them are omitted below)
These acts are simple examples to help you write your own MWX library, but many of them have the following features
Obtaining sensor values
After obtaining the sensor value, send a wireless packet to the master
Sleeps for a period of time (or waits for an interrupt) after transmission is complete
The Parent-MONOSTICK act is used to receive and display packets. This act for the parent is output in ASCII format. (:00112233AABBCC.... .FF[CR][LF]
, and the middle part is a hexadecimal byte expressed by two ASCII characters. The trailing ? is also a two-character byte, but it becomes a checksum byte called LRC. Reference: ASCII format)
When trying to get it to work in practice, try the following combinations:
Now let's take a look inside the PingPong folder from within ACT.
You can also build other acts in Act_samples
. In this case, the folder and file names should be read differently.
You must have a .cpp
file with the same name as the folder directly under the folder.
If it is a small act, you can write it in this .cpp
file. If you have a larger act, you can build it in multiple files by referring to the Makefile description.
The ACT file PingPong.cpp is located directly under the PingPong folder. If you change the name of the folder, make sure to rename the .cpp file to the same name as the folder.
Next, open the build folder.
It contains the scripts and Makefiles needed for the build.
Build by running make TWELITE={BLUE or RED}
in the folder containing this Makefile
. Building with VSCode is the same, calling make internally.
The TWELITE STAGE app can be used to build, write, and run. This section describes the TWELITE STAGE application from startup to build.
Connect MONOSTICK or TWELITE R to your USB port.
TWELITE is a sensitive electronic component and should be handled with care. Typical precautions are listed below.
Especially when TWELITE R is used, the electronic board is often in direct contact with the outside without a case, which may cause unintended shorts, noise, or other problems that prevent the USB device from operating properly.
In this case, closing the application and unplugging and plugging in the USB device will usually restore it. In the worst case, the USB device may be damaged or the PC may be corrupted.
Also, handle electronic circuit boards with care.
Circuit error.
Check the circuit again before turning on the power.
Be careful not to reverse-insert batteries or over-voltage.
Static electricity
Even a voltage that is not human-sensitive can cause a semiconductor failure. Even simple measures such as touching metal parts before working, wristbands, and special mats can have a reasonable effect.
Short-circuits caused by touching metal objects, etc.
Make sure that there are no metal objects near the electronic board. If clips or other objects are scattered around, this may cause a short circuit, or even a dangerous situation in which the battery heats up due to a large discharge.
Launch the executable TWELITE_Stage.{extension}
located in the {TWELITE SDK installation} folder. (reference: TWELITE STAGE Application Manual - Usage)。
Below is an example of the screen while the TWELITE STAGE application is running. The main screen on the left and the command prompt screen are shown, but the main screen is usually used. The command prompt screen is not normally used, but it displays various information and input data from the TWELITE microcontroller serial port.
The main operations on the main screen are as follows
Left mouse click (selection)
Double right mouse click (return to previous screen)
Quickly press ESC
twice, or ESC
once on some screens (return to previous screen)
Hold down the Alt(Cmd) key (help screen)
Normal keyboard input (follow the screen)
(Reference: TWELITE STAGE App Manual - Key and Mouse Operations)
This is the first screen that appears when you start the TWELITE STAGE application. If TWELITE R or MONOSTICK is connected in advance, it will be listed on this screen. Select the TWELITE you wish to operate on this screen. It is also possible to select the TWELITE without selecting it on this screen.
(Reference: TWELITE STAGE App Manual)
After exiting the serial port selection screen, the main menu appears. Select the "Application Rewrite" menu for build and write.
(Reference: TWELITE STAGE App Manual)
Before selecting the application programming menu, please check the TWELITE connection and serial port selection. The serial port selection status can be checked on the help screen that appears by holding down the Alt(Cmd) key.
There are several categories of projects that can be referenced from the TWELITE STAGE application. HELP
on the right side displays related information in a browser. Foldr
displays the folder where the project is located.
If TWELITE is already connected, the TWELITE model is determined when the menu is selected. (Inside the TWELITE STAGE application, the build is performed according to the TWELITE model that has been determined.)
If an error occurs here, return to the main menu from this screen and reselect the menu. If necessary, deselect the serial port by pressing Alt(Cmd)
+ 0
on the TWELITE STAGE application and check the various connections, including the USB connection. Some USB connection errors may not be resolved until you reboot your computer.
(Reference: TWELITE STAGE App Manual)
Here, select "Act Build & Wrt" from the " Wrt Firmware" menu.
Project names, such as sample acts, are listed. The HELP
on the right side displays the related information in a browser. The foldr
displays the folder where the project is located.
Reference: TWELITE STAGE App Manual-Act Build & Wrt)
Here, select BRD_APPTWELITE
in the project selection screen shown earlier.
Once selected, writing will be performed as shown in the following screen example. If an error is displayed, follow the on-screen instructions or return to the previous screen and try again.
(Reference: TWELITE STAGE App Manual-build screen)
When the programming is successfully completed, it will continue to Interactive settings mode (settings screen). However, the screen will not be displayed unless the firmware supports Interactive settings mode.
In Interactive settings mode, you can configure various settings, including TWELITE's wireless CHANNEL.
(Reference: TWELITE STAGE App Manual-Interactive settings mode)
Return to the root menu and select Viewer
> Terminal
.
This is a very simple terminal where you can check messages from TWELITE and input data into TWELITE.
The screen displays a message when a wireless transmission is made approximately every second. You can also transition to the Interactive settings mode screen by typing + + +
.
(Reference: TWELITE STAGE App Manual-Terminal)
VSCode is a powerful editor for source editing, but it is also possible to build firmware for TWELITE microcontrollers on VSCode.
VSCode is started from the TWELITE STAGE application from the project listing in Build&Write menu. (Note: The settings is required at TWELITE STAGE App [Setting Menu] > Wrt Firmware > Open a folder with VSCode
. For simplicity of configuration, the executable TWELITE_Stage_VSCode.{extension}
is available for Windows, Linux, and macOS.)
Set "Open folder with code (VSCode)" to 1
in STAGE settings.
Press [VSCode]
on the right end of the list of builds.
If VSCode is already launched, the necessary settings by setting the system environment variables may not be reflected. In this case, exit VSCode and start VSCode again from the TWELITE STAGE application.
Because of the use of system environment variables to reflect information, in principle, simultaneous operation of multiple TWELITE STAGES that reference different library folders may cause problems. If you open Terminal on VSCode and the environment variable MWSDK_ROOT
is properly set, you can expect the build to be successful.
Firstly, open a workspace from TWELITE STAGE app that you want build. The attached workspace in TWELITE STAGE SDK has build task definitions for TWELITE microcontroller.
In the example below, a workspace is opened with an example screen of the English interface.
Open a workspace and select [Terminal>Run Task...]
.
Select the type of TWELITE radio module (BLUE/RED) and the act name to build. In the example below we have selected Build for TWELITE BLUE PingPong (for TWELITE BLUE/PingPong act). The build will start immediately after selection.
The progress of the build is shown in the TERMINAL section at the bottom of the screen.
If the build is successful, you will see a message about the creation of the .elf
file, along with its size information (text data bss dec hex filename
), as shown in the highlighted part of the screenshot above.
Also, a BIN file (in the above example, PingPong_BLUE_???.bin
) file should be created under the build
folder. Please check it.
The build definition adds a definition to convert folder names (e.g. /c/User/...
) that do not conform to the Windows 10 file system (e.g. C:/User/...
).
The conversion is not complete, but you can extract the filename and line number of the error from the compilation message.
The execution command in .vscode/tasks.json
is sh -c "make ... | sed -E -e s#..."
to rewrite the string of the drive name equivalent in the output message.
If the build does not work, check the error messages first; it is often easy to identify the cause of an error from a message on a line containing the string error.。
To be sure, clean (remove intermediate files in the objs_???
folder) and rerun the build to be sure. (All operations, including make clean
, will fail if there are intermediate files left over from builds in other environments).
Additional information about building in the command line environment.
A working knowledge of the command line (e.g. bash) is required.
Depending on the OS environment, security warnings may appear when running each executable program. It is necessary to configure the settings to suppress the warning. (Please consult with yourself or your system administrator to determine if you wish to run the program with the warning suppressed.)
To build by command line, run make
in a window where bash
(or some other shell) is running. Make sure that the environment variable MWSDK_ROOT
is set correctly beforehand. For example, if you install to /work/MWSTAGE/MWSDK
, set ~/.profile
as follows.
Run make
from the command line (bash). If make
is not available, you need to install a package. (The following is an example for Ubuntu Linux)
On Linux environments, install the make
or build-essential
package.
In the macOS environment, install Command Line Tools in Xcode.
On Windows, run {MWSTAGE SDK install}/MWSDK/WIN_BASH.cmd
. Environment variables and make utility are already set.
A build should look like this:
See the Makefile description for more details.
When the build is done, the objs_???
folder is created and an intermediate file is created in it. This file is dependent on the environment in which it was compiled, so if any files from other environments are left, make will fail.
Deleting the objs_???
folder'' may resolve the make
error.
Other platforms
Must be able to compile in C++11.
Ability to use C++11 standard library headers (utility, algorithm, functional, iterator, etc.)
new/delete/virtual are not used.
Memory allocation by new may be used in exceptional cases.
In serparser/pktparser, alloc_heap which uses new operator is processed by delete.
(Reference) However, the mwx library has been designed on the assumption that delete is not taken into account.
Build definition Makefile
The Makefile is stored in build/Makefile and is pre-defined to build the act by running the make command.
MWSDK 2020-04 automatically detects the .cpp file in the project folder, so there is usually no need to modify the Makefile.
If the source file is to be stored in a subfolder, it will need to be edited.
MWSDK 2019-12 requires you to edit the Makefile if you have more than one .cpp file.
After copying the project folder from another environment, make sure to delete the build/objs_???
folder. If any intermediate files from the other environment remain, make will fail.
(MWSDK 2020-04)
You can avoid errors by adding USE_APPDEPS=0 to clean and then running make again.
$ make USE_APPDEPS=0 TWELITE=BLUE clean
...
$ make TWELITE=BLUE
``
Specify the build target as BLUE or RED; for TWELITE BLUE, use make TWELITE=BLUE
.
Run the build. Usually, you can omit this and use make TWELITE=BLUE
.
Remove intermediate files from the build. Do this as make TWELITE=BLUE clean
.
Remove all intermediate files. Do this as make cleanall
, the same as removing all of the objs_???
folder in the build folder.
When set to 1 (the default), the build file is determined based on file dependencies. For example, if there is a change in a header file, the associated source file will be recompiled.
If set to 0, the makefile will not error if there are inconsistent intermediate files left.
Depending on the size of the act, and when defining behaviours, the source files are usually split and built separately.
One of the build files is {project folder name.cpp}.
If you want to define other files, edit the build/Makefile
in your project folder.
The above is an example Makefile with sample PAL_AMB-bhv.
Specify the version number. This will be reflected in the build result file name.
During compilation, it is passed as a definition like -DVERSION_MAIN=0
-DVERSION_SUB=1
-DVERSION_VAR=0
.
(MWSDK 2020-04)
If you do not place files in subfolders, you no longer need to specify additions. All .c .cpp files in the project file will be added.
When you add a source file, you need APPSRC_CXX
and APP_COMMON_SRC_DIR_ADD?
.
If you place source files in a subfolder, you must specify the folder APP_COMMON_SRC_DIR_ADD?
.
Append the name of the source file to `APPSRC_CXX'. This file name must not contain a folder name. Anything in a subfolder should also be specified without a folder (i.e. if the same filename is in a subfolder, the build will fail)
Next, specify the search path if the source files are stored in a location other than the project folder. You can set up to four.
The folder specification is relative to the Makefile.
A number of other options can be passed to the compiler linker.
Parents | Child | Remark |
---|---|---|
Example | Remark |
---|---|
Build definitions are provided so that some features (, , Serial object for console) can be built on other platforms. Only the necessary files are cut out.
The build definitions are stored in the {mwx library storage}/stdio folder. See (link is on GitHub) for build instructions.
Designation | Remarks |
---|
The parent device is started with the M1 pin low (GND level). In normal mode (always running), you can see it works like App_TweLite.
The system works with two children. When one of them sends a ping packet, the other sends a pong packet back.
Other
You can check the transmission of packets of the act for the child machine.
make TWELITE=BLUE
build for TWELITE BLUE
make TWELITE=RED
build for TWELITE RED
make cleanall
Delete intermediate files
| Specify compilation options for C++ source files. |
| Specify compile options for C/C++ source files. |
| Specify the include file for the header file. |
| Define this if you have a special reason for wanting to apply a compile option other than |
| Specify linker options. (This is not mentioned in the comments of the Makefile above, but can be specified) |
Sample Acts
To help you understand how the ACT works, we have prepared some samples.
The samples can be found in Act_samples in the folder where you installed the MWSDK.
Several samples are provided to help you understand how the act works.
act0..4 is a very simple example, without any radio functions, to give you an idea of the basic structure of Act.
This is an example of a wireless sensor implementation that connects an I2C sensor and sends wireless packets while performing a brief operation by sleeping. Since this is a relatively simple and typical structure, it is recommended that you refer to it after reviewing act0
through act4
.
Typical elements for implementing wireless sensors in TWELITE (simple relay net <NWK_SIMPLE>
, Interactive settings mode <STG_STD>
, I2C sensor handling Wire
, intermittent operation with sleep, etc.).
These are samples of sending or receiving wireless packets, each implemented from a slightly different perspective.
Scratch is a simple code that receives 1 byte commands from the UART, sends them and so on.
Slp_Wk_and_Tx uses a state machine and intermittent operation with sleep, repeating the process of sleep recovery, radio transmission and sleep.
PingPong is a sample of sending packets from one side to the other and receiving packets back by the other side. It contains basic procedures for sending and receiving.
WirelessUART interprets the UART input into ASCII format using serparser and sends it.
Note: App_Wings can also be used to receive wireless packets for the ACTs included in this sample.
Refer to this when implementing your own Receiving Parent Node application.
Parent_MONOSTICK exclusively receives and outputs the reception result to the serial port. The wireless packets in this sample, which are addressed to the parent device (0x00) or to the child device broadcast (0xFE), can be received. It also includes a procedure to add the interactive mode <STG_STD> to Act.
Rcv_Univsl is an example code for universal packets receiver (e.g. TWENET layered tree network, App_Twelite, Act, ...). It alse uses EASTL library for container or some algorithm.
The explanation of the ACT using Interactive settings mode describes the general flow of the program. There are no major differences between the explanations for any of the samples. (Here we quote BRD_I2C_TEMPHUMID)
BRD_I2C_TEMPHUMID executes I2C sensor device read/write commands and wirelessly transmits measurements obtained from I2C sensors. It also uses the Interactive settings mode <STG_STD> to Act.
Setting provides a higher degree of customisation of the interactive mode <STG_STD>.
This sample obtains sensor information from built-in peripherals and external sensor devices.
BRD_I2C_TEMPHUMID executes I2C sensor device read/write commands and wirelessly transmits measurements obtained from I2C sensors. It also uses the Interactive settings mode <STG_STD> to Act.
BRD_APPTWELITE provides bidirectional communication using digital input, analogue input, digital output and analogue output. It also contains the procedure for adding the interactive mode <STG_STD> to Act.
PulseCounter uses a pulse counter function to count the number of pulses detected on the input port, even during sleep, and to transmit this data wirelessly.
PAL_AMB_behavior is a behavioural example: in PAL_AMB the temperature and humidity sensors are called by the code inside the library, but this sample also includes its own procedure for accessing the temperature and humidity sensors via I2C bus.
Although a standard PAL application is written into TWELITE PAL, it is possible to write a description using ACT without using the PAL application. The MWX library provides standard procedures for MOTION SENSE PAL use.
This is a sample for various PAL boards. This sample acquires sensor values, transmits these valuse, and sleeps on the PAL board.
The following is an example of an advanced application, which is a little more complicated to describe than the above ACT.
PAL_AMB_usenap is a sample that aims to save more power by allowing the TWELITE microcontroller to sleep briefly during the sensor's operating time, which can take several tens of milliseconds.
PAL_AMB_behavior is a behavioural example: in PAL_AMB the temperature and humidity sensors are called by the code inside the library, but this sample also includes its own procedure for accessing the temperature and humidity sensors via I2C bus.
PAL_MOT_fifo for continuous acquisition and wireless transmission of samples without interruption, using the accelerometer's FIFO and FIFO interrupts.
Acts with names starting with Unit are intended to introduce features and APIs.
We have put the complete source on Github for the purpose of checking the latest code and the revision history between MWSDK versions. See the links below for more information.
The following items are common settings in the Act sample and are explained below.
The following settings are common to all sample acts.
Application ID 0x1234abcd
Channel 13
Both the application ID and the channel are mechanisms to ensure that the network does not mix with other networks.
Systems with different Application IDs will not mix, even if they are on the same channel. However, if a system with a different Application ID is transmitting frequently, this will cause interference and will have an effect.
The channel determines the frequency used for communication; in principle, 16 channels are available on the TWELITE radio module, and it is not possible to communicate with different channels except in very exceptional cases, which would not be the case in a normal system.
As a common specification of sample acts, the payload (data part) of the packet is prefixed with a 4-byte string (APP_FOURCHAR[]
). This is for explanatory purposes, although one byte is sufficient for species specific identifiers. The inclusion of such system-specific identifiers and data structures is another way to prevent confusion.