Hello, here is how you can turn on an LED using PWM.
Include Library
#include "pwm.h"
#include "gpiodriver.h"
Define Macros
#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 LED
// 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 LED
// disable gpio_configurePin(GPIO_PORT(LED_RED), GPIO_PIN(LED_RED), DISABLE_LED_GPIO, 0); pwm_disableChannel( 1 << LED_RED_CHANNEL );
References
Hardware User Guide (SDK 2.x and TAG3 Board)
James
Show LessThe WiFi module power and reset pins are controlled by the host MCU.
BCM943362WCD4:
For BCM943362WCD4 evaluation board, the power and reset pins are controlled by the following definitions in .../platforms/BCM943362WCD4/platform.c
[WWD_PIN_POWER] = { GPIOB, 2 },
[WWD_PIN_RESET] = { GPIOB, 5 },
The "WWD_PIN_POWER" definition in WICED SDK controls the host MCU (STM32F205) PB2 pin. The host MCU PB2 pin controls the VBAT (power) on the WiFi module. Wifi module power completely turned of by the hos MCU to save energy if the WiFi module is not in use at all.
The "WWD_PIN_RESET" definition in Wiced SDK controls the host MCU PB5 pin. The host MCU PB5 pin controls the WLAN_RESET_L (reset) on the WiFi module.
Setting this pin logic level to low causes WiFi module reset.
BCM943341WCD1:
For BCM943341WCD1 the reset pin is controlled by the following definition in .../platforms/BCM943341WCD1/platform.c
Although it is named as WWD_PIN_POWER but actually controls the reset pin of the BCM943341 SiP module. Reason is being the logic level to reset the BCM943341 SiP module is inverted compared to the other SiP modules.
[WWD_PIN_POWER] = { GPIOB, 2 },
The "WWD_PIN_POWER" definition in WICED SDK controls the host MCU (STM32F417IGH6) PB2 pin. This pin from the host MCU controls the WL_REG_ON (reset) on the WiFi module. Setting this pin logic level to high causes WiFi module reset.
Unlike on BCM943362WCD4 evaluation board, on BCM943341WCD1 evaluation board the WiFi module power (VBAT) is not controlled by the host MCU. The WiFi module VBAT pin directly connected to the 3.3V via bypass capacitors.
If needed, the similar power switching circuit from BCM943362WCD4 evaluation board could be used on BCM943341 module based designs as well.
.
Show LessThe 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 LessProduct Selection | Product Evaluation | WICED Sense | Product Development | Manufacturing / Production |
Replace the …/apps/demo/appliance/appliance.c and …/resources/apps/appliance/top_web_page_top.html with attached copies.
Then build and download the updated appliance application to your target EVB, example is BCM943362WCD4 EVB “demo.appliance-BCM943362WCD4 download run“.
Follow the same steps described in the appliance demo, Demo of the "Appliance Application" in WICED SDK, to associate EVB to your network and go to the website served by the EVB.
Use the buttons to toggle Red and Green LEDs on the BCM943362WCD4 EVB, as shown below screen shot.
Revision | Change Decription | Date |
---|---|---|
1.0 | Initial | 06/22/14 |
Hello Community Members,
This BLOG should be used as a "guide" for examining Sleep and Deep_Sleep techniques.
This is a compilation of Sleep and Deep Sleep questions and answers from several of our forum users and I thank you for your questions and answers.
Let's start out with a explanation of how to place the BCM2073x in Sleep and Deep_Sleep modes and then move to sample Q/A regarding a few use cases.
Sleep Deep_Sleep Modes:
Here's a list of the Sleep/Deep Sleep modes:
Deep_Sleep: Known on the BCM2073x devices as HIDOFF (Taken from the Human Interface Device OFF mode from Classic Bluetooth.
Waking the Device:
Permanently Disable Sleep
Notes regarding HidOff:
Deep_Sleep (HIDOFF) is not supported while the connection is up.
However, a connection can be kept when sleep is enabled (but not when deep sleep engages).
When the device is connected/scanning/advertising, it will always sleep between RF activity if the application allows it and there is sufficient time before the next scheduled activity.
Deep_Sleep (HIDOFF) does not retain state, so the chip cannot enter deep sleep when connected.
The most important point in determining Sleep and Deep Sleep modes is when to do it:
In many of our SDK 2.0 examples, power is automatically managed by the firmware based on input device activity.
As a power-saving task, the firmware controls the disabling of the on-chip regulator when in deep sleep mode - More on this later.
This BITES everyone - Be careful:
The BCM20732A0.cgs file has a Low Power Configuration section:
By default:
"Sleep enable" = 1
Change to 0 to disable the sleep function.
################################################################################
# Low power configuration
###############################################################################
ENTRY "Sleep Mode Configuration"
{
"Sleep mode" = "HIDD"
"Sleep enable" = 1 ; Change to 0
}
##############################################################################
Sleep Current Consumption is roughly 24uA using the internal power management of the BCM20732.
In 1.5uA deep sleep, the xtal, IR and PWM blocks will be turned off.
The PWM does not operate in sleep or in deep sleep, and the PWM block is not capable of interrupting or waking up the processor.
GPIOs, peripheral uart, IR transmit, Keyscan and quadrature inputs can interrupt/wake the processor.
GPIOs that are output enabled will remain so and drive as configured in sleep/deep sleep.
Sleep operation in BLE Packet Transmissions:
Q: When sending packets periodically for BLE (e.g. 25 ms to 4 seconds), does the BLE stack put the 20732 in 1.5 uA deep sleep mode between the transmissions or is just the sleep mode (20+ uA)?
A: No, when advertising or in connection, the device will not go into deep sleep. However, it will go into other low power modes like sleep and pause based on the connection/ADV interval and other activities. If you want to ADV every few minutes, it is possible to ADV for some seconds, then configure timed wake from deep sleep and then enter deep sleep. After the configured time, the device will be woken up and then the application will be initialized.
Q: In deep sleep mode, the data sheet says core and base are turned off. Does that mean it loses the RAM contents? If so, where does application software store state information when it goes into deep sleep? The EE or an offboard chip?
A: Yes, in deep sleep the chip will lose its RAM contents. When woken up, the application will be loaded to RAM from the NV storage and re-initialized. This is very similar to a power-on-reset except that in the case of a wake from deep sleep, some HW state information is retained so that the application can find out what caused the wake.
Sleep Times:
Our BCM2073x device includes the ability to wake after configured time.
With the internal clock, this value is anywhere from 64mS to ~36 Hrs.
With an external 32 KHz xtal, 128mS - ~144 Hrs is possible.
PREVENTING THE DEVICE FROM GOING TO SLEEP WHEN USING THE P_UART:
If you are working with the PUART and in particular trying to Rx data with the PUART you will need to ensure that the following functions shown below are added into your PUART_Init() function.
You will also see these functions in the 'uart_firmware_upgrade' example.
The reason these are needed is otherwise the Device will put the PUART to sleep.
These functions disable the device from putting the PUART to sleep:
Put these inside of your PUART_Init() function devlpm_init();
// Since we are not using any flow control, disable sleep when download starts.
// If HW flow control is configured or app uses its own flow control mechanism,
// this is not required.
devlpm_registerForLowPowerQueries(Puart_device_lpm_queriable, 0);
//Callback function that is registered from function shown above:
devlpm_register...()
// Callback called by the FW when ready to sleep/deep-sleep. Disable both by returning 0
// when there is an active download ongoing.
UINT32 Puart_device_lpm_queriable(LowPowerModePollType type, UINT32 context)
{
// Disable sleep.
return 0;
}
Wake time from deep sleep:
Determination of Wake time from deep sleep is a combination of many factors:
Since this involves a full boot, it depends on whether you are using the BCM20732S/36S modules or BCM2073x SOC design, EEPROM or Serial flash (application + patch size), speed of NV access.
20732S modules:
The 20732S contains an EEPROM internally:
Boot Time: boot time* ~= 50ms + ~45mS/KByte of application + patch code (whats printed at the end of a build) assuming default I2C speed (400 KHz).
The 20732 chip-on-board design:
EEPROM Case:
You can increase the read speeds to 1MHz instead of the default 400 KHz.
But the boot time will not reduce by 2.5 times because there is a lot of processing involved during this process.
So this will be 50mS + ~30mS/KByte of app + patch code.
Serial FLASH Case:
When NV storage is serial FLASH, boot time ~= 50mS + 4mS/KByte of code.
BCM20736/7 modules:
EEPROM Case:
boot time ~= 20mS + ~35mS/KByte of app + patch code @ 400 KHz.
If I2C speed is increased to 1 MHz, this should be ~ 20mS + 23mS/KByte.
Serial FLASH Case:
boot time ~= 20mS + 900uS/KByte when SPI speed is 12 MHz.
Note: *boot time here is the time from wake interrupt to application create call.
Advertising and Sleep Modes:
When advertising (ADV) or in connection, the device will not go into deep sleep.
However, it will go into other low power modes like sleep and pause based on the connection/ADV interval and other activities.
If you want to ADV every few minutes, it is possible to ADV for some seconds, then configure timed wake from deep sleep and then enter deep sleep.
After the configured time, the device will be woken up and then the application will be initialized.
Crystal and Sleep:
The external 32KHz oscillator is optional with respect to timed wake from deep sleep.
The internal 128KHz LPO is used for sleep and timed wake from deep sleep
More later..
Please provide comments/questions
Thanks
JT
Show LessThis application snippet demonstrates the e-mail capability based on the state changes on the selected input.
The selected input could be discrete or analog input. Input could be the current temperature, security device going off, PIR detector, reed switch output, etc. For this example discrete input is used and the input is toggled by the push button switch (SW1) on the evaluation board.
To setup the application, please download the attached push2email snipped application and copy it to the WICED -SDK. For example the .../apps/snip directory of the WICED SDK.
Using .../apps/snip/push2email/wifi_config_dct.h, update the wi-fi configuration for WICED target platform board to connect to your network.
Change the CLIENT_AP_SSID with your access point SSID.
Change the CLIENT_AP_PASSPHRASE with your access point's security code.
You should change the "wiced.email.test@gmail.com" email address with your own email address, in the push2email.c file. This should first be changed after #define RECIPIENT (line 48) and then again in the section to setup email account (line 168).
Build the push2email application and download it to your target
snip.push2email-<YourPlatform> download run
For BCM943362WCD4 WICED evaluation board make target would be as following:
snip.push2email-BCM943362WCD4 download run
When the push2email application runs on the target, the initial state of the LED1, based on the state of the SW1 switch, is sent as an email to the recipient. The following would be received by the email recipient: "WICED device is up initial LED state is ON."
As the SW1 switch is pressed to toggle the LED1 state, the state changes of the LED1 are sent to email recipient.
With new smtp signin security added by the mail service providers, embedded devices sign-in is prevented. The wiced.email.test@gmail.com email address is created for demo purposes and the sign-in is set to access for less secure apps. Similar sign-in setup may require to send mail using your own smtp server. To receive email no such setup is required but Wiced device generated emails may end up in spam folder.
Use BCM9WCD1EVAL1 (P402) base evaluation board with BCM943362WCD4 module to re-purpose GPIO pins utilized for serial flash and thermistor.
1. Remove the serial flash (U8) and thermistor (TH1) from the breakaway board. The breakaway board could simply be broken, but because the push button switches and LEDs are used in this demo only some components are removed.
2. Using ULN2803A transistor array, make the connections described in the following schematics.
3. Update SDK with attached code as shown below.
Update .../include/default_wifi_config_dct.h as following or your choice of name and pass phrase.
#define CONFIG_AP_SSID "WICED Motor Control"
#define CONFIG_AP_PASSPHRASE "12345678"
4. Start the WicedSerial.exe serial port application to observe messages from WICED device.
5. Build and download the motor control sample application to the target.
demo.motor_control-BCM943362WCD4_MTR download run
In this case the BCM943362WCD4_MTR is a new platform derived from WICED evaluation board.
6. Connect your wireless web browser supported device (PC or smart phone) to 'WICED Motor Control" with "12345678" pass phrase.
7. Using your web browser go to 192.168.0.1 or directly go to http://192.168.0.1/config/scan_page_outer.htm to connect to your network.
8. Get the WICED board's IP address from the serial terminal and use your browser connect to WICED webpage.
Use ON/OFF to control the motors or your device connected to the re-purposed GPIO.
Use LED Brightness + and - to control LED1 (D1) and LED2 (D2) brightness on the evaluation board.
LED1 brightness could also be controlled using SW1 and SW2 on the evaluation board as well as from the remote webpage.
Here is modified evaluation board to drive DC motors.
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.
Challenge:
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.
Detailed Instructions:
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
Good luck!
JT
Show LessThanks to seyhan for putting this snip together.
It is a good use of the scan application, the push button SW, and the GPIOs
This "snip" will launch the "scan" snip, scan for WiFi networks and display the details on the Console.
The red LED will remain illuminated while the scan is running.
The scan will repeat until the button press and the LED will go out.
Here's how to use it...
Extract the attached "push2scan.zip" directory, to a directory of your choice.
Copy the directory to your WICED SDKs .../Apps/snip directory. You will see the other snips there as well.
When you launch the Eclipse SDK (or Refresh/F5) next you will see your new push2scan "snip" populated.
Copy and Paste the "scan" make target and rename it "snip.push2scan-BCM943362WCD4 download run"
Keep in mind it has to match exactly the name of the directory "push2scan"...
Your "Make Target" should look similar to this
Double-click the target and let it complete until "Target running" is displayed in the "Console" tab
Now have a look at your Console window. In this example we are using the WICEDSerial Windows executable provided here:
WICEDSerial - Console tool to communicate to your WICED Board
You will see the following output on the console:
Notice the red LED is illuminated. This indicates the "scan" is running.
Push SW1 (lower left corner in this photo) to "stop" and "start" the scanning and toggle the LED on/off.
Thank you.seyhan
Show Less