ATUC64L4U Atmel Corporation, ATUC64L4U Datasheet - Page 25

• Manufacturer Part Number: ATUC64L4U
• Manufacturer: Atmel Corporation

Specifications of ATUC64L4U

• Flash (kbytes): 64 Kbytes
• Pin Count: 48
• Max. Operating Frequency: 50 MHz
• Cpu: 32-bit AVR
• # Of Touch Channels: 17
• Hardware Qtouch Acquisition: Yes
• Max I/o Pins: 36
• Ext Interrupts: 36
• Usb Transceiver: 1
• Usb Speed: Full Speed
• Usb Interface: Device
• Spi: 1
• Twi (i2c): 2
• Uart: 4
• Lin: 4
• Ssc: 1
• Graphic Lcd: No
• Video Decoder: No
• Camera Interface: No
• Adc Channels: 8
• Adc Resolution (bits): 12
• Adc Speed (ksps): 460
• Analog Comparators: 8
• Resistive Touch Screen: No
• Temp. Sensor: Yes
• Crypto Engine: No
• Sram (kbytes): 16
• Self Program Memory: YES
• Dram Memory: No
• Nand Interface: No
• Picopower: Yes
• Temp. Range (deg C): -40 to 85
• I/o Supply Class: 1.62 to 3.6
• Operating Voltage (vcc): 1.62 to 3.6
• Fpu: No
• Mpu / Mmu: Yes / No
• Timers: 6
• Output Compare Channels: 18
• Input Capture Channels: 12
• Pwm Channels: 35
• 32khz Rtc: Yes
• Calibrated Rc Oscillator: Yes

3.8.3
32002F–03/2010
Masking interrupt requests in peripheral modules
This can usually be ensured by scheduling the code sequence disasserting the interrupt request
in such a way that one can be certain that the interrupt request has actually been disasserted
before the rete instruction is executed.
Code 3-1.
The mechanisms and timing required for disasserting an interrupt request from a module is spe-
cific to different modules. Usually, the request is disasserted within a few clock cycles after the
load or store instruction has been received by the module. In this case, a simple way of making
sure that the request has actually been disasserted is to use a data memory barrier
ory barriers” on page
been disasserted. At this point, the rete instruction can safely be executed.
Code 3-2.
The programmer should consult the data sheets for the different peripheral modules to check if
special timings or concerns related to disasserting of interrupt requests apply to the specific
module.
Handling an interrupt request involves several operations like pushing of registers to stack and
takes several clock cycles. The required operations are controlled by sequencing logic in hard-
ware. This sequencing hardware does not permit that an asserted interrupt request is
disasserted while it is in the process of handling this interrupt request.
Hardware makes sure that manipulation of the GM and IxM bits in SREG can be performed
safely at all times using the mtsr, csrf and ssrf instructions. The programmer does not need to
take any special concerns when issuing one of these instructions.
All hardware connected to the CPU is implemented in such a way that once an interrupt request
is asserted by the hardware, it can only be disasserted by explicit actions by the programmer.
// Using scheduling of instructions in the IRQ handler to make sure that the
// request has been disasserted before returning from the handler.
// Assume that the IRQ is cleared by reading PERIPH_INTCAUSE, r0 points to
// this register.
irq_handler:
// Using data memory barriers in the IRQ handler to make sure that the
// request has been disasserted before returning from the handler
// Assume that the IRQ is cleared by writing a bitmask to PERIPH_INTCLEAR.
// r0 points to this register, r1 contains the correct bitmask.
irq_handler:
<some instructions>
ld.w r12, r0[0] // Clear the IRQ
<some other instructions, enough to make sure that the IRQ is cleared>
rete
<some instructions>
st.w r0[0], r1
ld.w r12, r0[0] // data memory barrier
rete
Clearing IRQs using code scheduling
Clearing IRQs using data memory barriers
64). The DMB will block the CPU pipeline until the interrupt request has
AVR32
(“Data mem-
25