AT89LP51ED2 PORT Timing abnormal

[Gerhard O. (gerhard_)]

Ich schlage mich zur Zeit mit einem widerspenstigen 8051 Timing Problem 
herum. Das Setzen und Zurücksetzen eines PORT Pins nimmt scheinbar 
wesentlich mehr Zeit in Anspruch wie es sollte.

Der MCU lauft mit 16MHz in Kompatibilitäts-X12 Mode und 5.33MHz ALE 
Timing (siehe Bild). Das stimmt mit den Einstellungen der Fuses überein. 
Soweit so gut. Kompiliert wurde alles mit uV2 V7. ISP mit ASIX PRESTO. 
(Die FUSES sind wie angezeigt korrekt gesetzt wie PRESTO im READ Modus 
anzeigt.)

Das angefügte Scope Bild zeigt das Timing Verhältnis zwischen ALE und 
den Instruktionen wie hier vom List File Ausschnitt gezeigt:

0011 D291              SETB    PIN_P1_1
0013 C291              CLR     PIN_P1_1

CLOCK  (blau) = ALE (5.33MHz oder 187.5ns) (PIN 30)
DATA (gelb) = P1.1

Der Kursor ist auf 64 ALE Zyklen eingestellt. Das sind fast 12us um den 
PORT Pin zu setzen und rücksetzen. (In Fast Mode sind es immer noch 
2.54us)

Um P1.1 wie obig zu steuern, werden also 64 ALE Zyklen anstatt von vier 
gebraucht. Das kann doch nicht wirklich möglich sein! Was soll man nun 
davon halten? Dem "Atmel 8051 Microcontrollers Hardware Manual" nach 
sollten die zwei obigen Instruktionen nicht mehr als 4 ALE Zyklen in 
Anspruch nehmen oder 0.75us. Der CPU braucht offensichtlich genau um den 
Faktor 16 mehr ALE Zyklen wie er sollte.

Ich bin leider auf dem Gebiet der 8051er noch ein richtiges "Greenhorn". 
Trotz stundenlangem Studium der ATMEL Handbücher bin ich immer noch 
nicht zu einer Erklärung gekommen wie so etwas prinzipiell möglich ist.

Mir ist das Problem erst aufgefallen als mein I2C Transfer im Programm 
mit dem Oszi geprüft über 750us pro Transaktion brauchte. Das Test 
Steuerungsprogramm an sich funktioniert sonst einwandfrei. Es sind ein 
PCA9554 (LCD-HD44780), TPIC2810, DS1307, TMP101, und ein AT24C08 am I2C 
Bus dran.

Sollte ich irgendwo einen richtigen Blödsinn gebaut haben danke ich Euch 
schon im Voraus wenn mich jemand in die richtige Richtung stupsen 
könnte.


mfg,
Gerhard

[Thilo H. (thaala)]

Hallo,

es kann praktisch nur einen Grund geben: Hefige Interrupt-belastung.

Setze um deine zwei Befehle mal das hier...

EA = 0;
SETB    PIN_P1_1;
CLR     PIN_P1_1;
EA = 1;

Oder nimm ein Testprogramm, das nur den Pin bedient.

Gruß Thilo

[Gerhard O. (gerhard_)]

Hallo Thilo,

vielen Dank für Deinen Ratschlag mit dem Du den Nagel genau auf den Kopf 
getroffen hattest. Jetzt stimmt die Timing!

Pin Setzen/Zurücksetzen geht jetzt in nur 124ns in Fast Mode und 375ns 
im X12 Kompatibilitäts-Modus. Siehe Bild.

Wie es sich jetzt herausgestellt hatte, hatte ich auch die falsche ADC 
Interrupt Nummer gesetzt. Sollte 13 sein und nicht 12. Dieser falsche 
ISR monopolisierte dauernd den CPU.

Ich schalte den Interrupt sicherheitshalber jetzt auch während der I2C 
Zugriffe ab und jetzt stimmt auch die I2C Timing. Die I2C hat jetzt rund 
3.6us/clock bit. Das sind also rund 270kBit/s - Also ist ganz ideal.

Du hast Dir ein Bier redlich verdient;-)


Viele Grüße aus Kanada,
Gerhard


Thilo Haala schrieb:
> Hallo,
>
> es kann praktisch nur einen Grund geben: Hefige Interrupt-belastung.
>
> Setze um deine zwei Befehle mal das hier...
>
> EA = 0;
> SETB    PIN_P1_1;
> CLR     PIN_P1_1;
> EA = 1;
>
> Oder nimm ein Testprogramm, das nur den Pin bedient.
>
> Gruß Thilo