Forum: Mikrocontroller und Digitale Elektronik Blockschaltbild bitte mal drüberschauen


von C. H. (hedie)


Angehängte Dateien:

Lesenswert?

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

von (prx) A. K. (prx)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?


von C. H. (hedie)


Lesenswert?

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? :)

von C. H. (hedie)


Lesenswert?

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?

von Grrrr (Gast)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

Claudio Hediger schrieb:

> Da sehe ich nur den 74HCT163 (4bit Synchron) als alternative...

Entweder dieser (besser als 74HC), oder 74HC590.

von C. H. (hedie)


Lesenswert?

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)

von C. H. (hedie)


Lesenswert?

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?

von (prx) A. K. (prx)


Lesenswert?

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.

von C. H. (hedie)


Lesenswert?

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

von Grrrr (Gast)


Lesenswert?

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.

von Grrrr (Gast)


Lesenswert?

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.

von C. H. (hedie)


Lesenswert?

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 :)

von (prx) A. K. (prx)


Lesenswert?

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.

von C. H. (hedie)


Lesenswert?

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 :)

von C. H. (hedie)


Lesenswert?

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

von (prx) A. K. (prx)


Lesenswert?

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.

von C. H. (hedie)


Lesenswert?

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?

von (prx) A. K. (prx)


Lesenswert?

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.

von Grrrr (Gast)


Lesenswert?

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