1 of 1 people found this helpful
the magic numbers are for led buzzer button as labelled .. If you notice these are based on masking the bits 0,2,4,8 ..
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.
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.
in fact this is taken as "flag and will enable function define in bleprofile.h (below middle page)
* \brief Turn LED On
* \ingroup bleprofile
* \details This function turns on LED that is defined in BLE_PROFILE_GPIO_CFG.
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.