Hallo! Ich dachte an folgende Lösung zum Füllen eines externen SRAMs mit möglichst wenig Leitungen am Mikrocontroller: 1) Der uC sendet eine Synchronisier-Bitfolge (101010101010...) bevor die Daten für den Buffer gesendet werden. 2) Eine externe Schaltung liest die Synchronisier-Bitfolge und passt ihren Taktgeber daran an. 3) Der uC sendet zB. 64k an Daten indem er sie einfach hintereinander an die 8 Leitungen anlegt. Zweck des Ganzen ist es ein möglichst universales Buffer-Interface zu haben dass auch mit langsameren uC benutzt werden kann. Die Synchronisier-Bitfolge entspricht dem maximalen Tempo in dem der uC Daten an die 8 Leitungen anlegen kann. Weiss jemand wie man so eine Synchronisierung eines Adress-Zählers erreichen könnte ?
Fassen wir zusammen: - Möglichst wenige Leitungen - 8 Leitungen für 8 Bit hast du aber schon eingeplant - Es gibt SPI und I2C RAMs, die brauchen deutlich weniger als 8 Leitungen - 8 Leitungen wären scheinbar ok, aber ne neunte für den Takt ist zuviel? Wenn du unbedingt ne Lösung für das Problem willst: Kodiere deine Daten auf den 8 Bits so, dass immer (bei jedem übertragenen Byte) eine Pegeländerung auf irgendeiner Leitung sein muss. Daraus kannst du dann den Takt zurückgewinnen.
H-G S. schrieb: > 1) Der uC sendet eine Synchronisier-Bitfolge (101010101010...) bevor die > Daten für den Buffer gesendet werden. > > 2) Eine externe Schaltung liest die Synchronisier-Bitfolge und passt > ihren Taktgeber daran an. Genau das wird bei LIN (Local Interconnect Network) gemacht ... > 3) Der uC sendet zB. 64k an Daten indem er sie einfach hintereinander an > die 8 Leitungen anlegt. ... allerdings wird bei LIN nach wenigen Bytes neu synchronisiert, und die maximale Geschwindigkeit ist 20 kbit/s. > Zweck des Ganzen ist es ein möglichst universales Buffer-Interface zu > haben dass auch mit langsameren uC benutzt werden kann. Dafür nimmt man normalerweise SPI oder I²C, weil auch langsamere µCs die in Hardware unterstützen.
THOR schrieb: > Wenn du unbedingt ne Lösung für das Problem willst: Kodiere deine Daten > auf den 8 Bits so, dass immer (bei jedem übertragenen Byte) eine > Pegeländerung auf irgendeiner Leitung sein muss. Daraus kannst du dann > den Takt zurückgewinnen. 8bit-Extension for Manchester...
Serielle Flash können mit DDR Quad I/O Read bis zu 80MB/s übertragen und benötigen nur 6 Leitungen dazu: http://de.farnell.com/spansion/s25fs128sagmfi100/ic-speicher-flash-128mbit-1-8v/dp/2367707
Die 8 Bit brauche ich für den 3R-3G-2B-Farbcode ... ich möchte nämlich einen Videoadapter entwerfen der 256 Farben unterstützt (wohl im 320x240-Modus). Da bleibt kein Bit über für andere Nutzsignale - nichtmal für die Umrissmaskierung eines Sprites/Tiles. Es sei denn ich opfere einen Farbton wie zB. Cyan/Magenta oder so und unterdrücke dann den SRAM-Write mit Logikchips. Ich muss einen Buffer vollmachen aber der uC soll nicht extra noch einen Takt-Pin umschalten denn das kostet 1-2 Befehlszyklen extra um den Pin des anderen Ports umzuschalten. Edit: und der uC darf auch etwas lahm sein, also kein super-DDR-RAM ...
:
Bearbeitet durch User
H-G S. schrieb: > Ich muss einen Buffer vollmachen aber der uC soll nicht extra noch einen > Takt-Pin umschalten denn das kostet 1-2 Befehlszyklen extra um den Pin > des anderen Ports umzuschalten. Wenn Du AVR meinst, dann nimm einen mit externem Memoryinterface (z.B. ATmega162, ATmega2561), da wird das /WR automatisch generiert.
Peter D. schrieb: > Wenn Du AVR meinst, dann nimm einen mit externem Memoryinterface (z.B. > ATmega162, ATmega2561), da wird das /WR automatisch generiert. Es sollte für jeden Mikrocontroller funktionieren, aber ich behalte die AVR mal im Auge :-)
Hi So ganz habe ich Deine Anforderung noch nicht verstanden. Warum muß die zu findende Lösung auf 'allen' µC laufen? Was ist mit µC mit weniger 'Beinchen'? Sollen Die dann ein Schieberegister ansteuern, Das wiederum die Daten für den RAM bereit stellen? DAS ginge mit 2 'Beinchen' und zur Not auch mit zwei Tastern, Die der geneigte RAM-Befüller in Seiner Freizeit stundenlang betätigen kann. Du möchtest Grafik/Sprites in einem RAM unterbringen - was machen Die dann darin? Irgend wer muß damit ja wieder arbeiten - auch sehe ich ein Problem darin, wenn der beschreibende µC, egal wie langsam Er nun ist/war, mit der Arbeit fertig geworden ist, und man den µC 'austauscht', damit mit den Daten gerechnet werden kann. Müsste dann ja 'unter Spannung' passieren, sonst wird das RAM direkt unter Alzheimer leiden und dem geneigten Frickler würde man dann wohl Tourette andichten ;) MfG
H-G S. schrieb: > 2) Eine externe Schaltung liest die Synchronisier-Bitfolge und passt > ihren Taktgeber daran an. > > 3) Der uC sendet zB. 64k an Daten indem er sie einfach hintereinander an > die 8 Leitungen anlegt. Takt anpassen und zu hoffen, dass sich da nach 64kx (Bit oder Byte?) ohne externe Zeitquelle nichts verschiebt, ist blauäugig. Bring notfalls über bit stuffing ein bisschen Struktur in die Daten und schon kann der Empfänger zwischendurch immer wieder seinen Datenübernahmetakt synchronisieren.
Marcus H. schrieb: > THOR schrieb: >> Wenn du unbedingt ne Lösung für das Problem willst: Kodiere deine Daten >> auf den 8 Bits so, dass immer (bei jedem übertragenen Byte) eine >> Pegeländerung auf irgendeiner Leitung sein muss. Daraus kannst du dann >> den Takt zurückgewinnen. > > 8bit-Extension for Manchester... Die Ellipse...kommt da noch was...?
>ein bisschen Struktur in die Daten
Da gibt es doch schon 50 Jahre Erfahrung.
Schon damals, als das noch mit 50 Baud über die Telefonleitung lief,
machten sich die Leute Gedanken, wie man den Overhead für die
Synchronisierung auf das absolut erforderliche Minimum drückt.
Ich dachte an eine VGA-"Grafikkarte" für Mikrocontroller. Zwei SRAM (womöglich 55ns) Buffer werden hin und hergeschaltet, der eine wird mit Adress-Zähler und R2R-DAC zur VGA-Leitung gereicht. Der andere Buffer steht währenddessen dem Mikrocontroller zur Verfügung. Solange kein Buffer-wechseln-Signal zur Grafikkarte geht wird weiter der eine Buffer zum VGA-Ausgang geschickt. Ich dachte an eine 320x240-Auflösung und einem 640x480-Pixeltakt der einfach nur alle 2 Pixel einen Adresszähler für das 55ns-SRAM taktet. Auch die Zeilen würden gedoppelt. An den TV ginge das Ganze mittels VGA-zu-HDMI-Converter. Ich sehe ein Problem im füllen des Buffers durch den Mikrocontroller. Man möchte ja möglichst viel Rechenzeit zwischen den Bildern haben, daher soll der Buffer-Füllvorgang möglichst wenig Zeit benötigen. Als schnellste Möglichkeit habe ich daher eine taktsynchrone serielle Ausgabe der Bytes per 8-Bit-Port ersonnen. Ein zusätzlich generiertes Taktsignal an einem 9. Pin würde sehr viel Rechenzeit kosten.
Nimm einfach von vornherein einen µC, der entsprechenden Dampf hat. Es macht doch keinen Sinn, einen unterdimensionierten µC mit hoffnungsloser Hardware für eine Aufgabe aufzurüsten, wenn es µCs gibt, die das von Haus aus abliefern. Bei 320 Pixeln und 31kHz benötigst Du einen Pixeltakt von 10MHz. Schnapp Dir einen µC mit 4-Bit SPI und auf jeden Fall DMA. Irgendwas mit mit etwas wumms z.B. einen PIC32MZ, der hat auch ordentlich RAM (Es gibt bestimmt auch etwas passendes mit ARM-Kern) Da kannst Du Deinen DAC dann direkt anschnuddeln. Der Propeller hat ein VGA-Interface eingebaut! (Ist sonst allerdings etwas ... sonderbar ...) Gruß Jobst
Mal abgesehen von den Beiträgen, die immer nur ezählen, dass es mit teuer Gekauftem viel besser geht, - rechnen wir doch einfach mal nach: Dein Konzept lässt sich verwirklichen, aber nur mit SEHR GROSSEM AUFWAND: Schon bei einer simplen Seriellen Übertragung mit minimal 10 Bit Synchroninierungsabstand durch Stopp/Start-Bit sind 2,5% Frequenzgenauigkeit erforderlich. Für 64K Bit kommt man auf 3,8ppm erforderlicher Genauigkeit. 1) Es wird "101010101010..." gesendet. 2) Eine Schaltung synchronisiert sich darauf. 3) Die Synchronierung muss für 64K Takte reichen. Wie genau muss dazu die Synchronierung sein? Der Empfänger soll die Daten möglichst in der Mitte der Zeit, wo sie bereitgestellt werden abtasten. Wenn es zum Ende nicht die Mitte = 50%, sondern 25%, oder 75% werden, wird es auch noch klappen. Dazu muss die synchronisierte Abtastfrequenz äußerst genau einstellbar sein! Über 64K Perioden darf sie nur um 1/4 Periode abweichen. Das erfordert eine Einstellgenauigkeit von 1 / (64K * 4) = 1/256K = 3,8 ppm Also muss der Taktgeber des Abtastgenerators eine stabile Frequenz von 262144 x der höchsten Übertragungsrate haben, um daraus die erforderliche Abtastrate abzuleiten. Sonst ist das bei beliebiger Datenrate UNMÖGLICH!
H-G S. schrieb: > Ich dachte an eine VGA-"Grafikkarte" für Mikrocontroller. > ... > An den TV ginge das Ganze mittels VGA-zu-HDMI-Converter. Nimm einen Raspberry als "Grafikkarte", das wird einfacher und billiger. ;-)
Jakob schrieb: > Also muss der Taktgeber des Abtastgenerators eine stabile > Frequenz von 262144 x der höchsten Übertragungsrate haben, > um daraus die erforderliche Abtastrate abzuleiten. > > Sonst ist das bei beliebiger Datenrate UNMÖGLICH! Das klingt nicht gut :-) Ich werde mir wohl etwas anderes einfallen lassen. Konrad S. schrieb: > Nimm einen Raspberry als "Grafikkarte", das wird einfacher und billiger. > ;-) Ich hasse die Dinger irgendwie ... Jobst M. schrieb: > Nimm einfach von vornherein einen µC, der entsprechenden Dampf hat. Ich hätte ja lieber einen Mikroprozessor aber irgendwie scheine ich an Mikrocontrollern hängenzubleiben ...
THOR schrieb: > Marcus H. schrieb: >> THOR schrieb: >>> Wenn du unbedingt ne Lösung für das Problem willst: Kodiere deine Daten >>> auf den 8 Bits so, dass immer (bei jedem übertragenen Byte) eine >>> Pegeländerung auf irgendeiner Leitung sein muss. Daraus kannst du dann >>> den Takt zurückgewinnen. >> >> 8bit-Extension for Manchester... > > Die Ellipse...kommt da noch was...? Mmh, nö, eigentlich steht schon alles da. Was ist denn die Besonderheit an einer Manchester-Codierung? Du darfst Google benutzen. ;)
Einen großen Vorteil haben ja die Mikrocontroller: Kein großer und schnell getakteter externer Bus, also kein EMI/EMC- Problem aus der Richtung. Wenn der Mikrocontroller ein Programm im internen RAM ausführen kann ist es ja möglich Programme je nach Bedarf reinzuladen. Ein Problem könnte aber die Größe des internen RAM für den Buffer sein - da kommen wohl nur größere uC-Boliden in Frage. Meist haben die scheinbar sehr viele kleine Anschlussbeinchen am Gehäuse und sind wahrscheinlich schwer zu löten.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.