Hello, here is how you can turn on an LED using PWM.
#define LED_RED 26 /* PWM 0 */ #define LED_BLUE 27 /* PWM 1 */ #define LED_GREEN 28 /* PWM 2 */ #define GPIO_PORT(x) (x/16) #define GPIO_PIN(x) (x%16) #define ENABLE_LED_RED PWM0_OUTPUT_ENABLE_P26 #define ENABLE_LED_BLUE PWM1_OUTPUT_ENABLE_P27 #define ENABLE_LED_GREEN PWM2_OUTPUT_ENABLE_P28 #define DISABLE_LED_GPIO GPIO_INPUT_ENABLE | GPIO_PULL_DOWN #define LED_RED_CHANNEL (PWM0) #define LED_BLUE_CHANNEL (PWM1) #define LED_GREEN_CHANNEL (PWM2)
Note: depending on which chip you are using, the GPIO Pins might change
// enable gpio_configurePin(GPIO_PORT(LED_RED), GPIO_PIN(LED_RED), ENABLE_LED_RED, 0); pwm_start( LED_GREEN_CHANNEL, LHL_CLK, 0x000 , 0); // pwm_start( id, clk, toggleCount, initCount); // Output Voltage | Toggle Count (Found these values by trial & error) // -------------------------------------------- // ~ (4/4) V_MAX | 0x000 // ~ (3/4) V_MAX | 0x100 // ~ (2/4) V_MAX | 0x210 // ~ (1/4) V_MAX | 0x315
Note: depending on the hardware configuration, the V_MAX may change
// disable gpio_configurePin(GPIO_PORT(LED_RED), GPIO_PIN(LED_RED), DISABLE_LED_GPIO, 0); pwm_disableChannel( 1 << LED_RED_CHANNEL );
The BCM2073x chip (SoC) has 40 logical GPIOs (P0-P39).
The GPIOs themselves are broken out into three separate ports (meaningful when you start programming):
• P0 through P15 on port0
• P16 through P31 on port1
• P32 through P39 on port2
The 32 pin package (i.e. the SoC - BCM20736 and BCM20737 *without* the S) only brings out 14 of the 40 logical GPIOs. The System in Package/SIP (the BCM20736S and BCM20737S modules) follows the SoC closely with regards to which pins are brought out (but there is a slight difference) and these are what you see in the SIP module datasheets.
Since the 32 pin package (SoC) and the modules are pin-limited, some of the logical GPIOs within the SoC are multi-bonded before bringing them out on the balls on the chip.
For the 32 pin package, the following pins are bonded in this manner:
Very Important Note: The SOC packaged part described above is not used for the SIP module. The SIP uses the raw die and wirebonds it differently than the DFN part, so the IOs described above for the SoC are not bonded together from the die - they are bonded together on the DFN wirebond package.
Always refer to the BCM20737S Bluetooth Low Energy SiP Module Technical Reference for the bonding/alternate function information relevant to the SIP modules, not the BCM20737 SOC Data Sheet.
When leveraging the WICED™ Smart Hardware Interfaces for your development, you will run across several GPIO mapping tables in the document that look like this one:
Note here that you can use only one of the GPIOs (noted in black) from each of the vertical rows above. This is what is referenced in the WICED™ Smart Hardware Interfaces as a "group" (all signals must be selected from the same group, which is essentially the table).
All options may not be available in the package used within the SIP module (shown in red). Combinations shown in red text are also not generally available on the BCM20732 TAG. Additional options may be unavailable if they are being used for the peripheral UART interface.
All GPIOs support programmable pull-up and pull-down resistors, along with a 2 mA drive strength except P26, P27, and P28, which provide a 16 mA drive strength at 3.3V supply (this will change as the supply drops and the GPIO pins will sink less current).
The GPIOs are all capable of waking the device from sleep or deep sleep and the application can configure interrupts (both/either edges, level), pull-up/pull-down High-Z, etc.
The following GPIOs are available on the BCM2073XS based SIP Modules (remember, only 14 are brought out on the SIP module):
For unused dual bonded pins, the unused GPIO should be input/output disabled (especially when it is an input).
From the perspective of writing software against the GPIO mappings defined above, it's important to keep in mind that the GPIO is physically mapped to a BCM2073XS device within the platform.h file which is custom to the TAG development board by default.
However, this mapping in platform.h can be reconfigured for a custom design.
The values in platform.h then map to definitions and function prototypes in bleprofile.h
Note that the specific values in the bleprofile.h bitmasks themselves are not intended to be exposed as the code beneath these bitmasks is proprietary and cannot be released for reasons outside the scope of this discussion.
In addition to reconfiguring the mappings of your custom board within the bleprofile.h, GPIO can also be assigned within BLE_PROFILE_GPIO_CFG within the .c file for each application. This is also where you allocate/initialize the GPIO within your application. The bleprofile_xxx() routines are then how you use/access what you have configured above.
With this said, I realize there is some ambiguity in this message as we have documents like WICED™ Smart Hardware Interfaces which clearly states that the BCM2073X (note that this guide was written for the SoC, then modified slightly for the SIP module) includes two sets of APIs that are available for the application: the low-level driver API and the high-level profile API.
So yes, the Low Level API is there and in some cases ok to use, but we are not consistent in exposing everything a developer needs to actually use it effectively on a consistent basis.
Hopefully you guys find this helpful. I know many of you have tidbits to add, so feel free to comment (please stay on topic). I would love to see some examples and code snippets showing usage of the bleprofile_xxx() routines.Show Less
|Product Selection||Product Evaluation||WICED Sense||Product Development||Manufacturing / Production|
Welcome to the IoT Hackathon Challenge!
If you cannot attend the IoT Hackathon, you can still submit your solution online.
Use your innovative idea for a Bluetooth low energy device. Using WICED Smart SDK you can easily develop a device which performs as a sensor/peripheral, an embedded central, a broadcast or an observer, or can combine any of the these functions. Broadcom will provide you required hardware, SDK and help to speed up your development.
Develop tone client and a tone server applications to run on the WICED Smart evaluation boards. The server should be able to play music based on the notes sent by the client.
Use WICED Smart SDK to create a tone client and a tone server applications to run on the WICED Smart evaluation boards. The server should be able to play music based on the notes sent by the client.
1. Developing Tone Service
a. Use WICED Smart Designer feature of the WICED Smart SDK (File->New->WICED Smart Device Configuration) to create a new tone_server device. The device will need access to a buzzer of the development board.
b. Add a Vendor Specific Service (tone_service) with 2 Vendor Specific writable characteristics Note and Command. The Note characteristic value corresponds to the tone to be played on the buzzer. The Command characteristic is a control point which peer device can use to Start or Stop playing the tone.
c. Add a code from pwm_tones.c sample which supports playing tones on the buzzer.
d. Implement a write_handler so that when peer device writes Start command the server starts playing the tone corresponding to the value of the Note characteristic.
e. Make sure that the device is discoverable while there is no connection.
f. (Bonus) Turn on LED while a tone is being played.
2. Developing Tone Client
a. Use proximity_client WICED Smart SDK as a sample.
b. Start scanning on the startup and connect to any device publishing UUID of the Tone Server.
c. When connection is established perform the GATT discovery to find out the handles for the Note and Command characteristics. (You can cheat and skip this step because handles will be hard coded in the tone_server_db.h created in step 1.a).
d. Using a timer callback play your favorite music using Bluetooth and the buzzer of the tone_server. When it is a time to play a specific note write to the Note characteristic and write the Start command to the Command characteristic. You can use SONG ).
Notes from our Applications Team.
1. The PWM can only modulate one tone at a time -can’t do polyphonic tones
2. So we have to time-slice it with some timers to change the tones every timer event.
3. Hint: If I were doing it, I would have an array of tone, duration, pause duration.
4. And then play in the fine timer.
The trick is:
How to convert standard notes to pwm_start(PWM2, PMU_CLK, 0x2FF, 0x200); from