4 ms·

There are people who care about power as well, right? E.g. the security system where I'm living now has remote wireless units with fairly big lithium batteries

by hga 11y ago

There are people who care about power as well, right? E.g. the security system where I'm living now has remote wireless units with fairly big lithium batteries that last roughly 10 years....

bsder 11y ago
> There are people who care about power as well, right? Not as much as you would think. Battery life in the embedded space is mostly defined by how much you can stay off and what your leakages are rather than what your active current is--since you can quite often just stay asleep a little longer. Most of these microcontrollers are in the same range for leakage and are at the point where you have to start considering other leakage sources on the board (capacitors for example). It's Amdahl's Law in action: the big contributors have all been smacked down pretty much as far as they can (sure, you might get 10% here or there ... but it's going to be real work now) so now getting overall performance isn't so easy. If someone really wanted to get my attention with their microcontroller, they should produce a combined BLE/WiFi chip where the WiFi can be run off of a coin cell battery like BLE (that would mean something like 2mW transmit power rather than 200mW).
- paulmd 11y ago
  In particular I suspect there's very few gains that can be made for wireless communications. My contention is that there exists a information-theoretic lower bound on the amount of energy it takes to transmit a given amount of information a given distance. Like a heat engine, at some point you can no longer make generational improvements in efficiency. You get asymptotically closer to the bound, you can't ever beat it. And wireless power tends to dominate the power budget of anything that uses it. High-bandwidth signals require more power to travel a given distance, low-bandwidth signals go farther on less power but transmit less information. Intuitively this is why you can go worldwide with CW (Morse code) on just a few watts of power, while a SSB signal on the same frequency doesn't go far at all. But I think you can mathematically support this by playing with the bandwidth+power terms of the Shannon-Hartley theorem. If we want to transmit a given amount of data per time unit, there are two natural extremes. We can either transmit it at the average data rate necessary, or we can race-to-sleep by blasting it out as fast as possible. I'm not sure which is more efficient given that SNR is inside the log2 of the S-H theorem, it depends on the relationship between SNR and bandwidth as you spread a given quantity of RF power thinner and thinner. Based on the log2 I would think this is an inverse-square kind of thing, making it an equivalent tradeoff. Showerthoughts: because of the Inverse Square Law, it's probably more efficient to make a mesh of multiple small hops than a single long shot. As the spacing of the mesh decreases to zero, you end up with a wire. Also, check out the ESP8266 chip, it doesn't have a BTLE onboard but it does handle the "SOC with low-power wifi" thing.
  - bsder 11y ago
    > Also, check out the ESP8266 chip, it doesn't have a BTLE onboard but it does handle the "SOC with low-power wifi" thing. I know all about it. Still won't run on a coin cell. Nobody will build a 2mW WiFi chip until Apple forces somebody to build it. Then EVERYBODY will rush to build it. Then EVERYBODY-1 will go bankrupt when Apple doesn't use their chip. It's the Zen of Hardware.
- petra 11y ago
  When LoRa will be deployed, it would probably be a much better solution than wifi.
  - bsder 11y ago
    Ayup, but until then I need a gateway to talk to the outside world. If I don't have a phone, then that's WiFi.
aylons 11y ago
Yes, there are, and the industry players are pushing this as their main differentiator. However, for most projects I see, people don't care much. A better efficiency in a car is good, but a few microwatts can't compete with double the RAM in this context. Lots of electronics projects are not battery dependent, and engineers care more about reliability, development ease and speed and flexibility. I surely like the idea of not reimplementing a firmware ten years from now by just upgrading the micro controller, instead of dealing with a whole new set peripheral drivers.
t2015_08_25 11y ago
yes. bsder's comment should only be taken to represent his own reality. As an embedded firmware developer for 18 years, I've seen every project has its own constraints, just like most engineering. Design constraints on microcontrollers include: power, clock speed, FPU, number of digital GPIO, number of analog GPIO, quality of IDE and debugger, price, package size, available operating systems, longevity of part, volatile and non-volatile memory, quality of compilers, peripherals and so on. IME, Atmel had a great 8-bit series with good documentation and few bugs that scaled from 8-pins to 40 very well. With analog inputs and PWM output, they were well-equiped to do analog input->processing->output tasks. They really blew it when they moved to 32-bit as others have said. They weren't very fast, changed all the peripherals around and didn't improve on the clumsy fuse system. ARM M ("M"->embedded) Cores like stm32f4, Freescale Kinetix, etc. have all but obliterated Atmel. Finally differentiation in the Cortex family includes ethernet (F27/F29), Front-side Memory Controller, FPU, low-power (STM32L0), extreme low power (MSP432), low-price (STM32F0) and so on.
- bsder 11y ago
  > yes. bsder's comment should only be taken to represent his own reality. No argument. > Design constraints on microcontrollers include: power, clock speed, FPU, number of digital GPIO, number of analog GPIO, quality of IDE and debugger, price, package size, available operating systems, longevity of part, volatile and non-volatile memory, quality of compilers, peripherals and so on. True. But most of the embedded work I have been dealing with over the last 5? years seems to be very different from prior. In the last 5 years, choice of microcontroller moved from contentious to almost an afterthought: 8-bit, 16-bit, 32-bit? Motorola/Atmel/Microchip/ST/Renesas? gcc vs proprietary? Sufficient frequency? GPIB/RS-232/USB? All gone. I get asked about memory and footprint (BGA/CSP is starting to become popular ... bangs head on wall) and that's about it. Even cost just doesn't come up much anymore--I don't know if its that things are cheap enough or that everybody now actually knows what microcontrollers cost. Pretty much things seem to be splitting into two bands: internal memory only (M0, M3/M4 class--generally an RTOS) and external memory (A-class+, runs Linux). And, given some of the higher end M-series, I suspect Linux is going to hit there shortly.
  - 11y ago
dfox 11y ago
For commodity systems that run off cheap lithium primary cell with essentially any modern low power microcontroller the major limiting factor for battery lifetime is actually the self-discharge rate of the battery itself (and to somewhat lesser extent the fact that most lithium battery chemistries have discharge curves that depend on peak load).

by hga 11y ago

There are people who care about power as well, right? E.g. the security system where I'm living now has remote wireless units with fairly big lithium batteries that last roughly 10 years....

bsder 11y ago

> There are people who care about power as well, right? Not as much as you would think. Battery life in the embedded space is mostly defined by how much you can stay off and what your leakages are rather than what your active current is--since you can quite often just stay asleep a little longer. Most of these microcontrollers are in the same range for leakage and are at the point where you have to start considering other leakage sources on the board (capacitors for example). It's Amdahl's Law in action: the big contributors have all been smacked down pretty much as far as they can (sure, you might get 10% here or there ... but it's going to be real work now) so now getting overall performance isn't so easy. If someone really wanted to get my attention with their microcontroller, they should produce a combined BLE/WiFi chip where the WiFi can be run off of a coin cell battery like BLE (that would mean something like 2mW transmit power rather than 200mW).

paulmd 11y ago
In particular I suspect there's very few gains that can be made for wireless communications. My contention is that there exists a information-theoretic lower bound on the amount of energy it takes to transmit a given amount of information a given distance. Like a heat engine, at some point you can no longer make generational improvements in efficiency. You get asymptotically closer to the bound, you can't ever beat it. And wireless power tends to dominate the power budget of anything that uses it. High-bandwidth signals require more power to travel a given distance, low-bandwidth signals go farther on less power but transmit less information. Intuitively this is why you can go worldwide with CW (Morse code) on just a few watts of power, while a SSB signal on the same frequency doesn't go far at all. But I think you can mathematically support this by playing with the bandwidth+power terms of the Shannon-Hartley theorem. If we want to transmit a given amount of data per time unit, there are two natural extremes. We can either transmit it at the average data rate necessary, or we can race-to-sleep by blasting it out as fast as possible. I'm not sure which is more efficient given that SNR is inside the log2 of the S-H theorem, it depends on the relationship between SNR and bandwidth as you spread a given quantity of RF power thinner and thinner. Based on the log2 I would think this is an inverse-square kind of thing, making it an equivalent tradeoff. Showerthoughts: because of the Inverse Square Law, it's probably more efficient to make a mesh of multiple small hops than a single long shot. As the spacing of the mesh decreases to zero, you end up with a wire. Also, check out the ESP8266 chip, it doesn't have a BTLE onboard but it does handle the "SOC with low-power wifi" thing.
- bsder 11y ago
  > Also, check out the ESP8266 chip, it doesn't have a BTLE onboard but it does handle the "SOC with low-power wifi" thing. I know all about it. Still won't run on a coin cell. Nobody will build a 2mW WiFi chip until Apple forces somebody to build it. Then EVERYBODY will rush to build it. Then EVERYBODY-1 will go bankrupt when Apple doesn't use their chip. It's the Zen of Hardware.
petra 11y ago
When LoRa will be deployed, it would probably be a much better solution than wifi.
- bsder 11y ago
  Ayup, but until then I need a gateway to talk to the outside world. If I don't have a phone, then that's WiFi.

aylons 11y ago

Yes, there are, and the industry players are pushing this as their main differentiator. However, for most projects I see, people don't care much. A better efficiency in a car is good, but a few microwatts can't compete with double the RAM in this context. Lots of electronics projects are not battery dependent, and engineers care more about reliability, development ease and speed and flexibility. I surely like the idea of not reimplementing a firmware ten years from now by just upgrading the micro controller, instead of dealing with a whole new set peripheral drivers.

t2015_08_25 11y ago

yes. bsder's comment should only be taken to represent his own reality. As an embedded firmware developer for 18 years, I've seen every project has its own constraints, just like most engineering. Design constraints on microcontrollers include: power, clock speed, FPU, number of digital GPIO, number of analog GPIO, quality of IDE and debugger, price, package size, available operating systems, longevity of part, volatile and non-volatile memory, quality of compilers, peripherals and so on. IME, Atmel had a great 8-bit series with good documentation and few bugs that scaled from 8-pins to 40 very well. With analog inputs and PWM output, they were well-equiped to do analog input->processing->output tasks. They really blew it when they moved to 32-bit as others have said. They weren't very fast, changed all the peripherals around and didn't improve on the clumsy fuse system. ARM M ("M"->embedded) Cores like stm32f4, Freescale Kinetix, etc. have all but obliterated Atmel. Finally differentiation in the Cortex family includes ethernet (F27/F29), Front-side Memory Controller, FPU, low-power (STM32L0), extreme low power (MSP432), low-price (STM32F0) and so on.

bsder 11y ago
> yes. bsder's comment should only be taken to represent his own reality. No argument. > Design constraints on microcontrollers include: power, clock speed, FPU, number of digital GPIO, number of analog GPIO, quality of IDE and debugger, price, package size, available operating systems, longevity of part, volatile and non-volatile memory, quality of compilers, peripherals and so on. True. But most of the embedded work I have been dealing with over the last 5? years seems to be very different from prior. In the last 5 years, choice of microcontroller moved from contentious to almost an afterthought: 8-bit, 16-bit, 32-bit? Motorola/Atmel/Microchip/ST/Renesas? gcc vs proprietary? Sufficient frequency? GPIB/RS-232/USB? All gone. I get asked about memory and footprint (BGA/CSP is starting to become popular ... bangs head on wall) and that's about it. Even cost just doesn't come up much anymore--I don't know if its that things are cheap enough or that everybody now actually knows what microcontrollers cost. Pretty much things seem to be splitting into two bands: internal memory only (M0, M3/M4 class--generally an RTOS) and external memory (A-class+, runs Linux). And, given some of the higher end M-series, I suspect Linux is going to hit there shortly.
- 11y ago

dfox 11y ago

For commodity systems that run off cheap lithium primary cell with essentially any modern low power microcontroller the major limiting factor for battery lifetime is actually the self-discharge rate of the battery itself (and to somewhat lesser extent the fact that most lithium battery chemistries have discharge curves that depend on peak load).