PCINT, Signal-Timing?

@  sous (Gast)

>wie lang muss so ein Impuls sein, um vom ATtiny sicher als PinChange
>erkannt zu werden?

Ich schätze mal alles über 10ns. Das Ganze wird asynchron detektiert, 
ist also unabhängig vom aktuellen CPU-Takt.

MFG
Falk

ATTiny25/45/85 Datenblatt Seite 35, PinChange funktioniert im Power Down 
Sleep Mode und im Power Down Sleep Mode ist CPU Takt abgeschaltet.
Seite 36:

"Power-down Mode
When the SM1:0 bits are written to 10, the SLEEP instruction makes the 
MCU enter Powerdown mode. In this mode, the Oscillator is stopped, while 
the   external interrupts, the USI start condition detection and the 
Watchdog continue operating (if enabled). Only an External Reset, a 
Watchdog Reset, a Brown-out Reset, USI start condition interupt, an 
external level interrupt on
INT0 or a pin change interrupt can wake up the MCU. This sleep mode 
halts all generated clocks, allowing operation of asynchronous modules 
only.
"

Gruß Hagen

>Muss mich korrigieren. Aus dem Sleep-Mode (asynchron) muss der Pegel
>>=Start-Up-Time anliegen. Sleep-mode war allerdings nicht gefragt.

Power Down ist ein Sleep Mode.


>>Ich schätze mal alles über 10ns. D
>Das ist grundsätzlich die Art von Antwort, die ich suche.

Quatsch. Das ist eine triviale Aussage die nichts aussagt. 10ns = 
100Mhz, kein AVR schafft so einen Takt. Geht man davon aus das 
mindestens 1 CPU Takt nötig wäre zum Abarbeiten und Aufruf der ISR und 
die AVRs mit maximal 25Mhz laufen so wären >= 40ns eine wesentlich 
genauere aber denoch so triviale Vorhersage.

Gruß Hagen

Wenn ich das richtig sehe, ist der Pin-Change wie der Level-Interrupt, 
d.h. die Änderung muß solange anliegen, bis der CPU-Takt läuft, 
ansonsten legt sich die CPU einfach wieder schlafen.

Der Unterschied ist nur, daß durch das EXOR beide Level die CPU wecken 
können. Gehen sie aber wieder weg, bevor die CPU das latchen kann, 
schläft sie wieder.

Wenn schnell sein soll, also den internen RC mit der kürzesten Startzeit 
nehmen.


Peter

ATTiny25/45/85 Datenblatt Seite 52.

der PCINT wird mit dem Takt synchronisiert und benötigt 3 Takte bis zum 
setzen des PCIF Interrupt Flags. Kommen noch die Takte zum Einsprung in 
die ISR hinzu. Je nach ISR Aufbau (ASM, C oder BASIC) also 5+x Takte bis 
dein ISR Code ausgeführt wird.

In den Sleep Modes musst du noch die eventuell auftretenden Startup 
Zeiten der CPU mit hinzurechnen, sind ja auch durch die Fuses variabel 
konfigurierbar.

Tratt während des PCINT ein noch höher priorisierter und 
freigeschalteter Interrupt auf so musst du dessen 
Gesamtabarbeitungszeiten auch noch hinzurechnen um den Worstcase 
ausrechnen zu können. Wahrscheinlichkeit dafür ist 1 zu 3.

Tratt der PCINT während der Abarbeitung einer ISR auf so musst du die 
verbleibende Restzeit die die CPU innerhalb dieser ISR verbringt 
ebenfalls dazu rechnen.

Gruß Hagen

@sous (Gast)

>Noch eine Frage: Welcher Grundlage entspringt denn Deine Schätzung?

Pi mal Daumen.

Die AVRs kann man bis 20 MHz takten, das sind 50ns. Sie sind aber 
deutlich schneller als das was garantiert wird, erst Recht einzelne, 
kleine Logikfunktionen.
Mal sportlicher Faktor = 10ns ;-)

@ Hagen Re (hagen)

>>Das ist grundsätzlich die Art von Antwort, die ich suche.

>Quatsch. Das ist eine triviale Aussage die nichts aussagt.

Meinst du?

> 10ns = 100Mhz, kein AVR schafft so einen Takt.

Hat irgendjemand behauptet, man könne eine AVR mit 100 MHz takten?

Nein.

Aber es geht um die Frage, wie schnell die FlipFlops in so einem AVR 
schalten können, und das ist deutlich schneller als der maximale Takt 
des Gesamtsystems.
Gilt für so ziemlich alle Digitalschaltkreise.

http://www.geocities.com/jacquesmartini/digital/glitch/glitch.html

> Geht man davon aus das mindestens 1 CPU Takt nötig wäre zum Abarbeiten und 
Aufruf der ISR

Vollkommen die Frage verfehlt. Lies mal die Frage des OP.

> und
>die AVRs mit maximal 25Mhz laufen so wären >= 40ns eine wesentlich
>genauere aber denoch so triviale Vorhersage.

Und vollkommen falsch ;-)

MFG
Falk

Hagen Re wrote:

> Tratt während des PCINT ein noch höher priorisierter und
> freigeschalteter Interrupt auf so musst du dessen
> Gesamtabarbeitungszeiten auch noch hinzurechnen um den Worstcase
> ausrechnen zu können.

Man muss hier 2 Dinge unterscheiden:
- Die Zeit zwischen Änderung und Ausführen des Interrupts
und
- Die Zeit die der geänderte Pegel anliegen muss, ehe dieser als 
Änderung erkannt und gespeichert wird.

Letzteres dürfte wenige ns bis maximal 1 CPU Takt + wenige ns sein (da 
ein mit dem CPU Takt getaktetes Register die Änderung samplen muss, und 
CPU Takt bedeutet, dass die Taktquelle dazu laufen muss, deren Startup 
Zeit dürfte daher auch dazu kommen.) Zumindest würde ich Figure 12-1. 
Timing of pin change interrupts im mega48 Datenblatt so interpretieren. 
Ersteres interessiert hier nicht.

>Hat irgendjemand behauptet, man könne eine AVR mit 100 MHz takten?

>Nein.

>Aber es geht um die Frage, wie schnell die FlipFlops in so einem AVR
>schalten können, und das ist deutlich schneller als der maximale Takt
>des Gesamtsystems.
>Gilt für so ziemlich alle Digitalschaltkreise.

;) gut dann müssen wir minimalst 10ns Slew + 3 CPU Takte rechnen bis das 
PCIF gesetzt wird. Da Nichts im AVR asynchron weiterverarbeitet werden 
kann (ich gehe jetzt davon aus das die Software und damit CPU auf 
iregendein Register oder Flag reagieren soll) ist die schnellste 
Reaktionzeit im AVR automatisch 1 CPU Takt. Da die höchste Taktrate bei 
den AVR auf 25Mhz begrenzt ist und wir mal annahemen das just in 
richtigen Zeitpunkt das PCINT Eregnis am Pin synchron zum CPU Takt 
eintritt, mit 10ns Slewrate darauf reagiert wird, so können wir mit 3 
Takten rechnen.

>> Geht man davon aus das mindestens 1 CPU Takt nötig wäre zum Abarbeiten
>> und Aufruf der ISR

>Vollkommen die Frage verfehlt. Lies mal die Frage des OP.

>> und die AVRs mit maximal 25Mhz laufen so wären >= 40ns eine wesentlich
>> genauere aber denoch so triviale Vorhersage.

> Und vollkommen falsch ;-)

Der PCINT wird nicht asynchron abgearbeitet, es interessieren also die 
minimalen Schaltzeiten der FFs im AVR nicht.

Es interessiert den OP die Frage wie schnell er in seiner Software auf 
Änderungen am Pin per PCINT reagieren kann. Dazu muß man die 
Synchronisierunglogik am PCINT Eingang, den nötigen Takt und seine 
Frequenz, die Aufrufzeiten und Ausnahmebedingungen der ISRs und seinen 
ISR EInsprungscode heranziehen. Zusätzlich noch den Zustand des Taktes 
des AVRs beim Auslösen den PCINT Ereignisses, also ob der AVR zb. im 
Power Down Mode war und somit die per Fuse eingestellten PowerUp Zeiten.

Erst nach Berücksichtigungen all dieser Parameter kann man eine echte 
Aussage über die Frage wie lange es dauert bis man per Software auf den 
PinChange reagieren kann.

Der OP wird nun feststellen das es in seiner Obhut liegen wird welche 
Bestcase/Worstcase Zeiten er auf seinem Sytem zu erwarten hat und 
sicherlich begriffen haben das keiner hier ihm die exakten Taktzyklen 
des AVRs für seine Software sagen kann. Da es eben von seiner 
Konfiguration abhängig ist.

Gruß Hagen

@Benedikt:

>- Die Zeit die der geänderte Pegel anliegen muss, ehe dieser als
>Änderung erkannt und gespeichert wird.

>Letzteres dürfte wenige ns bis maximal 1 CPU Takt + wenige ns sein (da
>ein mit dem CPU Takt getaktetes Register die Änderung samplen muss, und..

Gut sogesehen hast du Recht, es müsste minimal solange anliegen müssen 
wie die Slewrate von steigender Flanke CPU Takt zum pin_sync Signal + 
Slewrate der pin_latch(0) sein.

Ich würde mit 1 CPU Takt rechnen um sicher gehen zu können. Da wir die 
internen Logik Reaktionszeiten/Slewraten im Grunde nicht kennen.

Gruß Hagen

Hagen Re wrote:

> Es interessiert den OP die Frage wie schnell er in seiner Software auf
> Änderungen am Pin per PCINT reagieren kann.

Nein:

sous wrote:
> Folgende Information kann ich nicht finden:
> wie lang muss so ein Impuls sein, um vom ATtiny sicher als PinChange
> erkannt zu werden?

Also ich entnehme daraus, dass er nur wissen wie lange der Impuls 
mindestens sein muss, damit er erkannt wird und einen Interrupt auslöst.
Und das dürfte eben ein CPU Takt sein, bzw. streng genommen reicht eine 
steigende Flanke von dem im Datenblatt als clk bezeichneten Signal aus.

Hagen Re wrote:

> wie die Slewrate von steigender Flanke CPU Takt zum pin_sync Signal +
> Slewrate der pin_latch(0) sein.

Nein, die Signale interessieren hier nicht, da diese den alten Zustand 
speichern.
Das geänderte Signal nimmt den oberen Weg, direkt zum XOR Gatter, über 
das PCINT Enable AND Gatter, über ein OR Gatter das alle PCINT Signale 
verbindet zu einem D-FF.
Wobei die Laufzeit ja auch egal sein dürfte, es muss nur am Eingang von 
diesem FF für mindestens 1 steigende Flanke eine 1 anliegen.

>Also ich entnehme daraus, dass er nur wissen wie lange der Impuls
>mindestens sein muss, damit er erkannt wird und einen Interrupt auslöst.
>Und das dürfte eben ein CPU Takt sein, bzw. streng genommen reicht eine
>steigende Flanke von dem im Datenblatt als clk bezeichneten Signal aus.

Gut soweit ist das mal klar. Der nächste Timeslot einer Erkennung wäre 
also der nächste CPU Takt und damit ist die Reaktonsgeschwindigkeit in 
Timeslots a 1 CPU Takt unterteilt. Ansich ein guter Wert für eine CPU.

Aber damit ein Takt anliegt muß man auch den aktuellen Zustand des AVRs 
berücksichtigen, also ob er im Power Down Modus ist oder nicht. Je 
nachdem kann sich somit die Zeitspanne wie lang ein Ereignis am PCINT 
Eingang anliegen muß verändern. Minimal also 1 CPU Takt, maximal 1 CPU 
Takt + Startup Zeit des CPU Taktes.

Können wir uns darauf einigen ?

Betrachtet man nun die schnellste Reaktionszeit der Software auf den 
PCINT so sind es schon 3 Takte + Aufwachzeit auf Grund der 
Einsynchronisierung. Dazu kommen im idealfall noch 2 Takte zum Einsprung 
in die ISR + x Takte zum sicheren der Register in der ISR = Startup Code 
der ISR. Im schlechtesten Fall kommen noch Takte hinzu weil entweder ein 
höher priorisierter IRQ abgearbeitet wird oder weil sch die CPU schon in 
einer ISR befindet die erst abgearbetet werden muß.

Gibts da noch Einwände ? Ansonsten wäre das Thema ja dann abgearbeitet 
;)

Sorry das ich die OP Frage falsch verstanden habe.

Gruß Hagen

Hagen Re wrote:
>> Minimal also 1 CPU Takt, maximal 1 CPU
> Takt + Startup Zeit des CPU Taktes.
>
> Können wir uns darauf einigen ?

Ja. Wobei interessant wäre, ob clk wirklich (eventuell über Buffer, 
Inverter usw.) direkt der Takt ist, ober ob dieser Takt für die 
eingestellte Power On Delay erstmal gesperrt wird.

> Betrachtet man nun die schnellste Reaktionszeit der Software auf den
> PCINT so sind es schon 3 Takte + Aufwachzeit auf Grund der
> Einsynchronisierung.

Ja, das sehe ich genauso. Wobei ich mich allerdings frage, welchen Zweck 
die 3 Flipflops haben. Eines würde meiner Meinung nach auch reichen.

> Gibts da noch Einwände ?

Nein, es sollte alles geklärt sein, bis auf die Startup Zeiten + deren 
Auswirkungen auf die Mindestdauer.

Hm, wenn ich es recht überlege stellen sich mir da aber noch Fragen.

Also wir gehen davon aus das 1 CPU Takt lang das PCIINT Event am Pin 
anliegen muß. Die Einsynchronisierung benötigt aber insgesamt 3 Takte. 
Was passiert nun wenn während der Synchronisierung der Eingang wieder 
toggelt ?

Normalerweise hat man ja ein oder zwei PCINT Vektoren. In den ISR muß 
man also das PIN Register auslesen um feststellen zu können welcher 
Eingang nun signalisiert hat. Da wir aber kein temnporäres Register 
haben das den PIN Status zum Zeitpunkt des Samplings speichert können 
wir also nicht mehr über das PIN Register den Auslösezustand zum 
Zeitpunkt des Samplings erkennen.

Die CPU kann also minimal 1 Takt lange Signale erkennen aber das nützt 
uns real in Software relativ wenig weil wir es nicht gezielt auswerten 
können.

Gehen wir vom Polling des PCIF in einer Schleife aus so müsste das 
Signal minimum 4 CPU Takte am Pin anliegen damit wir es auch in Software 
exakt auswerten können.

Liege ich richtig ?

Es fehlt in der AVR Architektur ein Schattenregister das den Pin Status 
speichert der den PCINT ausgelöst hat.

Gruß Hagen

@ Benedikt K. (benedikt)

>>> Minimal also 1 CPU Takt, maximal 1 CPU
>> Takt + Startup Zeit des CPU Taktes.
>
>> Können wir uns darauf einigen ?

>Ja.

Ich nicht. Das ist in diesem Fall schlicht falsch. Die (asynchrone) 
Logik erkennt einen Pegelwechsel, wenn dieser ein paar ns lang ist und 
setzt ein Flag/Bit. Wie schnell die CPU dann darauf reagiert ist ein 
vollkommen andere Frage.

Wenn das Bit erstmal gesetzt ist, kann sich die CPU alle Zeit der Welt 
nehmen, um aus dem Sleep-Mode aufzuwachen und auf das Ereignis zu 
reagieren.

>> Gibts da noch Einwände ?

Ja, einige. ;-)

MFG
Falk

@Falk:

Hast du dir mal das Datenblatt des ATTiny25/45/85 oder ATMega48 
angeschaut ?
Seite 67 im ATMega48 Datenblatt ist die Eingangslogik. Dort ist keine 
asynchrone Eingangslogik zu erkennen, geschweige denn ein asynchron 
gesetztes Flag für den PCINT. Alles getaktet per clk und würde dieser 
Takt nicht anliegen so würde

1.) das Latch + FF nicht den aktuellen Status des Eingangs abspeichern 
können
2.) somit das nachgeschaltet EXOR nicht diesen zwischen gespeicherten 
Status mit dem aktuell Status am Eingang EXOR'en können
3.) das AND mit dem Freischaltflag den EXOR Ausgang verküpfen können
4.) die nachgeschaltete OR-FF Kaskade nicht das PCIF setzen können

Und was nützt es uns wenn zwar das EXOR mit 10ns Durchlaufzeiten 
arbeitet aber

1.) nicht mit dem vorherigen zum Takt synchronen Pinstatus verglichen 
wird
2.) die Pinchange Änderung nicht per PCIF signalisiert wird

Aber für all dies benötigt man eben clk. Ergo muß die CPU erstmal 
aufwachen um einen Takt zu bekommen und erst mit diesem kann das PCIF 
gesetzt werden, bzw. die Pinchange Änderung detektiert werden. Ergo: der 
Power Down Modus verlängert definitiv die Zeitspanne in dem ein 
PinChange Event detektierbar ist.

Ich denke es ist sogar noch viel schlimmer. Denn wir können davon 
ausgehen das ein schnelles Toggeln am Pin zwar den PCINT auslösst aber 
bei der Auswertung des PIN Registers können wir nicht mehr erkennen 
welcher Pin nun den PCINT ausgelösst hat.

Gruß Hagen

@Hagen Re (hagen)

>Hast du dir mal das Datenblatt des ATTiny25/45/85 oder ATMega48
>angeschaut ?

Teilweise.

>Seite 67 im ATMega48 Datenblatt ist die Eingangslogik. Dort ist keine
>asynchrone Eingangslogik zu erkennen, geschweige denn ein asynchron
>gesetztes Flag für den PCINT.

Wer sagt, dass diese Bilder zu 100% den IC beschreiben? das sind 
bestenfalls detailierte Blockschaltbilder. Und schau dir mal das Signal 
DIxn an . . . ;-)

Fakt ist, der Pin Change kann asynchrin erkannt werden, auch wenn 
SÄMTLICHE Takte im AVR inaktiv sind. Also MUSS es eine asycnhrone Logik 
geben.

Das Bild im Dokument doc2586.pdf (Attiny25/45/85) auf Seite 52 halte ich 
für falsch oder unzulässig vereinfacht.

>Aber für all dies benötigt man eben clk. Ergo muß die CPU erstmal
>aufwachen um einen Takt zu bekommen und erst mit diesem kann das PCIF
>gesetzt werden,

Ja.

> bzw. die Pinchange Änderung detektiert werden.

NEIN! Das zwei VERSCHIEDENE Dinge!

1.) Die Änderung asynchron detektieren und speichern
2.) darauf reagieren

> Ergo: der
>Power Down Modus verlängert definitiv die Zeitspanne in dem ein
>PinChange Event detektierbar ist.

Nö. Dann wäre er ja noch unsinniger als der Low Level INT0. Es gibt noch 
Logikblöcke, welche NICHT im Datenblatt abgebildet sind und die PCINT(0) 
asynchron erzeugen.

>Ich denke es ist sogar noch viel schlimmer. Denn wir können davon
>ausgehen das ein schnelles Toggeln am Pin zwar den PCINT auslösst aber
>bei der Auswertung des PIN Registers können wir nicht mehr erkennen
>welcher Pin nun den PCINT ausgelösst hat.

Das ist eine ganz andere Baustelle.

MFG
Falk

Falk Brunner wrote:

> Wer sagt, dass diese Bilder zu 100% den IC beschreiben? das sind
> bestenfalls detailierte Blockschaltbilder.

Wenn das wirklich komplett asynchron erkannt wird (wobei natürlich die 
Frage bleibt, ob erst das PCIF den µC aus dem Tiefschlaf weckt, oder 
nicht schon ein Signal vorher her, was warscheinlicher ist), dann würde 
ich dieses Blocksckaltbild sogar als schlichweg falsch bezeichnen. Wobei 
man das ja relativ einfach nachmessen kann, denn der PCIF müsste demnach 
eine Latenz von mindestens 3 Takten + Interruptlatenzzeit haben.

>wobei natürlich die
>Frage bleibt, ob erst das PCIF den µC aus dem Tiefschlaf weckt, oder
>nicht schon ein Signal vorher her, was warscheinlicher ist)

So sehe ich das auch. Das Signal pcint_in(0) wird per 8 fach ODER 
verknüpft. Dessen Ausgangsignal ist bis dahin asynchron und kann zum 
Aufwecken der CPU dienen.

Allerdings wird dieses Signal dann durch 3 FFs und dem Takt als PCIF 
einsynchronisiert. Ebenfalls das "Shadow-Register" das den vorherigen 
Pin Zustand speichert. Dessen Status wird ja mit dem aktuellen 
Pinzustand per EXOR verknüft. Dessen Ausgang in das 8-fach ODER und 
dessen Ausgang kann zum Aufwecken dienen.
Dieses synchrone Shadow Register ist es auch warum ich meine das diese 
Logik keinesfalls vollständig asynchron ist. Da dieses DFlop ebenfalls 
getaktet wird speichert es den Vergleichszustand des Pins nur wenn auch 
ein Takt vorhanden ist. Eigentlich logisch da erst so ein Weakeup per 
Pinchange asynchron und denoch einsynchronisierbar möglich wird. Nimmt 
man den Takt wieder weg so gilt der aktuelle Pinstatus vor Wegnahme des 
Taktes als Referenzpegel für das EXOR, auch logisch, und logisch ist 
auch das man ein gelatchtes DF dafür benutzt hat.

Ich denke also das das Schaltbild nicht falsch ist. Die Annahme von Falk 
das es falsch wäre ist eine Vermutung die aus meiner Sicht noch 
unwahrscheinlicher ist als die Annahme sich als Entwickler auf die 
Aussagen des Datenblattes von Atmel zu verlassen.

Meine Bedenken mit dieser Logik sind aber andere. Wenn es so sein sollte 
dann heist dies das ein kurzer Impuls am Pin zwar den AVR aufwecken kann 
aber auf Grund der Powerup Zeiten des Taktes es kein Signaling des 
PCINTs im PCIF manifestiert.

Also angenommen:

1.) AVR ist im Power Down
2.) PCINT ist aktiviert
3.) Impuls von zb. 100ns am Pin weckt den AVR
4.) Powerup Zeit des Taktes beträgt 50ms
5.) in der Zwischenzeit liegt der Pin wieder auf Low
6.) Clk fängt an zu takten
7.) Signal am ersten FF vor pcint_sync ist wieder LOW und wird per Clk 
in die FFs getaktet
8.) PCIF wird also nicht gesetzt
9.) ISR für PCINT wird nicht aufgerufen

Bei nächster Gelegenheit werde ich das mal selber testen. AVR in Power 
Down, Wakeup Zeiten per Fuses möglichst lang, und kurzen Impuls auf den 
Pin. AVR wird aufgeweckt, und falls PCIF nicht gesetzt wird und keine 
PCINT ISR aufgerufen wird dann dürfte das Schaltbild so stimmig sein.

Gruß Hagen

@Falk:

>NEIN! Das zwei VERSCHIEDENE Dinge!

>1.) Die Änderung asynchron detektieren und speichern
>2.) darauf reagieren

Und exakt da unterscheiden sich unsere Meinungen. Du sagst

>1.) Die Änderung asynchron detektieren und speichern

Ich behaupte mal an Hand des von dir bezweifelten Schaltbildes das da 
eben nichts asynchron ge-speichert wird. Es wird asynchron ein Signal 
erzeugt und mehr nicht. Die Speicherung dieses Signales erfolgt jeweils 
synchron und damit getaktet. Einmal im latched-DF um den vorherigen 
Pinzustand als Referenz für das EXOR zu haben und zweitens die 
FF-Kaskade um das PCIF daraus zu erzeugen. Die FF-Kaskade könnte 
übrigens exakt dazu da sein um Glitches beim Powerup zu vermeiden und 
damit das PCIF nicht falsch zu setzen.

Davon mal abgesehen frage ich mich wie du asynchron überhaupt ein 
Signalzustand speichern möchtest.

Gruß Hagen

Hagen Re wrote:

> Davon mal abgesehen frage ich mich wie du asynchron überhaupt ein
> Signalzustand speichern möchtest.

z.B. über ein RS-FF.

Auf alle Fällle erklärt mir das Schaltbild so einige Merkwürdigkeiten 
die ich mit dem PinChange und dem Powerdown hatte. Ich habe par Takte 
vor dem PowerDown den PCINT aktiviert, danach den internen Pullup des 
Pins und dann gleich den Powerdown Sleep Modus. Resulat, der AVR kam 
sofort wieder aus dem Powerdown. Meine Vermutung damals war das der hohe 
interne Pullup langsammer den Pin umgeladen hat als das Setzen in den 
Powerdown. Denn durch einfügen von par NOPs vor dem Sleep Befehl konnte 
ich dieses Verhalten beseitigen.

Gruß Hagen