Lab2 – Using Buttons to Control LEDs

Announce on 2007/03/28

Environment

• When you build up your environment in Lab1– BoardAPI– FontalBSP

• FontalButton, FontalLED

– HardwareAPI– Stack – 802.15.4 MAC

• Application Queue API• Service Access Point – AppApi.h

– Access functions and structures used by the application to interact with the Jennic 802.15.4 stack

Lab2 sample

• This sample code can let us use buttons to control LEDs– HardwareAPI– FontalBSP

•led_init();•btn_init();•led_toggle();•btn_pressed();

Lab2 sample overview

• Through HardwareAPI , we can initialize the Button and LDE devices

• Through FontalBSP, we can control the LEDs and monitor the button status

• Through callback mechanism provided by HardwareAPI, we can catch the interrupt event about the buttons

Lab2 sample flowchart

YES

while(TRUE);

Interrupt

Is Button0 ?Toggle LED0 No Toggle LED1

Callback function

Integrated peripherals API

• This API was previously known as the Hardware Peripheral Library or the Hardware API

• The functions are defined in AppHardwareApi.h

• u32AHI_Init(void);

– This should be called after every reset or wake-up and before any other AHI calls are made

– We can see that in sample codes about Lab1 and Lab2

BoardAPI

• Allow rapid software development by providing a function library for interfacing to the evaluation board components – LED control– Button control– Sensor control

• The FT 6250 device provides the FontalBSP

FontalBSP

• FT 6250 device has its own DIO– FontalButton.h– FontalLED.h– FontalWtd.h

• There is no sensor component in FT 6250 device– We will give you FT 6251 that has temperature sensor

and lighting sensor component after Lab3

• FT 625x device is a high power module device– JN-SW-4021-HighPowerModuleUpdate-2v6v1.msi

Interrupt Handling

• Interrupts from peripheral devices are handled by a set of device-specific callbacks– vAHI_SysCtrlRegisterCallback(

vSystemISR);– PRIVATE void vHwDeviceIntCallback(uint32 u32DeviceId, uint32 u32ItemBitmap)

– u32DeviceID is an enumerated value indicating the peripheral that generated the interrupt

– u32ItemBitmap is set for each individual interrupt source within the peripheral

Callback function versionPRIVATE void vSystemISR(uint32 u32DeviceId, uint32

u32ItemBitmap){

switch (u32DeviceId){case E_AHI_DEVICE_SYSCTRL:

if (btn_pressed(BUTTON0))led_toggle(LED0);

else if (btn_pressed(BUTTON1))led_toggle(LED1);

break;default:

break;}

}

Application API

• u32AppApiInit– A general interrupt handler can be registered

during the initialization of the application API

• After vAHI_init()– Call u32AppApiInit(NULL, NULL, NULL, NULL,

NULL, NULL, NULL);– Init Application API to use callback function

Lab2 sample pseudo code

1. u32AHI_Init();2. u32AppApiInit(NULL, NULL, NULL, NU

LL, NULL, NULL, NULL);3. led_init();4. btn_init();5. vAHI_SysCtrlRegisterCallback(vSyst

emISR);

Lab2

• What should you do in this lab– Using the Application Queue API to handle

the interrupt events– Application queue API is a interface between

IEEE 802.15.4 MAC and hardware devices – In the application layer, you can catch the

interrupt events by the application queue

Architecture

Jennic 802.15.4 Stack API

• This facilitates control of the 802.15.4 MAC hardware within the Jennic JN5121 single chip wireless microcontroller – IEEE 802.15.4 MAC protocol

• Low Rate Wireless Personal Area Networks

– The interface described is exposed at the level of transactions into and out of the stack

Application Queue API

• The Application Queue API provides a queue-based interface between an application and both the IEEE 802.15.4 stack and the hardware drivers – MCPS (MAC Data Services) interrupts coming

from the stack – MLME (MAC Management Services)

interrupts coming from the stack – Hardware interrupts coming from the

hardware drivers

Application Queue API

• u32AppQApiInit– Init the Application Queue API, as well as the

underlying 802.15.4 Stack API – The function creates there queues

• MLME indications and confirmations

• MCPS indications and confirmations

• Integrated Peripherals API indications

– The function refers to callback functions for the three queues

u32AppQApiInit

Polling queue

• MLME– PUBLIC MAC_MlmeDcfmInd_s *psAppQApiReadMlmeInd(void);– PUBLIC void vAppQApiReturnMlmeIndBuffer(MAC_MlmeDcfmInd_

s *psBuffer);• Return MLME buffer previously passed

• MCPS– PUBLIC MAC_McpsDcfmInd_s *psAppQApiReadMcpsInd(void);– PUBLIC void vAppQApiReturnMcpsIndBuffer(MAC_McpsDcfmInd_

s *psBuffer);• Return MCPS buffer previously passed

Polling queue

• Hardware Indication– PUBLIC AppQApiHwInd_s *psAppQApiReadHwInd(void);– PUBLIC vAppQApiReturnHwIndBuffer(AppQApiHwInd_s

*psBuffer);• Return hardware event buffer previously passed

typedef struct

{

uint32 u32DeviceId;

uint32 u32ItemBitmap;

} AppQApiHwInd_s;

Flowchart – for polling

McpsInd ?

YesMlmeInd ?

No

Process Incoming Data

Process Incoming Mlme

Yes

No

Process HwInd

Yes

YesProcess Hardware Indication

while(1)

Lab2 Requirement

• Install the Lab2 sample code to your FT device– Observe the LED result– Analysis the Lab2 sample code

• Change the mechanism provided by the hardware integrated peripherals API to the other one provided by the application queue API– Your code flow chat will be similar with the polling

flowchart

Lab2 Requirement

• Due day– 2007/04/11

• Reports – Each team should only hand over one report– The content of your Lab report should not more than

10 pages

• Demo– Each team should shows a demo about your lab– The arrangement will be announced later

Bonus

• Battery limitation – Using a busy loop will exhaust your battery so

on – Using vAHI_CpuDoze

• Requirement – Using button to control LEDs– If no one press the buttons for a long time, aut

omatically turn them off