Hallo! Ich hab nen kleinen Code für meinen Mega48 geschrieben, den ich mit einem DRam ausstatten möchte. Jetzt ist das Problem, dass er sich aufhängt, sobald ich den DRam Refresh aktiviere und dann noch Daten per SPI schicke. Hardwarebeschreibung: µC mit 8MHz interner Oszillator SPI Slave, Master ist der PC am Parallelport (eigene Software für Kommunikation geschrieben) am PortD hängt an PD0-PD4 ein Latch, an dem per R2R DAC ein Lautsprecher angeschlossen ist... Latch enable ist PD6 das DRAM ist da ebenfalls teilweise mit angeschlossen, das spielt jedoch keine Rolle für das Problem. DRam cas ras sind PB0/PB1, OE und W (low active!) an PB6 / PB7. So nochmal ne genaue Problembeschreibung: Deaktiviere ich den Timer, der alle 2,0xms 144 Zeilen Refresht (cas before ras) - damit also rund 12ms für alle 1024 Zeilen braucht - , ist alles okay. Ich lasse mir die über SPI empfangenen Bytes direkt wieder ausgeben, kommt alles korrekt an. Ich kann ne 4kHz Sounddatei per SPI rüberschicken und durch den Lautsprecher hören - halt schlechte Qualität, was aber am Prinzip liegt. Ich kann auch das Flash korrekt auslesen und Programmieren, deshalb ist meine SPI Software wohl nicht fehlerhaft. Aktiviere ich nun den DRam Refreshtimer, passiert folgendes: Per SPI kann ich noch 5-30 Bytes schicken & richtig empfangen, danach ist MISO dauerhaft high mit gaaaaaaanz kurzen Low-Peaks drin (aufm Oszi geguckt). Empfangen tu ich nurnoch 255 am PC, ist ja klar. Die RAS Leitung wird weiterhin getoggelt. Was passiert dort? Kann mir das jemand erklären? Was kann ich dagegen tun? Source im Anhang. Ich bedanke mich schonmal im Vorraus, Matthias Larisch
Hi! Das Problem hat sich gerade in Luft aufgelöst - dadurch, dass ich in der DRam Refresh Routine PortB gesichert hab, und den MISO Pin oben als Eingang definiert hab, hat er dann wohl beim Wiederausgeben am Ende der Refrehroutine den Pullup für MISO aktiviert oder so. Jetzt hab ich MISO als Ausgang definiert und alles ist okay :) Sorry, dass ich dafür extra nen Thread aufgemacht hab. Geht mir oft so, sobald ich über mein Problem geredet hab, hab ich ne rettende Idee g Schönen Sonntag noch! Matthias Larisch
So richtig ok ist das immer noch nicht. Alles was an PortB hängt wird durch ldi temp1,194 out PORTB,temp1 im Timer-Interrupt verändert, nicht nur die DRAM-Pins. SS wird darin also für die Dauer vom Refresh aktiviert. Was hier nicht zwingend ein Problem ist, aber sicher unschön. Abgesehen davon ist "194" für 3 gesetzte Bits grässlicherer Stil. Besser: (1<<aaa)|(1<<bbb)|(1<<ccc) und für aaa/bbb/ccc die offiziellen Bezeichnungen der Bits verwenden. Der Grundfehler aber: Du schreibst Ports immer komplett ohne Rücksicht auf "fremde" Pins. Guck mal im Handbuch unter SBI und CBI nach. Tip am Rande: man kann auch runterzählen. Also ldi temp1,128+(128/8) TIM0_OVFL1: ... dec temp1 brne TIM0_OVFL1
Hi! Ich hab deine Ratschläge mal berücksichtigt. SS auf High wäre überhaupt kein Problem gewesen, aber es ist unschön, da hast du Recht. Und ich werd auch mal auf meinen Stil achten :) Durch das Runterzählen spar ich mir temp3. Das ist schön. Matthias Larisch
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.