Habe mir jetzt auch mal den MiniLOG vom Michael Ulbrich nachgebaut, auch
wenn der bereits von 2009 war, jedoch noch heute interessant ist.
Siehe alten Eintrag.
Beitrag "8 Kanal 50Ms/s AVR Logic-Analyzer"
Habe mir aber einen 32k x 8 RAM Baustein mit 10nS anstelle des
originalen 4k RAM eingebaut und die Tabellen im Assemblercode auf 32k
angepasst. Hardwaretechnisch läuft es, aber die PC Software versteht
zwar, das es jetzt 32k sind, zeigt bei 32k aber nichts auf dem Display
an. Sieht aus, als würde die Software weiterhin auf Daten warten, obwohl
die 32k Daten zur PC Software aber gesendet werden.
Habe auf 16k gewechselt und da funktioniert dann auch die Anzeige auf
dem PC. Allerdings werden 4 x 4k nur gespiegelt angezeigt. Also die
ersten 4k werden 4 mal auf dem Display hintereinander angezeigt. Auch
wenn ich die Tabellen im Assemblercode ändere, so das definitiv der
Speicher mit 16k beschrieben und ausgelesen wird, es sind immer nur 4
mal die selben ersten 4k die angezeigt werden. Vermute mal das es an der
PC Software MiniLog.exe liegt, die ich leider nicht ändern kann.
Ansonsten wenn ich den Speicherbaustein auf 4k begrenze funktioniert
alles sehr gut und sogar die PC Software läuft recht stabil unter
Win8.1.
An alle die ebenfalls den MiniLog vielleicht mal nachgebaut haben:
Hatte ihr auch Probleme mit der Anzeige von mehr als 4k?
Wenn ja was habt ihr gemacht?
Hat jemand eventuell eine eigene PC Software für die MiniLog Hardware
geschrieben und könnte diese zur Verfügung stellen?
Ich bin zwar MC Programmierer, aber in Sachen PC Software kenne ich mich
nicht aus. :-(
Hallo,
ich denke mal, Du bist der Thomas, der auch eine Meil dazu geschickt
hat.
Ich antworte mal hier, falls es noch jamenden beschäftigt.
Die Ramgröße und das Auslesen durch die Software sind eigentlich
ziemlich gleich angelegt.
Es werden entsprechend der Ram-Größe die Clock-Impulse an den
Adresszähler gelegt. Ich habe bei Dir eher den Verdacht, daß die oberen
Zähler nicht mehr stabil mitzählen. Es würde dann auch schon falsch
gesampelt, ab 4k wären dann schon keine Daten mehr eingelesen und beim
Übertagen die gelichen 4 k immer wieder geschickt.
Es sieht aus, als ob entweder der 4. 'AC161 nicht mehr mitzählt oder die
Adresswechsel für den Ram zu spät kommen im Verhältmis zu /WE.
Ausgelesen wird mit Takt vom AVR, das ist unkritisch vom Zeitverhalten.
Zur Software: wenn man die Kommandostruktur und die Datenübertragung im
AVR anpasst, kann man sicher auch eine der OpenSurce-Lösungen bei der
PC-Software nehmen. Ein Bekannter hatte sich das mal anschauen wollen,
müßte ich nachfragen...
Gruß aus Berlin
Michael
Ja, ich bin der, der die E-Mail gestern gesendet hat. ;-)
Das finde ich ganz großartig, das Sie selber mir eine Antwort geben
können.
War nicht sicher, ob Sie nach so langer Zeit (von 2009) überhaupt noch
erreichbar seien. Aber ich freue mich sehr, das Sie auch nach so langer
Zeit mir antworten können.
Die Problematik mit den Zählern ist sehr interessant und ich werde mal
in dieser Richtung das Ganze noch prüfen.
Also Ihrer Antwort nach, kann ich nun davon ausgehen, das es kein
Problem in der MiniLog.exe geben kann, sondern definitiv das Problem bei
meiner Hardware liegen muß. Dann werde ich mal den Lötkolben
Schwingen...
Und nochmals besten Dank, für die Hilfe auch nach so langer Zeit...
Finde ich großartig!
Gruß Tom
Die Hilfe vom Meister Ulbrich hat geholfen. :-)
habe mir den 4. Zählerbaustein mal genau angesehen und das Problem
entdeckt. Grund für das Problem... die alten Rentneraugen die für den
Miniaturkram halt nicht mehr taugen... ;-)
Es gibt ja immer eine Übertragungsleitung vom RCO (Pin15) des vorherigen
Zählers zum ENT (Pin10) des nachfolgenden Zählers. In meinem Layout
verläuft diese Leitung zwischen den Pin16 und Pin15 unter den Zähler IC
74ACT161 an den Pin10. Bei der Durchführung dieser Leitung zwischen
Pin16 und Pin15 war ein Fitzelchen von Lötzinn zum Pin16 (VB) leider
noch vorhanden, der einen Kurzschluss zu VB verursachte. Somit konnte
der 4. Zähler wie es Michael Ulbrich schon vermutet hatte gar nicht
mitzählen.
Das Stückchen Lötzinn was da noch zwischen hing, konnte ich gerade so
noch mit einer sehr guten Lupe erkennen. War wesentlich dünner als ein
Haar. Zum Glück hatte der vorherige 3.Zähler den Kurzschluss überstanden
und jetzt funktioniert auch alles bestens mit 16k. Angehangen ein Bild
wo die Stelle des Kurzschlusses blau eingezeichnet ist.
Allerdings gibt es noch immer das Problem mit den 32k. Da weigert sich
die PC Software noch immer permanent etwas anzuzeigen und wartet und
wartet und wartet... Habe dafür leider überhaupt keine Idee warum das
bei 32k nicht funzt. Aber egal, die 16k funktionieren nun perfekt und
die sollten mir eigentlich auch reichen. Habe auch mal ein Bild der
Software angehangen woran die Funktion zu erkennen ist.
Nochmals besten Dank an Michael Ulbrich, der uns mit dem MiniLog
Logicanalysator ein ganz Tolles Projekt zur Verfügung gestellt hat und
es auch bestens beschrieben und dokumentiert hat! Ist selten so etwas.
Danke.
Tom schrieb:> Allerdings gibt es noch immer das Problem mit den 32k. Da weigert sich> die PC Software noch immer permanent etwas anzuzeigen und wartet und> wartet und wartet...
Kannst Du irgendwo in der Software als RAM-Größe 32767 angeben (das eine
Byte weniger wäre wohl zu verschmerzen) oder gehen nur "glatte" Werte
wie 4k, 8k, 16k oder 32k?
In der Assembler Firmware für den ATmega kann man sehr komfortable die
Menge an Bytes die gesendet werden müssen/sollen einstellen. Das die
Assembler Firmware auch richtig gut ist und das der Programmierer
Michael Ulbrich auch richtig Ahnung von Assembler Programmierung hat
sieht man sehr gut an der Struktur wie das Programm aufgebaut ist und
vor allem an der Verwendung des "icall" Befehls. Denn hierfür muß man
wirklich fundierte Kenntnisse im Assembler haben.
Ein paar Bytes weniger bzw. mehr habe ich auch schon probiert. Hatte mal
einen weniger und einen mehr, dann auch mal 10 weniger und 10 mehr und
sogar 100 weniger und 100 mehr ausprobiert. Aber leider immer das
gleiche.
Ich habe jetzt noch mal ein bisschen herumprobiert um die 32k doch noch
zum laufen zu bringen und habe folgendes festgestellt.
Wenn ich 32938 Bytes in der Assembler Firmware eingebe, dann wird ab
diesem Wert auch nach der Übertragung etwas angezeigt. Werte unterhalb
32938, also ab 32937 lassen die PC Software nichts anzeigen. Größere
Werte gehen aber auch. Ich kann auch 33000 angeben und nach drücken des
Buttons "START" und der Übertragung der Daten wird dann auch immer etwas
in der PC Software angezeigt.
Jetzt könnte man sagen, na gut dann lassen wir mal die Einstellung halt
auf 32938 und alles ist in Butter. Aber leider nein. Denn dann zeigt die
PC Software nämlich nur einmal an. Beim zweiten Betätigen des Buttons
"START" passiert wieder nichts mehr. Ich nehme an, weil halt noch zu
viele Bytes irgendwie im PC-Speicher liegen bzw. ein Bytezähler oder
Pointer nicht auf den Anfang des PC-Speicherbereiches zeigt.
Also weiter probieren...
Hallo,
schön, daß das eine Problem erstmal gelöst ist.
Ich muß mal schauen, daß ich meinen LA mal an einen Rechner hänge und
teste.
Ein VB6 habe ich leider im Moment nirgends mehr installiert, um in die
alten Sourcen zu schauen.
Es gab bei 32k ein Problem mit dem seriellen Buffer auf PC-Seite,
deshlab sende ich 2x 16k Blöcke. Vielleicht ist da wirklich noch ein
Fehler drin. Ich bin im Moment auch nicht sicher, ob die PC-Software auf
der Webseite wirklich die "allerletzte" Version ist. Liegt alles leider
etwas unorganisiert in Archiven hier rum...
Gruß aus Berlin
Michael
Tom schrieb:> Wenn ich 32938 Bytes
Was hat diese Zahl mit "32k" zu tun?
32k (korrekter: 32 Ki) ist 2^15, und das ist 32768.
Wo kommen die 170 Überschussbytes her?
Hallo,
Rufus Τ. F. schrieb:> Tom schrieb:>> Wenn ich 32938 Bytes>> Was hat diese Zahl mit "32k" zu tun?>> 32k (korrekter: 32 Ki) ist 2^15, und das ist 32768.>> Wo kommen die 170 Überschussbytes her?
ich vermute mal, er hat hier rumexperimentiert:
1
.equ RAM_SIZE = 0x32 ; genutzter Speicher in kB als Packed BCD
2
.equ BUF_LEN_MAX = 32768
macht genaugenommen wenig Sinn, der Wert landen in Y und wird beim
Übertragen der Daten runtergezählt.
Bei 32k werden erst 16k Datenblöcke zum PC geschickt, dann wird auf ein
(beliebiges) Byte vom PC gewartet und die 2. 16k gesendet.
Ich hatte damals Probleme mit der virtuellen FTDI-COM und dem comm von
VB6 wenn der Buffer größer war. Es sah so aus, als ob der Wert aus VB6
immer als signed int beim Treiber ankam. Deshalb dann kurzerhand 2x 16k
geschickt.
Gruß aus Berlin
Michael
Ja, ich hatte gestern mehrere Möglichkeiten mit der Sukzessive
Approximation Methode, oder auf deutsch Schrittweise Annäherung,
ausprobiert und bin so auf den komischen Wert von 32938 gekommen.
Also ich habe mir über Nacht überlegt, woran es vielleicht liegen könnte
wenn die PC Software doch funktioniert. Das es funktioniert, wenn solch
ein komischer Bytewert in die Assembler Firmware eingegeben wird, ist
schon sehr merkwürdig.
Das Einzige was mir aber dazu eingefallen war, ist eventuell die hohe
Baudrate, so das vielleicht ein paar Bytes (die 170) der 32768 verloren
gehen könnten.
Habe deshalb heute Morgen mal die Baudrate auf 19200 heruntergesetzt,
dauert ewig, aber funktioniert auch nicht. Also an verloren gegangenen
Bytes kann es dann auch nicht liegen.
Was aber nun ein neuer Versuchsansatz ist, ist die Information vom
Michael Ulbrich, über das senden von 2 x 16k. Also ich habe von der
Internetseite vom Michael Ulbrich eine Hardware Version 1.1 und eine PC
Softwareversion 1.0. In dem Assemblercode zum Senden der Daten ist aber
definitiv keine Teilung von 2x16k vorhanden. Ich kopiere mal den
Send-Teil hier hinein.
send_daten:
lds YL, BUF_LEN_L ;alle Daten senden,
lds YH, BUF_LEN_H
send_daten_loop_1:
in TEMP_0, DATEN_IN ;Byte holen aus Sample-SRAM
rcall uart_send_byte ;Über die UART an das PC Programm senden
sbi CTRL_PORT, C_CLOCK ;Adresse weiterschalten
nop ;Kurz warten für Taktübernahme
cbi CTRL_PORT, C_CLOCK ;Taktflanke wieder zurück auf LOW
sbiw Y, 1 ;Adresse der lesenden Bytes um 1 verringern
brne send_daten_loop_1 ;Solange Y nicht 0 ist, ein weiteres Byte
senden.
ret ;Zurück zum Aufrufenden Programmteil.
Ich werde nun mal dieses Programmteil so modifizieren, das es 2x 16k mit
einer Wartezeit dazwischen sendet und melde mich dann wieder.
Vorerst vielen vielen Dank für die Hilfe.
Alle können nun glücklich sein!!!! Jetzt funktioniert es auch mit 32k
Byte!!!!
Es lag eindeutig daran, das 2 x 16k gesendet werden müssen und
dazwischen auf ein Empfangsbyte gewartet werden muß. Habe nun erst
einmal auf die schnelle folgenden Code verwendet:
send_daten:
ldi YL, LOW(16384)
ldi YH, HIGH(16384)
send_daten_loop_1: ;Erste 16k Senden
in TEMP_0, DATEN_IN
rcall uart_send_byte
sbi CTRL_PORT, C_CLOCK
nop
cbi CTRL_PORT, C_CLOCK
sbiw Y, 1
brne send_daten_loop_1
;-----------------------
rcall uart_receive_byte ;Warten auf beliebiges empfangene Byte
;-----------------------
ldi YL, LOW(16384)
ldi YH, HIGH(16384)
send_daten_loop_2: ;Zweite 16k Senden
in TEMP_0, DATEN_IN
rcall uart_send_byte
sbi CTRL_PORT, C_CLOCK
nop
cbi CTRL_PORT, C_CLOCK
sbiw Y, 1
brne send_daten_loop_2
ret
Werde jetzt das Sendeprogrammteil so gestalten, das die normale angabe
der Menge an Bytes bestehen bleiben kann und der Sendeprogrammteil
selber erkennt, wann er 1x oder 2x senden muß.
Ganz tolle Sache das es nun doch mit 32k funktioniert!!!!!
Ganz groß0en Dank an Michael Ulbrich das er für mich Zeit gefunden hat,
mich bei dieser Sache zu unterstützen und mir die notwendigen
Informationen hat zukommen lassen. Super Sache!
Hallo,
die Webseite ist nicht soooo sonderlich gepflegt, aber die
Mega88-Version enthält alle Anpassungen, die ich damals noch gemacht
habe, auch 80MHz/32k Ram.
Die Senderoutine aus diesem Archiv sendet 2x 16k.
PS: die 500kBaud sind ohnehin eher virtuell, die Laufzeit der
Sendeschleife dürfte das auch bei 20MHz wohl nicht schaffen. Habe ich
nichtmal nachgerechnet, 250k/500k mit dem FTDI waren aber stabil und der
Teiler im AVR kann die aus den 20MHz ohne Fehler erzeugen. Somit sind
die 500kBaud eben drin geblieben.
Gruß aus Berlin
Michael
Da Michael Ulbrich sogar noch eine Routine zur Erkennung ob 32k oder
weniger bereit gestellt hat, habe ich einfach diese übernommen und in
die Firmware für den ATmega16 eingebaut.
Somit ist jetzt alles fertig und Funktionstüchtig. Ein kleines
Aluminiumgehäuse ist jetzt Drumherum und sieht somit auch optisch gut
aus.
Hier noch ein paar Daten für die, die es interessiert.
Die Kosten für alles beliefen sich auf ca. 60-70 € da die 74ACT Typen
nicht überall zu bekommen waren und bei z.B. Eibtron.com (Adresse für
private Besteller von RS-Components Artikel) auch manchmal gleich 10
Stück genommen werden mussten, obwohl man nur 1 brauchte. Leider konnte
ich bei HBE was einmal die Adresse für private Besteller für die Teile
von Farnell war, nichts mehr bestellen, da es die nicht mehr gibt.
Sonnst wäre es eventuell etwas billiger geworden. Da es leider nicht
alle 74ACT Teile bei Eibtron gab musste ich dann den Rest bei Conrad
bestellen.
Das Gehäuse habe ich von Reichelt (GEH EFG 1A) und habe es auf die
benötigte Länge abgeschnitten.
Der SRAM Baustein CY7C199D-10nS habe ich ebenfalls bei Eibtron für 2,50€
/ Stück gefunden.
Das Layout der Platine wurde mit Target2001 gemacht und die zweilagige
Platine selber geätzt und bestückt.
Wenn Michael Ulbrich nichts dagegen hat, würde ich mal ein ZIP Packet
zusammen stellen, mit allen Hardware und Softwareteilen die man zu einem
Erfolgreichen Gerät benötigt. Muss aber Michael Ulbrich erst anfragen,
denn die Software und der Schaltplan stammen ausschließlich von ihm. Ich
habe lediglich den Schaltplan umgesetzt zu einem Layout für eine
Platine.
Gruß an alle die sich dieses Tolle Gerät auch nachbauen wollen.
Es ist zwar kein Profigerät, aber für Hobbyisten, die nur mit MC
arbeiten die sowieso nur mit maximalen Taktfrequenzen von 20MHz laufen,
vollkommend ausreichend.
Nochmals einen ganz großen Dank an Michael Ulbrich für seine
Unterstützung.
Gruß Tom
Das wäre prima, ich hab nämlich auch Interesse an dem kleinen Projekt.
Da steht noch die Frage nach dem verwendeten RAM Typ im Raum, welchen
hast Du eingesetzt?
Der Speicherchip hat die Bezeichnung CY7C199D-10 und habe den bei
Eibtron.com eingekauft.
Ich habe einen 80MHz Oszillator von Reichelt (OSZI 80.000000) verwendet.
Allerdings laufen die 80 MHz nicht korrekt. Liegt vielleicht an dem
nicht ganz so guten Ausgangssignal des Oszillators. Habe mir mal das
Ausgangssignal des Oszillators im Oszilloskop angesehen und sieht schon
sehr verbogen aus. Habe aber leider keinen anderen Oszillator zum testen
hier. Oder es liegt vielleicht auch am SRAM Baustein der vielleicht doch
etwas anders ist, als den Speicher den Michael Ulbrich 2009 verwendet
hatte.
Alle anderen Samplefrequenzen funktionieren jedenfalls garantiert
hervorragend. Also ab 40MHz.
Aber wenn man z.B. mit einem ATmega arbeitet, dann hat man maximal 20MHz
Taktfrequenz am MC. Ausgaben an den Ports können dann maximal 10MHz
haben. Wenn man nun mit einer Samplefrequenz von 40MHz ein 10MHz Signal
"aufnimmt" so hat man für eine Periode immerhin noch 4 Speicherstellen
zur Verfügung. Und das ist vollkommend ausreichend, um Fehler o.a. auf
Datenleitungen zu erkennen. Wenn man TWI oder SPI Signale "aufnehmen"
also sampeln möchte, dann hat man noch sehr viel mehr Speicherstellen
pro Periode wo man sogar genaue Angaben zu den Zeitverhältnissen machen
kann.
Ein Beispiel:
Wenn man 400kHz TWI hat, was ja für die meisten TWI bzw. I2C Bausteine
das Maximum ist, dann hat ein Takt 2,5uS. Das wären bei 40MHz = 100
Speicherstellen nur für 1 Takt. Eigentlich eine Verschwendung... ;-)
Wenn dann z.B. eine Adresse = 8Bit = 8 Takte + ACK und z.B. einmal Daten
versendet werden, also nochmals 8Bit = 8Takte + ACK, dann benötigt man
für das Senden der beiden Bytes 18 Takte. Bei 40MHz würden dann 1800
Speicherstellen beschrieben werden. Bei 32k können nun also maximal 36
Bytes mit höchster Auflösung sichtbar gemacht werden.
Ich denke das reicht aber vollkommen aus!!!
Und sollten es doch mal mehr als die 36 Bytes inklusive ACK werden, dann
kann man ja auf 20MHZ gehen wo ein Takt noch immer 50 Speicherstellen
beschreibt. Das ist immer noch von der Auflösung hervorragend. Zumindest
für Hobbyisten vollkommend ausreichend!
Sorry habe mich etwas verrechnet.
Bei 32k SRAM Speicher können dann bei 40MHz 18 Bytes sichtbar gemacht
werden und nicht 36! Wo die 36 jetzt herkam weis ich nicht;-)
Michael U. schrieb:> Ein VB6 habe ich leider im Moment nirgends mehr installiert, um in die> alten Sourcen zu schauen.
In die Sourcen kann man problemlos auch ohne VB6 schauen, ein simpler
Texteditor tut's genauso gut, notfalls sogar notepad.exe...
> Es gab bei 32k ein Problem mit dem seriellen Buffer auf PC-Seite,
Vermutlich: Variable(n) vom Typ integer verwendet. Integer sind bei VB6
nur 16 Bits breit. Wenn sie dann auch noch als Index für einen
Arrayzugriff verwendet werden und die "option base" für Arrayzugriffe
auf den VB6-Standard (also schwachsinnige 1) konfiguriert ist, kann man
natürlich nicht mal mehr auf volle 32kiB zugreifen...
Mann, war das 'ne Scheiß-Sprache. Schon zu ihrer Zeit...
c-hater schrieb:> Mann, war das 'ne Scheiß-Sprache. Schon zu ihrer Zeit...
Das mag sein, das Visual Basic nicht das Beste war. Da stimme ich sogar
zu. War vor vielen vielen vielen Jahren mal Programmierer mit Basic
unter DOS. Wenn überhaupt noch jemand "DOS" kennt. :-)
Danach hatte ich alles was den Namen Basic beinhaltete abgelehnt!
Später mal mit Borland Builder 4 in C++ paar Dinge gemacht. Aber das ist
auch schon mindestens 15 Jahre oder sogar noch länger her...
Aber die PC Software von 2009 vom Michael Ulbrich funktioniert halt,
auch wenn Umwege über 2x 16k gegangen wurden. Aber auf das funktionieren
kommt es mir letztendlich an. Wie es intern werkelt, ist mir eigentlich
egal.
Gruß Tom
Hallo,
c-hater schrieb:> Mann, war das 'ne Scheiß-Sprache. Schon zu ihrer Zeit...
:-))) Hat mir trotzdem gute Dienste geleistet...
Hätte ich noch ein lauffähiges VB6 zur Hand, hätte ich das Projekt
aufgemacht, mit einem Editor habe ich einfach keine Lust dazu. ;)
Ich hane damals keinen Hinweis gefunden, daß der comm-Buffer nicht
größer als 16k sein durfte. Über 16k gab es auch keine Fehlermeldung,
ich glaube, er kam nie mit Buffer voll zurück. Ob vom FTDI-Treiber oder
dem mscomm32.ocx habe ich nie ergründet. Es sollte letztlich ja nur
funktionieren...
@Tom: Du kannst das gerne zur Verfügung stellen. Ich habe mal das
VB6-Projekt hier angehängt. Einen Hinweis auf mich oder/und ein Link zum
Forum hier und/oder meiner Homepage wirst Du ja sicher einfügen.
Gruß aus Berlin
Michael
Hallo liebe Logic Analysator Freunde.
Als erstes möchte ich darauf verweisen, das in dem ZIP File auch eine
Datei "Info_Copyright.txt" sich befindet, wo darauf hingewiesen wird,
das Michael Ulbrich das Urheberrecht auf all die Hardware und Software
hat, die mit dem MiniLog Logic Analysator zusammen hängt. Bitte
beachten!
Als zweites möchte ich mich im Namen aller bei Michael Ulbrich bedanken,
für das Bereitstellen seines eigen entwickelten MiniLog.
Als drittes möchte ich gleich darauf hinweisen, was auch in der
Textdatei "Anleitung.txt" nachzulesen ist.
"Die Hardware wird zwar von einem 80MHz Oszillator angetrieben und
stellt die benötigten höheren Samplefrequenzen bereit.
Allerdings ist nicht Garantiert, das die 80MHz als Samplefrequenz
genutzt werden können, da es abhängig davon ist,
welche Qualität der 80MHz Oszillator hat, von welchem Hersteller die
74ACT161 Zähler und 74ACT00 Schaltkreise sind
und vor allem von dem verwendeten RAM-Baustein!
Nur Samplefrequenzen ab 40MHz (in der PC Software 25nS auswählen) sind
garantiert!
Sind aber auch vollkommen ausreichend wenn man Signale eines
Mikrocontrollers sampeln möchte der mit maximal 20MHz getaktet ist!"
In dem ZIP File ist auch eine Anleitung zur Herstellung der Platine und
zum Umgang mit der Assembler Software.
Viel Spaß beim Nachbau wünscht Tom.
Wenn Ihr den MiniLog nachgebaut habt, könnt ihr ja ein Bild mal hier
hineinstellen!
