Low Power

Created by Miroslav Biňas / mirek

#### http://kpi.pages.kpi.fei.tuke.sk/iot1
#### https://mattermost.kpi.fei.tuke.sk/iot1
[![Hack Košice 2019](img/hack.kosice.png)](https://hackkosice.com/)
### IoT Challenges * security * ergonomy * technologies for communication * low energy
### Low Power
### General Approaches for Low Power * when **designing software**, and * when **designing hardware**
### Additional Low Power Approaches * lower power supply (at least _3.3V_) * lower the work of microcontroller (e.g. sleep mode, frequency) * use CMOS with low power when idle
### Battery Life dependes on * battery capacity * device consumption
### Battery Capacity * the energy stored in a battery * measured in either watt-hours (Wh), kilowatt-hours (kWh), or ampere-hours (Ahr) * the number of hours for which a battery can provide a current equal to the discharge rate at the nominal voltage of the battery Notes: * http://pvcdrom.pveducation.org/BATTERY/capacity.htm
### Rechargable Batteries * self discharge over the time * don't use them in your _IoT_ solutions!
### Device Consumption $$ t = \frac{battery capacity}{load current} $$ problem: power consumption of device can change in time
### Managing Energy Consumption with Software
### Motivation
### The Polling > Actively sampling the status of an external device by a client program as a synchronous activity [Wikipedia](https://en.wikipedia.org/wiki/Polling_(computer_science))
### Features of Polling * simple, sufficient for most problems * high potential of data loss * synchronous activity - needs more resources
### The Interrupts > Interrupt is a signal to the processor emitted by hardware or software indicating an event that needs immediate attention. [Wikipedia](https://en.wikipedia.org/wiki/Interrupt)
### Features of Interrupts * asynchronous activity - doesn't need so much resources * better reaction time * similar approaches - event driven architecture/programming, observer design pattern
### Polling vs Interrupts main difference - whether *software* asks itself or *hardware* let microcontroller know about special event
### Interrupt Service Routine * handles the interrupt * executed automatically, when interrupt occurs * main program is paused, ISR is executed, and after execution main program continues, where it was paused
### ISR Features * no return value * no params * only way, how to communicate with the rest of the system from within ISR, is with *global variables*
### Recommendations for ISR When writing an _Interrupt Service Routine_ (ISR): * Keep it short * Don't use `delay()` * Don't do serial prints * Make variables shared with the main code `volatile` * Variables shared with main code may need to be protected by _"critical sections"_ * Don't try to turn interrupts off or on Note: * http://www.gammon.com.au/interrupts
### Reasons to use Interrupts * To detect pin changes * Watchdog timer * Timer interrupts - used for comparing/overflowing timers * SPI data transfers * I2C data transfers * USART data transfers * ADC conversions (analog to digital) * EEPROM ready for use * Flash memory ready Note: * http://www.gammon.com.au/interrupts
### Types of Interrupts * **hardware** / **external** / **pin-change** interrupts * **software** / **internal** interrupts / **timers**
### Interrupt Vector
## Questions?
![qr code](https://api.qrserver.com/v1/create-qr-code/?data=http://bit.ly/2NwNYwr&size=300x300) (**http://bit.ly/2u1sPBh**)