Hallo!
Ich habe nach Rescherschen keinen günstigen und leicht erhärtlichen VCO IC gefunden, der höher als 30 MHz geht.
Nach weiteren Überlegungen habe ich festgestellt, dass die Abtastung der Signale immer mit der Taktfrequenz ausreichend ist, weil die höchste Frequenz der Signale, die der untersuchte µC ausgeben kann, Taktgenerator/2 beträgt.
MfG
Al schnellen VCO gibt es z.B. den NE564 (bis 50 MHz). der sollte gut zu bekommen sein. Bei den PICs sollte man ja auch mit dem Niedrigeren Takt auskommen.
Das Gerät sollte auf jeden Fall mal 4 Kanäle haben um auch mal eine SPI überprüfen zu können.Hallo wkrug!
Ich möchte das ganz von Anfang selber entwickeln, mir fehlen nur sinnvolle Funktionen, die das Gerät haben soll.
Dann sollte die Samplefrequenz einstellbar sein, damit man auch längere Sequenzen in den Controller reinkriegt.
Die Triggerung sollte auf jedem Kanal mit der steigenden oder fallenden Flanke eines Signals ausgelöst werden können.
Das Stop der Aufzeichnung sollte manuell, mit einer Flanke oder nach einer bestimmten Zeit möglich sein.
Die Zeitachse sollte bei jeder Samplerate eine eindeutige Beschriftung erhalten.
Da kann ich Dir nicht zustimmen. Ich würde da auch ein grafisches Monochromdisplay einsetzen. Die Ansteuerung ist da zwar ein wenig komplizierter, aber es lassen sich mehr Zeichen darstellen als bei einem DOT Matrix Display. Noch dazu wären auch Logik Diagramme möglich, da wirst Du auch bei einem 4x40 Zeichen Display Probleme damit kriegen.Ich möchte ein 2x16 bzw. 4x16 Zeichendisplay mit nur zwei selbstdefinierten Zeichen verwenden (siehe Code), weil es einfacher anzusteuern und sehr gut lesbar ist, oder?
Um die Menge an Daten auch speichern zu können wär, wegen der Geschwindigkeit auch ein externes RAM ( parallel ) nicht zu verachten.
Das könnte man mit einem Akku oder einem GoldCap auch gegen Datenverlust absichern.
Eine Schnittstelle ist bei so einem Messgerät eigentlich ein Muß.
Um nicht unnötig Software proggen zu müssen könnte man das Open Format von Logview verwenden.
( http://www.logview.info )
Wenn man sich da an einige Konventionen hält und eine kleine .ini Datei für sein Projekt verwendet kann man damit die Ergebnisse seiner Messung auswerten.
Ein nettes Feature wäre noch, wenn man einen Analog Komperator mit einer Vergleichsspannung füttert und den anderen Eingang als Schwellwertindikator verwendet.
Damit ließe sich auch Testen, wann eine Eingangsspannung die Vergleichsspannung überschreitet.
Ja, das wären mal dann Sachen, die mir auf die Schnelle einfallen, die Liste könnte man sicher aber noch länger machen.
Hallo!
@ Besserwessi
Danke sehr für deine Information. Den NE564 gibt es sogar beim Reichelt!
Weil die VCO (PLL) ICs ziemlich schmalle Bereiche für Frequnzen, an die sich einstellen können, haben, würde es einen Bereichsumschalter benötigen, der die Schaltung komplizieren würde. Aus dem Grund werde ich bei der einfacher Verdopplung der Oszillatorfrequenz bleiben. Wenn jemand eine µC Schaltung mit internem Oszillator entwickeln würde, müsste in der Entwicklungszeit einen Quarz- bzw. RC Oszillator mit gleicher Frequenz benutzen.
@ wkrug
Deine Wünschliste sicher sinnvoll ist, lässt sich aber bei Einfachkeit meines Projektes nicht realisieren. Der µC Tester wird 4 Kanäle haben, ist aber kein umfangreiches Logic Analyser, den ich zwar zuerst bauen wollte, aber doch nicht zu Ende gemacht habe, weil die Schaltung nicht mehr einfach wäre und viel Funktionen fast nie benutzt würden.
Ich sehe keinen Zusammenhang zwischen der variabler Abtastfrequenz und Länge der in RAM eingelesener Sequenz. Bei hier benutzter fester synchronner Aufzeichnung ist die Beschriftung der Zeitachse überflüssig.
Die Auswahl des Signalls, das SCAN starten sollte, wird durch umlegen des Clips Trigger der mit Flankenumschalter verbunden ist, realisiert. Der Trigger wird mit keinem aufgezeichnetem Kanal fest verbunden (siehe Code).
Ich habe schon sehr lange ein Grafikdisplay getestet und mich für Zeichendisplay nicht ohne Grund entschieden.
Es wird kein externer RAM verwendet, da ich den Speicher des µCs ausreichend finde (4x2048 Bit).
Ich weiß, dass nur selber entwikelte Schaltungen für den Entwickler keine Nachteile haben. Und bei eventuellem Nachbau hat man zum Glück freie Wahl.
MfGCode:.-----------. | | \/ | | Kanal1 /\-------------------| | | | \/ | | Kanal2 /\-------------------| | | | \/ | | Kanal3 /\-------------------| | | µC Tester | \/ | | Kanal4 /\-------------------| | | | \/ | | Trigger /\-------------------| | | | \/ | | GND /\-------------------| | | | | | '-----------'
Damit hast Du sicher recht.Ich weiß, dass nur selber entwikelte Schaltungen für den Entwickler keine Nachteile haben. Und bei eventuellem Nachbau hat man zum Glück freie Wahl.
Jeder kann seine selbst entwickelte Schaltung so entwerfen, wie sie Seinen Vorstellungen entspricht.
Du hast halt eben gefragt, was wir ( somit auch ich ) davon halten.
Ich halte Deine Idee wirklich für sehr gut und hab halt meinen Senf dazu gegeben, was ich mir wünschen würde.
Es ist mir klar das meine Wunschliste nur mit einem schnellen Controller mit vielen Ports realsierbar ist. ( RAM, Display, usw. )
Allerdings stell ich mir die Peripherie nicht sonderlich aufwändig vor.
Am Eingang wäre eventuell ein Puffer sinnvoll, ansonsten geht es Hardwaremässig nur um ein zusätzlices RAM, einen anderen Displaytyp, einen USB Bridge Baustein und ein paar Tasten.
Bei der Speicherung der Daten im Flash, seh ich halt das Problem, das man den Flash nicht beliebig oft beschreiben kann, er geht irgendwann dabei kaputt.
Von der Softwareseite kann ich nicht viel mitreden, da ich mich mit PIC's dazu zu wenig beschäftigt habe.
Ich lese jeden Beitrag und vergleiche mit meiner eigener Vostellung. Wenn mir etwas zu kompliziert scheint, lehne ich den Vorschlag ab.
Mit dem Puffer am Eingang hast Du vollig Recht und ihn wird es sicher geben, weil der PIC nicht sofort reagieren kann und die Eigangsdaten müssen um ein paar Takten verzögert werden. Zur Zeit habe ich 4 Takten angenommen, können aber mehr nötig sein.
Danke dir, mit dem Speichern in Flash stimmt. Laut Microchip sollte sich der Flash 100 000 mal programmieren lassen und der EEPROM 1 000 000 mal. Ich werde dann die Daten wahlweise in EEPROM oder Flash speichern lassen, dass eine wichtige Änderung des Menüs ergibt. Ich denke, dass nicht jedesmal die Daten vom RAM dauerhaft gespeichert werden. Es wird, im schlimmstem Fall, der PIC jede paar Jahren, wie eine leere Batterie gewechselt.
Ich habe im Code die Bilder auf dem Display und die Bedienungselemente skizziert, wobei "X" den blinkenden Cursor beim ausgewähltem Menüpunkt und die vierstellige Zahl die aktuelle Adresse des linksten Samples in RAM bedeutet.
MfGCode:.------------------. | | Bedienungselemente | X SCAN SAVE E | .--. | | Menü |# | RAM (Schiebeschalter) | VIEW CALL E | '--' | | _ .--. _ | EDIT SAVE F | _| |# | |_ (Schiebeschalter) | | '--' | GEN CALL F | .--. | | (Takt) x1 |# | x2 (Schiebeschalter) '------------------' '--' _ .------------------. Start (_) (Drehencoder mit Taster) | _ _ _ _ _ _ _ | | 1_ _ _ _ _ _ _ _ | | __ __ __ _ | | 0__ __ __ __ | | ____ ___ | | 0____ ____ | | _______ | | 0________ | | | '------------------'
Hallo!
Nach einem Vergleich von PIC und AVR µCs habe ich mich, vor allem wegen niedrigerem Preis und doppelter Taktfrequenz, fast für einen ATMega168-20 entschieden. Ausserdem haben die AVRs keine innere Taktteilung, was die Hardware deutlich vereinfacht.
Weil ich mich zuletzt mit PIC µCs beschäftigt habe, würde die Entwicklung leider ein bißchen länger dauern. Ich müsste mir zuerst einen Entwicklungsboard und Brenner bauen sowie neue Befehle erlernen. Zum Glück gibt es nur einen ASM.
Damit ich mir eventuell unnötige Arbeit ersparen kann, frage ich lieber AVR Kenner, ob ich wirklich bei 20 MHz Taktfrequenz Daten vom Port ins RAM mit 10 MHz einlesen kann?
Ich habe aus dem Befehlsatz im Datenblatt erfahren, dass dafür 3 Takte benötigt werden (IN+STO), was effektiv 6,66 MHz ist. Mit einem PIC der mit 48 MHz arbeitet kann ich das gleiche mit 6 MHz machen. Wegen so kleiner Differenz würde es sich sicher nicht lohnen.
Oder gibt es noch schnellere AVRs ohne inneren Taktteilung mit min. 1kB RAM ? Mir ist eigentlich egal ob es 8, 16 oder 32-Bit CPU hat. Die ARM basierte AVRs haben leider zu wenig RAM.
In Frage kommen noch eventuell die C51 basierte, die mit 40/2 bzw. 60/2 MHz Takt arbeiten können. Bei dem letztem ergibt sich für 3 Takte einlesen mit 10 MHz, aber ob es stimmt? So weit ich mir noch erinnern kann arbeiten die C51 mit einer Taktteilung Fosc/12.
Ich würde ungerne einen µC in PLCC Gehäuse nehmen, nur wenn es seien muss...
MfG
hallo Picture,
was du da gestern mit wkrug besprochen hast:
nun ja ..da ist ein denkfehler drinne.Bei der Speicherung der Daten im Flash, seh ich halt das Problem, das man den Flash nicht beliebig oft beschreiben kann, er geht irgendwann dabei kaputt.
das flashram , das kann man garnicht mit daten beschreiben!!
da liegt ausschliesslich der programmcode drinne (zumindest bei atmel).
die variablen-daten speichert man ja im SRAM, für das es keine zyklengrenze gibt. der mega 644 (40Pin-DIL) hat davon schonmal 4kb.
gruss klaus
ach so...
und wie ich das auf den ersten blick sehe (ich bin eigentlich kein assemblertyp) .. brauchste wohl 3 takte midestens um vom port was in das sram zu schaffen.
allersinks kann man in der gleichen zeit auch ein ganzes portset (also 8 it) transferieren.
wenn man da jetzt für den eingang ein serial-in parralel-out shift nehmen würde, könnte man doch zeit sparen .. oder ?
gruss
p.s.
und jetzt wirds lustig in meinen gedanken.:
wenn man 2 cpu nimmt, die um 180grad phsenverschoben takten,
dann hätte man doch ein gesmttakt von 40mhz .. oder ?
Hallo kolisson!
Bei einigen Typen von PIC µC (alle PIC18FXXX) kann man Daten im Flash ablegen, dazu habe ich ausprobierte fertige Unterprogramme. Ich habe schon mit direkt vom Oszillator (eventuell durch Frequenzdoppler auf 2Fosc max. 40 MHz erhöhte Frequenz) getaktete universelle Schieberegister 74HC299 vorgesehen für PORT<->RAM Datentransfer beim SCAN und GEN zu gewährleisten.
Die Idee mit zwei gegengetakteten µCs würde sicher bei AVRs funktionieren, aber bei PICs, die innere Taktteilung Fosc/4 haben, kann ich mir die innere Synchronisation nicht vorstellen.
So wie es bisher ausschaut, würde ich bei PICs und 4 Kanälen mit max. 10 MHz bzw. 2 Kanälen mit max. 20 MHz Abtastfrequenz bleiben müssen.
Ich persönlich würde mir wahrscheinlich, wegen Geschwindigkeit, die Version mit 2x20 MHz und 2x24 Zeichen Display bauen, weil ich mich überwiegend mit PICs aus der Familie 18FXXX beschäftige, die mit Fosc = 40 MHz (CPU Takt 10 MHz) laufen.
Meistens werde ich sowieso 1 Kanal mit 40 MHz Abtastfrequenz und einer Spitze benutzen um durch den µC generiertes Signal anzuschauen. Um mehr Signale anzuschauen, wenn ich das laufende Programm nicht geändert hätte, braüchte ich nur die Aufnahme für andere Pins mit gleicher Triggerung wiederholen. Ich werde den µC Tester vor allem als DSO benutzen.
Der µC Tester sollte möglichst universiell und auch für AVRs anwendbar sein. Ich sehe hier zwei Möglichkeiten: entweder werden sich die AVR Benutzer ihn mit PIC bauen, oder wird jemand von mir benutzte Hardware um Software fur AVR ergänzen.
In dem erstem Fall fehlt mir noch die max. Frequenz des Signals, das ein AVR µC bei bestimmter Taktfrequenz ausgeben kann. Mit dem Befehlsatz aus Datenblätter für AVRs komme ich auf Fosc/6 (SBI, OUT, CBI, OUT), bin aber nicht sicher, ob das stimmt. Wenn es stimmen würde, wären die AVRs langsamer als PICs mit Fosc/8, da sie mit niedrigerer Fosc arbeiten.
MfG
Berechtigungen
Zitieren
Lesezeichen