Lab2 – Using Buttons to Control LEDs

1. Lab2 – Using Buttons to Control LEDs Announce on 2007/03/28

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

3. Lab2 sample • This sample code can let us use buttons to control LEDs • HardwareAPI • FontalBSP • led_init(); • btn_init(); • led_toggle(); • btn_pressed();

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

5. Lab2 sample flowchart

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

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

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

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

10. Callback function version PRIVATE 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; } }

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

12. Lab2 sample pseudo code • u32AHI_Init(); • u32AppApiInit(NULL, NULL, NULL, NULL, NULL, NULL, NULL); • led_init(); • btn_init(); • vAHI_SysCtrlRegisterCallback(vSystemISR);

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

14. Architecture

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

16. Application Queue API • The Application Queue API provides a queue-based interface between an application and both the IEEE 802.15.4stack 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

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

18. u32AppQApiInit

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

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

21. Flowchart – for polling

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

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

24. Bonus • Battery limitation • Using a busy loop will exhaust your battery soon • Using vAHI_CpuDoze • Requirement • Using button to control LEDs • If no one press the buttons for a long time, automatically turn them off