Mal ein paar Grundlagen (wird sicher vieles klar sein, aber trotzdem):
Die AVR besitzen entsprechend ihrer Harvard-Architektur getrennte Speicher für Code und "Anwendung":
Der Program Flash nimmt das Programm (Code) auf, wobei die dort stehenden Words auch Byteweise als Daten gelesen oder geschrieben (eingeschränkt) werden können.
Im SRAM werden zur Laufzeit alle möglichen Daten (Variablen) abgelegt, außerdem befindet sich dort der Stack (für Rücksprungadressen aus Subroutine Calls und IRQs).
Dann gibts ggf noch den Eeprom.
Der Zugriff auf die gesamte Peripherie läuft über I/O-Register ab.
Allerdings erlauben nur die ersten 32 Adressen direkten bitweisen Zugriff (und selbst da nicht immer alle).
Der "Rechenkern" selbst (die ALU) ist selbst nur an 32 Rechenregister (und das Statusregister) angebunden.
Wenn also ein Statusbit gepollt werden soll, muß erstmal das entsprechende I/O-Register in ein Rechenregister geladen werden (IN/LDS/LD), dort dann eine Maskierung der restlichen Bits erfolgen (ANDI), was das SREG manipuliert; entsprechend dieser Manipulation kann dann verzweigt werden (BRxx).
Wenn ein Byte aus dem SRAM (mit konstanter Adresse) in ein I/O-Register (zB das Uart-Transmit-Register) geschrieben werden soll, muß dieses Byte erstmal aus dem SRAM in ein Rechenregister geladen werden (IN/LDS), und anschließend von dort in das I/O-Register kopiert werden (OUT/STS).
Ist die SRAM-Adresse nicht konstant (oder schlichtweg außerhalb des durch LDS adressierbaren Bereiches), muß diese Adresse erstmal in ein Pointer-Register (zwei Bytes) geladen werden, und dann indirekt von dieser Adresse das Byte geladen werden (mit LD statt LDS). Reicht auch der 16bit-Adressraum nicht, muß ein drittes Ramp-Register miteinbezogen werden.
Ähnliches gilt auch beim Schreiben in die Peripherie mit STS->ST.
Quasi identisch läuft das Kopieren von Bytes innerhalb des SRAM ab.
Erfolgt das ganze innerhalb eines Interruptes, muß sichergestellt werden, daß die 32 Rechen- und das Statusregister so hinterlassen werden, wie man sie vorgefunden hat. Also zu Beginn die verwendeten Rechenregister und das SREG auf den Stack gesichert, am Ende von dort wiederhergestellt.
Um die ALU zu entlasten arbeiten die periphären ... Module mehr oder weniger autonom. Ein Timer tackert entsprechend eingestellt seine Zählwerte durch und erzeugt ggf nebenbei 'ne PWM. Der UART pumpt ein Byte raus und/oder empfängt eins. Der ADC digitalisiert 'ne analoge Spannung usw usf.
Diese periphären Module hinterlassen Ihre Ergebnisse in ihren I/O-Registern (wo die ALU sie pollen/laden) kann, außerdem können Interrupts (des eigentlichen Programmes) angefordert werden.
Was ist jetzt das Event-Netzwerk?
Über dieses Netz kannst Du einige Peripheriemodule miteinander verbinden - triggertechnisch. Ein Timerüberlauf kann dann zB eine ADC-Conversion starten o.ä. (wobei es sowas auch schon bei älteren AVR ohne Event-Netz gab).
Ohne ALU-Intervention.
Das Event-Netz kann aber nur (bestimmte) einzelne Signale verbinden.
Und der DMAC?
Der kann Bytes kopieren - vom I/O-Space/SRAM in den I/O-Space/SRAM. Ggf getriggert, mit inkrementierenden Adressen, blockweise,...
Ohne weitere ALU-Intervention, ohne Umweg über die Rechenregister.
Die CCL?
Jeder Kanal besteht quasi aus einem konfigurierbaren Logikgatter mit mehreren Eingängen und einem Ausgang. Damit lassen sich komplexere Regeln im Event-Netz realisieren, der DMAC läßt sich auch durch das Event-Netz triggern.
@Mikro23 : Soweit korrekt zusammengefaßt?