The General Interest forum is for non-support discussion only. If you have a question about, or need help with a Silicon Labs product, please visit one of the individual product forums.
 

Application engineers do not monitor this forum.
 

View General Interest Board Guidelines ›

Hi Everyone, I'm the SVP/GM responsible for all MCU, Wireless, and Sensor Products at Silicon Labs. This includes everything from high level strategy down to all product roadmaps and features. I want to make myself available to the community to ask questions. As they come in, I'll respond to them here. I'll answer all questions through the end of August.

 

Have fun.

 

[edit: I'm going to log on 1-2x per day and answer questions until the end of August]

  • Discussion Forums
Unanswered
  • Thanks Daniel, I'll go first:

     

    I've been stalled in my development of a WT32i based product for a week now.  The issue began with a documentation omission in the iWrap manual, and when that was resolved I was told I needed to update the firmware in the WT32i module. The module because "bricked" during that process, and I've been stuck there communicating back in forth with the tech support guy ever since. He's working hard, but the overlap between his working hours and mine apparently leave room for just a single response a day.

     

    As a result, it's taken > a week to resolve what i hope is a simple product, and I am fast approaching the point where I may have to recommend an otherwise less attractive device. You will understand how a company would be leery of proceeding into mass production after both the unexplained crash and the fact that it takes a week to resolve it.

     

    Can't more timely support for US-based customers be provided?

     

    Gerald Cooper

    Virginia

    0
  • Hi @gcooper, thanks for reaching out. As you know, we are in a global industry, which means that we have customers in almost every country in the world. Our goal is to have 100% coverage in the three major regions (AMER, EMEA, APAC) to work in real-time, but it is not always possible. I hear you and will discuss this with the team. In the meantime, I'll have someone reach out to you separately.

    0

  • DanielCooley wrote:

    Hi Everyone, I'm responsible for all MCU, Wireless, and Sensor Products at Silicon Labs. This includes everything from high level strategy down to all product roadmaps and features.


    Hi Daniel,

    ok : One road map question, is around Wide Vcc MCUs, which are a somewhat glaring blindspot in SiLabs lineups. SiLabs have only the now quite old C8051F5xx series as Wide Vcc.

     

    Most new vendor releases these days, especially in small MCUs, are Wide Vcc.

    Some quick examples:

     STC STC8F 8051 series, is wide Vcc and 24b opcode fetch

     Nuvoton have 28c, 16kF wide Vcc parts,

     Nuvoton have Wide Vcc in both ARM and 8051 & new ARMs have 1.8~5.5V VccIO feature.

     SyncMOS have 1.8~5.5V 1T 8051 series

     Infineon XMC1xx series are 1.8~5.5V, as are Cypress PSoC4 family.

     

    Other questions :  "Silicon Labs IoT Business. AMA."

     What is AMA ?

     Does IoT Business include Clock Generators ?

    0
  • Hi @jmg, AMA stands for 'ask me anything' Robot Happy

     

    Regarding wide VCC products, Silicon Labs IoT products are for the most part is focused on energy-efficient and battery-powered applications. This means we need to make design choices that optimize for VCC levels at 3.8V and below. If you look at any of the most common low power platforms (CC26xx, STM32L, nRF52x, KW4x, and so on), you will find similar characteristics.

     

    Lastly, the IoT business doesn't include clock generators specifically. It includes MCU, Wireless, and Sensors. But feel free to visit our webpage on clock generator products!

    0
  • With the popular LiPo batteries going upto 4.35V I would say that 3.8V is not enough for battery-powered applications.

    0
  • @vanmierlo you're right about battery chemistries like LiPo and Li-Ion. In an ideal world, we'd be able to support a direct connection to VCC of 5.5V, which would cover all major battery chemistries plus USB. But as we ride Moore's law down the curve, the transistor options become more and more limited. At 40nm, for example, we are stuck with 2.5V transistors as the maximum VCC. We have to play all kinds of design tricks just to get up to the 3.8V that we support today. We could simply stick with older technologies with 3.3V or even 5V transistors, but then we wouldn't be able to pack enough memory, processor, and RF capabilities into our chips.

     

    What most of the market has adopted is power management ICs (PMICs) to manage the charging and/or discharging of batteries that go above the ~3.8V range. You can find tons of examples out there from the usual suspects (TI, ADI, etc.).

    0
  •  Thanks, but not quite the road-map answer many were hoping for...


     

    Regarding wide VCC products, Silicon Labs IoT products are for the most part is focused on energy-efficient and battery-powered applications. This means we need to make design choices that optimize for VCC levels at 3.8V and below.


    ?  Yet a very common battery chemistry today is 4.3V  ?

    http://batteryuniversity.com/learn/article/charging_lithium_ion_batteries

     


    If you look at any of the most common low power platforms (CC26xx, STM32L, nRF52x, KW4x, and so on), you will find similar characteristics

    I see you focused there on wireless and 32b part codes, when I mentioned small MCUs, but even in 32b & wireless, look at most-recent entries like PSoC4, which offers Wide Vcc and RF.

     

    Quick highlights :

    • Wide Operating Range 1.7 - 5.5 V (Radio operational 1.9 V onwards)
    • Flexible Low Power Modes
      • 1.3-µA Deep-Sleep Current
      • 150-nA Hibernate Current
      • 60-nA Stop Current
    0
  • Hello Daniel,

     

    Well over two weeks ago, I assured my client that in little over a week I would have some very basic code for him.  We didn't even plan to use the radio; just simple IO, a uart connection to a PC, and a working I2C channel.  My schedule was based upon past experience with three different btle soc vendors.

     

    To date, I am able to toggle an LED in response to a button press on one of your starter kits.  That's it.  My client is unhappy, my reputation has taken a hit, and I am unhappy.

     

    I'm confident things will get better if I can ever get past this initial set of hurdles, but I am running out of patience and faith in this environment.  

     

    Steve

     

    0
  • I'm confident things will get better if I can ever get past this initial set of hurdles,

    one important item missing which chip?

    0
  • Hi Daniel,

     

    To the extent you can talk about silicon roadmap, are there any plans to offer chips with...

     

    1) Separate VDD/AVDD support. Many chips allow this, but the EFM32s that I know of do not: these pins must be essentially tied together, dragging all the system's switching noise or other voltage wiggles onto the analog rail. This unnecessarily complicates mixed-signal designs (ADC usage, etc.), especially toward IoT-focused designs, where they are often running from a small (relatively high-impedance) battery source and a power-hungry radio sharing that source can key up at any time.

     

    2) More RAM! Any plans to offer EFM32 product variants with >128K RAM, especially the RF parts? Any plans to offer DSP/FPU-enabled (M4 / Wonder Gecko) parts with >32K? I suspect there is a good reason behind this amount (fixed silicon area and making room for the FPU?), but 32K of RAM is pretty crippling for many of the applications you'd need a DSP for. A good example is power-limited IoT applications doing, say, equipment health monitoring, power and bandwidth constraints force most of the processing (including nasty signal processing and compression) to happen device-local rather than fob it off to a distant server. Understandably, having the RAM on-die has power implications whether you use it or not (some other vendors get around this with a register to cut power to unused banks), but when you need it, you need it, and chucking a giant external SRAM on the board isn't always an option.

     

    Thanks!

    0
  • @jmg we will be introducing 5V parts in a few years (they are on the roadmap) but nothing in the next year or two. For applications that require higher voltages, you can use the PMICs I referenced or vendors like Infineon XMC, Cypress PSoC4, NXP Kinetis KE, Atmel SAM C, etc. There are lots to choose from.

    0
  • @Drmn4ea, great questions.

     

    1. Our latest (and all future) products will support separate VDD/AVDD supplies. You can see this in our latest Wireless Gecko (EFR32 [link]) and Gecko (EFM32 [link]) releases. We detail this extensively in AN0002, which can be found on our website...link here.

     

    2. Yes, more RAM is coming soon; it's one of our most requested features. I don't want to give it all away here, but you'll have alot to play with...alot. Robot Happy

    0
  • Very cool!

    Are you able to give any more details on how soon we can expect the high-RAM parts?

    0