|
Datum:
|
Angehängte Dateien:
-
pic.png
22,3 KB, 1842 Downloads
Möchte hier meinen Logikanalyzer für das 25€ Pollin CPLD Board mal bereitstellen. Ich weiß das es sowas schon mehrfach gab, aber vielleicht interessiert es ja doch den einen oder anderen...sind recht viele Funktionen eingebaut. Eckdaten : - 8 Kanäle - Samplerate von 16mhz bis 250Khz in 63 Schritten einstellbar per Software - Sampletiefe von 128k, entspricht 8 bis 500 ms je nach Samplerate - Triggern auf Flankenänderung, für jeden Kanal abschaltbar per Software - Pretrigger Buffer von 0 bis 87.5% in 8 Stufen per Software einstellbar - Übertragungsdauer für kompletten Speicherinhalt : ~10 Sekunden per rs232 mit 115200 baud - stufenlose Teilübertragung des Speicherinhalts möglich - 8 Output Pins mit Zähler(8mhz bis 62khz) als Vergleichswert oder Pattern nutzbar Hardware : - Pollin CPLD Board ohne Veränderungen - Schaltung entworfen in VHDL - läuft mit gelieferten 16 MHZ Oszi komplett mit Low Power Macrozellen - Software legt nahezu der ganze Chip lahm solange er nicht benötigt wird -> insgesamt sehr niedriger Verbrauch. Betrieb per 9V Zelle recht lange möglich - 1.5V, 1.8V, 2.5V und 3.3V von einem FPGA Board wurden im Test alle einwandfrei erkannt - 5V zu erkennen laut Datasheet kein Problem, hab jedoch keine Testmöglichkeit - mit high performance Macrozellen bis 36Mhz möglich (weiß allerdings nicht ob der Sram das packt, Datasheet nicht auffindbar) - Sources und Bitfile im Rar Archive. Achtung beim selbst erstellen : ISE11.1 + optimize Speed + exhaustive Fit nötig für 16mhz@low power. ISE6 schafft es nicht. Software : - in c# geschrieben, nur für windows - Steuert den CPLD per Seriell Port - rudimentäre Auswertung als Waves - Timelines direkt an Flankenänderungen mit exakter Zeitangabe - man verzeihe mir den codingstil, sollte schnell gehen - sources+executable im .rar Archive ToDo : - rs232->usb Adapter und 1Mbaud testen - mit schnellerem Quarz ausstatten und Sram testen War ein nettes Projekt und ist zumindest halbwegs brauchbar einzusetzen. Durch die 16 MHz natürlich nicht universel genug, aber was will man bei 25€ auch erwarten.
|
Datum:
|
Update : LA läuft im highspeed modus mit 40mhz. Damit sind zwar die Komponenten tw deutlich außerhalb der Spezifikation(Speicher mit 25ns statt 55ns), aber es funktioniert bisher ohne irgentwelche Fehler, nichtmal einzelne Bits sind fehlerhaft. Beim cpld wundert mich das jedoch wenig, ein Ringoszi offenbart eine Gatter-Durchlaufzeit von unter 6ns statt 10ns wie er laut Speedgrade haben müsste. Warscheinlich lassen sich langsamere gar nicht mehr herstellen ;) Leider habe ich oberhalb der 40mhz keinen Oszi mehr. Hatte einfach nicht damit gerechnet das der Speicher überhaupt soviel mit macht, deswegen ist hier vorerst Ende. zum Rs232 -> usb Adapter : Habe einen mit ftdi 232R Chip genommen und der läuft bis 1Mbaud. Bei der VCP Lösung ist jedoch die Auslastung so extrem hoch, dass Samples verloren gehen sobald irgentwas im Hintergrund läuft. Bin deshalb auf 230400 runter, das funktioniert problemloser.
|
Datum:
|
Leider hab ich es mit ISE 11.1 nicht hinbekommen die Hardware für den CPLD zu fitten. Begonnen haben die Probleme bereits beim Öffnen der Projektdatei. ISE wollte diese konvertieren und bricht mit folgendem Fehler ab: ERROR: migrating C:/Users/TeslaZwerg/Downloads/logicanalyzer/hardware/la.ise failed, could not generate original project information. Nachdem ich dann ein neues Projekt angelegt hab und die Sourcen - la.vhd - uart_transmit.vhd, - analyzer.vhd - mem_control.vhd - arbiter.vhd - 9500.ucf hinzugefügt hab gibt es beim Fitten mehrere Stunden lang immer die beiden Fehler: ERROR:Cpld:837 - Insufficient number of macrocells. The design needs at least 662 but only 144 left after allocating other resources. ERROR:Cpld:868 - Cannot fit the design into any of the specified devices with the selected implementation options. Natürlich mit unterschiedlichen Zahlen, da Exhaustive Fit an ist. Beim Fitten hab ich die Standardeinstellungen verwendet, bis auf: - Implementation Template: Optimize Speed - Macrocell Power Setting: Low - Exhaustive Fit Mode: Haken gesetzt vielleicht hat ja jemand einen Tip für mich, was ich falsch gemacht aben könnte.
|
Autor:
Läubi ..
(laeubi)
Datum:
|
Mal die Fehlermeldung gelesen? Da steht das zuwenig Platz ist und du optimierst auf SPeed... änder das mal in AREA um. Ebenso solltes du die Zellen im High Performance anstelle von Low Poswer btreiben.
|
Datum:
|
Danke für die Antwort. Klar hab ich die Meldung gelesen, allerdings steht im ersten Beitrag explizit: "Achtung beim selbst erstellen : ISE11.1 + optimize Speed + exhaustive Fit nötig für 16mhz@low power." aus diesem Grund hab ich bei mir die Einstellungen entsprechend gewählt. Aber ich werde es heute Abend nochmals mit den anderen Einstellungen versuchen.
|
Autor:
Läubi ..
(laeubi)
Datum:
|
Okay, hm... dann ist am Design aber irgenwas faul, oder du must dem Fitter halt alle Möglichkeiten durchprobieren lassen (der TE hätte ja auch mal schreiben können bei welchen Einstellungen der Fitter es hinbekommt)
|
Datum:
|
Mit den oben genannten Einstellungen benötigt ISE 11 bei mir keine 2 Minuten, deswegen hielt ich es nicht für nötig die input limits usw anzugeben. aber wenns hilft : Collapsing Input Limit (2-54) : 30 Collapsing Pterm Limit (1-90) : 27 die Synthese steht übrigens auf Area und nur der Fitter auf speed zusammen mit dem gewünschten timing contraint. Synthese Effort auf high sollte klar sein. Bei so einem knackvollen Design muss man halt ein wenig probiern. Die Pin Belegung von Pollin war dabei sicher keine große Hilfe, viele Funktion Blöcke sind einfach völlig überlaufen. So haben grundsätzlich die FB noch Produktterme frei, welche durch die Pinbelegung keine mehr aufnehmen können. Deswegen bringt auch der Fitter auf Area rein garnichts. Für den Fall das es gar nicht klappt habe ich aber extra das fertig erstellte File mit beigelegt. Bei mir läuft der LA im highspeedmodus jetzt mittlerweile bei 50mhz und das ohne Probleme. Bei dem Takt ist zwar an eine Versorgung per Batterie nicht mehr zu denken, dafür kann man wirklich etwas damit anfangen.
|
Datum:
|
Kann mir Jemand ein Archiv des Projekts für WebPack 11.1 zuschicken? Obwohl ich alle Projektdateien importiert habe, treten Fehler wie z.B.: ERROR:ConstraintSystem:59 - Constraint <NET "button<3>" LOC = "P49" ;> [_pace.ucf(9)]: NET "button<3>" not found. Please verify that: 1. The specified design element actually exists in the original design. 2. The specified object is spelled correctly in the constraint source file. auf.
|
Datum:
|
Ich habe Probleme mit der Windos-Software. die *.exe installiert nicht. Bekommt man das ganze irgendwie unter gtkwave zum laufen oder gibt es ein ähnliches Projekt unter Linux für den Xillinx XC95144XL ?
|
Datum:
|
Die exe muss auch nicht installieren, die muss nur gestartet werden. Falls es nicht läuft kann das eigentlich nur an fehlemdem Framework liegen(dotnetfx) oder eventuell an uralter windows version.... xp oder vista wäre schon schön, weiter zurück teste ich sowas nicht. Das der button3 fehlt ist klar : der wird nicht verwendet. Du musst einfach nur in den Fitter-Optionen "allow unmatched constrains" einschalten und schon läuft das auch. Ich hab halt die Pins nicht aus dem ucf entfernt. Sorry, aber eventuell auch mal etwas mitdenken, die Lösung findet man ziemlich schnell wenn man bei google nach error 59 für ise sucht...
|
Datum:
|
Ahh - die NET framework hat gefehlt. Ich dachte eigentlich die .NETFW 3.0 wäre installiert, jetzt die 2.0 installiert und es läuft :-). Kommt davon, wenn man Windos nur noch in der Virtualbox laufen läßt. Vielen Dank, der Logictester scheint zu funktionieren. Werde jetzt mal testen. Viele Grüße, Armin
|
Datum:
|
ich hab das mit dem Fitten nach einigem herumprobieren hinbekommen. Einstellungen müsst ich nachschaun, aber soweit ich mich erinnern kann kommt es ziemlich auf die gleichen raus. Leider kenn ich mich mit dieser Art der Hardwareentwicklung (noch) nicht so gut aus, sonst hätt ich das ganze wohl schneller geschafft. Bei mir läuft das ganze mit 40 MHz bisher fehlerfrei. Allerdings hab ich die Windowssoftware neu geschrieben, da mit dir CPU Last viel zu hoch war, und das Zeichnen zu unkomfortabel. Hab auch schon einen Analyzer für eine RS232 Übertragung mit 8N1 implementiert. Falls interesse besteht kann ich das gane gerne hochladen. Allerdings ist dotnet 3.5 SP1 Vorraussetzung und ich verwende zum Zeichnen MSCharts. Das ist eine Komponente, die von MS zur Verfügung gestellt wird, aber standardmäßig nicht bei VS2008 dabei ist. Gruß und schöne Weihnachten, Michael
|
Datum:
|
Jop, das die Software eher schnell zusammengeschustert ist habe ich ja schon erwähnt ;) Hätte auch Interesse an der neuen Software. Für die übertragung verwende ich mittlerweile allerdings eh 1Mbaud samt ftdi-treiber (usb -> rs232 adapter dazwischen) Damit überträgt man den ganzen Speicher in einer statt zehn Sekunden. Hat zudem den Vorteil das weniger CPU-Leistung abverlangt wird, allerdings ist bei meinem Programm wohl eher das zeichnen der Ressourcenfresser. Und natürlich spart man ein paar FF für den Zähler im CPLD. Kann ich nur jedem raten, die 5-10€ ist so ein Kabel auf alle Fälle wert.
|
Autor:
Manuel Stahl
(thymythos)
Datum:
|
Cooles Projekt, welche Probes verwendet ihr dafür, die die 16MHz mitmachen?
|
Datum:
|
Ich verwende Servokabeln (3 benachbarte Leitungen) und hatte damit bisher keine besonderen Probleme. Selbst 25 und 12,5mhz(erzeugt von einem FPGA) auf benachbarten Pins/Kabeln haben kaum Probleme verursacht und werden mit 50mhz Abtastfrequenz gut aufgenommen: 1-2 Fehler über den gesamten Speicherinhalt, wobei ich nicht sicher sagen kann ob die nicht auch dadurch versucht werden das der Speicher eigentlich nichtmal 20mhz mitmacht, hier aber 50 mhz leisten muss ;) Zugegeben, bei 25mhz auf einer Leitung sollte man die Benachbarte nicht unbedingt zum triggern nehmen, aber ansonsten kann ich mich nicht beschweren. Wer bedenken hat kann die Pins weiter auseinander legen, sind ja genug frei. Hatte ursprünglich auch mal überlegt das ganze auf ein kleines FPGA Board zu packen, aber die Abtastrate und Sampletiefe reicht mir eigentlich völlig aus.
|
Datum:
|
Also hier der aktuelle Stand meiner Software. Die ist auch mehr oder weniger nur zusammengeschustert und hat noch so ihre Problemzonen. Das benötigte MSCharts müsste man unter folgendem Link bekommen. Für den Rest einfach ein bisschen suchen. http://www.microsoft.com/downloads/details.aspx?di... insgesammt hab ich zu dem Chart folgendes installiert: - dotnet 3.5 SP1 - MSChart - MSChart VisualStudioAddOn - MSChart Languagepack deutsch und es gibt dazu eine Projekt mit sehr vielen Beispielen und nun noch ein paar Infos zur Software selbst: - beim Start wird nach verfügbaren COM-Ports gesucht, also Dongles etc. vorher anschließen - Baudrate ist momentan fest bei 288000. Entspricht dem unveränderten HW-Projekt bei 40 MHz Quarzoszi - Beim Ändern von Presaplebuffer und Frequenz wird automatisch mit dem ausgewählten COM-Port eine Verbindung aufgebaut. Also vorher richtigen COM auswählen - Beim Ändern des Triggers wird (noch) keine Verbindung aufgebaut - Kommunikation zur Hardware etwas fehlerhaft. Es kommt öfter vor, dass die neue Samplefrequenz nicht übernommen wird (liegt wohl an meinen mangelnden VHDL Kenntnissen) - Bei Klick auf Aquire werden die Daten geholt (dauert). Unten läuft eine Progressbar durch. Während dem Vorgang am besten nirgends klicken (Fehler werden noch nicht abgefangen) - Wenn die Daten da sind mit einem Klick auf Show Data zeichen lassen (war faul und wollte das Zeichnen aus dem "Daten-Holen-Thread" vermeiden) - jetzt kann Dank des Charts beliebig gezoomt werden. Dazu einfach mit der Maus einen "Rahmen" um die gewünschte Stelle ziehen. Rauszoomen geht mit einem klick auf dem kleinen Symbol links von der X-Achsen Scrolleiste - Um den RS232 Analyzer zu verwenden (es wird nur der aktuell sichtbare Bereich analysiert) einfach die Baudrate und den Kanal auswählen und auf Analyze klicken. Wenn die Hardware die richtige Samplefrequenz bekommen hat, und an der Chombobox zur Frequenzeinstellung nichts verändert wurde müsste die Analyse funktionieren. Der Hauptvorteil meiner Software ist wohl die geringe CPU-Last und das einfachere Handling durch das Chart. Da hat Microsoft meiner Meinung nach sehr gute Arbeit geleistet. Das Teil macht sogut wie alles von selbst. Die geringere CPU Last wird allerdings nur dadurch erreicht, dass ich beim Zeichnen alle unnötigen Datenpunkte wegschmeiß. Wenn man ein Signal mit sehr vielen Pegeländerungen auf allen 8 Kanälen analysiert wird meien Software genauso langsam. Man muss dabei bedenken, dass im schlimmsten Fall 128*1024*8 = 1.048.576 Datenpunkte gezeichnet werden müssen! Es gibt also auch meiner Software noch viel zu schustern. Dennoch viel Spaß damit.
|
Datum:
|
Angehängte Dateien:
-
la.png
44,8 KB, 1310 Downloads
Hier noch ein Screenshot. @ Iulius Wäre nett, wenn du deine aktuellen Hardwaresourcen hier posten würdest. Vorallem an der Übertragungsrate mit 1 MBaud bei 50 MHz wär ich interessiert. Mein Dongle müsste das laut Datenblatt eigentlich mitmachen
|
Datum:
|
Kann ich machen, aber leider erst im neuen Jahr da ich weder LA noch den Rechner mit der Software mitgenommen habe in die Feiertage :) Ist aber auch nicht viel Aufwand. Den zähler(bzw die 3 Positionen an denen der Zähler geprüft wird) auf 50mhz/9xxxxx baud einstellen und durchlaufen lassen. Timing schafft zwar angeblich nur 35mhz, aber juckt nicht weiter, wie gesagt ist zumindest mein CPLD durchschnittlich fast doppelt so schnell wie er nach speedgrade sein sollte. Zu deiner Software : Etwas stört mich schon beim lesen, hoffe das lässt sich auch anders machen : >> Bei Klick auf Aquire werden die Daten geholt (dauert)... Wenn die Daten >> da sind mit einem Klick auf Show Data zeichen lassen Bsp : ein zyklisches Ereignis das ein paar mal pro Sekunde auftaucht. Dadurch das ich bei meiner Software sofort sehe was ich aufzeichne kann ich auch gleich neustarten(die Hardware unterstützt das extra) bzw im dauerhaften aquiremodus solange laufen lassen bis ich das Ereignis eingefangen habe und dann stop drücken. Das ist bei deiner Methode derzeit scheinbar nicht möglich. Ansonsten sieht das gut aus, insbesondere wenn die cpu Last deutlich niedriger liegt. Die Ansteuerung des CPLD zum Ändern der verschiedenen Modi kann ich gerne mal zusammenfassen falls es noch nicht 100%ig klar ist.
|
Datum:
|
Ich hab bei den Chart-Beispielen schon was entdeckt von wegen threadübergreifendem Zugriff, also müsste das ganze auch so umzuprogrammieren sein, dass es wie bei deiner Software abläuft. Ist nur etwas mehr Aufwand und man müsste die Logik die das wegwerfen der überflüssigen Samples übernimmt etwas umschreiben. Vielleicht schaff ich das noch einzubauen, bis ich in meine Feiertage gehe :) Jetzt weiß ich auch, für was du den dauerhaften Aquiremodus eingebaut hast ;) Was ich allerdings noch nicht ganz verstehe: Die Datenübertragung ist eigentlich langsamer als die Samplefrequenz. Wie funktioniert das ganze dann genau mit dem dauerhaften Daten holen?
|
Datum:
|
Das klingt doch vielversprechend :) Dauerhaft bedeutet eigentlich nur das nach der kompletten Übertragung sofort eine neue gestartet wird. Natürlich ist es auch bei 1Mbaud nicht schnell genug um 100% zu sampeln aber zumindest muss man nicht ständig neu starten. Bei erneutem drücken von "aquire once" wird hingegen sofort der CPLD gestoppt und wartet auf den nächsten Trigger. (kann aber vorkommen das z.b. noch Zeug aus dem ftdi Puffer nachläuft) Leider reicht die Logik im 144er CPLD nicht aus um einen timestamp-modus reinzupacken...zumindest ist es mir nicht gelungen, somit wird man bei 50mhz abtastrate selbst bei 1Mbaud zu ~99,7% der Zeit blind sein. Ein programmierbarer Triggermodus (mit Abfolgen) ist genauso utopisch... Das Einzige was ich mir noch vorstellen kann : in der Software einen besseren Triggermodus, der, wenn vom CPLD nicht das erwünschte Ergebnis kommt, sofort einen "Reset" des CPLD einleitet. Aber dazu fehlt mir die Muße, bin den letzten Monat auch so ausgekommen.
|
Datum:
|
Das Anzeigen der Daten während dem Einlesen funktioniert nun einigermaßen. Allerdings wird nur gezeichnet, wenn eine Pegeländerung auftritt. Alles andere ist wohl zu langsam Da ich gestern versehentlich mein Pollin Board gebraten habe, muss ich mit dem Programmieren warten, bis mein neues da ist.
|
Datum:
|
Warum machst das Zeichnen nicht auch mit einem timer ? Bei jeder Pegeländerung klingt ziemlich aufwendig... ich lasse z.b. immer 25mhz als Vergleichwert per Jumper auf dem ersten Pin laufen, d.h. eine Änderung in jedem Takt :) Werde das ganze aber auf jeden Fall mal testen sobald ich wieder die Möglichkeit dazu habe. Was ist denn mit deinem Board passiert ? Ich hielt es bis jetzt immer für ziemlich stabil wenn ich mal überlege mit was ich da schon alles ran bin.
|
Datum:
|
meinst du die eingelesenen Daten Puffern und dann nur beim Timeraufruf zeichnen, was neu hinzugekommen ist? Lustig wirds natürlich wenn viele Pegeländerungen auftreten, dann wird das ganze schon langsam. Müsst ich bei Gelegenheit mal mit denem Ansatz testen. Was genau mit meinem Board passiert ist weiß ich nicht. Ich habe den VHDL-Code soweit umgeschrieben, dass ich bei 50 MHz 1 MBaud Übertragungsrate habe und das ganze in den CPLD gepresst, wobei ich allerdings Synthese und den Fitter auf Area stellen musste. Mit Speed bekomm ichs irgendwie nicht hin. Jedenfalls hab ich dann noch ein einziges mal Daten vom Board bekommen und dann nichts mehr. Die beiden Regler werden richtig heiß, und die Ausgangsspannungen sind auch viel zu klein, was auf einen zu hohen Stromfluss schließen lässt. Später ist mir noch aufgefallen, dass ich auf meinem Tisch Entlötlitze rumfliegen hatte. Ich vermute, dass die einen kurzen Verursacht hat, wodurch irgend ein Bauteil zerstört wurde. Naja, es nächste mal bin ich schlauer und kleb die Platinenunterseite gleich ab. Hab bisher nur Kuststoffbolzen als Füße verwendet. Die waren dann wohl doch nicht hoch genug
|
Datum:
|
> Später ist mir noch aufgefallen, dass ich auf meinem Tisch Entlötlitze > rumfliegen hatte. <Nelson> HA HA </Nelson>
|
Datum:
|
>> meinst du die eingelesenen Daten Puffern und dann nur beim Timeraufruf >> zeichnen, was neu hinzugekommen ist? So hab ichs gemacht, allerdings immer ALLES und nicht nur das Neue ;) Allerdings weiß ich nicht was mit diesen Charts möglich ist. Schade um das Board...hab meins extra in ein kleines Gehäuse verbaut und nur die Kabel nach draußen verlegt. Auf Dauer staubt mir das sonst einfach zu sehr ein wenn es ständig offen liegt. Werde aber demnächst auch mal auf die Wärme achten...kann nur sagen das es bis jetzt mehrere Stunden Dauerbetrieb durchgehalten hat. Sind ja auch nur um die 200mA was das Teil zieht, hätte gar nicht gedacht das die Regler da richtig heiß werden können.
|
Datum:
|
ja, ich hab hier auch schon eine Plastikdose rumfliegen, in die das ganze rein sollte. Die Regler werden ja auch nur richtig heiß, seit die Platine defekt ist. Ich bin mir auch fast sicher, dass es der CPLD ist, weil der nach ca. 1 min auch schon spürbar warm wird. Bei dem Chart muss man lediglich die Datenpunkte hinzufügen. Das zeichnen wird von der Komponente selbst übernommen. Im Prinzip läuft das ähnlich ab wie mit einem Excel Diagramm. Man gibt die Daten und die Art des Diagramms vor und der Rest erledigt sich von alleine. Ich werde wohl demnächst mal einen "Demomodus" implementieren, sodass ich auch ohne Board an der Software weiter arbeiten kann
|
Datum:
|
Was ich noch fragen wollte: würde es Sinn machen dem Board einen µC als Unterstützung zur Verfügung zu Stellen, der zum Beispiel die serielle Kommunikation übernimmt, um den CPLD zu entlasten. Wäre dann eventuell Spielraum für mehr Funktionen? Ich denke da konkret an eine Verdopplung der Kanäle bei halbierter Samplerate. Also man sollte auswählen können, ob man 8 Kanäle bei voller Samplerate, oder 16 bei halber Samplerate/Anzahl Samples möchte.
|
Datum:
|
So einen Modus kannst du auch so problemlos einbauen : Ich hab im Moment 8 niedrig belastetete Makrozellen für den debugcounter eingesetzt um ein paar Frequenzen als Vergleichswert immer parat zu haben (einfach per Jumper rüberbrücken) Für einen 16 Kanalmodus brauchst du lediglich 8 Makrozellen für die Muxe und eine fürs toggeln -> passt problemlos. Einziges Manko : das lässt sich dann nicht umschalten. Dafür brauchts geschätzt nochmal 3-5 Makrozellen. Zum rs232-> µC um zu sparen...naja ich sags mal so : wenn du eine Möglichkeit findest die beidseitige Kommunikation im Bereich 1 Mbit mit unter 15 Makrozellen schafft(inklusive dem Sende- und Empfangspuffer !) dann kann sich das lohnen. Allerdings fällt mir da konkret nichts ein. Wenn du wirklich was besseres als 8 Kanal 50 Mhz willst dann am besten gleich ein FPGA Board mit SDRAM. bsp : das DE0 als academic kostet 80$. Damit schafft man recht einfach 32 Känale mit 150-200mhz und dank timestamp modus und 8 MB Speicher eine irre Sampleanzahl die mit ~3MBit per USB auch noch fix zurück geht. Aber da ist eben die Frage ob sich das lohnt. Schöner ist diese Lösung aber in jedem Fall und hätte ich so ein Board übrig würde ich das gerne mal umsetzen.
|
Datum:
|
Hallo Mich interessieren die aktuellen Daten von den Hardwareressurcen mit dem 1MBaut und 50MHz auch, könntest du sie noch Onlinestellen? Welchen Ozilator hast du benutzt für den Takt?
|
Datum:
|
Ich würde, allerdings habe ich derzeit absolut keinen Zugriff auf den Rechner wo das Projekt erstellt wurde. Geändert werden muss aber nur das uart transmit. Wenn ich mich nicht völlig verrechnet habe tut es die .vhd im Anhang. Als oszi habe ich einfach einen 50mhz genommen, genau wie der, der schon im sockel drin war. gibts z.b. bei conrad.
Thread beobachten
Seitenaufteilung abschalten