Hallo Ich habe vor einen LogicAnalyzer zu entwickeln... Zuerst mal mit einem AVR und später evntuell mit einem MaxII von Altera... Ich habe dazu mal ein Blockschaltbild gezeichnet... Was denkt ihr dazu? Mein Ansatz: Da ich, wenn ich den avr so schnell wie möglich clocks erzeugen lasse, keinen zähler mehr hochzählen kann um zu wissen wie viele samples bereits gespeicher wurden (es wäre möglich mittels interrupt am nächst höheren Zählerpin jedoch immer noch mit taktfrequenz / 4 ) dachte ich an eine PLL... Ich gebe zuerst einige clocks zb mit 2 MHz oder 1MHz auf die PLL um diese einzuschwingen. Nach der PLL sollten so ca 10 Mhz zur verfügung stehen oder auch 15MHz nach ein paar ms beginne ich dann zu samplen indem ich CS aktiviere und den zähler clear... Nun habe ich in der interrupt routine des zählers (da 1MHz) genügend zeit um meinen Sample zähler hochzuzählen (interne variable nicht den externen) ist die Samplerate welche das SRAM speichern kann erreicht, so stoppe ich die PLL bzw setze CS high also deaktiviere das SRAM. Zum auslesen verlangsame ich den Takt auf die PLL (angenomen PLL hat faktor 10) auf 10Khz nun lese ich nach jedem interrupt (ausgelöst durch den PLL takt) das byte auf dem Datenbus aus (RW etc wurden zuvor korrekt gesetzt) und wird per RS232 versendet. Soweit die Theorie... Was denkt ihr dazu? Eine frage zum blockschaltbild... muss ich eurer meinung eine verzögerung in die rote box packen? Danke schonmal
Der 4040 ist ein asynchroner Zähler (ripple counter) und hat reichlich Verzögerung zwischen dem ersten und dem letzten Bit. Hierfür total ungeeignet.
Vielleicht hilft dir dies: http://www.watterott.com/DS1077-Programmable-Oscillator-Breakout-162kHz-to-133MHz
A. K. schrieb: > Vielleicht hilft dir dies: > http://www.watterott.com/DS1077-Programmable-Oscil... Danke... Sieht spannend aus... doch dann kann ich ja meine samples nicht mehr zählen... es sei denn ich würde den clock herunterteilen... Kennst du per zufall ein 12bit Synchron up counter mit reset? :)
A. K. schrieb: > Der 4040 ist ein asynchroner Zähler (ripple counter) und hat reichlich > Verzögerung zwischen dem ersten und dem letzten Bit. Hierfür total > ungeeignet. Hmmm Da sehe ich nur den 74HCT163 (4bit Synchron) als alternative... Aber bei einem 512kbit x 8 SRAM bräuchte ich ja ganze 5 IC's für die adresse (19 Leitungen da log(512kbit) / log(2) = 18.96)... und beim übertrag entsteht ja auch ein gewisses delay... Was würdet ihr mir empfehlen? findet ihr den grundsätzlichen ansatz überhaupt umsetzbar?
Ich vermute, dass Du erst kurze Zeit mit uC zu tun hast. Ist ja kein Problem und auch nicht vorwerfbar. Aber dann neigt man dazu auf einmal buchstäblich Alles mit uC zu machen. Und das führt Dich meiner Ansicht nach in die Irre. Versuche Dir mal das Konzept ohne uC zu überlegen. Dann kannst Du rückwärts überlegen, welche Teilfunktionen du mit dem uC erledigen kannst. Darüber hinaus hat Dein Konzept einen Schwachpunkt: Du willst im allgemeinen zu einem "gewissen" Zeitpunkt mit dem abtasten anfangen und nicht "irgendwann, wenn die PLL eingeschwungen ist". Darüber hinaus muss der VCO (der hier übrigens fehlt) ständig nachgeregelt werden und kann nicht sich selbst überlassen werden. Und: Du hast das Zählen doch schon mit dem Adressregister erledigt. Wozu den uc parallel zählen lassen? Was bleibt also übrig für den uC (abgesehen von der Kommunikation)? Die Ausgabe der Steuerfrequenz. Dafür gibt es aber schon fertige ICs.
Claudio Hediger schrieb: > Da sehe ich nur den 74HCT163 (4bit Synchron) als alternative... Entweder dieser (besser als 74HC), oder 74HC590.
Grrrr schrieb: > Ich vermute, dass Du erst kurze Zeit mit uC zu tun hast. Nunja... dem kann ich nicht zustimmen aber das ist ja nicht gegenstand der derzeitigen diskusion :) >Und: Du hast das Zählen doch schon mit dem Adressregister erledigt. Wozu >den uc parallel zählen lassen? Wie soll ich sonst beim auslesen wissen, welches Sample aktuell an der reihe ist, wenn ich nicht intern die clocks direkt oder indirekt mit zähle? indirekt -> die ausgabe clocks multipliziert mit dem PLL Multiplikator direkt -> nach der PLL was ja nicht geht da der AVR zu "lahm" ist... >Und das führt Dich meiner Ansicht nach in die Irre. Versuche Dir mal das >Konzept ohne uC zu überlegen. Dann kannst Du rückwärts überlegen, welche >Teilfunktionen du mit dem uC erledigen kannst. Hmm... meiner meinung nach sind die Teilfunktionen: Clock erzeugung Daten übertragung Welche teilfunktionen hat der UC deiner meinung nach? >Du willst im allgemeinen zu einem "gewissen" Zeitpunkt mit dem abtasten >anfangen und nicht "irgendwann, wenn die PLL eingeschwungen ist". Ich lassen die PLL direkt nach der Stromversorgung einschwingen... Somit ist sie "allzeit bereit" >Darüber hinaus muss der VCO (der hier übrigens fehlt) ständig >nachgeregelt werden und kann nicht sich selbst überlassen werden. Ich gebe zu, da habe ich etwas unbeachtet belassen... Ich dachte bei der PLL an den 74HC4046 der hat den VCO bereits integriert muss man den auch nachregeln? (bitte verzichtet auf den kommentar wie: was ist den das für ne frage oder ähnliche)
A. K. schrieb:
> Entweder dieser (besser als 74HC), oder 74HC590.
Danke :)
jetzt sinds nur noch 3 IC's :)
Aber die durchlaufzeit beim übertrag darf ich doch auch nicht unbeachtet
lassen oder?
Claudio Hediger schrieb: > Wie soll ich sonst beim auslesen wissen, welches Sample aktuell an der > reihe ist, wenn ich nicht intern die clocks direkt oder indirekt mit > zähle? Die Frage ist eher wann und wie du mit der Zählerei aufhören willst, damit der Controller auch mal ran darf. Wenn der Zähler also irgendwo mittendrin durch welchen Mechanismus auch immer stoppt: Mit Controller als Taktquelle den Zähler solange weiterzählen und in Software mitzählen bis der Übertrag kommt. Dann weisst du wo er vorher stand.
A. K. schrieb: > Die Frage ist eher wann und wie du mit der Zählerei aufhören willst, > damit der Controller auch mal ran darf. > > Wenn der Zähler also irgendwo mittendrin durch welchen Mechanismus auch > immer stoppt: Mit Controller als Taktquelle den Zähler solange > weiterzählen und in Software mitzählen bis der Übertrag kommt. Dann > weisst du wo er vorher stand. hmmm interessanter ansatz... damit würde sich die performance beim auslesen um einiges erhöhen... :) Danke
Claudio Hediger schrieb: > muss man den auch nachregeln? Ja. Claudio Hediger schrieb: > Ich lassen die PLL direkt nach der Stromversorgung einschwingen... > Somit ist sie "allzeit bereit" Nein. >>Darüber hinaus muss der VCO (der hier übrigens fehlt) ständig >>nachgeregelt werden und kann nicht sich selbst überlassen werden. Wo steht, das ein VCO, wenn einmal geregelt dann auf der Frequenz stehen bleibt? (Andernfalls gäbe es wahrscheinlich Miet-PLLs) :-) Claudio Hediger schrieb: > Wie soll ich sonst beim auslesen wissen, welches Sample aktuell an der > reihe ist, wenn ich nicht intern die clocks direkt oder indirekt mit > zähle? Da scheint mir ein Widerspruch zu bestehen. Beim "Auslesen", d.h. das auslesen der Abtastwerte aus dem Speicher, etwa zum Zweck der Anzeige oder Übertragung an einen PC, kann ja beliebig langsam erfolgen. Wer soll da was, woher und wohin lesen? Jedenfalls ist das Konzept da irgendwas auf gut Glück parallel zählen zu lassen um es mal klar zu sagen "krank". Am besten mal anhand der Skizze klar machen wie das "auslesen" erfolgen soll. Claudio Hediger schrieb: > Hmm... meiner meinung nach sind die Teilfunktionen: > > Clock erzeugung > Daten übertragung > > Welche teilfunktionen hat der UC deiner meinung nach? Meine Anregung war: >>Und das führt Dich meiner Ansicht nach in die Irre. Versuche Dir mal das >>Konzept ohne uC zu überlegen. Dann kannst Du rückwärts überlegen, welche >>Teilfunktionen du mit dem uC erledigen kannst. Das Konzept gibt die Teilfunktionen. Und das werden wohl so an die zwanzig sein, denke ich.
Claudio Hediger schrieb: > Wie soll ich sonst beim auslesen wissen, welches Sample aktuell an der > reihe ist, wenn ich nicht intern die clocks direkt oder indirekt mit > zähle? > > indirekt -> die ausgabe clocks multipliziert mit dem PLL Multiplikator > direkt -> nach der PLL was ja nicht geht da der AVR zu "lahm" ist... Kann ja sein, das ich hier was von Dir lernen kann. Bitte erkläre mal das Konzept. Du hast doch den Zählerstand im Adressregister. Das brauchst Du nur auszulesen und weisst wieviel Samples im Speicher sind.
Grrrr schrieb: > Kann ja sein, das ich hier was von Dir lernen kann. Bitte erkläre mal > das Konzept. > > Du hast doch den Zählerstand im Adressregister. Das brauchst Du nur > auszulesen und weisst wieviel Samples im Speicher sind. hmmm also vieleicht reden wir aneinander vorbei deshalb erkläre ich nochmal detailliert was ich meine... Ich möchte ja im mikrocontroller wissen wie viele samples ich bereits entweder A: gespeichert habe oder B: vom SRAM eingelesen und wieder per RS232 versendet habe... Damit ich schnellstmöglich die adresse, welche 19 Leitungen benötigt, an das SRAM bekomme, verwende ich ja externe zähler bausteine welche nach einem clock um eins hoch zählen... Nun schön und gut... Doch ich weiss ja nach x Clocks nicht welcher zählerstand der externe baustein hat. Parallel einlesen möchte ich bei 19 Leitungen nicht... Also gibts nur eins! Clocks welche ich ausgebe mitzählen im Controller. Wenn ich ne PLL habe welche den Clock zb verdoppelt, bedeutet dies, pro clock werden 2 Samples gespeichert. Also Clock * 2 = Aktueller Sample stand. So weiss ich im Controller immer welches Sample gerade gespeicher wurde oder übertragen... was auch immer :)
Claudio Hediger schrieb:
> damit würde sich die performance beim auslesen um einiges erhöhen... :)
Hast du es da irgendwie eilig? Ok, maximal ne halbe Million Ticks ist
also für eine Verzögerung von einigen zig Millisekunden gut. Für'n
Kaffee wird das kaum reichen. ;-)
Übrigens wird es per RS232 ein bischen dauern, das halbe Megabyte zu
übertragen. Da wird's auf diese kleine Verzögerung auch nicht ankommen.
A. K. schrieb:
> Hast du es da irgendwie eilig? Ok, maximal ne halbe Million Ticks ist
Hehe... nein eigentlich nicht :)
Beim Reinsamplen schon :) aber beim auslesen nicht mehr so extrem :)
A. K. schrieb: > Übrigens wird es per RS232 ein bischen dauern, das halbe Megabyte zu > übertragen. Da wird's auf diese kleine Verzögerung auch nicht ankommen. Da hab ich auch bereits eine lösung parat... Ich übertrage nur die daten welche sich geändert haben... die restlichen werden verworfen... Also es wird byte um byte miteinander verglichen und wenn änderung stattgefunden hat, wird der kanal und die sample nummer zum programm übertragen... somit ist der zeitpunkt eindeutig
Beschleunigte Variante: Nimm doch die 74HC16x, zähl runter bis auf Übertrag und übertrage die Daten dabei rückwärts an den PC. Den wird das kaum stören. Allerdings solltest du dir schon mal Gedanken um die Triggerung machen, bzw. darum, wann das Sampeln eigentlich aufhören soll. Diese ganzen Gedankenspiele könnten sich dann nämlich als ziemlich witzlos erweisen.
A. K. schrieb: > Allerdings solltest du dir schon mal Gedanken um die Triggerung machen, > bzw. darum, wann die Zählerei eigentlich aufhören soll. Diese ganzen > Gedankenspiele könnten sich dann nämlich als ziemlich witzlos erweisen. Hmmm Also ich habe immer gedacht das nach einem Trigger etwas beginnt... also meinst du wann ich beginne zu zählen? Ich dachte mir ich höre auf zu zählen wenn der speicher voll ist... Gibts beim übetragt der einzelnen zähler ic's kein timing problem?
Claudio Hediger schrieb: > Also ich habe immer gedacht das nach einem Trigger etwas beginnt... also > meinst du wann ich beginne zu zählen? Oft ist der Kram direkt vor dem Trigger mindestens so interessant wie der Kram danach. Wenn du erst etliche Takte nach dem Trigger loslegst, fehlt das Wichtigste. Idealerweise startest du also nicht mit dem Triggr, sondern hörst zeitverzögert nach dem Trigger auf. Und dann interessiert dich der Zählerstand einen Sch..ssdreck, denn dann taktest du einfach das halbe Megabyte durch und kriegst den Kram automatisch in chronologischer Reihenfolge. Ganz exakt auf den Takt genau kriegst du den Triggerzeitpunkt so allerdings nicht raus, dazu wären dann Par/Ser-Schieberegister am Zähler hilfreich wenn du das wirklich sogenau brauchst. > Ich dachte mir ich höre auf zu zählen wenn der speicher voll ist... Und da fragst du dich noch, wo der dann steht? > Gibts beim übetragt der einzelnen zähler ic's kein timing problem? Nicht, wenn man die so kaskadiert wie das vorgesehen ist, und wenn man dafür zusätzlich Zeit einplant. Siehe Datasheets der Zähler. Bei den 16x-Zählern gibt's dazu eine recht trickreiche Variante der schnellen Kaskadierung, die in manchen Datasheets zu finden ist, m.W. aber nicht überall korrekt.
@ Claudio Hediger So, wie Du das erklärt hast, habe ich das auch aus dem Blockschaltbild entnommen. Vor Deine Frage gestellt, ob das so geht, reflektiere ich das an dem wie ich mir einen LA vorstelle bzw. wie ich das machen würde. Notwendigerweise stösst Du dabei auf verschiedene Vorstellungen und Betonungen von Schwerpunkten. Zum einen liegt es mir fern, von vorneherein davon auszugehen, das das auslesen der Daten mit der selben Geschwindigkeit vorgeht wie das einlesen. Das haben ja hier auch andere bemerkt. Aber gut. Es "geht" irgendwie, wenn man es denn so tun will. Geschwindigkeit spielt "nach meinem Paradigma vom LA" beim auslesen keine Rolle. Dann würde ich mir sowieso mehr Freiheit bei der Taktung vorstellen. Du kannst nur mit einem Takt arbeiten, da einstellbare Vorteiler etc. fehlen. Man "kann" es natürlich so machen wie Du, wenn man will. Zuletzt basiert die Funktion an zwei Stellen auf Annahmen das ein Ablauf so sein "soll" aber nicht darauf das er durch die Konstruktion erzwungen in bestimmter Weise "ist". Das betrifft die Triggerung und das Auslesen in Bezug auf den Takt. Da keinerlei Synchronisation vorgesehen ist, können sich Abläufe um bis zu (etwas weniger als) zwei Takten verzögern. Ich hingegen habe den Wunsch jeden Zustand und jeden Übergang voll unter Kontrolle zu haben. Ich will jedes Register steuern können und mich nicht darauf verlassen, das es "so sein müsste". Wieder "kann" man das so wie Du machen. Da Du fragst "ob das so geht", reflektiere ich das daran wie es sein "müsste" mit allen Ansichten die man über Konstruktion haben kann. Fazit: Es geht so mit Einschränkungen, aber ich würde diese Einschränkungen nicht für akzeptabel halten.
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.