Ich möchte mit einem ATtiny25 an einem Input-Pin eine Pegeländerung detektieren. Das entsprechende Signal besteht aus kurzen H-Pulsen. Folgende Information kann ich nicht finden: wie lang muss so ein Impuls sein, um vom ATtiny sicher als PinChange erkannt zu werden? Ich hab's nicht im Datenblatt gefunden. Weiß jemand wo das steht?
@ 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
Hi Im Datenblatt vom ATTiny stehts leider nicht drin. Aus anderen Datenblättern (ATMega1281) ist zu entnehmen, das der PinChange-IR etwa 3 Takte bis zum Auslösen braucht. MfG Spess
> das der PinChange-IR etwa 3 > Takte bis zum Auslösen braucht. Hmmm... - Funktioniert der PCI nicht auch bei deaktiviertem I/O-Takt (Power down)? ~
Hi >Hmmm... - Funktioniert der PCI nicht auch bei deaktiviertem I/O-Takt >(Power down)? Aber nicht bei deaktivierten CPU-Takt. MfG Spess
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
Hi
Muss mich korrigieren. Aus dem Sleep-Mode (asynchron) muss der Pegel
>=Start-Up-Time anliegen. Sleep-mode war allerdings nicht gefragt.
MfG Spess
@Falk Brunner (falk):
>>Ich schätze mal alles über 10ns. D
Das ist grundsätzlich die Art von Antwort, die ich suche.
Allerdings bräuchte ich eine sichere Aussage und nicht nur eine
Schätzung.
Nichts desto Trotz: Vielen Dank für Deine Antwort (auch allen anderen
sei gedankt)!
Noch eine Frage: Welcher Grundlage entspringt denn Deine Schätzung?
Hi Im Datenblatt ist ein Timing-Diagramm. Daraus geht hervor, das der Interrupt zwischen ca.3,2-3,7 Cpu-Takten ausgelöst wird. MfG Spess
@spess53: Danke für die Antwort, auch wenn das nicht die Info ist, die ich suche. Ich möchte wissen, wie lang ein H-Pegel-Impuls mindestens sein muss, damit ein PCINT ausgelöst wird. ;)
>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
Hi Halbe Taktperiode vom CPU-Clock. Sicherheitshalber etwas mehr. Der Eingang wird mit der negativen Flanke des CPU-Takts übernommen. MfG Spess
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
@Benedikt K. @Falk Brunner: Ihr zwei habt erkannt, was ich wissen möchte. @alle anderen: Für mich ist nur wichtig, wie lang ein anliegender Impuls sein muss, damit daraufhin ein PCINT ausgelöst wird. Wie schnell dann darauf reagiert wird, ist für mich unwichtig. Meine bisherigen Erkenntnisse: Laut Datenblatt und Versuchsaufbau wird der PinChange asynchron erkannt, der Impuls darf deutlich kürzer sein, als ein Taktzyklus. Mein Aufbau: Taktfrequenz ca. 128kHz aus dem On-Chip Watchdog-Oszillator, (Warum so langsam? Zwecks Stromsparen und weils nicht schneller sein muss!) Die anliegenden Impulse haben eine Dauer von 100ns und lösen wie gewünscht einen PCINT aus. Ich benötige die Information, wie kurz die Impulse denn sein dürfen, damit es immer noch klappt. Inzwischen habe ich eine entsprechende Anfrage an Atmel gestellt und werde Euch über die Antwort auf dem Laufenden halten. Vielen Dank Euch allen!
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
Ich versprach Euch auf dem Laufenden zu halten, wenn ich Nachricht von Atmel erhalte. Die offizielle Antwort auf meine Frage lautet (sinngemäß und übersetzt aus dem Englischen): ...die Erkennung funktioniert asynchron, so dass recht kurze Impulse den Eingang triggern. Für die Schaltung selbst (Anmerkung von mir: auf dem IC also) genügt ein etwa 5 ns langer Impuls. Unter Berücksichtigung parasitärer Kapazitäten (...und anderer Dreckeffekte) sollte man von 50 ns als minimaler Pulsbreite ausgehen können. Da (wie immer) alles auch von der äußeren Beschaltung in der entsprechenden Applikation abhängig ist, sollte man in Einzelfall am besten Versuche unter verschiedenen Bedingungen durchführen. Das wichtigste nochmal zusammengefasst: 50 ns.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.