Sample ACTs

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.

Introduction to sample ACTs

Several samples are provided to help you understand how the act works.

Short ACT with no wireless communication and only microcontroller functions

  • act0..4 is a very simple example, without any radio functions, to give you an idea of the basic structure of Act.

Example of ACT description with I2C sensor

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.).

Basic ACT for wireless communication

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.

ACT on Parent Node side

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.

ACT to add Interactive settings mode

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>.

ACT to operate sensors and other devices

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.

ACT to use TWELITE PAL

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.

ACT, which introduced the stand-alone function

Acts with names starting with Unit are intended to introduce features and APIs.

Get the latest version.

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.

https://github.com/monowireless/Act_samples

Common description

The following items are common settings in the Act sample and are explained below.

const uint32_t APP_ID = 0x1234abcd;
const uint8_t CHANNEL = 13;
const char APP_FOURCHAR[] = "BAT1";

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.

前へOther platforms次へact0 .. 4

最終更新