Hallihallo, ich habe an einem ATmega 644 einen PIN am PORTC den ich als Ein- und Ausgang nutzen möchte. Das ganze Umschalten funktioniert in der Simulation ganz gut doch wenn es real auf dem µC läuft habe ich das Gefühl das die Umschaltung etwas hinkt. Nun wollte ich nach dem Umschalten der Datenrichtug etwas warten, doch wie lange wartet man da? Ich habe mal 10ms genommen, das klappt doch wie weit kann man runter gehen das es immer zuverlässig funktioniert? Viele Grüße, AVRli...
>Nun wollte ich nach dem Umschalten der Datenrichtug etwas warten, doch >wie lange wartet man da? Ich habe mal 10ms genommen, das klappt doch wie >weit kann man runter gehen das es immer zuverlässig funktioniert? Das kommt darauf an, was für Bausteine Du am anderen Ende dran hast und wie schnell diese schalten. Eine Portrichtungsumkehr am AVR dauert in ASM 2-4 Taktzyklen (je nach voherigem und zu erreichendem Zustand). Das sind 125 bis 250 Nanosekunden bei 16 Mhz.
@ Travel Rec. (travelrec) >wie schnell diese schalten. Eine Portrichtungsumkehr am AVR dauert in >ASM 2-4 Taktzyklen (je nach voherigem und zu erreichendem Zustand). ??? Das dauert im besten Fall 1 (einen) Takt.
1 | out r16,ddrd ; 1 Takt |
2 | sbi ddrd,pd0 ; 2 Takte |
MFG Falk
Schau am Besten mal ins Datenblatt. Ich meine mich zu erinnern dass das dort genauer erlaeutert ist mit Zeitdiagramm...
Will nicht meckern, aber:
1 | out r16,ddrd |
müsste
1 | out ddrd,r16 |
lauten. Aber ich denke @ Travel Rec. (travelrec) meint irgendwie sowas:
1 | in r16,ddrd ;1 Takt |
2 | ori r16,0x01 ;1 Takt |
3 | out ddrd,r16 ;1 Takt |
So komme ich auf 3 Takte, wenn jetzt noch die Pullups umgeschaltet werden müssen wirds mindestens einer mehr (Wenn der Status aller Pullups auch dem DDR register entspricht) EDIT: Achja nochwas: Beim Umschalten ist der pin nach dem Befehl auch wirklich schon input (also am ende vom OUT), beim Ausgeben auf einen port, steht das Signal erst einen takt später auch am Pin zur verfügung (irgend eine Synchronisation ist dafür verantwortlich, habs nich mehr soo genau im kopf)
@ Hauke Radtki (lafkaschar) >müsste >out ddrd,r16 >lauten. Ja ;-) >Aber ich denke @ Travel Rec. (travelrec) meint irgendwie sowas: >in r16,ddrd ;1 Takt >ori r16,0x01 ;1 Takt >out ddrd,r16 ;1 Takt >So komme ich auf 3 Takte, wenn jetzt noch die Pullups umgeschaltet Sowas macht ein intelligenter Programmierer/Compiler aber mit
1 | sbi ddrd,1 ; 2 Takte |
>werden müssen wirds mindestens einer mehr (Wenn der Status aller Pullups >auch dem DDR register entspricht) Warum? Dein Sequenz oben ist nur nötig, wenn mehr als ein Bit sich ändern soll. >Achja nochwas: Beim Umschalten ist der pin nach dem Befehl auch wirklich >schon input (also am ende vom OUT), beim Ausgeben auf einen port, steht >das Signal erst einen takt später auch am Pin zur verfügung (irgend eine >Synchronisation ist dafür verantwortlich, habs nich mehr soo genau im >kopf) Nicht ganz. Auch ein out führt sofort zum Ändern des Ausgangspegels. Was du meinst ist http://www.mikrocontroller.net/articles/AVR-Tutorial:_IO-Grundlagen#Stolperfalle_bei_Matrixtastaturen_etc. MFG Falk
@Falk: Ah ok so war das, wusste doch, dass da die Synchronisierung mit reinspielt ;) Und du hast recht, die Sequenz ist nur dann nötig, wenn mehrere Pins umgeschaltet werden sollen UND die anderen nicht beeinflusst werden dürfen.
>Sowas macht ein intelligenter Programmierer/Compiler aber mit >sbi ddrd,1 ; 2 Takte Haarspalterei an: Bei großen AVRs funktioniert das bei den höheren Ports nicht, da geht nur lds und sts. Demzufolge muß man die Pins erst lesen, modifizieren, schreiben. Gleiches bei den Datenrichtungsregistern. Haarspalterei aus
Hallo, dank Euch für Eure Antworten. Ich möchte an einem LCD Display das BUSY Flag abfragen und dafür muß man einen Ausgang als Eingang umschalten, abfragen und dann wieder auf Ausgang setzen. Sollte also alles schnell genug gehen OHNE das man warten muß. Muß ich mir meinen Quelltext wohl nochmal genauer ansehen warum es nicht will... MfG AVRli...
Das Display ist viiiiel langsamer, als der AVR. Du wirst also mit dem AVR auf das Display bzw. auf ein gültiges Busyflag warten müssen. Du kannst Dir den ganzen Zinnober auch sparen, auf die Auswertung des Busy verzichten und in zyklischen Abständen auf das Display schreiben.
Schau Dir mal das Timing im Datenblatt des LCD-Controllers an. Da ist der µC vermutlich viel zu schnell. Und Du willst es noch schneller machen?
Hi! Danke für die Tip's, Timing Daten waren es. Die Pegel müssen eine bestimmte Zeit anliegen und dann kann man das ENABLE triggern und anschließend auch das BUSY super abfragen. Mit anderen Worten, die Ports vom Display überholte der ATMEL allemale. :-D Rennt nun ganz ausgezeichnet. dance Problem ist gelöst, ich danke Euch! Gruß AVRli...
@ AVRli (Gast) >Danke für die Tip's, Timing Daten waren es. >Die Pegel müssen eine bestimmte Zeit anliegen und dann kann man das >ENABLE triggern und anschließend auch das BUSY super abfragen. Ein Blink ins Datenblatt hätte dir das sofort sagen können. MfG Falk
Thread beobachten
Seitenaufteilung abschaltenBitte 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.