## Week 03
miroslav.binas@tuke.sk / [**IoT1**](http://kpi.pages.kpi.fei.tuke.sk/iot1)
#### 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
### 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
### 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**
![qr code](https://api.qrserver.com/v1/create-qr-code/?data=http://bit.ly/2NwNYwr&size=300x300)
(**http://bit.ly/2u1sPBh**)