mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Taktvervielfachung - wer hat eine Idee?


Autor: Jürgen VR (tfhh)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

ich habe hier eine knifflige Aufgabe und suche hierfür nach einer Lösung 
- wer hat Ideen/Tipps/Vorschläge hierzu?

Ich möchte für einen 8-Bit Computer mit einem krummen Grundtakt von 1,77 
MHz eine Art "Erweiterungsmodul" entwickeln. Auf diesem kommen 2 GALs, 
eine Batterie EProms, SRAMs und Flash-Bausteine sowie ATmega32 zum 
Einsatz.

Ganz wichtig: Es darf/soll kein Eingriff in die Grundhardware (dann wäre 
es ja einfach...) nötig sein. Meine Schaltung wird in den Parallelen 
Anschluß gesteckt und muß ohne Änderungen des Computers funktionieren.

Der ATmega muß synchron zum Takt des Computer laufen, allerdings - damit 
Zeit für Rechenoperationen ist - mindestens viermal so schnell. Optimal 
wäre es, den ATmega mit 14,187 MHz laufen zu lassen. Das wäre dann ein 
Verhältnis 1:8 und damit ausreichend Luft bei Assemblerprogrammierung.

Soweit, so gut. Es nützt nur nichts, den ATmega einfach mit einem 
eigenen Takt zu versorgen, weil dieser nie synchron zum Taktsignal der 
8-Bit Gurke läuft - dies ist für mein Projekt notwendig.

Ich suche also nach Lösungen, dies zu bewerkstelligen. Erste Idee: Den 
Grundtakt von 1,77 MHz zu verachtfachen - nur wie? Da fehlt mir eine 
sinnige Idee - sofern das überhaupt machbar ist.

Andere Idee wäre es, einen Takt mittels Quarz & Co. zur Verfügung zu 
stellen und diesen dann irgendwie mit dem Grundtakt zu synchronisieren.

Hat jemand hier sowas schon mal gemacht? Eine Idee dazu?

Danke & Gruß, Jürgen

Autor: Gast21 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PLL

Autor: R. Max (rmax)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Muß wirklich der ganze AVR synchron zum bestehenden System laufen oder 
würde es auch reichen, nur die Kommunikation zwischen den beiden zu 
synchronisieren, den AVR selbst aber asynchron, z.B. mit 20MHz laufen zu 
lassen?

Autor: Jürgen VR (tfhh)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
R. Max schrieb:

> Muß wirklich der ganze AVR synchron zum bestehenden System laufen oder
> würde es auch reichen, nur die Kommunikation zwischen den beiden zu
> synchronisieren, den AVR selbst aber asynchron, z.B. mit 20MHz laufen zu
> lassen?

Moin,

hmm... theoretisch nicht. Praktischer wäre es jedoch, da ich ja 
ansonsten vor jedem Befehl & I/O Abfrage einen Flankenwechsel des 
Grundtakts abfragen müßte. Dies wollte ich mir natürlich ersparen, da es 
sonst mit den Ausführungszeiten knapp wird. Der µP soll eingesetzt 
werden, recht komplexe Addressdekodierungen, Bankswitching usw. 
vorzunehmen - wofür sonst mindestens 5 GAL 22V10 nötig wären.

Gruß, Jürgen

Autor: Mathi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht kannst Du beide Seiten mit einem Dual-Clock-FIFO entkoppeln?!

Autor: R. Max (rmax)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jürgen Van radecke schrieb:

> hmm... theoretisch nicht. Praktischer wäre es jedoch, da ich ja
> ansonsten vor jedem Befehl & I/O Abfrage einen Flankenwechsel des
> Grundtakts abfragen müßte.

Das leuchtet mir so erstmal nicht ein, aber um mehr sagen zu können, 
müßte ich noch mehr über die Aufgabenstellung wissen.

> Der µP soll eingesetzt werden, recht komplexe Addressdekodierungen,
> Bankswitching usw. vorzunehmen - wofür sonst mindestens 5 GAL 22V10
> nötig wären.

Hmm - Adreßdekodierer brauchen doch eigentlich gar keinen Takt, sie 
müssen nur schnell genug sein, sprich eine möglichst enge Schleife, die 
permanent die Eingänge liest und auf die Ausgänge abbildet.

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jürgen Van radecke schrieb:
> vorzunehmen - wofür sonst mindestens 5 GAL 22V10 nötig wären.
Mal mit einem aktuellem CPLD versucht? Die aktuellen XC95xxxXL sind 
immerhin 5V kompatibel an den I/Os und stecken eine ganze Menge logik 
weg...

Autor: Du (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
schau dir den PLL Baustein mal an:
74HC 4046

Autor: Michael H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jürgen Van radecke schrieb:
> Hat jemand hier sowas schon mal gemacht? Eine Idee dazu?

Freilich, für sowas wurde u.a. die PLL erfunden. Nimm einen 74HC4046 
(der CD4046 schafft die Frequenz nicht) und einen 1:8-Dividierer, damit 
baust Du einen spannungsgesteuerten Oszillator mit den gewünschten 
14MHz. Das Signal wird durch 8 geteilt und geht zusammen mit den 1,77 
MHz in den Phasenkomparator, wo es die Nachführspannung für den VCO 
erzeugt.
Schon hast Du den phasenstarren 8-fach Takt.
Im Philips-Datenblatt ist eine Beispielschaltung und die nötigen 
Dimensionierungsangaben drin.

Michael

Autor: Helmut Lenzen (helmi1)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
74HC4046 und ein :8 Teiler sind deine Freunde.

Damit kannst du deinen Takt von 1.77MHz * 8 nehmen.

Gruss Helmi

Autor: R. Max (rmax)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael H. schrieb:
> [...] und einen 1:8-Dividierer,

Den kann im Grunde sogar der AVR selbst liefern, sofern ein Timer und 
der zugehörige Ausgang noch frei sind.

Eine andere Variante ohne zusätzliche Hardware könnte noch sein, den 
internen Oszillator des AVR per OSCAL auf ein Vielfaches des 
Master-Takts zu ziehen und immer wieder nachzuregeln.

Autor: Du (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aber du musst bei der Ausgabe dann halt auch das Signal zum Richtigen 
Zeitpunkt wechseln. Das ist denke ich schwieriger. Um was für einen 
8-Bit Computer handelt sich es denn? Und was für eine Schnittstelle 
willst du benutzen. C64?

Autor: Jürgen VR (tfhh)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin Helmut & Michael und auch alle anderen,

die Idee mit dem 4046 und der Schaltung sieht super aus. Vorallendingen 
dürfte der Gleichlauf damit gut möglich sein.

Ich denke, zusammen mit den anderen Tipps werde ich das mal in Angriff 
nehmen.

Vielen Dank!

Gruß, Jürgen

Autor: R. Max (rmax)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kannst Du nochmal ein bißchen mehr zur Aufgabenstellung schreiben?

Ich halte eine Taktsynchronisierung bei einem (wenn auch komplexen) 
Adreßdekoder nach wie vor für overkill, denn ein hardwaremäßiger 
Adreßdekoder bekommt ja auch nur die Adreß- und Steuerleitungen, aber 
keinen Takt. Aber vielleicht übersehe ich ja was...

Autor: Jürgen VR (tfhh)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
R. Max schrieb:
> Kannst Du nochmal ein bißchen mehr zur Aufgabenstellung schreiben?

Moin,

nee, kein C64, sondern Atari 8-Bit Serie. Es geht darum, mittels eines 
µP oder auch CPLD (wobei das Neuland für mich wäre...) zum Einen eine 
Unmenge an TTL/GAL Gräbern zu entsorgen und zum Anderen die Emulation 
mehrerer vorhandener Schaltungen zusammenzuführen. Sinn und Zweck ist 
es, eine Erweiterung zu haben, die z.B. verschiedene Spielmodule und 
dessen Bankswitching-Methoden zu emulieren.

Die Cartridges werden im Flash mittels Information, welches Schema nötig 
ist, gespeichert. Ein Menü erlaubt dem Nutzer das Auswählen. 
Anschließend wird der nötige Algorithmus durch den µP simuliert, 
anstelle dafür z.B. ein oder 2 GALs einzusetzen. Die Daten werden aus 
dem Flash in das SRAM kopiert und die oberen Adressleitungen des SRAMs 
durch den µP und der hinterlegten Matrix gesteuert, währenddessen die 
unteren Adressleitungrn A0-A12 direkt von der CPU bedient werden - 
klassisches 8 KB Bankswitching halt. In einigen Sonderfällen (z.B. 
Tool-Module) auch nur 4 KByte, das sind aber nun Feinheiten.

Desweiteren soll es möglich sein, das SRAM als als externe RAM-Disk zu 
nutzen und viele Spielereien mehr. Es gibt alle diese Lösungen in der 
Fangemeinde, aber immer nur "Einzeln" - und vieles gibt es nur vergossen 
als Block, währenddessen ich einen Großteil bereits in Handarbeit 
dechiffriert habe. Das Endprodukt wird dann die "eierlegende 
Wollmilchsau" werden und dank µP/CPLD auch für künftige Sachen 
erweiterbar.

Langt das als grober Überblick?

Gruß, Jürgen

Autor: Reinhard Kern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

das Problem ist: du brauchst 2 Synchronisationen. Bisher wurde nur die 
erste besprochen, damit hast du einen Atari-Takt und einen Atari x 
8-Takt. Aber für den Ablauf muss deine Logik sich nach dem Atari-Takt 
richten, z.B. wann ein Read-Zyklus anfängt. Im Prinzip musst du den 
Achtfach-Takt also durchnummerieren von 1 - 8 mit 1 = Start eines 
Atari-Taktes, so dass die Logik immer weiss, wo sie sich im Atari-Zyklus 
befindet. Sonst gibt es 8 verschiedene "Phasenlagen".

Du könntest dazu die Teilerbits verwenden (wäre meine Lösung) oder 
zumindest den Subzyklus 1 mit einem zusätzlichen Signal kennzeichnen.

Gruss Reinhard

Autor: R. Max (rmax)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jürgen Van radecke schrieb:

> Langt das als grober Überblick?

Ja, danke. Klingt nach einem interessanten Projekt.

Auf den ersten Blick habe ich da aber jetzt nichts entdecken können, was 
eine genaue Taktsynchronisierung nötig machen würde. Falls der AVR im 
freilaufenden Betrieb für den Wost-Case (Eingang ändert sich einen 
AVR-Takt nachdem er gelesen wurde) wirklich zu langsam ist, reicht eine 
Ausrichtung der Schleifendurchläufe am Atari-Takt, was gleichzeitig auch 
den Jitter verkleinert. Die Hauptschleife würde also auf die 
Atari-Taktflanke warten, die Eingänge lesen, die Ausgänge schreiben und 
wieder zum Anfang springen.

[Edit:]
Andererseits könnte das bei 8..9 (bei 16MHz) AVR-Takten pro Atari-Takt 
schon ein bißchen eng werden, je nach dem, wie komplex die Dekodierlogik 
ist.

Wieviele Systemtakte braucht denn der Atari, z.B. für einen Read aus dem 
Speicher?

Autor: Jürgen VR (tfhh)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Reinhard Kern schrieb:
> Du könntest dazu die Teilerbits verwenden (wäre meine Lösung) oder
> zumindest den Subzyklus 1 mit einem zusätzlichen Signal kennzeichnen.

Moin,

jop, da hast Du recht. Ich werde es mit dem Start des Zyklus probieren. 
Ich werde - das kann etwas dauern, alles rein privat und in Freizeit - 
mal sehen, die ganzen Tipps mit meinem ersten Design aufzubauen und zu 
schauen, was bei ´rumkommt.

Danke, Jürgen

Autor: Jürgen VR (tfhh)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
R. Max schrieb:

> wirklich zu langsam ist, reicht eine
> Ausrichtung der Schleifendurchläufe am Atari-Takt, was gleichzeitig auch
> den Jitter verkleinert. Die Hauptschleife würde also auf die
> Atari-Taktflanke warten, die Eingänge lesen, die Ausgänge schreiben und
> wieder zum Anfang springen.

Jop, das hatte ich auch vor, daß Atari-Taktsignal liegt natürlich auch 
am µP an und wird abgefragt. Ich werde die ganzen Tipps nochmal zu Hause 
in Ruhe sortieren und prüfen, ob ich wirklich eine Synchronisität 
benötige - evtl. habe ich mich da gedanklich auch einfach nur verrant.

> Andererseits könnte das bei 8..9 (bei 16MHz) AVR-Takten pro Atari-Takt
> schon ein bißchen eng werden, je nach dem, wie komplex die Dekodierlogik
> ist.
> Wieviele Systemtakte braucht denn der Atari, z.B. für einen Read aus dem
> Speicher?

Also ein Zugriff auf den I/O Bereich (beim Atari im Segment $D0xx-$D7xx 
eingeblendet) benötigt für einen Lese- oder Schreibzugriff mindestens 6 
Takte (6502-Takte), d.h. der AVR hätte mit Sicherheitsreserve mindestens 
40 Takte (AVR-Takt bei 8 * Atari-Takt) Zeit, entsprechende I/O Ports zu 
programmieren. Das sollte langen, wenn ich mit Tabellen arbeite, in 
denen die Bitkombinationen vorher abgelegt sind. Und in der Realität 
funken ja Interrupts usw. dazwischen, so daß es eher unwahrscheinlich 
ist, daß massive sequentielle Änderungen erfolgen. Dennoch wird das 
natürlich genau geprüft :)

Danke & Gruß, Jürgen

Autor: Weingut Pfalz (weinbauer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
öha ... ich denk das wird beim 8-fachen
takt haarig vom Timing her.
er hat dann zwischen den Takten maximal 8
Systemtakte Zeit bei 13 i/o die zu
verwursteln sind,
also 2 Ports in Register laden, verwursteln
und wieder ausgeben.
Ich denk das wird mit dem Timing eng, da der
Atari wahrscheinlich auch nicht auf den nächsten
Takt zum Einlesen warten wird.

Empfehle CPLD oder FPGA

Das CPLD-Board von Pollin hab ich grad in der Mache,
ist nicht ohne was dass Ding so leisten kann.
Soweit ich das als Einsteiger beurteilen kann natürlich.

Autor: R. Max (rmax)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jürgen Van radecke schrieb:

> Also ein Zugriff auf den I/O Bereich (beim Atari im Segment $D0xx-$D7xx
> eingeblendet) benötigt für einen Lese- oder Schreibzugriff mindestens 6
> Takte (6502-Takte), d.h. der AVR hätte mit Sicherheitsreserve mindestens
> 40 Takte (AVR-Takt bei 8 * Atari-Takt) Zeit, entsprechende I/O Ports zu
> programmieren.

So viel Zeit hat der AVR nicht. Der Output des Dekoders muß ja schon 
ziemlich am Anfang des Zugriffs zur Verfügung stehen, denn der 
angesprochene Speicher- oder I/O-Baustein braucht ja auch nochnal Zeit 
für seine interne Adreßdekodierung und das Übernehmen oder Bereitstellen 
der Daten.

Autor: Jürgen VR (tfhh)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fhutdhb Ufzjjuz schrieb:

> Empfehle CPLD oder FPGA
>
> Das CPLD-Board von Pollin hab ich grad in der Mache,
> ist nicht ohne was dass Ding so leisten kann.
> Soweit ich das als Einsteiger beurteilen kann natürlich.

Schicke doch mal bitte die Artikel-Nr. (per PN, damit´s kein Ärger hier 
wegen Werbung gibt, bitte) von Pollin.

Ich habe bisher nichts gemacht mit CPLD... zum Einen, weil es da nichts 
Vernünftiges in DIL gibt und ich natürlich die ersten Prototypen auf 
Lochraster mache. Bin halt auch nur Hobbyist mit chronischem Geldmangel 
für teure Hobby-Projekte :-)

Zum Anderen gibt es keine/kaum aktuelle CPLD, die auf 5V TTL Pegeln 
sauber arbeiten. Von anderen Bastlern und dessen Projekten weiß ich, daß 
z.B. die Xilinx-CPLD (die kleinen), die laut Datenblatt "5 Volt 
tauglich" sind und mit 3,3 Volt betrieben werden, in der Praxis sehr oft 
Probleme z.B. mit SRAMs (5 Volt Typen) oder anderen Gatterbausteinen 
haben. Solchen Problemen würde ich natürlich gern aus dem Wege gehen.

Gruß, Jürgen

Autor: R. Max (rmax)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jürgen Van radecke schrieb:

> Schicke doch mal bitte die Artikel-Nr. (per PN, damit´s kein Ärger hier
> wegen Werbung gibt, bitte) von Pollin.

Einfach im Suchfeld "CPLD" eingeben, es gibt genau einen Treffer.

Autor: Jürgen VR (tfhh)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
R. Max schrieb:

> So viel Zeit hat der AVR nicht. Der Output des Dekoders muß ja schon
> ziemlich am Anfang des Zugriffs zur Verfügung stehen, denn der
> angesprochene Speicher- oder I/O-Baustein braucht ja auch nochnal Zeit
> für seine interne Adreßdekodierung und das Übernehmen oder Bereitstellen
> der Daten.

Nee, das ist eben nicht erforderlich. Der "Trick" dieser 
Bankswitching-Module (nur bei diesen ist das Timing kritisch, beim Rest 
liefere ich sowieso die "Treibersoftware" mit und kann daher Rücksicht 
auf evtl. Timings nehmen) ist, daß ein Lese- und/oder Schreibzugriff auf 
den I/O Bereich z.B. Bank 15 eines 512 KByte EPROMs aktiviert. Die Bänke 
werden immer im gleichen Speicherbereich der CPU eingeblendet. Es ist 
technisch garnicht möglich, ein Bankswitching etc. zu adressieren und im 
gleichem Atemzug schon Code auszuführen bzw. Daten aus der neu 
selektierten Bank zu holen. Von daher hat der AVR immer mindestens 6 
Takte 6502-Zyklen Zeit, die gewünschten Änderungen vorzunehmen, bevor 
der nächste Zugriff erfolgen kann. Das sollte eigentlich langen - ich 
werd´s merken :)

Gruß, Jürgen

Autor: R. Max (rmax)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hatte Dich am Anfang so verstanden, daß der AVR außerdem auch 
sozusagen "live" als Adreßdekoder arbeiten soll, sprich bei jedem 
Zugriff auf den entsprechenden Adreßbereich die Finger im Spiel hat.

Wenn er aber wirklich nur bei Dummy-Zugriffen auf bestimmte Adressen 
reagieren soll, und Du dafür dann sogar 40 Takte Zeit hast, weil die 
Daten aus diesem Zyklus gar keine Rolle spielen, sollte es wirklich kein 
Problem sein, selbst ohne jegliche Synchronisation, einfach nur durch 
schnelles Pollen der Adreß- und ggf. Steuerleitungen.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.