Forum: Mikrocontroller und Digitale Elektronik 5/3,3V auf gemeinsamen Bus


von Andreas Auer (Gast)


Lesenswert?

Hi.

Bin jetzt irgendwie an nem Punkt angekommen, wo ich nicht mehr so recht
weiterweiß, warum und wieso das so ist.
Also mein Problem.... Ich hab ein externes SRAM an einen Atmel
Controller (ATMega162) angebunden. Das funktioniert soweit eigentlich
auch.
Jetzt hab ich aber einen weiteren Baustein, einen CPLD - wollte das
trotz verwendeten Baustein nicht ins CPLD/FPGA Forum posten - auf den
selben Adressbus, wie den Atmel gelegt. Der CPLD ist mit 3,3V versorgt,
hat aber 5V Tolerante Eingänge. Die Ausgänge, die an den Adressen des
RAMs angeschlossen sind, sind vorerst mal die ganze Zeit im Tristate
Zustand.
Jetzt wollte ich mit dem Atmel das RAM wie zuvor beschreiben und wieder
auslesen... einfach als RAM-Test. Jetzt ist es so, dass Fehler beim
Schreiben bzw. Lese des RAMs auftreten (weiß leider nicht was
fehlschlägt). Lasse ich den CPLD unversorgt, dann funktioniert es
wieder einwandfrei.

Meine Frage ist jetzt, darf ich CPLD und Atmel so einfach
zusammenschalten, auch, wenn der CPLD seine Eingänge im Tristate Modus
hat, weährend der Atmel auf den Bus schreibt????? Oder weiß jemand, was
das für ein Fehler sein kann.

mfg
Andreas

von Matthias (Gast)


Lesenswert?

Hi

du hast Tri-State Pins an einigen Addressleitungen des SRAMs? Sonst
nichts? Du solltest da entweder Pull-Up/Down vorsehen oder die
betreffenden Pins des CPLD auf Ausgang schalten.

Matthias

von thkais (Gast)


Lesenswert?

Hört sich schwer nach Buskollisionen an. Bist Du Dir sicher, daß der
CPLD bei RAM-Zugriffen im Tristate ist? Dort würde ich ansetzen.
Wie hast Du /CE vom RAM beschaltet? Der RAM muß natürlich abgeschaltet
sein, wenn auf den CPLD zugegriffen wird.
Schließe doch Testhalber den CPLD an den Bus an und lege ihn per Hand
auf Tristate - vielleicht ist einfach nur ein Wurm bei der
Selektierung.

@Matthias: Wenn Du die Adressausgänge des CLPD auf Ausgang schaltest,
findet das der Atmel sicherlich nicht so prall - schließlich geht er
davon aus, daß er der Busmaster ist... Pull-Up/Down sind in der Regel
auch nicht nötig - wegen des Atmel.

von Andreas Auer (Gast)


Lesenswert?

Hi.

Danke schonmal für die Antworten.

@thkais:
Also, ich will mit Atmel und CPLD auf das RAM zugreifen. Über so eine
Art Chipselect garantiere ich, dass der CPLD immer im Tristate Zustand
ist, wenn der Atmel das RAM lesen/schreiben will.

Aber ich werde die Ausgänge des CPLD, die im Tristate zustand sein
sollen, nochmal genau unter die Lupe nehmen.

mfg
Andreas

von Hagen (Gast)


Lesenswert?

Das dürfte aber nicht so ohne weiteres funktionieren. Ich bastele gerade
am exakt gleichen Problem ;)

Du hast AD0-AD7, A8-A15, ALE am CPLD. Der CPLD arbeitet als 8Bit Latch
für AD0-AD7. Dessen 8 Ausgänge stellen die gelatchte Addresse A0-A7
dar. Der SRAM ist nun mit A0-A7 am CPLD A0-A7 Latch, A8-A15 am
gemeinsammen Bus zwischen AVR und CPLD,und die Datenausgänge IO0-IO7
des SRAMs sind wieder an AD0-AD7.

Das wäre die Standardbeschaltung. Man muss nämlich beachten das der AVR
seine Addressleitungen nach einem Speicherzugriff nicht auf Tristate
legt. Würden also der AVR und der CPLD als Busmaster auf den Addressbus
zugreifen wollen dann muß immer einer der beiden Master seine Ausgänge
auf Tristate/Pulldown legen. Aber ganau dies ist beim AVR nur möglich
wenn nach einem Speicherzugriff das XMEM Interface deaktiviert wird,
A0-A15 mus manuell auf Tristate/Pulldown gelegt werden. Das ist
natürlich, für mich zumindestens, inakzeptabel da das ziemlich die
Performance drückt.

Ich persönlich bastle da an einer anderen Idee. Als SRAM will ich
CacheSRAM Bausteine nutzen, also maximal 30ns Zugriffzeit.
Der AVR liegt komplett mit XTAL, ALE, WR\, RD\ am CPLD. Der CPLD hat
A0-A15, D0-D7, CS, RD\,WR\ wiederum als eigenen Daten-Addressbus. An
diesem liegen die externen Geräte wie eben auch der SRAM.
Der CPLD wird mit 32MHz getaktet und teilt das runter auf 16Mhz als
Takt für den AVR.
Nun sind mehrere Punkte gegeben:
1.) synchroner Takt zwischen AVR und CPLD
2.) CPLD Takt ist 2 mal höher als AVR Takt
3.) CPLD steuert komplett den schnellen SRAM und externe Geräte an.

Der CPLD wird nun intern wie ein Dual Port SRAM arbeiten. Dazu greift
er selber immer in 2 Zeitscheiben auf den externen SRAM synchronisiert
zum AVR zu. In der 1. Zeitscheibe erfüllt er alle Anforderungen des
AVRs. In der 2. Zeitscheibe greift er für sich selber auf den SRAM zu.
Die Gesammtzugriffzeit für den AVR ist danach wieder so wie ohne CPLD.

Nachteil ist der Punkt das der CPLD nun mehr IOs benötigt.


Deine Frage zielt erstmal nur auf einen Buskonflikt durch den CPLD wenn
der AVR zugreifen will, ab. Wenn der CPLD später selber den Bus
übernehmen will, er also selber aus dem SRAM lesen will, musst du ja
sicherstellen das der AVR seinen Bus auf Tristate/Pulldown legt. Das
kannst du aber nur wenn du das XMEM Interface deaktivierst und die
Ausgänge als Eingänge schaltest. So lange das XMEM Interface aber
aktiviert ist beleiben an AD0-AD7 und A8-A15 die zuletzt benötigten
Werte stehen, und kollidieren somit mit dem CPLD Zugriffen.

Gruß Hagen

von Andreas Auer (Gast)


Lesenswert?

Ok... also das Problem des gemeinsamen Zugriffs versteh ich. Sowas hab
ich mir eigentlich auch schon gedacht, dass der Atmel seine
Adressleitungen nicht in den Tristate Mode versetzt (zumindest nicht
selbst).
Das mit dem deaktivierem im XMEM Register ist bei mir nicht
problematisch, da ich
1. das ganze nicht auf Performance geht,
2. ich das RAM mit dem CPLD vollschreibe und dann mit dem Atmel
auslesen will.

Ich werd jetzt aber erst noch was anderes probieren. Ich werd die 15
Leitungen des CPLD einfach mal als Eingang schalten und versuchen das
RAM vom Atmel aus zu beschreiben und anschließend wieder auszulesen.

Hab die ganze Zeit eigentlich nicht erwähnt, was das ganze eigentlich
soll... Ich hab vor einen Logic Analyser zu bauen. Und zwar zählt der
CPLD nur die Adressen des RAMs hoch (Frequenz vorerst mal mit 12 MHz
danach sollte er das mit ca. 50 MHz machen und die Frequenz soll auch
runterteilbar sein).
Also, CPLD zählt die Adressen hoch und "taktet" den WR Eingang. Über
einen 74HC573 sollen die Daten immer wieder gelatcht werden.
Wenn das RAM - ist übrigens ein altes 20ns RAM von nem alten PC - voll
ist, wird ein high Signal auf einer Leitung ausgegeben und der Atmel
kann das RAM auslesen und die Werte an den PC übertragen.

Also theoretisch sollte das ganze funktionieren. Praktisch muss ich das
eben noch testen. Später soll ja auch noch ein analoger Teil für ein DSO
(digitales Speicher Oszi) hinzukommen.

mfg
Andreas

von Hagen (Gast)


Lesenswert?

Den 8Bit Latch für die unteren Addressen kannst du auch im CPLD
einbauen, somit brauchst du den 74HC573 nicht mehr. Das kostet fast
nichts an Makrozellen.

Über eine ähnliche Lösung wie deine hatte ich auch schon nachgedacht,
nur kommt die bei meinem Projekt nicht in Frage. Der CPLD und der AVR
müssen quasi zur gleichen Zeit (bezogen auf AVR takt) auf den SRAM
zugreifen können.
Am Anfang wollte auch ich es so machen das der AVR mit seinem Bus voll
am CPLD hängt. Der CPLD wiederum hat einen vollständigen und eigenen
Bus zum SRAM. So lange nun der CPLD in den SRAM schreibt wurde ein
externes Signal auf H gelegt. Nachdem der CPLD den SRAM
gelesen/geschrieben hatte wurde das Signal auf L gelegt und im AVR ein
Interrupt ausgelösst. In diesem Moment schaltet der CPLD alle
Anforderungen vom AVR Bus direkt 1 zu 1 zu seinem SRAM Bus durch.
Nun, leider geht das bei mir nicht, da ich eben zur "gleichen" Zeit
vom AVR und CPLD an beliebigen SRAM Addressen lesen oder schreiben muß.
Ich hoffe mal das mein "Timesharing" Ansatz funktioniert.

Der CPLD soll bei mir auch noch den 8Bit Addresslatch und eine
Addressdekodierung für Memory Mapped Devices enthalten.

Wenn es denn mal funktioniert kann man das VHDL auch leicht so
umschreiben das sich zwei AVRs den gleichen SRAM teilen können.

Zur zeit hänge ich am Simulator von Quartus II, die nötigen Wave Files
sind ziemlich zeitaufwändig.

Gruß Hagen

von Hagen (Gast)


Lesenswert?

"(Frequenz vorerst mal mit 12 MHz
danach sollte er das mit ca. 50 MHz machen und die Frequenz soll auch
runterteilbar sein)."

Wie willst die den Takt für den CPLD erzeugen ? Es gibt ja verschiedene
Ansätzeund ich bin mir bei meinem Projekt noch nicht so ganz im klaren
darüber. Ein externer TTL Oszillator wäre meine Vorstellung.

Gruß Hagen

von Andreas Auer (Gast)


Lesenswert?

Momentan erzeuge ich den Takt mit einem einfachen Quarz an nem Inverter
(direkt am CPLD hat das bei mir nicht geklappt).

  |     |\      |
  |  +--|/°-+   |
  |  |      |   |
  +--|------|---+
     |      |
     +-|R |-+
     |      |
     +-|Q|--+
     |      |
  C ---    --- C
    ---    ---
     |      |
     +---+--+
         |
        --- GND
         -

Das funktioniert aber auch nur bedingt. Ohne Oszi ist das alles etwas
schwierig abzustimmen. Und für 50 MHz ist die beste Lösung wohl sowieso
ein Quarzoszillator.

mfg
Andreas

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
Noch kein Account? Hier anmelden.