Mega48 hängt sich auf, bitte mal über Code schauen

[Matthias Larisch (Gast)]

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

[Matthias Larisch (Gast)]

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

[A.K. (Gast)]

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

[Matthias Larisch (Gast)]

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