Archiv verlassen und diese Seite im Standarddesign anzeigen : [ERLEDIGT] µC Tester (DSO) selber bauen (unterworfen)
Hallo!
Das für digitale Signale ein analoger Oszilloskop nicht geeignet und Speicheroszilloskop mit ADC überdimmensioniert ist, muss ich niemanden überzeugen.
Deswegen möchte ich mir ein PIC18FXXX basiertes, händliches Messgerät für Analise und Entwicklung von µc Schaltungen selber bauen. Es sollte mehrkanäliger DSO ohne ADC für digitale Signale sein.
Ich brauche keine technische Hilfe. Von Euch wird nur Hilfe beim Festlegung der Funktionen und Menüs erwartet. Meine letzte einfachste Idee ist mit der verdoppelter Taktfrequenz (PLL) die Signale synchron abzutasten und den Startimpuls durch den untersuchten µC generieren lassen.
Ich bedanke mich sehr im voraus für Ihre zahlreiche Beteiligung ! :)
MfG
Ich würde das, was Du da bauen willst als "Logic Analyzer" bezeichnen.
Vor einiger Zeit war mal so ein Projekt in ELEKTOR.
Die Grundroutinen von Da könntest Du sicher übernehmen.
Ein Punkt, der mich bei der Elektor Applikation gestört hat war, das die Zeitachse keine eindeutige Skalierung hatte.
Soweit ich mich erinnere, war dieses Projekt auch mit einem PIC Controller und einem 128x64 Punktmatrix Display.
Hallo wkrug!
Ich möchte das ganz von Anfang selber entwickeln, mir fehlen nur sinnvolle Funktionen, die das Gerät haben soll.
Ich habe schon sehr viel, aber nicht zu Ende gemacht, weil ich nicht überzeugt war, ob es wirklich sinnvol wäre.
Ich möchte ein 2x16 mit nur 2 bzw. 4 selbstdefinierten Zeichen verwenden (siehe Code), weil es einfacher anzusteuern und sehr gut lesbar ist, oder?
Weil es nur für µC vorgesehen ist, möchte ich den durch PLL verdoppelten Taktgenerator des untersuchten µCs zum Abtasten der Signale verwenden und somit ist die Skalierung eindeutig.
MfG
Für 1 Kanal pro Zeile
0 1
.-----. .-----.
|#####| |ooooo|
|#####| |#####|
|#####| |#####|
|#####| Low |#####| High
|#####| |#####|
|#####| |#####|
|#####| |#####|
|ooooo| |#####|
'-----' '-----'
Für 2 Kanäle pro Zeile
0 1 2 3
.-----. .-----. .-----. .-----.
|#####| |ooooo| High |#####| |ooooo| High
|#####| |#####| |#####| |#####|
|ooooo| Low |#####| |ooooo| Low |#####|
|#####| |#####| |#####| |#####|
|#####| |#####| |#####| |#####|
|#####| |#####| |ooooo| High |ooooo| High
|#####| |#####| |#####| |#####|
|ooooo| Low |ooooo| Low |#####| |#####|
'-----' '-----' '-----' '-----'
Mein bisher ausgedachtes Menü sieht so aus:
1. SCAN (vom PORT in RAM einlesen)
2. VIEW (in RAM Anschauen, Analisieren)
3. SAVE (RAM Inhalt in Flash abspeichern)
4. CALL (vom Flash ins RAM holen)
5. EDIT (in RAM editieren)
6. GEN (RAM Inhalt an PORT ausgeben)
Wenn niemand es ändern möchte, werde ich es so realisieren.
Der Impuls zum SCAN starten wird vom untersuchtem µC erzeugt.
Mfg
Besserwessi
15.12.2008, 22:01
Zum ansehen der Daten sollte man eine Übertragung zum PC vorsehen. Am besten mit einer isolierten Schnittstelle. Der Schrim am PC ist halt deutlich größer und übersichtlicher. Gerade bei der Logicanalyse braucht man schon mal relativ lange Datensätze. Da ist so ein kleines LCD schnell überfordert.
Die Startbedingung (alternativ auch das Ende) sollte man schon variabler machen. Wenigstens sollte man sich einen der Pins als Trigger aussuchen können.
Hallo Besserwessi!
Ich lasse die zwei Pins (RX und TX) unbeschaltet und verbrauche hoffentlich nicht den ganzen Programmspeicher, so dass wenn jemand möchte, könnte sich das mit eigenem Software erweitern. Das Gerätchen wird von mir vor allem ohne PC benutzt. Das Display wird nur ein Fenster das durch den ganzen RAM Inhalt durch Mausrad in beiden Richtungen verschoben werden kann.
Das Aussuchen des Startimpulses wird durch plazieren des Clips vom Trigger möglich. Es werden bei von mir dafür vorgesehenem PIC18F252 immer 1024 Bytes in RAM eingelesen. Das ergibt bei SCAN für 2 Kanäle Abtastfrequenz von 4 x µC Taktfrequenz und 2 x 4096 Impulsen bzw. für 4 Kanäle 2 x µC Taktfrequenz und 4 x 2048 Impulsen. Zum Entwickeln bleibt mir nur die PLL Schaltung die Taktfrequenz des untersuchten µCs vervielfacht.
MfG
kolisson
15.12.2008, 23:51
ja nun...
und sowas benötigt man für was... ?
eigentlich weiss man doch, was man programmiert .. oder ?
aber spass beiseite...
wenn man sowas baut, wäre da nicht eine "sozusagen" interne triggeruhr interessant, da man ja nur einen begrenzten speicher hat.
wenn also beim ersten messlauf das zu beobachtende ereignis am ende des speichers liegen würde, käme man doch auf die idee , bei der nächsten messung xxx-takte des kanals y verstreichen zu lassen, um dann erstz aufzuzeichnen.
was haltet ihr davon ?
gruss klaus
Das ist ja begründet, das sowas vorkommen könnte. Ich habe mir einfach gedacht, dass man in diesem Fall den Startimpuls für die Aufnahme in den untersuchten µC einprogrammieren könnte, da er noch in einer Entwicklungsphase wäre.
Das von mir geplanntes Gerätchen möchte ich möglichst schnell haben und es geht ausser Einlesen mit max. Geschwindigkeit des µCs nichts mehr (die RAM Adresse wird im Hintergrund erhöht). Ich musste sogar jeder Schritt ohne Schleifen programmieren und 1024 mal das gleiche PORT->RAM im Quellcode kopieren! :)
MfG
kolisson
16.12.2008, 00:35
dann bau wenigstens einen HC4538 mit ein...
dann kannste etwas besser wählen , auf was du triggern willst und
sogar nen INT auslösen.
.. und wie lange benötigt die PLL... bis die verdopplung der frequenz steht ?
... da habe ich keine ahnung.
wenn es etwas dauert.. braucht man dann doch den start-counter.
gruss klaus
Ich denke momentan nur an die Funktionen und Menü und mit Einzelheiten der Hardware werde ich mich später stressen. :)
Die Taktfrequenz des untersuchten µCs ändert sich mit der Zeit nicht und das PLL des Testers braucht sich nur beim Einschalten einzustellen.
Gerade ist mir eingefallen, dass ich für das Gerätchen noch ein Name brauche... vielleicht "µC Tester" ?
MfG
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
Besserwessi
16.12.2008, 16:25
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.
Hallo wkrug!
Ich möchte das ganz von Anfang selber entwickeln, mir fehlen nur sinnvolle Funktionen, die das Gerät haben soll.
Das Gerät sollte auf jeden Fall mal 4 Kanäle haben um auch mal eine SPI überprüfen zu können.
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.
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?
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.
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. :)
MfG
.-----------.
| |
\/ | |
Kanal1 /\-------------------| |
| |
\/ | |
Kanal2 /\-------------------| |
| |
\/ | |
Kanal3 /\-------------------| |
| µC Tester |
\/ | |
Kanal4 /\-------------------| |
| |
\/ | |
Trigger /\-------------------| |
| |
\/ | |
GND /\-------------------| |
| |
| |
'-----------'
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.
Damit hast Du sicher recht.
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.
MfG
.------------------.
| | 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
kolisson
17.12.2008, 09:43
hallo Picture,
was du da gestern mit wkrug besprochen hast:
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.
nun ja ..da ist ein denkfehler drinne.
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
kolisson
17.12.2008, 10:01
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
Besserwessi
17.12.2008, 17:45
Die routine für die AVRs braucht wirklich nur 3 Zyklen (Befehne In port,Reg und ST x+,Reg).
Wenn es wirklich schneller sein soll, wird man wohl die Daten direkt per Logic in ein externe RAM schieben können. Das braucht dann ein SRAM und ein paar Logic ICs (gar nicht so viele, etwa 4-5) oder alternativ ein CPLD oder FPGA. Dann sollten aber auch rund 50-100 MHz Abtastrate drin sein. Das auslesen usw. kann man dann per µC machen.
Hallo Besserwessi!
Du sagst also, dass die max. Frequenz eines Signals das ein AVR durchs Port ausgeben kann ist Fosc/3 und nicht Fosc/6 ?
Es soll nicht schneller, aber einfach sein und die Samplingrate 40 MS/s reicht mir fürs Testen von µC Schaltungen völlig aus.
Inzwischen habe ich entschieden, dass ich ein "echten" DSO mit ADC und Handydisplay 64x96 Pixel bauen möchte, weiß ich aber noch nicht wann ... O:)
MfG
Besserwessi
17.12.2008, 18:55
Der Wert FOSC/3 gibt ohne schelife drumrum. mit schleife sollte man FOSC/4 eventuell gerade noch schaffen können. Es gaht natürlich auch die Lösung den Code 4000 mal hinzuschreiben. Das Tempo gilt für Ein- oder Ausgabe für die meisten Ports. Bei den ganz großen wie MEGA256 oder so gehen nicht alle ports so schnell, aber die meisten.
Damit kommt man aber halt nur auf gut 6 MS/s. Für tests kann man allerdings den Controller in der Zielschaltung auch langsamer (z.B. 3 MHz beim AVR oder 12 MHz beim PIC) laufen lassen.
das flashram , das kann man garnicht mit daten beschreiben!!
da liegt ausschliesslich der programmcode drinne (zumindest bei atmel).
Und was macht dann der Assembler Befehl "SPM" ?
Den es aber zugegebenermassen nicht bei allen AVR's gibt.
Beim ATMEGA8 hab ich ihn auf jeden Fall gefunden.
Wunderbar! Wenn die AVRs nicht schneller als PICs sind, dann sollte es hinhauen. :)
Ein Beispiel zum Überprüfen:
AVR mit Fosc 20 MHz -> am Port Fosc/4 = 5 MHz
PIC mit Fosc 40 MHz -> am Port Fosc/8 = 5 MHz
Um das Signal am Port durch den µC Tester (PIC) bei Abtastfrequenz 20 MHz einzulesen muss ich die Schieberegister am Eigang mit 20 MHz takten, was für AVRs gleich Fosc und für PICs Fosc/2 ist.
Wenn ich Abtastfrequenz 40 MHz haben will, müsste ich nur für AVRs die Frequenz des Oszllators verdoppeln, kommt also noch ein Umschalter dazu (siehe Code).
Der PIC im µC Tester kann den Wert vom Port ins RAM mit Fosc/8 bringen, also die 8 Bits vom Eigangsregister mit 5 MHz einlesen. Das ergibt dann die max. Abtastfrequenzen:
1 Kanal -> 40 MHz, 2 Kanäle -> 20 MHz, 4 Kanäle -> 10 MHz
Wie ich schon früher geschrieben habe, finde ich, wegen Geschwindigkeit, eine Ausführung mit einem Umschalter für 1-2 Kanäle als optimal. Bei Einem Betrieb mit einem Kanal und Spitze, kann man das eingelesene Signal in zwei Displayzeilen darstellen.
MfG
Bedienungselemente
.--.
Menü |# | RAM (Schiebeschalter)
'--'
_ .--. _
_| |# | |_ (Schiebeschalter)
'--'
.--.
(Kanäle) 1 |# | 2 (Schiebeschalter)
'--'
.--.
PIC |# | AVR (Schiebeschalter)
'--'
-
Start ( ) (Drehrad mit Taster)
-
Beispiel für Display 2 x 20 Zeichen
.----------------------. .----------------------.
| | | _ _ _ _ _ _ _ _ _ |
| XSCAN VIEW EDIT GEN | | 10_ _ _ _ _ _ _ _ _ |
| | | __ __ __ __ |
| SAVE CALE SAVF CALF | | 00__ __ __ __ __ |
| | | |
'----------------------' '----------------------'
Besserwessi
17.12.2008, 21:00
Schaft der PIC das wirklich die Daten in 8 Zyken vom Port ins RAM inclusive einer Schleife drum rum ? Das wären ja nur 2 CPU zyklen.
Ohne Schleife schafts der AVR in 3 Zyken, der 4 te Zyklus war für die Schleife gedacht, wobei mit aber aufgefallen ist, das das wohl nicht ganz reicht mit konstant 4 Zyklen, denn die Sprünge brauchen auch wenigstens 2 Zyklen, genau wie der RAM zugriff. Da krigt man zwar im mittel FOSC/4 hin, aber nicht jedes mal gleich. Das geht dann erst mit FOSC/5.
Je mehr um so besser für mich. :)
So wie ich das jetzt sehe, hat der PIC zwar innere Taktteilung von Fosc auf 4 CPU Takten (Fosc/4), aber dafür braucht er z.B. für Port ins RAM einlesen ohne Schleife indirekt mit automatischer Adressenerhöhung nur zwei CPU Takte.
Deswegen bei Fosc = 40 MHz, wenn man die Daten in ein Schieberegister seriel mit Fosc eintaktet und sie dann parallel (8-bit) mit Fosc/8 = 5 MHz ins RAM einliest, hat man 8x5 MHz = 40 MHz Abtastrate (für ein Kanal).
Ich überlege immer noch ob ich nicht bei nur einem Kanal mit Spitze bleiben soll... und nur für PICs brauche ich keinen Frequenzverdoppler und PIC/AVR Umschalter... vielleicht macht es für AVRs jemand andere...
MfG
kolisson
17.12.2008, 23:54
hallo besserwessi...
das beruhigt mich aber .. was du schreibst:
Die routine für die AVRs braucht wirklich nur 3 Zyklen (Befehne In port,Reg und ST x+,Reg).
da ich heute nur mal kurz ins command-set geschaut habe, ohne die wirkliche beschreibubg der commands zu haben.
also ist mein intuitives ratespiel ja gut ausgegangen.
@picture...
demnach wird es wohl fosc/3 sein !
wenn du jedoch berücksichtigst, dass das einlesen eines bits genauso lange dauert, wie das einlesen von 8 bit, wäre es ja so, dass man durch geschickte externe beschaltung, wieder schneller werden kann.
gruss klaus
Hallo!
Mir ist nicht ums EINLESEN sondern ums AUSGEBEN beim AVRs gegangen, weil ich es eventuell mit PIC einlesen wollte. Wegen keiner klarer Antwort auf meine Frage, mache ich den µC Tester nur für PICs, weil mit AVRs kenne ich mich nicht genau aus.
Anscheinend sind die EDIT und GEN Funktionen nicht gefragt und das Abspeichern der eingelesener Signale im EEPROM, wegen zu kleiner Größe (nur 256 Bytes), uninteressant.
Deswegen habe ich mich letztendlich entschieden, dass ich nur ein einfachen DSO mit 4 Kanälen (Abtastrate max. 12 MS/s) und 2x16 Zeichen Display baue.
Wahrscheinlich als ersten baue ich mir jedoch 1-kanaligen DSO mit Spitze (PIC18F252) und max. Abtastrate 40 MS/s, weil er hardwaremässig am einfachsten ist. Um 4 Kanäle gleichzeitig beobachten zu können, müsste man das Einlesen der Signale 4 mal mit gleicher Triggerung wiederholen. Diese Lösung hat eben das Vorteil, dass nur zwei Kabel (OSC und TRG) nötig sind.
Im Code habe ich den vorläufigen Schaltplan skizziert, dazu muss ich nur Software schreiben, was etwas dauern wird. Ich melde mich wieder erst im nächstem Jahr im "PIC Controller" Forum, wenn ich damit fertig bin.
Vielen Dank an alle, die mir geholfen haben ein vernünftiges Menu zu erstellen.
Ich wünsche allen frohe Weihnachten, guten Rutsch und viel Erfolg im Jahr 2009! :)
MfG
VCC
+
| GND
+---+ ===
14| 9| |7
Spitze .---------------. 1,2.-------o-------.
<-----------|IC2 |------|IC3 |
+--| 74HC40105? | +--| 74HC164 |
| '---------------' | 8'---------------'
| | 1|1|1|1|6|5|4|3|
| | 3|2|1|0| | | | |
+----------------------+ | | | | | | | +-----> B0
| | | | | | | +-------> B1
| | | | | | +---------> B2
| | | | | +-----------> B3
| VCC | | | +-------------> B4
| + | | +---------------> B5
| | | +-----------------> B6
| +-----+-----+ +-------------------> B7
| | |
| .-. .-. GND
| | |R4 | |R5 ===
| | |10k | |10k |
| '-' '-' +-> GND
\ | | |
OSC X----+-------+-----------|--------------------------> OSC1
/ |
\ |
TRG X------------------------+--------------------------> TRG
/
+--+--+----------------+
| | | |
R1...R3.-..-..-. IC1 |
3 x 10k| || || | PIC |
| || || | 18F252 |
'-''-''-'.-------. |
Mausrad o-| | |-|1 28|-< B7 |
+--+-o--__ |\-+--|-|2 27|-< B6 |
| | o-+-----|-|3 26|-< B5 |
=== +-------o _/o-+-|4 25|-< B4 | /
GND | Flanke / -|5 24|-< B3 +--+-------X +VCC
TRG >-------|---------------|6 23|-< B2 | | \
| -|7 22|-< B1 | --- C1
+---------------|8 21|-< B0 | --- µ1
OSC1 >-----------------------|9 20|------+ | /
-|10 19|------+--+-------X GND
+-------|11 18|- | \
GND >-+ | +-----|12 17|- ===
| GND | | +---|13 16|---+ GND
=== === | | | +-|14 15|-+ |
GND VCC | | | | | '-------' | |
+ +-+-+ | | | | | |
| | | | | | | | | | | | | |
.-----------------------------.
|2 1 3 5 1 1 1 1 7 8 9 1 4 6|
| 1 2 3 4 0 |
| |
'-----------------------------'
Display 2x16 Zeichen
Hallo!
Ich bin jetzt auf ein Problem gestoßen, das ich bisher nicht, wegen fehlender Überzeugung, entgültig lösen konnte. Um ein Signal vom µC mit ausreichender Auflösung einlesen zu können, brauche ich einen Taktgenerator mit Frequenz 2xFosc (für AVRs) bzw. 4xFosc (für PICs, also 2x2) des zu testenden µCs.
Bisher habe ich nur feste HF Frequenzen mit LC Schwigkreisen multipliziert. Diesmal handelt sich aber um variable Frequenz, die im Bereich von ca. 8 kHz bis 10 MHz liegen kann.
Ich habe schon ein paar Ideen dafür, bevor ich jedoch eine realisiere, möchte ich zuerst hier einen Rat holen, um ein Rad nicht neu erfinden zu müssen. Mir geht es vor allem um eine einfachste Methode und nicht konkrete Lösung.
Erwünscht wären auch Meinungen über von mir zuletzt angenommene Variante des Menüs, wo in der oberen Zeile Meldungen (z.B. dass ein Takt vom zu testendem µC fehlt) und in der unteren Zeile Menüpukte zur Auswahl mit dem Drehencoder/Mausrad, dargestellt werden.
Meine bisherige Ideen:
1. Für jede Flanke ein Nadelimpuls erzeugen und mit Monoflop auf ca.T/2 verlängern (siehe Code).
2. Rechteck in Dreieck wandeln und gleichrichten.
3. PLL mit variablem Oszillator und Mischer um den ganzen Bereich ohne Umschaltung abzudecken.
Falls unvermeindbar, kann ich fürs Einstellen der sich ändernden Parameter natürlich der in der Schaltung schon vorhandenen und fast unbelasteten µC (PIC) nutzen. Mir scheint die 1. Methode am eifachsten zu sein.
Ich bedanke mich herzlich für jeden Beitrag im voraus. :)
MfG
+------------------------------------------+
| |
.-. |
R2| | |
| | |
'-' C2 |
| || |
+-||-+ VCC |
| || | + |
.------. ___ |\| |
| |--------|___|-+------|+\ ___ |
__ | MF1 | R3 | | K>-|___|+----+
Fx >--+---------| \ | | --- +-|-/ R4 | |
| ___ |XOR)-| o---> 2Fx C3--- | |/| - ---
+-|___|-+-|__/ '------' | === - D ^ ---C4
| R1 | === GND VCC | |
| --- VCC GND === ===
| ---C1 + GND GND
| | |
| === .-.
| GND R5| |
| | |
| '-' C5
| | ||
| +-||-+
| | || |
| .------.
| | |---> Takt present
| | MF2 |
| | |
+---------------| |
'------'
Nach ziemlich langen Überlegungen habe ich mich für eine gemischte Lösung die Methoden 1. und 3. verwendet, entschieden. Eine vereinfachte Skizze befindet sich im Code.
Falls jemand einen Denkfehler in der Schaltung findet, bitte melden! :)
MfG
.--------.
Data >----------------->| 164 |<---------------------+
'--------' |
|||||||| |
VVVVVVVV |
.-----------------. |
| | |
|Osc PIC18F252 | |
vom |/4 Osc| |
getestetem '-----------------' |
µC | A |
| | |
| +---------------+
| |
|Fx.------. 2Fx __ |
PIC +->| PLL |>-+---------\\ \ |4Fx
Takt >----+--------o | | | ___ ||86|-+
| .----. __--o---->|XR-215| +-|___|-+-//__/
+-| /2 |-o Fx'------' |
| 74 | AVR ---
'----' ---
Fx = 1...10 MHz |
===
GND
Besserwessi
05.03.2009, 17:59
Mit den PICs kenne ich mich nicht so aus, aber man sollte klären ob die mit einem etwas ungleichmäßigen Takt auch klarkommen, sonst müßte man den PLL die ganze Taktvervielfältigung machen lassen.
Soweit ich weiss gibt es auch einiger der neueren PICs mit interem PLL um die höhere Frequenz zu erzeugen. Es könnte aber passieren, das man an die hohe Frequenz nicht rankommt.
Je nach Quelle für den Takt, könnte man doch auch gleich eine Schnellere taktquelle (wohl ein Quarzgenerator) nutzen und sich den PLL ganz sparen.
Hallo Besserwessi!
Vielen Dank fürs genaue Analise von mir vorgeschlagener Schaltung.
Selbstverständlich werde ich die Lösung noch in der Praxis genau testen müssen. Weil der Tester für µCs vorgesehen ist, die mit unterschiedlichen Oszillatorfrequenzen arbeiten und der PIC 18F252 immer mit 4xFx arbeiten muss, ist eine permanente Frequenz z.B. vom Quarzoscillator unannehmbar.
Die interne PLL Schaltung ist im DB nicht genau beschrieben. Das einzige betrifft nur 10 MHz, dass sie daraus 40 MHz macht (ausprobiert). Ausserdem, lasst sich die Konfiguration des Oszillators durch selbstprogrammieren angeblich nicht ändern.
Es ist schwer einen VCO zu finden, der den ganzen nötigen Bereich deckt. Sollte der XR-215 mit dem einfachem verdoppler mit XOR nicht richtig für den PIC18F252 sein, habe ich noch als VCO einen LTC1799 betrachtet, der sollte bis 40 MHz laufen und mit der Bereichsumschaltung sogar Fx vom 10 kHz bis 10 MHz (also 4 Fx = 40 kHz bis 40 MHz) liefern können. In dem Fall muss aber zusätzlich ein externer Phasenkomparator aufgebaut werden.
Die früher analisierte Schaltung mit zwei mal Fx Verdoppelung habe ich doch als zu kompliziert verworfen.
MfG
Besserwessi
05.03.2009, 19:18
Die Verdopplung mit dem XOR gatter betrifft nicht nur den Controller, sondern auch den Abtastzeitpukt für den Eingang. Die Daten werden also nicht in gleichen Zeitabständen aufgenommen.
Danke, du hast Recht, ich habe es übersehen. Das muss ich dann mit dem LTC1799 machen. Den habe ich leider noch nicht, muss ich erst bestellen. Dabei werde ich versuchen einen Transistor (bipolaren p-n-p bzw. FET) als eintellbaren Widerstand zu benutzen, da die Frequenz beim LTC nicht mit Spannung festgelegt werden kann. Der LTC1799 sollte laut DB ein sweep 300:1 können.
Als einfachen Phasenkomparator möchte ich die Schaltung im Code verwenden. Muss ich aber vorher noch genauer analisieren, wie sie sich bei harmonischen Frequenzen verhält.
Falls mir das ganze mit PLL insgesamt zu komplieziert wäre, würde ich es mit zwei Oszillatoren (Quarz und LC + Mischer, z.B. NE612) und FLL (frequency locked loop) versuchen aufzubauen, was die Hardware erheblich reduziert. Diese Lösung benötigt aber sehr stabilen LC VCO, weil während des Einlesens der Eingangsdaten die FLL Schleife offen bleibt, da der PIC keine Zeit um sie zu steuern hat.
MfG
VCC
+
|
+-----+-----+
| | |
| .--o--. | D1
Takt Fx (max.10 MHz) +--|D S Q|--|-----------+-->|---+
vom zu | | | .-. | |
testendem >---------------|->|> _| | |R | |
µC | | R Qo | | | |
| '--o--' '-' __ | C1 |
| | | D / |-+ || |
| +-----+->|-o( 00| +-||-+
| 74HC74 | \__|-+ | || |
+-----+ | | === |
| | | | GND |
LTC1799 | .--o--. | | |
.-----. +--|D S Q|--|-----------+ |
| | | | | |
+-->| VCO | +->|> _| | |
| | | | | R Qo--|--------------|<---+
| '-----' | '--o--' | D2 |
| | | | | |
| V A +-----+ |
| .----------------. | |
| |4Fx Fx | --- C2 |
| | | --- |
| | PIC18F252 | | |
| '----------------' === |
| GND |
+---------------------------------------------------+
Hallo!
Ich habe mich momentan entschieden für sehr einfachen µC Tester, der ziemlich schnell fertig seien könnte. Danach kann ich ihn, durch praktisches Anwenden testen und eventuell noch verbessern (komplizieren).
Die übliche Taktfrequenzen für PICs und AVRs liegen im Bereich 4 bis 20 MHz und ich sehe es nicht ein, zumindest bei der erster Version, wegen Verdoppelung der max. Frequenz, die Hardware stark zu komplizieren. Die PLL Schaltung ist eben nur für PICs wegen innerer Taktteilung /4 nötig.
Ich finde es auch nicht sehr schlimm, wenn man bei einer Entwicklung einer µC basierter Schaltung mit halbierter Frequenz arbeitet (nur bei PIC18FXXX).
Im Code habe ich vereinfachter Schaltplan skizziert, die ich jetzt realisieren werde. Am Ende werde ich selbstverständlich detailierte Skizze der Hardware und Software (Quellcode für PIC18F252) posten.
Ich hoffe, dass einer von den AVR Benutzer entsprechende Software für meine Hardware schreiben könnte. :)
MfG
vom
getestetem µC
.--------.
Data >----------------->| |
Takt >-----+-----oAVR >| 164 |
AVR 4...20 MHz | __--o/ '--------'
PIC 1....5 MHz | +-oPIC ||||||||
| | VVVVVVVV
| | .--------------------.
| | | |
| | | PIC18F252 Osc|
| | |Osc /4|
| | '--------------------'
| | | |
| | o .-----. |
| | / | PLL |<-+
+---|-----+--o o--+-<| |
| |AVR PIC| |X-215|<-+
| | | '-----' |
| | | |
| +---------|-----------+
| |
| |
+---------------+
4xTakt
wäre es nicht sinnvoller das ganze als eingangskarte für den PC zu entwickeln, also die digitalen eingänge einlesen und dann über rs232 an ein programm senden... das ist zum anschauen einfach übersichtlicher...
ansosnten auf jedenfall eine gute Idee, denke sowas kann man immer brauchen..
Hallo goara!
Du hast sicher Recht, aber ich möchte mit etwas einfaches anfangen und wenn es sich in der praktischen Anwendung bewerten würde, könnte man das immer noch erweitern. Ich lasse z.B. zwei Pins RX und TX beim PIC frei, damit sich alle, die das brauchen, später noch Software für Übertragung der eingelesenen Daten per Kabel zum PC erweitern könnten.
Weil ich selber es nicht brauche, werde ich mich jetzt damit nicht beschäftigen. Ich möchte zuerst nur einen sehr kleinen (hand-held) und einfachen DSO fürs Analisieren digitalen Signalen in µC Schaltungen haben. :)
MfG
ist der code dann offen?? Hätte nämlich auch interesse an so einem Tester, würde dann auch eine kleine Gui für den PC schreiben
Ich weiß nicht ob du auch PICs programmieren kannst, da der Quellcode, den ich selbstverständlich am Ende hier poste, für den PIC18F252 geschrieben wird. Eventuell bin ich dann bereit für interessierten auch ein paar PICs zu programmieren. :)
Ich habe letztendlich entschieden, dass ich zuerst die Einfachste Version ohne PLL realisieren werde, da die Multiplizierung der Oszillatorfrequenz nur für PICs, die mit internem Oszillator arbeiten, nötig ist.
Weil es selten vorkommt und in schlimmsten Fall man bei Entwicklung meistens noch einen freien Pin für externen Quarzoszillator übrig hat, habe ich es entfernt.
Im Code habe ich jetzt die vereinfachte Version skizziert, die realisiert wird. Sie ist gleich für AVRs und PICs und benötigt ein Takt vom z.B. Quarz des getesteten µCs. Die Taktfrequenz kann damit von DC bis 40 MHz sein. Weil die AVRs mit Takt max. 20 MHz arbeiten, wäre für sie eine Verdopplung (z.B. mit PLL) vielleicht sinnvoll.
MfG
vom
getestetem µC
.--------.
Data >----------------->| |
Takt >---------------+->| 164 |
DC...40 MHz | '--------'
| ||||||||
| VVVVVVVV
| .--------------------.
| | |
| | PIC18F252 |
| |Osc |
| '--------------------'
| A
| |
.---------------. | .--------------.
|Quarzoszillator| +->|Taktdetektor +|
| | |automatischer |
| z.B. 40 MHz |------>|Umschalter |
'---------------' '--------------'
Hi,
ich finde deine Idee sehr cool. Aber ich weiß, dass du viel Ahnung hast und frage mich wieso du das nicht professioneller machst? Wenn man ein Projekt solcher Art von Grunf auf anfängt, bin ich der Meinung dass man es gleich richtig machen sollte. Was ich damit meine? Z.B. ein Controller mit CAN, so dass man das Ding gleichzeitung zur Analyse eines CAN Bus nutzen!
Außerdem würde ich ein TFT zur Anzeige verwenden. Sieh mal:
http://blog.cc-robotics.de/2009/02/21/canlogger-mit-temperaturmessung/
und das war total einfach von der Ansteuerung und Anzeige!
Hallo T.J.
Vielen Dank für deine Meinung, die aber mein Vorhaben sicher nicht ändern kann. Ich baue mir nur das, wass ich für mich nötig und richtig finde.
Ich möchte keinen komplizierten Projekt anfangen, den ich nicht ziemlich schnell beenden kann. Das hat mit Professionalität nichts zu tun, da ich hier im Forum, wie fast alle, nur ein Bastler bin, der macht nur das, was ihm Spaß macht.
Wer wirklich etwas anderes braucht, kann sich das bauen und bei Problemen versuche ich ihn helfen, so weit ich kann. Und wer feststellen würde, dass das was ich gebaut habe, für ihn ausreichend wäre, baut sich das einfach nach.
MfG
Hallo!
Ich habe jetzt schon die ganze Hardware zusammen skizziert, so wie ich das mir vorstelle. Jetzt werde ich Software dafür schreiben. Die Anzahl der nötigen Schieberegister 74HC164 für Data Verzögerung kann ich erst am Ende ermitteln, da die softwareabhängige Zeit zwischen der Triggerflanke und dem Anfang des Einlesens noch unbekannt ist. Um Übersicht zu verbessern, habe ich die pull-ups (10 k) an A0, A1, A2, A3 und Anschluß des Displays nicht skizziert. Der T schutzt vor Überpolung der Versorgungspannung bei verkehrtem Anschliessen an die zu testende Schaltung.
Wenn jemand einen Fehler findet, bitte melden. :)
Ich überlege momentan noch ob man die Umschaltung des Taktes nicht per Hand machen sollte. Es würde ermöglichen, das Messen der Taktfrequenz (Frequenzzähler für digitale Signale) und vereifacht ein bißchen die Hardware. Ihre Meinungen dazu werden mich sehr freuen.
MfG
+------------------------+ VCC
| R2 +
GND --- Cb D ___ |
=== --- µ1 +--|<---|___|--+--+------------+
| | |1N4148 10k | | +-----+ |+
+----+ | .---------. | | | | === Cb
| o-+ +-|Vpp|_| B7|>-|-.----. | /-\ 100µ
Drehenkoder +---o-- +-->|A0 B6|>-|-| | | |
| o o---->|A1 B5|>-|-|Dis-| | ===
M/D +-o/o------>|A2 B4|>-|-|play| | GND
Enter +-o/o------>|A3 B3|>-|-|2x16| |
| |A4 B2|>-|-'----' |
TAKTA >------|---------->|A5 B1|<-|-------o\o-+ Break
+-----------|VSS B0|<-|-----------|-----------> INT0
OSC1 >----+------------>|OSC1 VDD|--+-----------|---------+
| |A6 VSS|----------+---+ |
| +------>|C0 C7|<------+ | | ___ |/
| | +---->|C1 C6|<----+ | === +-|___|-| T
| | | +-->|C2 C5|<--+ | | GND | R3 1k |<
| | | | +>|C3 C4|<+ | | | | |
| | | | | '---------' | | | | | |
| | | | | PIC18F252 | | | | | |
| | | | | | | | | X X
| .---------------------------. / \ / \
+--->| | GND VCC
| 74HC164 |
DATA1 >-------->| | von zu testender
'---------------------------' Schaltung
µC Tester
VCC
+
|
+---+--+----------+
| | | |
Cb --- | .-. .-----.
µ1 --- | | |R1 | Osz.|
| | | |20k |40MHz|
=== | '-' '-----'
GND | | ||C1 |
| +-||-+ | |\
| | || | +---|3>-+-----> OSC1
| | 10n| |o |
| .------. | |
| |74HC Q|---------+--|-----> TAKTA
| | 123 | |
| |_ | |
\ |\ +-oA _ _| |
TAKT X-----|1>--+--|-|B R Qo---------+ |
/ |o | | '--o---' | | zum PIC
| | | | |o |
=== | +----+ +---|4>-+
GND | | |/
+----------------+
\ |\
TRG X-----|2>---------------------------------> INT0
/ |o
| 1,2,3,4 = 74HC125
===
GND
Taktdetektor + automatischer Umschalter
.----------------. .---------------.
Spitze <----->| |- - -->| |---> DATA1
| 74HC164 | | 74HC164 |
+->| | +->| |
| '----------------' | '---------------'
| |
+--------------------- - +----------------------< OSC1
Data Verzögerung
Besserwessi
08.03.2009, 10:50
Die Taktumschaltung würde ich auch eher per Hand machen. Mit dem Monoflop könnte man Probleme im Übergangsbereich bekommen. Beim Umschalten könnten auch Glitches entstehen und den Controller stören.
Der Verpolungsschutz mit dem Bipolaren Transistor ist interessant, geht aber nur bis etwa 5 V gut, viel mehr verträgt die Basis Emitter Strecke nicht in Sperrichtung. Üblicher ist da ein P-MOSFET.
Hallo Besserwessi!
Vielen Dank für Deine Meinung die meiner gleich ist! :)
Der µC Tester (DSO) ist vorgesehen nur für µCs die im HC Bereich von 3 bis 6 V arbeiten, deswegen habe ich höhere Versorgungsspannungen nicht berücksichtigt.
Im Code befindet sich aktuelle Version der Hardware, die sich wegen momentan unbekannter Anzahl der Schieberegister 74HC164 für nötige Verzögerung bzw. Fehler, die ich übersehen kann, ändern könnte. Ich habe der Anschluß des Mausrades, der Tasten und des Displays geändert um innere pull-ups auszunutzen. Sonst habe ich nur 4-stellige Schiebeschalter bei mir gefunden und noch modifizierte Version des Frequenzteilers skizziert. Es ändert sich nur Verdrahtung.
Es wird mit Frequenzteiler entweder der externe Takt vom zu testendem µC oder Quarzoszillator 40 MHz als Taktquelle für den hand-held µC Tester (DSO) angewendet. Falls Probleme mit der Umschaltung des Taktes durch den PIC mit TAKTU fürs Eincannen nur mit 74HC125 auftreten würden, könnten noch 2 SMD Bauteile dazu kommen: 74HC74 und 74HC86 um die Umschaltung durchführen, nur wenn beide Takte gleichen Logikpegel haben.
Durch den Umschalter am TAKT-Anschluß kann er als Eingang oder Ausgang dienen. In der Stellung OUT (Ausgang) kann der µC Tester (DSO) als sehr stabiler Rechteckgenerator mit durch den Teilungsumschalter Augangfrequenz von 40 MHz bis 1 kHz benutzt werden (z.B. fürs Takten des µCs, der untersucht wird).
Wegen noch nicht entgültig abgeschlossener Hardware, habe ich mich für Aufbau der Hardware mit SMD (1206) Bauteilen auf Lochrasterplatine entschieden, mit der Hoffnung, dass das ganze in ein dafür vogesehenes Gehäuse (SP 2090 SW, 129x40x26 mm zu 2,20 € vom Reichelt) mit schon befestigtem 2x24 Zeichen Display am Ende noch passt...
Die neue Ideen werden mich sicher bis zum fertigem µC Tester (DSO) begleiten und ich werde versuchen auch alle eure sinnvolle Vorschläge während des Schreibens der Software anzuwenden, da es länger dauern wird.
Deswegen bedanke ich mich sehr herzlich voraus für alle Meinungen die zur Verbesserung und Optimierung des entstehenden µC Testers (DSO) beitragen werden. :)
MfG
+----------+----------------+ VCC
| | R2 | +
Cb --- | D ___ | |
µ1 --- | +--|<---|___|--+--+----------------------+--+
| +--+ +--+ |1N4148 10k | | |+
| | | | | | .---------. | Cb | ===
+-+ .----. | +-|Vpp|_| B7|? | 100µ| /-\
| |Dis-|-|--<|A0 B6|? | | |
=== |play|-|--<|A1 B5|>-|-> TAKTU | ===
GND |2x16|-|--<|A2 B4|<-|-----------o\o---+Escape | GND
'----'-|--<|A3 B3|<-|-----------o\o---+Enter |
TAKTE >-----|--|--|-->|A4 B2|<-|-----------o | |
| +--|--<|A5 B1|<-|--------+ __--o-+Mausrad|
| +---|VSS B0|<-|-< INT0 +--o | |
OSC1 >--+---|-------->|OSC1 VDD|--+ | |
| +--------<|A6 VSS|----------------+---+ |
| +------>|C0 C7|<------+ | | |
| | +---->|C1 C6|<----+ | | === |
| | | +-->|C2 C5|<--+ | | | GND |
| | | | +>|C3 C4|<+ | | | | ___ |/
| | | | | '---------' | | | | +--|___|--| T
| | | | | PIC18F252 | | | | | R1 1k |<
| | | | | | | | | | |
| .---------------------------. | |
+--->| | \|/ \|/
| 74HC164 | X 3...6V X
DATA1 >----->| | / \ / \
'---------------------------' / - \ / + \
µC Tester Von zu testender
Schaltung
.----------------. .---------------.
Spitze <----->| |- - -->| |---> DATA1
| 74HC164 | | 74HC164 |
+->| | +->| |
| '----------------' | '---------------'
| |
+--------------------- - +----------------------< OSC1
Data Verzögerung
VCC
+
|
+-+-+
| |
.-. .-. .-----.
R1| | | |R2 | Osc.| |\
10k| | | |10k | |-|1>-+--------> TAKT
'-' '-' |40MHz| |o |
INT | | '-----' | |
o-|---+---------------+ |
+-o--__ | |
| o-+-------------------+ |
=== EXT | |
GND |o |
+-|2>-+
OUT | |/
\ o-----< OSC1 | R3
TAKT X---o--__ | |\ ___
/ o------------------+-|3>-|___|----> TAKTE
IN |o
| 470
===
1,2,3,4 = 74HC125 GND
\ |\
TRG X----------------------------|4>----------> INT0
/ |o
|
===
Taktumschalter GND
VCC
+
| 74HC107
+-----------+
| .-----. | .-----. .-------. .-------.
+-|J Q|-+ +-|J Q|-+ | | | |
TAKT >-+-|-|> | +-|-|> | | +-|74HC390|-+-|74HC390|-+
| +-|K R Q| | +-|K R Q| | | | | | | | |
| | '--o--' | | '--o--' | | '-------' | '-------' |
| | | | | | 1| | | | | | | ms|
| +----+ | +----+ o | | +---+ | +---+ o |
| | 0,5 | | | | | x100µs | OSC1
| +-----------o |-+ | | +-------o |---->
| 0,25 | | | | x10µs |
+-----------------------o<-| | | +-----------o |
| | µs |
| +---------------o |
| x100ns |
+-----------------------o<-|
Frequenzteiler (die Werte entsprechen x/ Zeichenfeld bei 40 MHz)
VCC
+
| 74HC107
+-----------+
| .-----. | .-----. .-------. .-------.
TAKT +-|J Q|-+ +-|J Q|-+ | | | |
>---+-|-|> | +-|-|> | | +>|74HC390|>+>|74HC390|>+
| +-|K R Q| | +-|K R Q| | | | | | | | |
| | '--o--' | | '--o--' | | '-------' | '-------' |
| | | | | | | | V A | V A |
| +----+ | +----+ | | | | | | | |
| | | +-------|---+ | | +---+ |
| | | | | | | | |
+-----------|-----------|-|----+ | | | | |
| | /10| | | | | | | /1000|
| | | o | | o-+ | | | o
| | /4| | | | | | /100 |
| | +-o | | o-+ | | +-------o |OSC1
| | /2 | | | | | /10 |-->
| +-------------o | | o-+ | +-----------o |
| /1 | | | | /1 |
+-------------------------o<-| |->o-+ +---------------o<-|
| | |
Frequenzteiler +-+----------+
Der gesamte Teilungsfaktor der Frequenz TAKT ist gleich dem Produkt
der Multiplizierung den Faktoren mitneinender.
.-----------------.
| |
| D i s p l a y |
| |
| |
'-----------------'
VCC | | |Kontrastpin
+ ===| |
ICL7660 bzw. MAX660| GND| |
+--+ +----------+ |
|+ | .-u-. | | |
10µ === | -|1 8|-+ z*|Dz
/-\ +---|2 7|- A |4V7
| +-|3 6|- -VCC ___ | |
+----|-|4 5|-+----|*__|-+/
| '---' | R 510
=== \-/
GND === 10µ
+|
GND
Spannungsversorgung für Display
Hallo!
Ich habe im Code meine Vorstellung des Bildschirmbildes vom Menü skizziert.
Das Bild wird nach dem drücken der "Enter" bzw. "Start" Taste nach der Auswahl durch das Mausrad erscheinen. Die laufende Adresse des linksten Samples wird im Bereich von 0000d bis 2047d - Anzahl der Zeichen des Displays sein (es werden immer 8d * 256d = 2048d Samples eingescannt) und beim Verschieben des Bildes durch Drehen des Mausrads sich ändern.
Mit der "Stop" Taste wird immer zum Menü zurückgekehrt.
Der µC Tester (DSO) wird mit internem Quarzoszillator 40 MHz arbeiten und nur fürs Einscannen wird er eventuell auf den externen Takt per Hand umgeschaltet (vorm drücken der "Start" Taste). Das gewährleistet, dass er dann immer mit dem zu testenden µC perfekt synchronisiert ist. Die niedrigste Scanfrequenz 1 kHz bei Taktfrequenz 40 MHz sollte für den DSO genügend sein, da bei 2028 Samples sie ca. 2s lange Aufnahme ermöglichst.
Ich bin sehr dankbar fürs Anschauen und eure Meinungen. :)
MfG
.-----------------.
TAKT |Takt I Scan Frq| I - intern 40 MHz
| xxxxxkHz| E - extern vom µC
'-----------------'
.-----------------. _
SLOPE |Slope | Scan Frq| |= _| - steigende Flanke
| xxxxxkHz| _ triggert
'-----------------' |= |_ - fallende Flanke
.-----------------.
FREQ |Freq xxxxxxxx| Frequenzzähler +/-1 Hz
| M^ k ^Hz| mit Messzeit 1 s (d)
'-----------------'
.-----------------.
SCAN |xx 1. Kanal | xx - Adresse des linksten
|xx aus RAM | xx Samples (d)
'-----------------'
.-----------------.
COMP |xx zwei gewählte| xx - Adresse des linksten Samples (d)
|xx Kanäle | xx Die Kanäle können beliebig aus RAM,
'-----------------' EEPROM bzw. Flash gewählt werden
.-----------------.
VIEW |xx vier Kanäle | xx - Adresse des linksten
|xx aus RAM | xx Samples (d)
'-----------------'
.-----------------.
SAVEE |SaveE | Ready wird nach der
|Ready | Ausführung angezeigt
'-----------------'
.-----------------.
SAVEF |SaveF | Ready wird nach der
|Ready | Ausführung angezeigt
'-----------------'
.-----------------.
CALLE |xx 1.Kanal | xx - Adresse des linksten
|xx aus EEPROM | xx Samples (d)
'-----------------'
.-----------------.
CALLF |xx vier Kanäle | xx - Adresse des linksten
|xx aus Flash | xx Samples (d)
'-----------------'
Besserwessi
11.03.2009, 18:04
Ich sehe da nicht so viel Sinn das Speichern mit einem µC zu machen. Ich kann mir Vorstelln das man öfter doch mehr als einen Kanal braucht und dann wird der interne Speicher schnell zu klein und langsam.
Es gibt genügend schnelle SRAMs die man auch relativ einfach direkt mit Logic ansteuern kann und so ein wesentlich leistungsfähigeres Gerät hat, mit kaum mehr aufwand. Ich z.B. noch einige RAMS mit 8 KBytes und 10 ns (oder 15 ns ?) rumliegen. Die Adressgenerierung könnte man z.B. mit Schieberegistern oder einem CPLD machen. Die Datenaufnahmen würde dann im wesentlichen ohne den µC laufen.
Hallo Besserwessi!
Vielen Dank für deine Meinung, die meine nicht ändert. Ich habe schon vorher eine Menge (ca. 14 kB in ASM) als Übung für 8-kanalligen Logic Analiser mit gleichem PIC und einem GLCD (64x128) geschrieben und praktisch ausprobiert. Es wurde von mir nicht zu Ende gemacht, weil es mir zu kompliziert war, aber die meisten Unterprogramme kann ich hier verwenden. Wenn ich nicht sicher wäre, dass es mit bisherigen Erfahrungen ziemlich schnell gehen würde, hätte ich damit gar nicht angefangen.
Es könnte natürlich sein, dass noch ein oder zwei ICs dazu kommen, wenn es nicht gut läuft. Die grössten Sorgen macht mir die Taktumschaltung, weil das habe ich noch nicht ausprobiert. Im schlimmstem Fall müsste die Umschaltung bei gleichen Pegel den beiden Taktquellen erfolgen, was zusätzliche Verspätung verursachen wird. Das wird sich aber erst in der Praxis zeigen. Sollte es nötig sein, würde ich versuchen ein aufgetauchtes Problem mit geringstem Hardwareaufwand zu lösen.
Meine Berufskrankheit in Gegenteil zu meisten Entwickler war immer das Vereinfachen und so bleibt es. Deswegen fange ich immer mit einem Gehäuse an, welches ermöglichst, alle mir einfallende Ideen mit Ausbau sehr schnell begründet zu verwerfen. Mein Motto: Egal wie, aber am einfachsten. :)
Als konkretes Beispiel:
Ich wollte ein Display mit möglichst viel Zeichen in einer Zeile haben. Dafür habe ich mir ein paar 2x24 (RCM2030R) zu 1 €/Stk. + Versandkosten bei eBay gekauft. Wenn ich sie bekommen habe, war das Display um ca. 2 mm für vogesehenes Gehäuse zu breit. Dann habe ich solange gefeilt, bis es ins Gehäse gepasst hat. Am Ende musste ich nur 4 weggefeilte Leiterbahnen mit 0,2 mm Lackkupferdraht herstellen und habe mein Ziel erreicht. :)
Ich möchte schon jetzt allen sagen, die am Ende den µC Tester (DSO) gut finden und sich ihn nachbauen wollen würden, dass ich, wegen Zeitersparnis, fast keine Kommentare im Programm schreibe und immer nur mit Programmablaufdiagrammen (PDAs) arbeite.
MfG
Hallo!
Ich bin seit ca. halben Jahr leider krank und meine Gesundheit wird mit der Zeit nur schlimmer werden. Deswegen bin ich nicht mehr sicher ob ob ich die Entwicklung noch zu Ende schaffe. Aus dem Grund werde ich die bisherige Ergebnise posten, mit der Hoffnung, dass sie eventuell von jemandem weiter geführt wird.
Um dieses Forum mit der Software für PICs nicht zu "beschmutzen", werden alle Programmfragmente in dem Forum "PIC Controller" in gleichnahmigem Tread gepostet.
Bis jetzt habe ich die Ausgabe des RAM Inhalts auf dem 2x16 Zeichendisplay beendet. Sie ermöglichst anschauen des RAM Inhalts, der am Ende des "Init" Unterprogramms (UP) vorprogrammierten Rechtecke. Das Drücken auf die "Enter" Taste umschaltet die Geschwindigkeit des Scrollens zwischen 1x und 10x. Bei der Entwicklung benutze ich den Drehencoder von Pollin wo diese Taste im Drehknopf integriert ist.
Im Code befindet sich meine Vorstellung über Bediennung des Gerätes. Ich werde gerne bis zum Ende der Programmierung alle eure sinnvolle Meinungen noch berücksichtigen. :)
MfG
Enter .-----------------. Enter Esc
SLOPE ----> |Slope | Scan Frq| ----> Flanke wählen ----> Hauptmenü (HM)
| xxxxxkHz|
'-----------------'
Enter .-----------------. Enter Esc
FREQ ----> |Freq xxxxxxxx| ----> messen ----> Hauptmenü
| M^ k ^Hz|
'-----------------'
Enter .-----------------.
SCAN ----> |xx 1. Kanal | Enter Esc
|xx aus RAM | ----> einscannen ----> Hauptmenü
'-----------------'
Enter .-----------------.
COMP ----> |xx zwei gewählte| Enter Enter Enter Esc
|xx Kanäle | ----> 1.Kanal ----> 2.Kanal ----> anschauen ----> HM
'-----------------' auswählen auswählen
Enter .-----------------.
VIEW ----> |xx vier Kanäle | Enter Esc
|xx aus RAM | ----> anschauen ----> Hauptmenü
'-----------------'
Enter .-----------------.
SAVEE ----> |SaveE | Enter
|Ready | ----> Hauptmenü
'-----------------'
Enter .-----------------.
SAVEF ----> |SaveF | Enter
|Ready | ----> Hauptmenü
'-----------------'
Enter .-----------------.
CALLE ----> |xx 1.Kanal | Enter Esc
|xx aus EEPROM | ----> anschauen ----> Hauptmenü
'-----------------'
Enter .-----------------.
CALLF ----> |xx vier Kanäle | Enter Esc
|xx aus Flash | ----> anschauen ----> Hauptmenü
'-----------------'
nietzsche
29.04.2009, 20:31
Okay, ich muss zugeben, die Anzeige ist doch ganz brauchbar... Hätte ich nicht gedacht, dass das so übersichtlich ist...
Interessantes Projekt... würde mir eigentlich erstmal vollkommen ausreichen...
Es wird aber leider noch eine Weile dauern, bis die Software fertig ist...
Nach der Feststellung, dass ich es eigenlich selber nicht brauche, habe ich das Thema unterworfen. ;)
MfG
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.