- Silicon Labs Community
- Welcome and Announcements
- Silicon Labs Knowledge Base
- 8-bit MCU
- 32-bit MCU
- Bluetooth / Wi-Fi
- Other Products Category
- Optical/RH/Temp Sensor
- Other Products
- Hardware and Software Tools
- Simplicity Studio and Software
- General Discussions and Suggestions
- Chinese Forum
- Software Libraries
- Development Kits
- Reference Designs
- Third Party Tools
- White Papers
- Official Blog of Silicon Labs
- Chinese Blog
09-06-2016 07:52 AM
@Timur we don't currently have any Cortex-M7 or Cortex-A products in the market. I'll address each separately.
In the case of the M7, it is a little too beefy for most of the applications that we are targeting. It starts to look more like a microprocessor architecture than a traditional MCU architecture from a system point of view. I'm not ruling out this kind of product in the future, but we are focused more in the M4-ish territory today with smart hardware enhancements (e.g. the crypto accelerators on our Wireless Geckos...much faster and lower power than running it in software).
In the case of Cortex-A, this is definitely out of scope for us today. ARM is doing a good job of bridging the gap between the Cortex-M and Cortex-A with products like the A32, but even this processor is out of scope for Silicon Labs today.
09-06-2016 08:17 AM
@ingse this currently on the roadmap and will come before the end of the year. We will then extend GCC support to the rest of our stacks in 2017. But bluetooth gets the priority!
09-06-2016 03:04 PM
@sunghwnCho HDP really isn’t my strong point, to dig deeper into this we would need to know the iWrap version. I have two seasoned iWrap experts in the team so they will be capable helping them further setting up the medication sensor. The app note has some bits of the configuration, but probably needs more explaining to help the customer.
On the interoperability issue with Samsung Smartphone, we would need to know more information on the iWrap version (again), the exact model and Android version. The error code would indicate the mobile device disconnects.
All and all, I think you should create a support request, or ask the question under the wireless forum.
09-06-2016 03:08 PM
@Sahil we are currently recommending that new designs use Si1133 instead of Si1132. The si1133 will give the user improved accuracy over a larger range of operating conditions compared to the si1132. The si1132 is not designed for use in reflected UV environments.
The si1133 will detect reflected UV. To improve performance in environments with off-vertical axis incident light, we recommend installing a diffuser. Recommendations for potential diffuser materials are given in the user guide for si1133 (https://www.silabs.com/Support%20Documents/TechnicalDocs/UG163.pdf).
09-06-2016 06:35 PM
Thank you for your answer.
We tested Samsung Smartphone as Samsung Galaxy Note5(SM-N920K) - Android 6.0.1
Samsung Galaxy Alpha(SM-G850S)
Samsung Galaxy Note2(SHV-E250K) - Android 4.4.2
Samsung Galaxy S4(SHV-E300K) - Android 4.4.2
Also iWrap version is 5.6.0.
If you want more information , Please tell to me.
09-06-2016 08:59 PM
@jlangbridge Don’t worry as we have not discontinued the BGScript support and but will continue to be a part key of our development tools offering for our Bluetooth and Wi-Fi products going forward.
Why you haven’t seen huge improvements in BGScript recently is because we have put a lot of effort in improving our C development experience and making sure there is a great integration and user experience with Simplicity Studio, our value-add tools like Energy Profiler and Packet Trace and the Bluetooth SDK and 3rd party tools like the Bluetooth SIG’s Bluetooth Developer Studio.
While doing this we have unfortunately not been able to develop BGScript at the same pace.
09-06-2016 09:02 PM
@mikey0407 Good catch, as optional is confusing as the Thread/ZigBee stacks require the EWARM compiler and doesn’t support GNU/GCC today. We will be supporting GNU/GCC in the first half of 2017 for the Thread/ZigBee stacks.
We will correct the documentation so that it is more clear as to what tools are required for the different stacks.
09-06-2016 09:12 PM
The original Gecko series devices have the ability to output PRS channels 0-3 to a GPIO. For example, WG can route 4 channels with up to two locations.
PRS output on some channels can be routed to external pins. This allows PRS to connect to external devices.
Routing a PRS signal to an external pin can also be a useful tool when debugging peripherals that operate while the CPU is asleep.
In this example, two PRS channels are used. The first channel is used by the TIMER to trigger the A/D converter, and the second channel is used by the A/D converter to signal when the conversion is done. When routing these two PRS channels to external pins, you can connect an instrument and measure the delay from a sample is triggered to the sample is done.
The newer parts have a lot more channel pin outputs and a lot more flexibility with route locations. For example, EFR32MG has 12 channel outputs and up to ~16 route locations for each channel output.
In addition, there are two ways to fake GPIO outputs by using other consumers. You could use the Timer CCn consumer to generate an output on the CCn pin output, which can be routed to several locations. See AN0025 main_prs_channel_scan example.
There’s also the ability to tie PRS to DMA request 0/1 using any of the PRS signals on EFR and newer. You could setup the DMA to write to the GPIO registers or use the new LDMA sync descriptor to wait until the PRS signal is asserted.
I hope that helps!
09-07-2016 01:00 AM
It's good to see the new micros are getting some love on the prs outputs. Those numbers sound good and should make it much more flexible.
I didn't follow how you intend to fake prs outputs onto gpio?
AN0025 main_prs_channel_scan simply waits for a prs event on the compare channel. There is no physical output to a gpio from a prs signal in this sample? It merely waits then does something in code. This is not useful. I'm talking about a real time(hardware) signal to exactly match a prs signal on an output pin that is not a PRS output. I also fail to see how you plan to use a timer ccn input prs to output to the same ccn output pin. These CC run as capture or compare, not both? ie a CCcapture can be triggered by a prs signal , but then the same CC is not able to be used as a compare at the smae time to generate pin output? How exactly can you do this on the current EFM's?
Also using a dma to write to a gpio will not work well as you have to write to the entire port. This would only be possible if all the other pins were inputs and not GPIO outputs as they would get overwritten by the port write, so it has a very limited use.
10-12-2016 11:04 AM
We are presently using WF121 in a product and want to add blue tooth and long range RF capability in the next gen product. Can you recommend a solution for us to investigate?
10-13-2016 08:17 AM
Thank you for all your valuable questions and feedback. The AMA (Ask Me Anything) session with Daniel Cooley, our SVP/GM, is now closed. But we will be hosting another AMA session with interesting IoT topics soon. So please stay tuned for updates!
Nari | Community Manager | Silicon Labs