Forum: FPGA, VHDL & Co. Suche günstigen und "kleinen" FPGA mit PCIe


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von M. H. (bambel2)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich suche nach einem günstigen FPGA mit PCIe (Das e ist wichtig. Das 
System hat kein PCI).

Der FPGA soll zur Digitalen Datenverarbeitung genutzt werden und ein 
paar Schnittstellen über ADC, DAC etc nach außen bringen.

Mein Wunsch wäre es, wenn der FPGA...

1. ... in einem "lötbaren" Gehäuse, sprich TQFP, wäre. QFN ginge zur Not 
auch. Nur BGA wird kritisch.

2. ... relativ günstig wäre.

3. ... von Altera wäre (SW bereits installiert).

Der dritte Punkt wäre cool. Habe allerdings keinen FPGA bei Altera 
gefunden, der PCIe beherrscht und im Rahmen meiner Möglichkeiten liegt.

Da ich vor einiger Zeit leider ein günstiges Dev-Board auf ebay verpasst 
habe, wollte ich das Board selber machen mit allen Komponenten die dazu 
gehören. Im Sinn habe ich eine 4 lagige Platine, gefertigt in Fernost 
(pcbway oder andere Verdächtige).

Ich möchte eigentlich einen FPGA, der wie ein Cyclone IV mit 6000LEs 
ist, aber PCIe beherrscht. Leider habe ich nur große FPGAs gefunden, die 
PCIe beherschen. Diese sind sowohl was die Bauform angeht unbrauchbar 
als auch preislich. Zudem würde ich einen >25000LEs Cyclone V (Beispiel) 
mit meinem Design sowieso nicht füllen. Zumindest habe ich das nicht 
vor. Voll bekommt man die Dinger immer...

Alternativ wäre auch eine 2 Chip Lösung akzeptabel. Also eine Art PCIe 
PHY, sodass man mit einem TQFP100 Popel-FPGA an den Bus kommt. Kennt da 
jemand eine Möglichkeit?

Die dritte Lösung, die mir eingefallen ist, wäre ein PCIe auf PCI 
Bridge-IC. PCI ist ein "langsamer" Bus, den man im FPGA hinbekommen 
sollte. Leider habe ich nur sehr wenige und völlig überteuerte Angebote 
von solchen ICs gefunden.

Hat jemand Lösungsvorschläge?
Oder ist der Wunsch PCIe und "bezahlbar für Student" außer Frage?

Bin auch für andere Vorschläge offen. Die Hauptsache ist es, einen FPGA 
an den PCIe zu bekommen und eigene Hardware (schätzungsweise 20 Signale 
kleiner 10 MHz) anzuschließen.

Vielen Dank

EDIT:
Es geht mir nicht darum große Datenraten zu nutzen. Eine PCIe Lane ist 
völlig ausreichend. Die Datenmenge wird höchstens bei 1 Mbit/s liegen. 
Vielmehr geht es darum, den Rechner als "unendlichen großen" Speicher 
und Rechenknecht zu verwenden. Linux-Treiber und Software stellen kein 
Problem dar.

: Bearbeitet durch User
von Weltbester FPGA-Pongo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Bei Deiner etwas sonderbaren SPEC fehlt noch die Kapazität des Busses. 
Wie schnell und wieviel Lanes? PCIe wirst Du in der Regel nur mit den 
GigabitPorts hinbekommen und die sind (auch bei Altera) in den kleinen 
Chips nicht verbaut. Allerdings meine Ich, dass es einen Cyclone IV 
gibt, der die Ports hat. Dazu braucht es aber IMHO die Vollversion von 
Quartus, da die C4s nur in der NICHT-GBT mit der Wbversion unterstützt 
werden.

Wie wäre es denn mit einem MIX? Der Artix von Xilinx kann das 
serienmässig. Nimmst Du einen 50er und einen Cyclone III. Das wäre wohl 
das billigste. Musst aber Vivado installieren. Das scheint wohl ein 
Kriterium zu sein.

Kannst natrlich auch nur mit Vivado arbeiten und das Cyclone-Geraffel 
noch mit im Artix machen. Xliinx versteht ja auch VDHL. Noch ...

von Zoltan (Gast)


Bewertung
1 lesenswert
nicht lesenswert
> FPGA
> TQFP
> PCIe


Gibt es AFAIK nicht (bei keinem Hersteller).


Es ist PCIe völlig egal wie doll Du es auslasten möchtest, datt rennt 
immer mit 2.5 oder mehr Gbit/s.

Warum nicht einfach USB?

von M. H. (bambel2)


Bewertung
0 lesenswert
nicht lesenswert
Weltbester FPGA-Pongo schrieb im Beitrag #4921896:
> Kannst natrlich auch nur mit Vivado arbeiten und das Cyclone-Geraffel
> noch mit im Artix machen. Xliinx versteht ja auch VDHL. Noch ...

Generell bin ich offen für einen Xilinx Chip. Kann man diesen mit der 
kostenlosen Entwicklungsumgebung "programmieren"?

Weltbester FPGA-Pongo schrieb im Beitrag #4921896:
> Der Artix von Xilinx kann das
> serienmässig.

Ist das ein echtes Können? Ist der IO Standard kompatibel mit PCIe oder 
ist das ein Mißbrauch eines anderen Standards?

von M. H. (bambel2)


Bewertung
0 lesenswert
nicht lesenswert
Zoltan schrieb:
> Warum nicht einfach USB?

Wenn du mir eine Lösung findest einen DMA Transfer über USB einzuleiten 
:/
Ebenso ist USB im FPGA auch keine spaßige Sache. ich erinnere mich noch 
an die schlaflosen Nächte mit nem STM32...

von M. H. (bambel2)


Bewertung
0 lesenswert
nicht lesenswert
Okay. Eine schnelle Suche bei Digikey hat ergeben, dass es die Artix 
FPGAs auch nur im BGA Gehäuse gibt. Somit fallen diese ebenfalls raus.

Ich hoffe jemand hat noch eine Idee, wie man FPGA+HW an PCIe bekommt für 
bezahlbares Geld.

USB möchte ich nur im allergrößten Notfall verwenden. PCIe wäre mir 
lieber, da, mit IP core recht einfach. Treiber sind auch einfach.

USb wäre auch möglich. Leider ist dies im FPGA mit erheblichem 
Mehraufwand verbunden. Softwaremäßig sollte das iwie gehen. Nur schade, 
dass der DMA Transfer im Rechner wegfällt.

von Charles G. (Firma: Ingenieurbuero Gardiner) (cfgardiner)


Bewertung
0 lesenswert
nicht lesenswert
Für PCIe, günstiger als das hier geht zur Zeit nicht, denke ich:
http://www.latticesemi.com/Products/FPGAandCPLD/ECP5ECP5GPromotion.aspx

Gibts z.B. bei Mouser

Es weicht zwar stark von deiner Spec ab, (BGA, nicht Altera ...) aber es 
ist halt günstig. Über einen Steckfeld (2x 40 Pin) kannst du deine 1 MHz 
Signalquellen anschliessen.

von Bla (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Was ist mit dem Dragon von Knjn?
https://www.knjn.com/eu/ShopBoards_PCI.html

400€ kostet der Spaß. Keine Ahnung ob/wie geeignet der ist. Signifikant 
billiger wird's mit einem eigenen Design wahrscheinlich nicht, 
spätestens wenn du deine Zeit einberechnest.

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
Gibt es nicht irgendwo PCI nach PCIe Brücken/Hubs? PLX baut doch so Zeug 
...

Sonst würde ich auch einen USB Stein ranflanschen, kann USB3 wirklich 
kein DMA?

Oder nimm ein BGA-FPGA aber schon auf einem kleinen Modul dass Du dann 
auf die PCIe Karte draufsteckst.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Wie wäre es mit Firewire? Gibt's als PCIe-Karte, kann DMA, scheint aber 
im FPGA viel Aufwand zu sein.

Wie wäre es mit SATA?
Wie wäre es mit Ethernet?

: Bearbeitet durch User
von Strubi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Charles G. schrieb:
> Für PCIe, günstiger als das hier geht zur Zeit nicht, denke ich:
> http://www.latticesemi.com/Products/FPGAandCPLD/EC...
>
> Gibts z.B. bei Mouser
>
> Es weicht zwar stark von deiner Spec ab, (BGA, nicht Altera ...) aber es
> ist halt günstig. Über einen Steckfeld (2x 40 Pin) kannst du deine 1 MHz
> Signalquellen anschliessen.

Das Board kann ich auch empfehlen. Nur vielleicht für den Studenten 
etwas knackig, viele ECP5-Primitiven sind auch nicht als 
VHDL-Simulationsmodelle vorhanden, das kann irritieren. Und die 
Diamond-Toolchain macht lustige Sachen, da ist man vielleicht mit der 
ISE und nem grösseren Spartan6 besser dran, aber mir fällt die britische 
Firma mit dem PCIe-Spartan6-Steckboard nicht mehr ein...

von Zoltan (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Gustl B. schrieb:
> kann USB3 wirklich
> kein DMA?

Doch kann es.
Das ist ja komplett anders als USB 2.0.

von M. H. (bambel2)


Bewertung
0 lesenswert
nicht lesenswert
Zoltan schrieb:
>> kann USB3 wirklich
>> kein DMA?
>
> Doch kann es.
> Das ist ja komplett anders als USB 2.0.

Nur leider ist kein USB 3.X vorhanden.

S. R. schrieb:
> Wie wäre es mit SATA?

Etwas anderes als Speicherbefehle (SCSI etc...) über SATA bzw diese 
dafür zu missbrauchen scheint mir etwas kritisch. Da stellt sich nunmal 
auch die Frage: SATA: 3/6 Gbps seriell Bus. Braucht man nen FPGA mit 
SERDES => Groß, teuer, unlötbar im Hobbybereich. Und selbst wenn. Die 
meisten FPGAs werden keinen IO Standard besitzen, der SATA kompatibel 
ist.

S. R. schrieb:
> Wie wäre es mit Ethernet?

Das hab ich mir auch schon überlegt. Die Datenrate wäre in Ordung, 
Ethernet PHYs sind billig bzw. nicht billig, aber bezahlbar. Zudem ist 
Ethernet noch ziemlich primitiv und nimmt nicht viel Platz weg, solange 
man nur MAC fährt. Ich werde mir das überlegen. Wobei ich da eventuelle 
Probleme sehe, einen Kerneltreiber für das über Ethernet angeschlossene 
Gerät zu schreiben... Muss mal überlegen, ob das als User-Software 
sinnvoller bzw. überhaupt machbar ist.

Strubi schrieb:
> Und die
> Diamond-Toolchain macht lustige Sachen

Das kannst du laut sagen. Mit Lattice, genauer Diamond, stehe ich auf 
Kriegsfuß.
<offtopic>
Meine Leidensgeschichte begann mit der Installation auf Linux.

Ein RPM zu entpacken auf einem System, dass keinen rpm Paketmanager hat 
ist n bisschen doof mit den ganzen Pre- und Post-install-Skripten. 
Nachdem Diamond installiert war, weigert es sich natürlich zu 
funktionieren.

Die überprüfen beim Start der sysnthese die Linux-Kernelversion. Meine 
war unsupported => Läuft nicht. Erstmal skripte patchen und das if 
umbasteln...

Nachdem die SW dann lief habe ich ein Ethernet Design synthetisiert. Hat 
auf dem FPGA (LFXP2-5E) nichts gemacht... Simulation ging. Da das Design 
aber schon häufiger einige Bugs hatte, habe ich gedebuggt wie wild. 
Nachdem ich nichts finden konnte und etliche Stunden und Kaffeetassen 
später, kam ich auf die Idee mal nen Altera Chip zu nehmen.

Ergebnis: Geht. => Also Lattice angeschrieben und gefragt, warum ihre 
Synthese bei einem 500 Zeilen VHDL Design mit n paar standart 
State-Machines die Grätsche macht.

Die wollten dann eine Timingsimulation. => Gemacht. Ergebnis: Tut nicht.

Screenshots von normaler Simulation und Timing-Sim hingeschickt. 
Ergebnis sinngemäß: "YOLO. Ist uns egal. Du bist eh nur Student..."

Aufgrund dieser Erfahrung meide ich Lattice momentan, obwohl ich ihre 
Chips immer sehr schön fand.
</offtopic>

von Bastler (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Schau dir mal auf devboards das DB4CGX15 Kit an.

Das ist mit Cyclone IV und durchaus bezahlbar.

von Strubi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>
> S. R. schrieb:
>> Wie wäre es mit Ethernet?
>
> Das hab ich mir auch schon überlegt. Die Datenrate wäre in Ordung,
> Ethernet PHYs sind billig bzw. nicht billig, aber bezahlbar. Zudem ist
> Ethernet noch ziemlich primitiv und nimmt nicht viel Platz weg, solange
> man nur MAC fährt. Ich werde mir das überlegen. Wobei ich da eventuelle
> Probleme sehe, einen Kerneltreiber für das über Ethernet angeschlossene
> Gerät zu schreiben... Muss mal überlegen, ob das als User-Software
> sinnvoller bzw. überhaupt machbar ist.
>

Warum Kerneltreiber? Brauchst du proprietäres/Echtzeit? Das geht nur mit 
wüsten Hacks und Direktzugriff auf die Packet Queue.
Hier hat doch gerade jemand den Hamster-UDP-Stack mit Labview 
verknotet..


> Strubi schrieb:
>> Und die
>> Diamond-Toolchain macht lustige Sachen
>
> Das kannst du laut sagen. Mit Lattice, genauer Diamond, stehe ich auf
> Kriegsfuß.

Sie haben halt seit Jahren gehörige Bugs in ihrem TCL-Gefrickel unter 
Linux und weigern sich, die zu beheben, deswegen funktioniert das Bauen 
nur wirklich rund um die Uhr, wenn man die .exe's per Makefile/shell 
aufruft. Das einzig nette an der Toolchain ist die IMHO sehr gut 
designte Synopsys-SW.
Ansonsten lässt sich Diamond per alien schon ohne Krücken unter Ubuntu 
installieren, aber spinnt halt regelmässig mit Pfadnamen rum, das ist 
einem Endkunden kaum zuzumuten.
Trotz der schönen Chips musste ich leider auch öfters diesbezüglich aus 
ganz pragmatischen Gründen aufs grosse X zurückfallen.

von Bitwurschtler (Gast)


Bewertung
0 lesenswert
nicht lesenswert

von Bernhard T. (bernhardt)


Bewertung
0 lesenswert
nicht lesenswert
Vieleicht wäre ja auch der Umweg über ein PCMCIA bzw. Cardbus über PCIe 
Karte eine Möglichkeit.

von Rudolph (Gast)


Bewertung
0 lesenswert
nicht lesenswert
M. H. schrieb:
> Alternativ wäre auch eine 2 Chip Lösung akzeptabel. Also eine Art PCIe
> PHY, sodass man mit einem TQFP100 Popel-FPGA an den Bus kommt. Kennt da
> jemand eine Möglichkeit?

Da gab' es mal Lösungen für den Spartan-3...

> Die dritte Lösung, die mir eingefallen ist, wäre ein PCIe auf PCI
> Bridge-IC. PCI ist ein "langsamer" Bus, den man im FPGA hinbekommen
> sollte. Leider habe ich nur sehr wenige und völlig überteuerte Angebote
> von solchen ICs gefunden.

Der XIO2001 (http://www.ti.com/product/XIO2001) ist nicht teuer und es 
gibt ihn tatsächlich im TQFP-Gehäuse.

von Duke Scarring (Gast)


Bewertung
0 lesenswert
nicht lesenswert
M. H. schrieb:
> Der FPGA soll zur Digitalen Datenverarbeitung genutzt werden und ein
> paar Schnittstellen über ADC, DAC etc nach außen bringen.

S. R. schrieb:
> Wie wäre es mit Firewire?
Das ist doch tot.

> Wie wäre es mit SATA?
Wäre eine Möglichkeit, passt aber m.E. nicht ganz so gut zu den 
Anforderungen.

> Wie wäre es mit Ethernet?
Das wäre mein Favorit. Da braucht man keine PCIe-Hersteller ID und 
keinen Kerneltreiber. In diesem Fall scheint letzteres ja kein Problem 
zu sein.
Der Code kann ja als Bibliothek im Userland laufen.


Bernhard T. schrieb:
> Vieleicht wäre ja auch der Umweg über ein PCMCIA bzw. Cardbus über PCIe
> Karte eine Möglichkeit.
Genauso obsolet wie Firewire.


Gustl B. schrieb:
> Gibt es nicht irgendwo PCI nach PCIe Brücken/Hubs? PLX baut doch so Zeug
So einen Umweg würde ich nicht gehen. PCI ist eben auch schon so gut wie 
tot.


Bitwurschtler schrieb:
> PCIe geht schon mit Spartan6, schau dich doch mal nach als obsolet
> ausgemusterte bitcoin mining boards um.
Das Bitcoinboard kann eher kein PCIe. Dafür braucht man m.E. die 
Spartans mit den Gigabit-Transceivern.
Das günstigste von Xilinx ist das SP605 für 500 Tacken.
Mir wäre das zuviel für's Hobbybudget.

Die anderen Anbieter (KNJN und Lattice) wurden schon genannt.
Für das KNJN-Dragonboard gibt es immerhin so eine Art Tutorial:
http://www.fpga4fun.com/PCI-Express.html

Bei Trenz findet man auch nix wirklich in günstig:
https://shop.trenz-electronic.de/de/search?sSearch=pcie


Duke

von M. H. (bambel2)


Bewertung
0 lesenswert
nicht lesenswert
Duke Scarring schrieb:
> Gustl B. schrieb:
>> Gibt es nicht irgendwo PCI nach PCIe Brücken/Hubs? PLX baut doch so Zeug
> So einen Umweg würde ich nicht gehen. PCI ist eben auch schon so gut wie
> tot.

Das schon. Aber Softwaretechnisch verhält es sich, zumindest bei Linux, 
identisch zu PCIe. Deshalb ja die Idee, die schnelle PCIe Lane auf den 
langsamen Bus umzubasteln. Das ist teilweise Heute auch noch üblich. 
Viele Mainboards besitzen irgendwo eine PCIe auf PCI Bridge für LAN, 
Audio und so weiter.

Duke Scarring schrieb:
> Das wäre mein Favorit. Da braucht man keine PCIe-Hersteller ID und
> keinen Kerneltreiber. In diesem Fall scheint letzteres ja kein Problem
> zu sein.
> Der Code kann ja als Bibliothek im Userland laufen.

Das ist mittlerweile der Plan, da die PCIe Sache doch etwas aus dem 
ruder läuft. Das Problem ist, es kommt auf sehr geringe Latenzen an. Das 
werde ich in einer ruhigen Minute testen. Hatte mit dem Netzwerkstack 
von Linux schonmal meine Probleme. Damals mit CAN...

von Gerd E. (robberknight)


Bewertung
0 lesenswert
nicht lesenswert
M. H. schrieb:
> Zoltan schrieb:
>> Warum nicht einfach USB?
>
> Wenn du mir eine Lösung findest einen DMA Transfer über USB einzuleiten
> :/

Warum muss das DMA vom FPGA direkt in den Rechner gehen können? Ist das 
ganze so latenzkritisch daß Du kaum puffern kannst?

> Ebenso ist USB im FPGA auch keine spaßige Sache. ich erinnere mich noch
> an die schlaflosen Nächte mit nem STM32...

Du musst das USB ja nicht komplett selber machen, dafür gibt es fertige 
ICs.

Folgende 2 Linien würde ich empfehlen mal anzuschauen:

FTDI
http://www.ftdichip.com/Products/ICs/FT2232H.html - USB HS
http://www.ftdichip.com/Products/ICs/FT600.html - USB 3 SS

Cypress
http://www.cypress.com/products/ez-usb-sx2 - USB 2 HS
http://www.cypress.com/products/ez-usb-fx2lp - USB 2 HS
http://www.cypress.com/products/ez-usb-fx3-superspeed-usb-30-peripheral-controller

Die FTDIs haben dabei immer die Funktion komplett festgelegt und Du 
musst im FPGA Glue-Hardware schreiben die an deren Interface andockt und 
auch etwas puffert.

Bei Cypress gibt es welche (FX2 und FX3) die einen eigenen Prozessor 
(8051 bzw. ARM) drauf haben den Du programmieren kannst. Das vereinfacht 
evtl. die Schnittstelle zum FPGA, Du musst aber natürlich ein Teil mehr 
programmieren, debuggen,...

USB hat den großen Vorteil daß es eine extrem weit verbreitete 
Peripherieschnittstelle ist und bisher immer Rückwärtskompatibel war. 
Eine 19 Jahre alte Maus kannst Du auch heute noch anschließen und sie 
wird sofort erkannt und funktioniert. Da stehen die Chancen also gut daß 
Dein Gerät auch in 10 Jahren noch an einen dann aktuellen PC 
angeschlossen werden kann.

Wenn man sich die Geschichte mit ISA/PCI/AGP/PCIe anschaut, könnte PCIe 
bis dahin verschwunden oder zumindest selten geworden sein. SATA wird es 
in der heutigen Form in 10 Jahren sicher nicht mehr geben. Nur mit 
Ethernet wirst Du vermutlich ähnlich zukunftssicher sein wie mit USB.

von No Y. (noy)


Bewertung
0 lesenswert
nicht lesenswert
Nimm ein Altera De0 Nano SoC.
Gibts für <100€ und hast alles was du brauchst...
Kannst die Daten mim FPGA holen im SoC zwischenspeichern bzw. packen 
oder sonstiges und per USB oder GBit Ethernet rausjagen.

von M. H. (bambel2)


Bewertung
0 lesenswert
nicht lesenswert
No Y. schrieb:
> Nimm ein Altera De0 Nano SoC.
> Gibts für <100€ und hast alles was du brauchst...
> Kannst die Daten mim FPGA holen im SoC zwischenspeichern bzw. packen
> oder sonstiges und per USB oder GBit Ethernet rausjagen.

Ist bereits vorhanden. Das Problem ist nur, dass der FPGA an den Rechner 
angeschlossen werden soll und nicht ein extra gerät gebaut werden soll, 
dass dann wiederum über Ethernet/USB kommuniziert.

Sollte ich das ganze über Ethernet machen, ist der SoC auch unnötig. 
Eine 100Mbit oder 1Gbit MAC geht gut in VHDL.

von Gerd E. (robberknight)


Bewertung
0 lesenswert
nicht lesenswert
M. H. schrieb:
> Das Problem ist nur, dass der FPGA an den Rechner
> angeschlossen werden soll und nicht ein extra gerät gebaut werden soll,
> dass dann wiederum über Ethernet/USB kommuniziert.

Das Problem ist also, daß das alles im Gehäuse des PCs drin sein soll 
und nicht als extra Kiste außerhalb des PCs rumstehen soll?

Einige USB-Schnittstellen sind normalerweise auch als Pin-Header am 
Mainboard für den Zugriff von Innen verfügbar. An die könntest Du 
rangehen und den Rest der Hardware z.B. auf eine Platine packen, die 
zwar den Formfaktor einer PCIe-Karte hat, aber einfach keinen 
PCIe-Anschluss verwendet.

von Peter (Gast)


Bewertung
0 lesenswert
nicht lesenswert

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert

: Bearbeitet durch User
von Duke Scarring (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Mir ist eben eine Werbung ins Postfach geflattert:
Mars XU3: Zynq® UltraScale+™ Kraftzwerg
108 User-I/Os, PCIe, Gigabit Ethernet, USB 3.0

Scheint es aber noch nicht zu geben ("In Development") und in den PC 
kann man das Board so auch noch nicht reinstecken...

Duke

von Jan S. (jannemann)


Bewertung
0 lesenswert
nicht lesenswert
Weltbester FPGA-Pongo schrieb im Beitrag #4921896:
> Xliinx versteht ja auch VDHL. Noch ...

Gibt es Pläne, dass Xilinx bald kein VHDL mehr versteht???
Grüße Jan

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.