Download: 8-bit Microcontroller Application Note AVR105: Power Efficient High Endurance Parameter Storage in Flash Memory

8-bit Microcontroller Application Note Rev. 2546A–AVR–09/03 AVR105: Power Efficient High Endurance Parameter Storage in Flash Memory Features • Fast Storage of Parameters • High Endurance Flash Storage – 350K Write Cycles • Power Efficient Parameter Storage • Arbitrary Size of Parameters • Semi-redundant Parameter Storage • Optional Verification of Written Parameters • Optional Recovery on Power Failure Introduction Embedded systems are relying on parameters that can be preserved across RESET or power loss. In some systems this static information is used to initialize the system to a correct s...
Author: Walway Shared: 8/19/19
Downloads: 299 Views: 2014

Content

8-bit

Microcontroller Application Note

Rev. 2546A–AVR–09/03

AVR105: Power Efficient High Endurance Parameter Storage in Flash Memory Features

• Fast Storage of Parameters • High Endurance Flash Storage – 350K Write Cycles • Power Efficient Parameter Storage • Arbitrary Size of Parameters • Semi-redundant Parameter Storage • Optional Verification of Written Parameters • Optional Recovery on Power Failure

Introduction

Embedded systems are relying on parameters that can be preserved across RESET or power loss. In some systems this static information is used to initialize the system to a correct state at start-up, in other systems it is used to log system history or accu- mulated data. EEPROM memory can be used for this, but cannot match the speed of Flash memory when multiple bytes need to be stored at the same time. The reason that Flash memory is more efficient for larger parameter sets is that page programming can be used, which decreases the programming time. The programming time per byte is thereby lower for Flash than for EEPROM when storing multi-byte parameter sets. As a direct result of a faster storage method, the power consumption can be reduced since more time can be spent in sleep mode. This application note describes how to implement a high endurance parameter stor- age method in Flash memory using the self-programming feature of the AVR. By utilizing an entire Flash page and an access method similar to the one used for circu- lar buffers, each single memory location in the Flash page is not write-accessed as often as if only one memory location was used. This approach increases the endur- ance of the storage and ensures that the storage area is not “worn out”. The storage endurance is proportional to the ratio between the size of the parameter set and size of the page allocated for the storage “buffer”.,

Theory of Operation The megaAVR® series has a feature called “self-programming”. This feature makes it

possible for the AVR to reprogram the internal Flash program memory. The program memory can be used in all AVRs to store constants, and now also parameters due to the possibility to change the contents of the Flash at run-time. Using the Flash memory for parameter storage is however not quite as simple as for example interfacing the EEPROM. The self-programming feature is intended to be used for firmware updating, but its flexibility allows it to be used for Flash parameter updating as well. This section describes basic information about Flash memory that is required to use the AVR’s internal program memory for parameter storage.

Read-While-Write Flash The Flash memory can be reprogrammed using the SPM instruction. The SPM instruc-

tion can only be executed from the Boot section of the memory. Executing the SPM instruction from the application section will have no effect. The Application section is located from address 0x0000 and up to the start of the Boot section (see Figure 1). Four different Boot section sizes can be selected; the Boot section size is determined by the fuse setting. The boot sizes that can be selected are depending on the AVR used. Figure 1. Memory Map of the ATmega128 Application and Boot Sections Program Memory BOOTSZ = "11" $0000 Application Flash Section End RWW Start NRWW Application Flash Section End Application Boot Loader Flash Section Start Boot Loader FlashendPMThe Boot section is always located in the part of the Flash referred to as the No-Read- While-Write (NRWW) section. The Application always includes the part of the Flash called the Read-While-Write (RWW) section (see Figure 1), but can, depending on the selected size of the Boot section, also include some of the NRWW part as well. When No Read-While-Write Section Read-While-Write Section 2 AVR105 App Note,

AVR105 App Note

the maximum Boot section size is selected the Boot section is taking up the entire NRWW part and the Application section is therefore purely RWW memory. The NRWW and the RWW parts are fixed and are not affected by the size of the Boot section. Refer to the datasheet of a device with self-programming for more details about this. A difference between the NRWW and the RWW part is that while erasing or writing pages in the RWW section, the AVR can continue to execute program code located in the NRWW part of the memory. This is not possible when erasing or writing pages in the NRWW part: the AVR core is halted while modifying pages in the NRWW part of the Flash. Roughly speaking, code located in the boot section can execute while the appli- cation section is being reprogrammed, assuming that the page being modified in the application section is located in the RWW memory. Consequently, the part of the code updating the Flash parameters must be located in the Boot section, and the Flash parameters must be located in the RWW part of the application section if the AVR is to continue operating while updating the parameters. This is desired for instance if interrupts must not be blocked while writing the parameters.

Erasing and Flash memory consists of independent cells each representing a single bit. The Flash Programming a Flash cells are base on floating gate transistor technology: an electrical charge “trapped” on Cell the transistor gate is determining the logic level read of the Flash cell. Slightly simplified,

the way that the Flash works can be described as follows: When “erasing” a cell, a charge is placed on the gate and the cell is read as logic one. “Programming” the Flash is equivalent to discharging the gate, bringing the logic value to zero. It is only possible to program (discharge) a cell that has been erased (charged). The Flash is arranged in pages. Erasing and programming the Flash is, when using Self Programming, done in pages. A Flash erase is performed on an entire page and a Flash write can be performed on an entire page. Note that bits can be programmed individually. Since only the bits being programmed are discharged, the remaining unprogrammed bits are still charged. Any unprogrammed bit can be programmed at a later stage. Therefore, programming a byte that is already programmed, without erasing it in between, will result in a bit-wise AND between the old value and the new value. Writing the value 0x01 to a Flash byte requires that the byte (8 Flash cells) is first erased, which makes the byte take the value 0xFF. To write (program) the value, the 7 most significant bits (Flash cells) are discharged. If the Flash is not erased in advance, it may not be possible to program it to the intended value: Assume that the value of the byte was 0xFE and that it was programmed with 0x01; the result would be 0x00, since the LSB could not be changed from zero to one.

Flash Endurance The fact that a parameter(1) can be stored several times within a single Flash page

makes the Flash suitable for parameter storage; the Flash cells have a guaranteed endurance of 10,000 erase/write cycles. That is, each cell can be erased and pro- grammed 10,000 times. Therefore, if a parameter can be written 10 times in one page by using different locations each time, the endurance of the storage (page) as a whole can be seen as 100,000 write cycles. This is because each cell is only erased and writ- ten 10,000 times by moving the parameter around within the page. Note: 1. The term “parameter” in this context covers both single parameters and sets of parameters. “Parameter” can thus refer to a set of data of arbitrary size.,

Write Time When writing to EEPROM one byte is written at a time. This is not the case when using

Flash since page programming is utilized. It is therefore an advantage to use Flash stor- age when the size of the parameter is larger than a single byte. The larger the parameter, the less time is used per stored byte. Writing a parameter of type long (4 bytes) takes approximately 4 ms (excluding the erase time, which is of the same duration). It thus takes 1 ms per byte when writing a long parameter to the Flash. In comparison it takes 32 ms to write the same amount of data to the EEPROM(1). For the EEPROM the erase is included, but the comparison is fair, since the erase of the Flash is only done when all locations in the Flash pages are used up: Consider using Flash parameter storage with an ATmega128. The page size for this device is 256 bytes. It is possible to store a long variable 256/4 = 64 times in one page. The duration of the erase should therefore be averaged over 64 writes to deter- mine the average erase-write time for the storing of the long variable. The erase time of approximately 4 ms divided by 64 is … not much. The conclusion is therefore that a larger parameter set is more efficient in Flash storage in terms of write time – thus more time can be spent in sleep modes, saving valuable power. Note: 1. Using ATmega128 as example, the EEPROM programming time is device dependent – please refer to the datasheet of the used device for these details. Flash Write Access The Flash and the EEPROM share modules for erasing and programming memory. The Constraints resulting constraint is that the EEPROM and Flash cannot be written (or erased) at the same time. This means that before using the self-programming feature to modify the program memory, it should be tested whether an EEPROM write cycle is ongoing. If so, the self-programming must wait for the EEPROM write-access to finish. This also applies the other way around; EEPROM write access must wait for Flash write-access to finish.

Flash Data Retention The duration of time that a programmable memory can preserve the correct values is Time referred to as the data retention time (or just data retention). The reason why the mem-

ory does not have infinite data retention is that the memory cells are leaking. This means that the charge stored in the cells is weakened over time and at some instance the charge no longer represents the logic level that it should have. Both the erased and the programmed cells are leaking towards an unpredictable state. If the data retention time is exceeded, the contents of the Flash memory become unreliable. Decreased Data Retention When erasing and writing the Flash cells they are physically worn. Read access does Due to Erase and Write not affect data retention. As the number of erase/write cycles increases, the leakage Access from the cells increases. The consequence is that the charge is weakened faster and that the data therefore will become invalid sooner – in other words, the data retention time is decreased. If the number of E/W cycles performed on a cell exceeds the guaran- teed 10K E/W cycles, the data retention will decrease below the expected 20 years. In relation to parameter storage in Flash it is important to know that the Flash pages are independent of each other; if one Flash page is used for parameter storage this page may have decreased data retention, while the rest of the Flash, used for program code, is not affected by the decreased data retention of the parameter page.

Power Loss One must assume that any embedded systems can be exposed to power failures. This Considerations is one of the reasons for using non-volatile memory types for parameters; it will then be

possible to recover the parameters after power cycling. 4 AVR105 App Note,

AVR105 App Note

There are many different methods to verify that parameters have been written correctly. The preferred choice depends on the time and code space available to do the verifica- tion. A safe method that uses very little memory space and time, is keeping a write- complete flag in a static part of the memory. This flag can be used when recovering from a power failure to determine if the last write was correctly completed. If not, appropriate actions can be taken. The considerations related to avoid Flash corruption resembles to those that applies for EEPROM corruption (refer to the AVR datasheet regarding voiding EEPROM corrup- tion). To avoid Flash corruption due to power loss it is therefore recommended to always enable the Brown-out Detection feature when using the self-programming feature.

Using Self-programming Details regarding the procedure used to perform self-programming can be studied in the

device datasheets and in the application note ”AVR109: Self Programming”. It is important to notice that a write-cycle to Flash is not stopped by an External RESET or a Brown-out RESET. Only the Power-on RESET will stop the ongoing Flash write cycle. The consequence is that the write cycle will continue as long as possible even if the supply voltage drops below minimum recommended operation voltage. This does not induce risk of data corruption – this feature increases the likelihood that the Flash page write/erase is completed.

Implementation The implementation of the Flash parameter storage example is done using the IAR

EWAVR 2.27b compiler. The implementation can be ported to other compilers, but this may require some work since several intrinsic functions from the IAR compilers have been utilized in the code example. The aim for the code example was to make a driver that can store a multi-byte parame- ter quickly and also to obtain a high endurance for this storage method. The endurance of the storage depends on the size of the parameter and the size of the Flash page used. In the code example a 7-byte structure parameter is stored within a Flash page on the ATmega128. The page size on this device is 256 bytes. One page can hold up to 35 copies of the parameter, in addition to the write-completed flags. The guaranteed endur- ance of the Flash storage is thereby: Endurance = Cell endurance * Copies = 10,000 * 35 = 350,000 writes. Relying on typical data on Flash endurance rather than the minimum guaranteed endur- ance, one could expect up to ten times the minimum endurance – several million updates of the parameter. Furthermore, it has been a focus to minimize the overall power consumption of an appli- cation using the Flash storage method. This is achieved by placing the parameters in the RWW part of the Flash memory. It is thereby possible to continue code execution from the NRWW part of the Flash while the parameters are updated, saving time. The code is made so that interrupts will continue to operate and interrupt driven code in the RWW section is therefore still executable. Optional To get an even more reliable storage method it is possible to “enable” the use of write- completion flags. If such a flag is used, the writing of the parameter and the parameter- location flag (which is also the write-completion flag) will be done in two separate write operations. It is in this way possible to determine that the parameter is stored correctly if the write-completion flag is programmed. However, the storing of the parameter and the write-completion flag will take twice the amount of time compared to storing both in one operation., To increase the robustness of the storage method, the parameter is temporarily stored in EEPROM while the parameter page is erased. This is done to ensure that a power- failure between the erase operation and the write operation will not result in loss of the parameter. If a power failure occurs while erasing the page, the parameter will thus be recovered from EEPROM and then programmed into the parameter page. These features are controlled by the FlashStorageDriver.c file and are by default enabled. Requirements The example is targeting the ATmega128 and is therefore adapted to the memory con- figuration of this device. If the example is to be used with other devices the linker command file and the device dependent information in the FlashStorageDriver.c file needs to be changed.

Firmware Description The driver consists of three functions. These are described by the flowchart (Figures 2,

3, and 4) and the following sections. FlashStorageInit The initialization of the Flash storage is an investigation of the state of the Flash storage. If the parameter is stored in the temporary EEPROM storage (determined from the EEPROM Back-up Valid flag), the parameter is recovered from there and copied into the Flash storage. Otherwise the last used position in the Flash buffer is identified from the index flags. Figure 2. Flash Storage Initialization Process FlashStorageInit() EE back-up Yes valid flag set? Set parameter page index No to End-of-Page (causes page erase on next Search parameter element parameter write) index flags to identify last used location Write EE back-up to Flash Set parameter page index according to index flags FlashStorageInit() FlashStorageInit() 6 AVR105 App Note,

AVR105 App Note

FlashStorageWrite The parameter storage routine will first inspect if EEPROM access is ongoing. If this is the case the routine will disable the EEPROM interrupt and wait for the access to final- ize. If the parameter page is full, the parameter is first stored in EEPROM. Next, the parameter page is erased. When the EEPROM holds the parameter, the EEPROM Back-up Valid flag is set. Once the erase is completed, the parameter is written to the parameter page and the EEPROM Back-up Valid flag is cleared. After writing a location in the parameter page, the corresponding Parameter Index Bit is cleared. This way it is possible to determine during initialization that a parameter location is valid. Finally, the EEPROM interrupt is restored to it original state. In addition to the operations listed above, the access control of the RWW part of the memory is handled so that the memory read access is enabled when returning from the function.,

Figure 3. Flash Storage Write Process

FlashStorageWrite() Back-up EEPROM interrupt mask and disable EE interrupt Wait until any ongoing EEPROM write finished Parameter Yes page full? No Data in No back-up EE storage? Store data in back-up EE Copy data to SPM page storage. Set EE back-up buffer Yes valid flag Write data (page write: latch data in SPM buffer) Erase parameter page Reenable RWW memory Reset parameter page index Update parameter page index bit (showing which elements is already written) Reenable RWW memory Copy parameter page index bit to SPM buffer Yes Write parameter page index Parameter bit (page write: latch data in page blank? SPM buffer) No Reenable RWW memory Restore EEPROM interrupt mask (enables EE int.) Clear EE back-up valid flag Return False Restore EEPROM interrupt mask (enables EE int.) Return True 8 AVR105 App Note,

AVR105 App Note

FlashStorageRead It is not possible for the application to read the Flash parameter directly, since to current location of the parameter is not known by the application. Therefore a special function is used to read the parameter. The function first verifies that the parameter can be read, that SPM is not ongoing, and then reads and returns the parameter from the parameter page. Figure 4. Flash Storage Read Process flashStorageRead() Is SPM Yes ongoing? No Read last written parameter location Return parameter value

Literature List

1. AVR datasheets for devices with self-programming, available on the Atmel web site. 2. Application Note “AVR109 – Self programming”, available on the Atmel web site.,

Atmel Corporation Atmel Operations

2325 Orchard Parkway Memory RF/Automotive San Jose, CA 95131, USA 2325 Orchard Parkway Theresienstrasse 2 Tel: 1(408) 441-0311 San Jose, CA 95131, USA Postfach 3535 Fax: 1(408) 487-2600 Tel: 1(408) 441-0311 74025 Heilbronn, Germany Fax: 1(408) 436-4314 Tel: (49) 71-31-67-0 Fax: (49) 71-31-67-2340

Regional Headquarters Microcontrollers

Europe 2325 Orchard Parkway 1150 East Cheyenne Mtn. Blvd. Atmel Sarl San Jose, CA 95131, USA Colorado Springs, CO 80906, USA Route des Arsenaux 41 Tel: 1(408) 441-0311 Tel: 1(719) 576-3300 Case Postale 80 Fax: 1(408) 436-4314 Fax: 1(719) 540-1759 CH-1705 Fribourg Switzerland La Chantrerie Biometrics/Imaging/Hi-Rel MPU/ Tel: (41) 26-426-5555 BP 70602 High Speed Converters/RF Datacom Fax: (41) 26-426-5500 44306 Nantes Cedex 3, France Avenue de Rochepleine Tel: (33) 2-40-18-18-18 BP 123 Asia Fax: (33) 2-40-18-19-60 38521 Saint-Egreve Cedex, France Room 1219 Tel: (33) 4-76-58-30-00 Chinachem Golden Plaza ASIC/ASSP/Smart Cards Fax: (33) 4-76-58-34-80 77 Mody Road Tsimshatsui Zone Industrielle East Kowloon 13106 Rousset Cedex, France Hong Kong Tel: (33) 4-42-53-60-00 Tel: (852) 2721-9778 Fax: (33) 4-42-53-60-01 Fax: (852) 2722-1369 1150 East Cheyenne Mtn. Blvd. Japan Colorado Springs, CO 80906, USA 9F, Tonetsu Shinkawa Bldg. Tel: 1(719) 576-3300 1-24-8 Shinkawa Fax: 1(719) 540-1759 Chuo-ku, Tokyo 104-0033 Japan Scottish Enterprise Technology Park Tel: (81) 3-3523-3551 Maxwell Building Fax: (81) 3-3523-7581 East Kilbride G75 0QR, Scotland Tel: (44) 1355-803-000 Fax: (44) 1355-242-743 Literature Requests www.atmel.com/literature Disclaimer: Atmel Corporation makes no warranty for the use of its products, other than those expressly contained in the Company’s standard warranty which is detailed in Atmel’s Terms and Conditions located on the Company’s web site. The Company assumes no responsibility for any errors which may appear in this document, reserves the right to change devices or specifications detailed herein at any time without notice, and does not make any commitment to update the information contained herein. No licenses to patents or other intellectual property of Atmel are granted by the Company in connection with the sale of Atmel products, expressly or by implication. Atmel’s products are not authorized for use as critical components in life support devices or systems. © Atmel Corporation 2003. All rights reserved. Atmel® and combinations thereof AVR® and megaAVR® are the registered trademarks of Atmel Corporation or its subsidiaries. Other terms and product names may be the trademarks of others. Printed on recycled paper.]
15

Similar documents

8-bit RISC Microcontoller Application Note AVR130: Setup and Use the AVR® Timers Features
8-bit RISC Microcontoller Application Note Rev. 2505A–AVR–02/02 AVR130: Setup and Use the AVR® Timers Features • Description of Timer/Counter Events • Timer/Counter Event Notification • Clock Options • Example Code for Timer0 – Overflow Interrupt • Example Code for Timer1 – Input Capture Interrupt •
8-bit RISC Microcontroller Application Note AVR151: Setup And Use of The SPI Features Introduction
8-bit RISC Microcontroller Application Note Rev. 2585A–AVR–11/04 AVR151: Setup And Use of The SPI Features • SPI Pin Functionality • Multi Slave Systems • SPI Timing • SPI Transmission Conflicts • Emulating the SPI • Code examples for Polled operation • Code examples for Interrupt Controlled operati
AVR241: Direct driving of LCD display using general IO
AVR241: Direct driving of LCD display using general IO Features • Software driver for displays with one common line • Suitable for parts without on-chip hardware for LCD driving • Control up to 15 segments using 16 IO lines • Fully interrupt driven operation Introduction As a low power alternative t
8-bit Microcontroller Application Note
8-bit Microcontroller Application Note Rev. 0938B–AVR–01/03 AVR204: BCD Arithmetics Features • Conversion 16 Bits ↔ 5 Digits, 8 Bits ↔ 2 Digits • 2-digit Addition and Subtraction • Superb Speed and Code Density • Runable Example Program Introduction This application note lists routines for BCD arith
8-bit Microcontroller Application Note
8-bit Microcontroller Application Note Rev. 2530B–AVR–01/04 AVR065: LCD Driver for the STK502 and AVR Butterfly Features • Software Driver for Alphanumeric Characters • Liquid Crystal Display (LCD) Contrast Control • Interrupt Controlled Updating • Conversion of ASCII to LCD Segment Control Codes (S
8-bit Instruction Set Instruction Set Nomenclature
8-bit Instruction Set Rev. 0856D–AVR–08/02 Instruction Set Nomenclature Status Register (SREG) SREG: Status Register C: Carry Flag Z: Zero Flag N: Negative Flag V: Two’s complement overflow indicator S: N ⊕ V, For signed tests H: Half Carry Flag T: Transfer bit used by BLD and BST instructions I: Gl
8-bit Microcontroller Application Note
8-bit Microcontroller Application Note Rev. 0933B–AVR–05/02 AVR102: Block Copy Routines Features • Program Memory (Flash) to SRAM Copy Routine • SRAM to SRAM Copy Routine • Extremely Code Efficient Routines Flash → SRAM: 6 Words, SRAM → SRAM: 5 Words • Runable Test/Example Program Introduction This
Novice’s Guide to AVR Development intended for
Novice’s Guide to AVR Development Preparing your PC for AVR Development Basic AVR Knowledge An Introduction Let's make an easy start, and download the files that we will need later on. The AVR Microcontroller family is a modern architecture, with all the bells andFirst you should download the files
AVR079: STK600 Communication Protocol
AVR079: STK600 Communication Protocol Features 8-bit • Supported Commands and Command options • Command and Answer package formats Microcontrollers 1 Introduction Application Note This document describes the STK®600 protocol. The firmware is distributed with AVR Studio® 4.14 or later. The definition
8-bit Instruction Set Instruction Set Nomenclature
8-bit Instruction Set Rev. 0856G–AVR–07/08 Instruction Set Nomenclature Status Register (SREG) SREG: Status Register C: Carry Flag Z: Zero Flag N: Negative Flag V: Two’s complement overflow indicator S: N ⊕ V, For signed tests H: Half Carry Flag T: Transfer bit used by BLD and BST instructions I: Gl
Designer’s Designing for Efficient Production Corner with In-System Re-programmable Flash µCs
Designer’s Designing for Efficient Production Corner with In-System Re-programmable Flash µCs By: OJ Svendlsi always the component where the majority of the engi- neering hours are spent. Thus, making sure the micro- For products where time-to-market and efficient pro- controller has what it takes t
AVR069: AVRISP mkII Communication Protocol
AVR069: AVRISP mkII Communication Protocol Features • General commands • ISP commands • Return values • Parameters 1 Introduction This document describes the AVRISP mkII protocol. The firmware is distributed with AVR Studio 4.12 or later. Download the latest AVR Studio from the Atmel web site, http:
Studio® Integrated Development A COMPLETE SOFTWARE ENVIRONMENT TO Environment DEVELOP AVR® APPLICATIONS. IT’S FREE!
MICROCONTROLLERSStudio® Integrated Development A COMPLETE SOFTWARE ENVIRONMENT TO Environment DEVELOP AVR® APPLICATIONS. IT’S FREE! AVR Studio® is an Integrated Development Environment for writing and debugging AVR applications in Windows® 98/XP/ME/2000 and Windows NT® environments. AVR Studio provi
Hexadecimal Object File Format Specification
Hexadecimal Object File Format Specification Revision A January 6, 1988 This specification is provided "as is" with no warranties whatsoever, including any warranty of merchantability, noninfringement, fitness for any particular purpose, or any warranty otherwise arising out of any proposal, specifi
AVR914: CAN & UART based Bootloader for AT90CAN32, AT90CAN64, & AT90CAN128 1. Features
AVR914: CAN & UART based Bootloader for AT90CAN32, AT90CAN64, & AT90CAN128 1. Features • UART Protocol 8-bit – UART used as Physical Layer – Based on the Intel Hex-type records Microcontrollers – Auto-baud • CAN Protocol – CAN used as Physical Layer Application Note – 7 re-programmable ISP CAN ident
AVR Microcontrollers Application Note
AVR Microcontrollers Application Note AVR495: AC Induction Motor Control Using the Constant V/f Principle and a Space-vector PWM Algorithm 1. Features • Cost-effective and energy efficient 3-phase induction motor drive • Interrupt driven • Low memory and computing requirements 2. Introduction In a p
AVR Microcontrollers Application Note AVR494: AC Induction Motor Control Using the constant V/f Principle and a Natural PWM Algorithm
AVR Microcontrollers Application Note AVR494: AC Induction Motor Control Using the constant V/f Principle and a Natural PWM Algorithm 1. Features • Cost-effective and flexible 3-phase induction motor drive • Interrupt driven • Low memory and computing requirements 2. Introduction Electrical power ha
AVR465: Single-Phase Power/Energy Meter with Tamper Detection
AVR465: Single-Phase Power/Energy Meter with Tamper Detection Features • Cost-Effective and Flexible Single-Phase Energy Meter • Fulfills IEC 61036 Accuracy Requirements for Class 1 Meters • Detects, Signals and Continues to Measure Accurately Under At Least 20 Different Tamper Conditions • Design E
AVR453: Smart Battery Reference Design
AVR453: Smart Battery Reference Design Features • Support for up to 4 Li-Ion series-connected battery cells • Battery protection by dedicated Hardware - Deep under voltage protection - Over-current protection during charging - Over-current protection during discharging - Short circuit protection • C
8-bit Microcontroller Application Note AVR450: Battery Charger for SLA, NiCd, NiMH and Li-Ion Batteries Features
8-bit Microcontroller Application Note Rev. 1659B–AVR–11/02 AVR450: Battery Charger for SLA, NiCd, NiMH and Li-Ion Batteries Features • Complete Battery Charger Design • Modular “C” Source Code and Extremely Compact Assembly Code • Low Cost • Supports Most Common Battery Types • Fast Charging Algori
Getting started with the AVR battery charger reference design.
Getting started with the AVR battery charger reference design. The AVR battery charger reference design is designed for use with several types of batteries and various number of battery cells. The AVR battery charger reference design is supplied with resistor values for scaling down the charge volta
8-bit Microcontroller Application Note
8-bit Microcontroller Application Note Rev. 2534A–AVR–05/03 AVR415: RC5 IR Remote Control Transmitter Features • Utilizes ATtiny28 Special HW Modulator and High Current Drive Pin • Size Efficient Code, Leaves Room for Large User Code • Low Power Consumption through Intensive Use of Sleep Modes • Cos
AVR336: ADPCM Decoder
AVR336: ADPCM Decoder Features • AVR Application Decodes ADPCM Signal in Real-Time • Supports Bit Rates of 16, 24, 32 and 40 kbit/s • More Than One Minute Playback Time on ATmega128 (at 16 kbit/s) • Decoded Signal Played Using Timer/Counter in PWM Mode 1 Introduction Adaptive Differential Pulse Code
8-bit Microcontroller Application Note
8-bit Microcontroller Application Note Rev. 1181B–AVR–04/03 AVR360: Step Motor Controller Features • High-speed Step Motor Controller • Interrupt Driven • Compact Code (Only 10 Bytes Interrupt Routine) • Very High Speed • Low Computing Requirement • Supports all AVR Devices Introduction This applica
8-bit RISC Microcontroller Application Note AVR335: Digital Sound Recorder with AVR and Serial DataFlash Features
8-bit RISC Microcontroller Application Note Rev. 1456B–01/04 AVR335: Digital Sound Recorder with AVR and Serial DataFlash Features • Digital Voice Recorder • 8-bit Sound Recording • 8 KHz Sampling Rate • Sound Frequency up to 4000 Hz • Maximum Recording Time 2 1/4 Minutes • Very Small Board Size • O
USB in a Nutshell. Making Sense of the USB Standard.
USB in a Nutshell. Making Sense of the USB Standard. Starting out new with USB can be quite daunting. With the USB 2.0 specification at 650 pages one could easily be put off just by the sheer size of the standard. This is only the beginning of a long list of associated standards for USB. There are U
What is USB Enumeration? What does enumeration look like?
What is USB Enumeration? Enumeration is the process by which a USB device is attached to a system and is assigned a specific numerical address that will be used to access that particular device. It is also the time at which the USB host controller queries the device in order to decide what type of d
Draft
CYCLIC REDUNDANCY CHECKS IN USB Introduction The USB specification calls for the use of Cyclic Redundancy Checksums (CRC) to protect all non-PID fields in token and data packets from errors during transmission. This paper describes the mathematical basis behind CRC in an intuitive fashion and then e
File: X:\USERS\IGOR\DOC\WORD\Atmel\USB to RS232 Application Note\Firmware\USBtoRS232_ATmega8\AVR Studio 4 project\USBtoRS232.asm 1.2.2004
1 ;*************************************************************************** 2 ;* USBSTACKFORTHEAVRFAMILY3;* 4 ;* File Name :"USBtoRS232.asm" 5 ;* Title :AVR309:USB to UART protocol converter 6 ;* Date :01.02.2004 7 ;* Version :2.8 8 ;* Target MCU :ATmega8 9 ;* AUTHOR :Ing. Igor Cesko 10 ;* Slovak
File: X:\USERS\IGOR\DOC\WORD\Atmel\USB to RS232 Application Note\Firmware\USBtoRS232_AT90S2313\AVR Studio 4 project\USB90S2313.asm 26.1.2004
1 ;*************************************************************************** 2 ;* USBSTACKFORTHEAVRFAMILY3;* 4 ;* File Name :"USB90S2313.asm" 5 ;* Title :AVR309:USB to UART protocol converter (simple - small FIFO) 6 ;* Date :26.01.2004 7 ;* Version :2.2 8 ;* Target MCU :AT90S2313-10 9 ;* AUTHOR :I