5 Replies Latest reply on Dec 4, 2014 6:47 PM by MichaelF_56

    GPIO Flag Magic Numbers in bleprofile.h

      In the WICED SMART SDK, under the include directory structure in bleprofile.h, starting on line 74, there are several #defines for GPIO flag bits.  The first section appears to define direction, initialization state, etc.  I can make sense of these.

      // GPIO flag bit (this is different than definition that used in gpio driver source code (GPIO_INPUT_ENABLE, etc)

      #define GPIO_NUM_MAX  16

      #define GPIO_INPUT          0x0000

      #define GPIO_OUTPUT         0x0001

      #define GPIO_INIT_LOW       0x0000

      #define GPIO_INIT_HIGH      0x0002

      #define GPIO_POLL           0x0000

      #define GPIO_INT            0x0004   // Interrupt

      #define GPIO_BOTHEDGE_INT   0x0008   // Both Edge

       

      Just under those, starting on line 82, there are another series of magic numbers.  Can anyone explain why the values are what they are?

      #define GPIO_WP             0x0010   //EEPROM write protect

      #define GPIO_BAT            0x0020

       

      #define GPIO_BUTTON         0x0100

      #define GPIO_BUTTON1        0x0100

      #define GPIO_BUTTON2        0x0200

      #define GPIO_BUTTON3        0x0400

       

      #define GPIO_LED            0x1000

      #define GPIO_BUZ            0x2000

       

      Thank you,

      -Troy

        • 1. Re: GPIO Flag Magic Numbers in bleprofile.h
          MichaelF_56

          I'll see if VikramR_26 can look into this...

          • 2. Re: GPIO Flag Magic Numbers in bleprofile.h
            VikramR_26

            the magic numbers are for led buzzer button as labelled .. If you notice these are based on masking the bits 0,2,4,8 ..

            1 of 1 people found this helpful
            • 3. Re: GPIO Flag Magic Numbers in bleprofile.h

              VikramR_26 MiTo_1583836

               

              I see that they are bit-masks.  My question is about how they are used.  I will use the push-button as the example.

               

              In bleprofile.h one of the buttons has a #define GPIO_BUTTON 0x0100.  I understand that this is a bit-mask.

               

              Then, in platform.h (for the BCM920737TAG) GPIO_BUTTON is used in the

              #define GPIO_SETTINGS_BUTTON (GPIO_INPUT | GPIO_INIT_LOW | GPIO_BUTTON | GPIO_INPUT)

               

              In turn, the GPIO_SETTINGS_BUTTON is used (in hello_sensor.c as an example) in the BLE_PROFILE_GPIO_CFG structure.

               

              The GPIO configuration is then used by bleapp_set_cfg() in APPLICATION_INIT()

               

              How does bleapp_set_cfg() use the bit mask?  I cannot locate a function description/usage anywhere.  If a customer wants to create a custom design and plans to initialize the GPIO with bleapp_set_cfg() but will have different GPIO as compared to the TAG, how do they know what the bit-masks should be set to?  i.e. The button as 0x0100 or the buzzer as 0x2000, etc.

               

              Thank you,

              -Troy

              • 4. Re: GPIO Flag Magic Numbers in bleprofile.h

                First, great work, but

                I'm a bit confused as well, I recently dig inside the prog.

                 

                #define GPIO_PIN_BUTTON     0

                #define GPIO_SETTINGS_BUTTON (GPIO_INPUT  | GPIO_INIT_LOW  | GPIO_BUTTON | GPIO_INT) #define GPIO_PIN_WP          1

                #define GPIO_SETTINGS_WP     (GPIO_OUTPUT | GPIO_INIT_LOW  | GPIO_WP)

                #define GPIO_PIN_LED         14

                #define GPIO_SETTINGS_LED    (GPIO_OUTPUT | GPIO_INIT_HIGH | GPIO_LED)

                #define GPIO_PIN_BATTERY 15

                #define GPIO_SETTINGS_BATTERY (GPIO_INPUT  | GPIO_INIT_LOW  | GPIO_BAT)

                #define GPIO_PIN_BUZZER        28

                #define GPIO_SETTINGS_BUZZER (GPIO_OUTPUT | GPIO_INIT_LOW | GPIO_BUZ)

                 

                What is these : GPIO:BUZ, LED, WP ?

                In fact I can understand the purpose of this in a platform.h file, but not in the standard lib that I will use. And No info found on what doesn't this settings.

                GPIO_INPUT/OUTPUT .... INIT ... Ok, but BUZ ?

                 

                Does it overrides what we add and set this GPIO as output even ?

                 

                Thanks for the explanation.

                 

                 

                [EDIT]

                in fact this is taken as "flag and will enable function define in bleprofile.h (below middle page)

                for example:

                 

                /**

                * \brief Turn LED On

                * \ingroup bleprofile

                *

                * \details This function turns on LED that is defined in BLE_PROFILE_GPIO_CFG.

                *

                */

                void bleprofile_LEDOn(void);

                ....

                ....

                ....

                • 5. Re: GPIO Flag Magic Numbers in bleprofile.h
                  MichaelF_56

                  I'm not a software developer, so bear with me. My understanding is that the GPIO is physically mapped to a 2073X device within the platform.h file which is custom to the TAG by default, but can be reconfigured for a custom/customer design.

                   

                  The values in platform.h then map to definitions and function prototypes in bleprofile.h

                   

                  Note that the values in the bleprofile.h bitmasks themselves are not intended to be exposed to the user for reasons I described to you in the email I sent earlier.

                   

                  BLE_PROFILE_GPIO_CFG within the .c file for each application is where you allocate/initialize the GPIO within your application.  The bleprofile_xxx() routines are then how you use/access what you have configured above.

                   

                  I agree there is some ambiguity in our message in that we have guides like this one: http://community.broadcom.com/docs/DOC-1023

                   

                  Which explain that the BCM2073X includes two sets of APIs that are available for the application: the low-level driver API and the high-level profile API.

                   

                  So the Low Level API is there in some cases to use, but we are not consistent in exposing everything a developer needs to actually use it effectively.