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 1.u32AHI_Init(); 2.u32AppApiInit(NULL, NULL, NULL, NULL, NULL, NULL, NULL); 3.led_init(); 4.btn_init(); 5.vAHI_SysCtrlRegisterCallback(vSyst emISR);

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

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