Beiträge von Michael D

  • 0-20V Steuerspannung

    X- beliebiger Rail to Rail OPamp, der kommt auch auf 0, z.B. der OPA347PA bei reichelt für 0.87€. Gibt auch vier in einem Gehäuse hab bei Reichelt aber keinen rail to rail gesehen beim flotten überfliegen. Versorgung dann mit Festspannungsregler 25V oder so. Ich würd am Eingang noch nen Widerstand (z.B. 22K) nach Masse machen, damit die der nicht rumfloatet wenn nix angeschlossen ist und auch die Steuerleitung ein bischen belastet ist.

  • PIC Programmierung für Einsteiger und andere Interessenten

    Ganz ehrlich?
    So ein Tutorial is sicherlich gut gemeint und war sicherlich auch etwas Arbeit. Der Punkt ist nur es gibt im Netz bereits deutlich bessere Anleitungen für sowas. Wir sind hier in einem PA Forum und nicht in einem Elektronikforum wo solche Artikel sicherlich besser aufgehoben werden. Schau mal auf http://www.mikrocontroller.net/, da gibts im Prinzip alles was man braucht: Tutorials für AVR, ARM und FPGA und gleich noch ein passendes Forum dazu. PICs werden nicht nur von mir als grundsätzlcih den AVRs unterlegen angesehen. Es gibt immer mehr Projekte mit AVRs und immer weniger mit PICs.

  • Matrix mit Par36

    Das nennt man Multiplexbetrieb. Ihr müsst beachten, dass die Zeilen immer nur 1/N der Zeit an sind, d.h. in dieser Zeit brauchen sie N fache Normleistung um am ende eben diese zu erreichen. Das wiederum bedeutet, dass sie die sqrt(N) fache Spannung brauchen. Bei 6V Pinspots mit 9 Zeilen sind dass dann also 18V. Wenn der Controller ausfällt und eine Zeile längere Zeit an ist, sind die Lampen kaputt ;)
    Kann man auch mit LEDs machen, da aber max. so 8 Zeilen, weil die LEDs auch kurzfristig nicht beliebig viel Übertsrom vertragen.

  • FPGA

    Es gibt ne freie Version von Modelsim die einfach bischen langsamer ist. Die 10000 Zeilen Code wirste so schnell sowiso nit erreichen:
    http://www.mikrocontroller.net/articles/ModelSim
    Klar sind die offiziellen Versionen von ModelSim unendlich teuer, schau dir mal an, wer die normalerweise benutzt...

    Trenz Electronic macht auch noch solche Boards, hab da aber noch nie bestellt:
    http://shop.trenz-electronic.de/catalog/product_info.php?products_id=178&osCsid=1661be96272bd8ee88a0aa39cf080538
    Oder halt das Spartan Starterboard von Xilinx.
    http://www.digilentinc.com/

  • DMX Steuersignal in der Mitte des Busses einschleifen

    Entgegen der allgemeinen Meinung hier ist es grundsätzlich kein Problem in der Mitte einzuspeisen, da RS485 wie bereits gesagt ja ein multisender Bus ist. Es müssen nach wie vor beide Enden des Busses terminiert sein und in der Mitte darf nichts terminiert sein.
    Also: Du musst die Enden der DMX Leitung an beiden Seiten terminieren _und_ du musst den Endwiderstand im Sender ausbauen. Dieser übernimmt normalerweise die Terminierung des einen Endes des Busses. Wenn du das gemacht hast, hast du ein vollkommen standardkonformes RS485 Netz.

  • FPGA

    Sorry für den langen Delay, aber is ja auch n komplexes Thema ;)
    Hab das ganze jetzt mal grob überflogen und sehe keinen prinzipiellen Fehler.
    Nächster Schritt wäre jetzt eine Testbench zu erstellen und in Modelsim eine Behaviol Simulation zu machen ob die Kiste auch so tut wie se soll. Danach noch ne kleine Schaltun die Startbyte prüft, Bytes zählt und das ganze in nen Dual Port Memory schreibt. An die andere Seite von dem Mem hängste dann nen Prozessor und fertig is der Empfänger.

  • FPGA

    Erstmal zu deinem code oben:

    1. Wie Arno schon schrieb kommst du aus dem Idle nur bei dmx_in = 0 raus. Ich sehe aber gerade gar nicht, wie du überhaupt wieder in den Idle Zustand kommen willst. Machst du nach nem ganzen Byte einfach nen Reset?

    2. Du benutzt alle 16 Sample zur Auswertung und nicht nur drei in der Mitte, aber ich schätze das ist dir klar.

    3. Du solltest das dmx_in noch synchronisieren, aber das kannst du natürlich auch ausserhalb dieses Blocks machen.

    4. Noch ein Tip wie ich gerne Signale generiere, die nur eine Clock high sein sollen (in deinem Fall z.B. ser_clk): Zu Beginn des Prozesses auf 0 setzten (also hier direkt unter der Clockabfrage und noch vor der Idle abfrage) und dann wenn benötigt an der (den) entsprechenden Stelle(n) auf 1 setzen. Das erspart einem das man das Signal an allen anderen Stellen auf 0 setzten muss.

    Zum Synchronen Design:

    1. Was du hier entdeckt hast ist das Hold Time Problem. In der Tat ist das direkte Verbinden von FFs meist nicht möglich. Jedes (D-)FF hat eine Setup und eine Hold Time.
    Setup gibt die Zeit an, die das Signal am D Eingang stabil anliegen muss bevor die Rising Clock Edge kommt, Hold gibt entsprechend die Zeit an, die das Signal nach der Clock Edge stabil sein muss.
    D.h. man (bzw. die Software wie hier Xilinx) muss bei der Timing Analyse checken, dass a) keine Signalpfade zwischen FFs zu schnell sind (Hold Violation) und b) keine Signalpfade zwischen FFs zu langsam sind (Setupt Violation).
    Die Holdtimes kann man durch Einfügen von Buffern fixen, bei den Setuptimes hilft nur mit der Taktfreq. runter zu gehen, bzw. der schlechteste Setup Pfad gibt dir deine max. Frequenz vor. Wie das jetzt bei FPGAs exakt ist weiss ich nicht, eventuell hat man da durch die LUTs und Leitungen auch so schon genug Delay, dasses für die Holdtime reicht.
    Damit das ganze auch richtig funktioniert muss man dafür sorgen, dass die Clock bei allen FFs möglichst gleichzeitig ankommt. Das erreicht man mit entsprechendem Aufbau des sog. Clocktrees, d.h. z.B. in Baumform oder man muss die Clocksignallaufzeiten eben genau berechnen. Der max. Unterschied der Ankunftszeit der Clock wird Clock Skew genannt.
    Übrigens, wenn Signale verschiedene Clockdomains überqueren (auch dein dmx_in ist so ein Fall, da es von einem Gerät ausserhalb mit eigener Clock generiert wird) ist es unmöglich die Setup und Hold Times der FFs einzuhalten. Wenn das passiert kann der FF in einen metastabilen Zustand gehen, d.h. er gibt irgendwas zwischen 0 und 1 aus.
    Dieser Zustand legt sich schnell wieder, dauert aber deutlich länger als ein normaler Schaltvorgang.
    Deshalb muss man das Signal mit Hilfe von mind. zwei direkt hintereinander geschalteten FFs (was halt mit der Holdtime minimal möglich ist)
    synchronisieren. Man hoft da, dass das Timingbudget bis zur nächsten Clock lange genug ist, dass sich ein eventueller metastabiler Zustand
    des ersten FFs gelegt hat. Ist das nicht so kann sich der metastabile Zustand in der ganzen Schaltung ausbreiten und diese zum Absturz bringen.
    100% sicher kann man sich da nie sein, aber die Fehlerraten liegen bei heutiger Technologie bei vielen vielen Jahren bis zum ersten Fehler.

    2. Wechselnde Clockflanken verwendet man normalerweise nicht (es gibt sicherlich Spezialfälle wo das Sinn macht). Du hättest ein Problem,
    wenn du ein Schaltnetz hast, welches ein Signal aus dem Output von zwei invertiert geclockten FFs generiert.

    3. Es macht absolut keinen Unterschied. Aber nur, weil du Signale verwendest. Hättest du im Bsp. 3 Variablen im Prozess würden dieses direkt übernommen.
    Denk dir das so: Ein (sequenzieller) Prozess hat normalerweise immer ein paar Signale zum Eingang (Variablen sind ausserhalb von Prozessen ja nicht möglich)
    und ein paar als Ausgang (die die er beschreibt). Wenn die Clock kommt friert er die Zustände aller Eingangssignale ein und berechnet die Ausgangssignale mit diesen Eingangssignalen.
    Variablen hingegen sind eine Art der Abstraktion für die Beschreibung innerhalb eines Prozesses. Wenn du von ihnen liesst enthalten sie den im selben "Prozessdurchlauf" zuletzt geschrieben Wert.
    Das lässt sich natürlich hardwaretechnisch nicht direkt abbilden (es geht ja nur um eine Clock), d.h. der Compiler baut daraus etwas, was nur aus "Signalen" besteht. Ich hoffe das kann man irgendwie verstehen.
    In Kurzform:

    b <= a;
    c <= b;
    d <= c;
    e <= d;

    und

    e <= d;
    d <= c;
    c <= b;
    b <= a;

    sind Identisch im Fall von Signalen, aber nicht im Fall von Variablen.

  • FPGA

    Du solltest dir erstmal klar machen, was du nacher im FPGA hast: Eine synchrone digitale Schaltung. Und das ist im Prinzip was ziemlich simples: Du hast D-Flipflops die synchron getatet werden und diese FlipFlops sind über logische Schaltnetze verknüpft (kombinatorische Logik). Ich denke es macht Sinn das beim Designen in VHDL immer ein bischen im Hinterkopf zu halten. Natürlich muss man nicht lauter geclockte Prozesse (FlipFlops) und Verknüpfungen (komb. Logik) hinschreiben aber ich glaube es macht Sinn wenn man eine ungefähre Vorstellung davon hat was nach der Synthese ungefähr rauskommt. Schwierig zu erklären...
    Generell würde ich keine Tristatesignale im FPGA verwenden, die sind im Spartan nur spärlich vorhanden und in den neueren glaub gar nicht mehr. Es gibt auch keinen Grund sie zu verwenden wenn man richtig designt. Bei Bussen mit mehreren Teilnehmern verwendet man eben Multiplexer die mit Hilfe der Adressbits gesteuert werden.
    Am Besten du besorgt dir Modelsim (gibts ne kostenlose Version die nur ein bischen langsamer ist als die Prof.) damit kannst du alles simulieren und schauen ob das was du programmiert hast auch das tut was es soll.
    In VHDL kann man zwar vieles machen aber man braucht eigentlich nicht viel um mehr oder weniger alles zu machen. Es gibt im wesentlichen drei Sachen: direkte komb. Logik, komb Logik in Prozessen (hier vergiss nie dass alle Eingangssignale in die sensitivityliste müssen, clock gibst in diesem prozess nicht), geclockte Prozesse (hier gehört nur die clock in die sensitivity liste und vielleicht noch der Reset wenn er asynchron ist, wobei ich synchronen Reset lieber mag). 'event (oder die xilinx variante rising_edge(clk)) sollte man nur mit der Clock verwenden: (if (clk'event and clk = '1' then...)) alles andere gibt Chaos. Denk immer daran, am Ende muss alles auf FFs und "Gatter" (simuliert duch die LUTs) abgebildet werden. Und die heutigen FPGAs sind numal auf synchrones Design ausgelegt, was soviel heisst wie clock an die Clockeingänge der FFs und sonst nix.
    Zum UART: Wie man das generell macht hab ich glaub ich mal in nem Atmel Datenblatt gelesen: Sample mit 16 facher Baudrate dein Eingangssignal, wenn du ne 1->0 Flanke findest starte nen counter und lies in der Mitte jedes Bits drei hintereinanderfolgende Samples und nimm den Wert der zwei oder dreimal Auftrat (zur Rauschunterdrückung). Wenn du beim samplen des Startbits keine Null hast wars falscher Alarm -> ignorieren. Der Rest geht dann so wie mans kennt, also die 8 Bits samplen und auf Stoppbits prüfen.
    Was noch wichtig ist: Du solltest Signale die von aussen in den FPGA kommen und damit asynchron zur Clock sind erstmal durch zwei FFs ohne komb. Logik schieben. Das macht man um Metastabilität zu vermeiden. Was das ist kannst du dir mal irgendwo im Web anschauen, das führt hier zu weit.
    Wegen den Kurzschlüssen musst du dir keine Sorgen machen, da meckert der Compiler schon und ausserdem siehst du sowas auch in der Modelsim Simulation.
    Wenn du magst kannst du uns ja mal deinen Entwurf für einen UART schicken (oder hier posten), dann können wir vielleicht ein paar Ideen äußern.

  • FPGA

    Zitat


    Michael D hat Folgendes geschrieben:

    Im Prinzip ja, es gibt nen Schematic Editor mit dem du im Prinzip die Opencores dinger zusammenklicken kannst. Allerdings will das keiner, viel zu umständlich und unübersichtlicht, das verdrahten macht man auch in VHDL.

    Da muss ich widersprechen.

    Gut, is vielleicht Ansichtssache, aber ich mag das rumgeklicke da nicht, da schreib ich lieber zweimal nen Signalnamen und das Toplevel bestand bei mir bis jetzt immer nur aus nem Bus oder NOC. Zum Ausgeben eines Blockschaltbildes isses natürlich schon ganz interessant.

    Was Opencores angeht hab ich bis jetzt nur den CAN Core verwendet (uneingeschränkt gut und verhält sich exakt wie der SJA1000) und die USB Cores, die sind aber meiner Meinung nach alle nicht so 100% USB konform. Der 2.0er Core schmiert mir immer ab wenn In und Out Transfers mit grossem Durchsatz gleichzeitig aktiv sind und der USB 1.1 Core macht keine wirkliche Fehlerkorrektur. Die Erfahrungen sind aber schon etwas älter, kann sein, dass sich da inzwischen was getan hat.
    Was meiner Meinung nach in Opensource aber ungeschlagen ist, ist http://www.gaisler.com/ ein kompletter Sparc V8 Prozessor mit Unmengen Peripherie (IDE, VGA-Grafik, Ethernet, PS2, usw) und die bieten sogar nen Linux 2.6 Kernel mit passenden Treibern dafür an.

  • FPGA

    Ahso, das habsch noch vergessen:

    Zitat

    Kann man in dieser Software die funktionien wirklich wie ICs in einem Schaltplan grafisch verbinden? Geschockt (konnte es noch nicht installieren, da ich keine 1.7GB auf meiner System HD mehr frei habe)

    Im Prinzip ja, es gibt nen Schematic Editor mit dem du im Prinzip die Opencores dinger zusammenklicken kannst. Allerdings will das keiner, viel zu umständlich und unübersichtlicht, das verdrahten macht man auch in VHDL. Und auch die Opencores Sachen sind nicht zwangsläufig einwandfrei, diese USB Cores da sind z.B. nit so der Hit, was hab ich damit Stunden verbracht... Dafür is z.B. der CAN Core erste Sahne...

    Besorg dir noch Modelsim und dann spielste halt mal bischen rum.

  • FPGA

    Was habt ihr gegen die Xilinx ISE? Vielleicht kann man damit nicht die abgefahrensten Sachen machen aber für normalen Kram wie nen monster DMX Router (was der OP wohl vor hat) reicht das doch 10x... Ich glaub jedenfalls nicht, dass man als Anfänger da so schnell an Grenzen stösst...

  • FPGA

    Schau mal auf meiner Seite, da hab ich letztens in der Bastelecke eine RGB LED Matrix für mehrere hundert LEDs auf FPGA Basis veröffentlicht. Das ganze ist auf diesem xc3s400 (Xilinx Spartan III) basiert und enthält auch den VHDL Sourcecode für einen DMX Empfänger. (Allerdings enthält dieser noch irgendwo einen Bug, so dass wenn alle Kanäle auf Max. stehen er die Synchronisation verliert. Hab im Moment keine Zeit und keine Mittel das zu fixen, kommt aber irgendwann sicherlich noch.) Weiterhin besteht die Platine nur aus FPGA und seinen Basiskomponenten (Spannungswandler, Takt, Config-Flash) und den entsprechenden Spalten/Zeilentreibern. Sprich, wenn du die Spalten/Zeilentreiber rauswirfst kannste dir da ein eigenes Board basteln und zig RS485 Wandler ranbauen. Muss dich aber warnen, ist schon ziemlich frikeliges SMD...
    Was den Prozessor angeht: Mit dem Webpack hast du natürlich keine EDK und damit auch keinen Microblaze (32 Bit). Aber vermutlich reicht für den Anfang auch der Picoblaze. Das is ein kleiner 8 Bit Prozessor speziell für Spartan FPGAs entwickelt. Der braucht kaum Ressourcen (ca. 100 Slices glaub ich und einen BRAM für die Software). Wenn einer zuwenig ist, nimmste einfach n paar, wofür hat man denn nen FPGA.
    Ich würde an deiner Stelle nicht anfangen den gross mit nem ext. Prozessor zu koppeln. Besorg oder bau dir n einfaches Experimentierboard und leg mit einfachen logischen Verknüpfungen und Statemachines los bis du weisst wie VHDL und die Xilinx Tools funktionieren und dann nimmste z.B. mal so nen Picoblaze und lässt damit paar LEDs blinken. Und wenn das läuft ist dir auch klar, wie man UARTs im FPGA baut.

  • DMX Signal Splitten ?

    Zitat

    Meine Güte...meine Mathelehrerin (Gymnasium LK) sacht immer, "Ihr Pfeifen solltet ma anne Hauptschule gehn, die können rechnen!".


    Vielleicht solltest du den Mathe LK mal gegen nen Deutsch LK tauschen... SCNR ;)

    Michael

  • DMX Signal Splitten ?

    Das Problem ist der Sprung im Wellenwiderstand an der Verbindungsstelle. Wenn du zwei Kabel an eins anschliesst dann werden die beiden abgehenden Kabel für die Welle (das Signal) praktisch parallel geschaltet. D.h. du hast hier nen Übergang von 120 Ohm auf 60 Ohm und das ergibt Reflexionen auf der hinführenden Leitung. Wenn dort (auf der zum Y hinführenden Leitung) kein anderes Gerät angeschlossen ist sollte diese Reflektion beim Abschlusswiderstand am Sender enden und niemanden stören. Eine Reflexion bedeutet aber auch, dass in den weitergehenden Leitungen nach dem Y Splitter weniger Signalenergie insgesamt vorhanden ist (das was reflektiert wurde is ja weg) und dann wird das was übrig bleibt noch mal halbiert und steht steht dann pro Leitung zur Verfügung.
    Du hast auch eine grössere DC Belastung des Sende Treibers weil du nun ja drei Abschlusswiderstände am Bus hast (falls du terminierst).
    Warum hier unterschiedliche Potenziale ein grösseres Problem sein sollen als bei einem durchgehenden Bus kann ich nicht nachvollziehen.