Architecture

Interruption pins

The microcontroller receives all type of interruptions as hardware interruptions. For external interruptions, Waspmote uses the following interruption pins:

• RXD1

• TXD1

keep in mind that the interruption pins are the same UART1 transmission/reception pins. This means that the same pin is used for both communication and interruption signals.

Figure: Interruption pins within the SPI-UART socket

Interruption sources

Waspmote has several interruption sources which can be used:

• Watchdog

• RTC

• Accelerometer

• Sensors

Figure: Interruptions diagram

The interruption signals from the RTC, accelerometer and sensors are connected to RXD1 pin. The internal Watchdog ‘simulates’ a hardware interruption using a reserved digital pin (DIGITAL0). This simulation by the Watchdog has been implemented to maintain the same functionality structure in all the interruption sources and can fill in flags in the same way.

The interruption pin of the modules is connected through a diode to RXD1 or TXD1 in order to avoid interferences between the different interruption sources. Besides, there is a unique monitoring pin for each module. Thus, when the interruption is captured, the monitoring pin of each module is analyzed to see which one generated it.

The definition of the monitoring and interruption pins can be found in the WaspConstants.h file:

ACC_INT: Accelerometer interruption RTC_INT: RTC interruption WTD_INT: Watchdog interruption SENS_INT: Generic Sensor Board interruption PLV_INT: Pluviometer interruption HIB_INT: Hibernate interruption RAD_INT: Radiation sensor interruption PIR_3G_INT: PIR sensor interruption (Video Camera Board)

Interruption Flags

Because of the multiplexing of these interruption signals, a series of flag vectors have been created in WaspVariables.h to find out the module which generated the interruption. These flags are:

• intConf

• intFlag

• intCounter

• intArray

intConf

This bitmap variable is used to set which interruptions are enabled to be captured by Waspmote. It is defined as a two-byte variable in WaspVariables.h:

uint16_t intConf;

Only interruptions previously enabled in this vector will be captured. Otherwise, if the interruption signal arrives, but intConf is not set correctly, the interruption will be lost.

A bit set to '0' indicates the interruption is disabled and even if it arrives it will not be captured.

A bit set to '1' indicates the corresponding interruption is enabled to be captured in the case it arrives.

Figure: Structure of the ‘intConf’ variable

For instance, if accelerometer and RTC interruptions have been enabled, then the corresponding bits inside intConf are set to '1'. The rest of the bits remain set to '0':

PIR 3G	-	RAD	HIB	PLV	SENS	WTD	RTC	ACC
0	0	0	0	0	0	0	1	1

This means intConf is equal to binary B000000011 which is the same as decimal 3.

The user does not have to configure this variable in the Waspmotes codes. Depending on the interruption source to set up, there are certain functions in order to configure the intConf variable and prepare the source to generate a new interruption signal. Refer to the corresponding programming guide in order to know how to set up the desired interruption event.

intFlag

This bitmap vector is used to indicate which module generated the captured interruption. It Is defined as a two-byte variable in WaspVariables.h:

uint16_t intFlag;

Each bit corresponds to a specific interruption source.

A bit set to '0' indicates no interruption has been captured for a specific source.

A bit set to '1' indicates the corresponding interruption has been captured.

Figure: Structure of the ‘intFlag’ variable

For instance, if the RTC interruption has been captured, then the corresponding bit inside intFlag is set to '1'. The rest of non-captured bits remain set to '0':

PIR 3G	-	RAD	HIB	PLV	SENS	WTD	RTC	ACC
0	0	0	0	0	0	0	1	0

This means intFlag is equal to binary B000000010 which is the same as decimal 2.

The API defines the following constants to check what interruption has been captured in intFlag:

#define ACC_INT 1 // bit 0 #define RTC_INT 2 // bit 1 #define WTD_INT 4 // bit 2 #define SENS_INT 8 // bit 3 #define PLV_INT 16 // bit 4 #define HIB_INT 32 // bit 5 #define RAD_INT 64 // bit 6 #define PIR_3G_INT 256 // bit 8

Therefore, the user must use this variable in order to check out new interruption events as follows:

{
 if (intFlag & ACC_INT)
 {
 // treat Accelerometer interruption
 }
 if (intFlag & RTC_INT)
 {
 // treat RTC interruption
 }
 // etc...
 }

intCounter

This variable is used to count the total number of interruptions which have been captured. Each time an interruption is captured this counter is increased independently of the interruption source.

intArray

This array of bytes is used to count the total number of interruptions that have been captured for each module. It is defined in WaspVariables.h:

uint8_t intArray[8];

Each time an interruption is captured the position corresponding to the module is increased.

Figure: Diagram of the ‘intArray’ variable

The API defines the following constants to read the number of interruptions captured for each module:

#define ACC_POS 0 #define RTC_POS 1 #define WTD_POS 2 #define SENS_POS 3 #define PLV_POS 4 #define RAD_POS 5 #define PIR_3G_POS 7

So, in Waspmote codes you only need to access this way:

Example of use:

{
 USB.println(intArray[ACC_POS], DEC);
 USB.println(intArray[RTC_POS], DEC);
 // etc...
 }

For instance, if the RTC interruption has been captured for 3 times, then the corresponding byte inside intArray stores this information:

PIR 3G	-	RAD	PLV	SENS	WTD	RTC	ACC
0	0	0	0	0	0	3	0