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
:
Bearbeitet durch User
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
Angehängte Dateien:
-
Fehlerursache.jpg
180 KB -
Software.jpg
190 KB
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.
1 | ;********************************************************************* |
2 | ; Sub: Send den Buffer-Inhalt |
3 | ; Parameter: Z zeigt auf erste Bufferposition |
4 | ; Return: - |
5 | ; Scratch-Reg: TEMP_0, Y, Z |
6 | ;********************************************************************* |
7 | |
8 | send_daten: |
9 | tst FLAGS |
10 | brne send_daten_end ; Stop erkannt |
11 | |
12 | lds YL,BUF_LEN_L ; alle Daten senden |
13 | lds YH,BUF_LEN_H |
14 | cpi YH,high(0x8000) ; 32k? |
15 | brne send_daten_loop_1 |
16 | |
17 | lsr YH ; untere 16k senden |
18 | ror YL |
19 | |
20 | send_daten_loop_1: |
21 | in TEMP_0,DATEN_1_IN ; Byte holen |
22 | and TEMP_0,DATEN_1_M |
23 | in TEMP_1,DATEN_2_IN |
24 | and TEMP_1,DATEN_2_M |
25 | or TEMP_0,TEMP_1 |
26 | |
27 | rcall uart_send_byte |
28 | sbi CLOCK_PORT,C_CLOCK ; Adresse weiterschalten |
29 | cbi CLOCK_PORT,C_CLOCK |
30 | sbiw Y,1 |
31 | brne send_daten_loop_1 |
32 | |
33 | lds YL,BUF_LEN_L ; alle Daten senden |
34 | lds YH,BUF_LEN_H |
35 | cpi YH,high(0x8000) ; 32k? |
36 | brne send_daten_end ; nein |
37 | |
38 | rcall uart_receive_byte ; auf Zeichen warten |
39 | |
40 | lsr YH ; obere 16k senden |
41 | ror YL |
42 | |
43 | send_daten_loop_2: |
44 | in TEMP_0,DATEN_1_IN ; Byte holen |
45 | and TEMP_0,DATEN_1_M |
46 | in TEMP_1,DATEN_2_IN |
47 | and TEMP_1,DATEN_2_M |
48 | or TEMP_0,TEMP_1 |
49 | |
50 | rcall uart_send_byte |
51 | sbi CLOCK_PORT,C_CLOCK ; Adresse weiterschalten |
52 | cbi CLOCK_PORT,C_CLOCK |
53 | sbiw Y,1 |
54 | brne send_daten_loop_2 |
55 | |
56 | send_daten_end: |
57 | clr FLAGS |
58 | |
59 | ret |
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
:
Bearbeitet durch User
Angehängte Dateien:
-
Fertiggeraet.jpg
430 KB
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?
Wer lesen kann ist klar im Vorteil... hab gerade gesehen, das Du das gepostet hast. Verwendest Du jetzt die 80MHz Version?
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
:
Bearbeitet durch User
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!
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.