Hallo, ich schreibe zurzeit an meiner Abschlussarbeit (seit einigen Wochen) und soll dazu einen Framegrabber auf einem FPGA entwickeln, der ein paralleles Videosignal über UDP/IP an einen PC schickt. Ursprünglich war geplant dafür ein Kette von IP Cores zu nutzen, doch jetzt haben wir (leider im Nachhinein) festgestellt, dass nicht alle benötigten lizenzfrei sind. Und Lizenzen für Cores zu kaufen ist erst mal nicht drin... Mit den Xilinx Entwicklungsumgebungen und VHDL habe ich so gut wie keine Erfahrung, habe mich aber nun doch darauf eingelassen und nun festgestellt, dass alles schwieriger ist, als ich es mir vorgestellt habe. Und auch in meinem Umfeld kennt sich keiner so richtig aus... Nun meine Frage - denkt ihr, dass dieses Thema überhaupt in den nächsten 3-4 Monaten (für einen Newbie) zu schaffen ist (d.h. dass ein Bild über UDP rausgesendet wird)? Ein weiterer Gedanke ist nun das ganze mit einem MicroBlaze Prozessorsystem aufzubauen. Könnt ihr mir ungefähr sagen, wie viel Aufwand das wäre auf diese Weise ein UDP Stack usw. zu implementieren und die Sache zum Laufen zu kriegen? ...sonst müsste ich das Thema irgendwie nochmal in eine andere Richtung lenken... Danke schon mal!
Fang schon mal am besten an gegen zu lenken. Da müsstest du viel Zeit investieren, allein schon nur für die Einarbeitung in VHDL. Dann kommt noch Microblaze dazu, bis du verstehst wie du es anwendest und wozu es da ist... Das müssten aber die Profs doch wissen, dass das so nichts wird, oder nicht? Ich habe selber mal den Microblaze verwendet, um Beispielsweise ein Bild aus einer CF-Karte einzulesen, in den RAM abzuspeichern und über ein Übertragungsprotokoll auf Anfrage loszuschicken. Und ich war kein Newbie, trotzdem hat es gedauert, so mind. 1-2 Monate. Hatte aber als RAM einen ext. DDR2, was auch noch Zeitintensiv war. Übertragungsprotokoll war CameraLink. Trotzdem wünsche ich dir viel Erfolg. Cihan
Hi, also ganz ehrlich, aus meiner Erfahrung (und ich bin schon ne ganze Weile dabei) ist das in 3-4 Monaten sehr knackig, je nachdem wie weit Du auf bestehende IP-Cores zugreifen kannst. Ich würde mal eine Einkaufsliste der fehlenden Komponenten machen. Poste die doch mal, dann kann Dir noch besser geholfen werden. Denn so kleine Knackpunkte wie "Brauche ich DDR Memory oder nicht" können die Entwicklungsdauer v.a. in Bezug auf Debugging um Monate verlängern. Auf der CPU einen UDP-Stack zu implementieren, ist nicht so schwer. Das knifflige wird vermutlich eher die Anbindung bzw. schon alleine ein gutes Konzept um die Daten abrissfrei durch die verschiedenen Nadelöre zu kriegen. Ich habe so etwas ähnliches gemacht, allerdings für den Versand der Bilddaten gleich einen embedded-Linux-Host eingesetzt um alle Netzwerk-Sachen abzuhaken. Den uBlaze habe ich eher gemieden und stattdessen auf der "Vorverarbeitung" eine ZPU rein zur Konfiguration eingesetzt. Da es ja wohl eine Arbeit und kein Produkt sein soll, einige Vorschläge (aber keine Ratschläge :-) ), um der Geschichte akademische Würze zu verleihen, aber die Komplexität etwas herunterzukochen: 1) Netzwerk weglassen und statt dessen USB FIFO nehmen (FX2). Das lässt sich gut auf bestehenden Testboards entwickeln und es gibt viele Referenzlösungen. 2) Mit Vorverarbeitung experimentieren: a) 3x3-Filterkernel implementieren b) Bayer-Demosaicing. Da es unzählige Bayer->RGB-Routinen gibt, könntest Du alternativ von Bayer direkt in den Luma-Chroma-Farbraum umrechnen, um z.B. schlussendlich sog. 'subsampled' YUV-Daten auszugeben. Das ist nicht unspannend... 3) Bevorzugt OpenSource und herstellerunabhängige Komponenten verwenden: a) z.B. statt closed "uBlaze" eine ZPU einbinden (siehe auch hier im Forum) b) generierte IPcores (Coregen) von Hand entwickeln (Vorsicht bei dual clock FIFOs, das ist sehr knifflig) Im Endeffekt leistest Du ja sicher irgendwo eine Eigenentwicklung und steckst nicht nur Komponenten zusammen. Diese kleine Herausforderung würde ich mir noch überlegen. So quasi als "Alleinstellungsmerkmal", damit dir nicht gleich jeder entgegenschmetter: Gibt's schon! Grüsse!
Vielen Dank schon mal für die Antworten. Leider habe ich jetzt festgestellt, dass die Profs nur oberflächlich Ahnung haben (Grundlagen VHDL, aber nicht darüber hinaus und auch keine Erfahrung mit den Xilinx Entwicklungsumgebungen). Daher gehe ich auch davon aus, dass sich der Prof das ein bisschen zu einfach vorgestellt hat. Ich will mal die Sache noch ein wenig konkretisieren: Ich schreibe die Arbeit in einer Firma (die aber sonst eigentlich andere Sachen macht - daher keine Erfahrung mit VHDL. Das Gerät ist als Testgerät für Displays gedacht). Daher ist sie natürlich auch an einem konkreten Ergebnis interessiert. Und das steckt auch wiederum einen gewissen Rahmen. So ist ein Entwicklungsboard bereits vorhanden (hat kein USB, dafür aber einen Ethernet PHY). Daten sollen über 1Gigabe Ethernet rausgesendet werden, was aufgrund der Datenrate (ca.70MByte/s) durchaus notwendig ist. Auf IP Cores kann ich leider nicht zurückgreifen und es wird auch - wie es momentan aussieht - erst mal nicht möglich sein, welche zu kaufen. Ein RAM sollte ursprünglich verwendet werden, nur habe ich gelesen, dass dadurch viel Performance verloren gehen soll (bei der Datenrate). Denn es wird ja fast wire speed benötigt. Die Frage ist dann nur, ob es ohne RAM möglich ist (bzw ohne asynchronen FIFO). Bearbeitet werden sollen die Daten nicht, sie sollen quasi im raw format (als Bytearray) gesendet werden, um dann später am PC das Bild (keine Bilddatei) pixelweise überprüfen zu können. Wenn es nach mir geht soll es so einfach wie möglich werden. Ich weiß nicht, ob das ein embedded Linux leichter macht (zudem ich kein Linux user bin). Und genug um drüber zu schreiben hätte ich jetzt schon. Soweit erst mal...
Naja wenn du kein Webinterface oder so habne willst. Kann vileicht doch noch was werden ... mußt dich halt wirklich auf die Basics konzentriern. Also wirklich nur die RAW Daten auslesen, in ein Paket packen und verschicken (als stream sozusagen), dazu noch nen paar sync Infos wann ne neu Zeile Anfäng und wann ein neues Bild, den rest muß der PC machen. Also ein Anzeigbares Bild darauß machen (Debayer und so).
Hi DS, ohne die akademische Elite angreifen zu wollen: die meisten stellen sich das zu einfach vor. Sie haben ja auch seltenst die Zeit, Aufgaben selbst zu implementieren, geschweige denn mit alle 2 Jahren wechselnden Tools auf dem Stand zu bleiben. Wichtig ist auf jeden Fall eine gute Betreuung. Habe in der Vergangenheit einige Studenten/Diplomarbeiten betreut und daher gut mitbekommen, wie die Studis ab und an schwimmen. Das kann extrem frustrierend sein, und gerade in externen Projekten mit limitierter Betreuung durch die Firma werden auf die Weise viele Studis richtiggehend verheizt. Darf ja die Firma auch nichts kosten, nech. Insofern wäre ich vorsichtig damit, was Dir die 'Vorgesetzten' so an Schwärmereien aufdrücken (wollen). Du verlierst ansich keinen Zacken aus der Krone, wenn Du den Chefs eine gute Begründung und Abschätzung liefern kannst, warum etwas nicht machbar oder wirtschaftlich ist. Bei uns gabs damals auch Punkte für eine saubere Aufwandsabschätzung und Evaluation der Risiken (sprich, Projektmanagement hatte min. 15% Gewicht) Zu deinen technischen Überlegungen: Du kannst auf jeden Fall mit dem internen BlockRAM auskommen, wenn Du nicht grade den kleinsten Spartan3 einsetzt. Du brauchst ein paar Zeilenpuffer und etwas RAM für die UDP-Pakete. Wenn Du bereits einen MAC-Block (mit RMII, etc.) hast, könnte das mit den 3-4 Monaten klappen. Auch wenn Du ev. einen fertigen DDR-Core (wie auf dem Spartan6) hast: Das Problem wird dann u.U, eine gute abrissfreie Pufferung der Daten hinzukriegen. Sehr aufwendig, deshalb würde ich externes RAM erst mal absolut vermeiden. Das ganze kannst Du auch komplett in der Simulation hochziehen, dann weisst Du etwa was an Resourcen fällig wird. Die Simulation kann allerdings mit einer freien Lizenz bei den meisten Tools (isim, Modelsim) zur Tortur werden. Sind deshalb auf GHDL ausgewichen (OpenSource). Hoffe, mit Anregungen gedient zu haben :-)
Ich habe ein Ethernet-UDP ganz ohne IP-Core implementiert. Dazu muss man - mit dem PHY kommunizieren (MDIO) - dem PHY die richtigen Daten mitteilen (Vorspann 0x55) etc - die korrekte CRC berechnen - über allen darüber dann die UDP-Packet füllen und eine Ablaufsteuerung implementieren. Alles das wird einem Anfänger mindestens 3 Monate Kosten. Und darin ist noch nichts vom Framegrabber und mit Bildern. Framegrabben alleine vielleicht mit dem FPGA. Aber den UDP-Teil würde ich lieber auf einem 'normalen' Prozessor abwickeln wollen. Vielleich geht ja ein Zynq oder ein Altera SoC. Aber rein FPGA würde ich nicht machen wollen. Zumal du keine Unterstützung von erfahrenen Leute erwarten darfst.
Was soll denn das Gerät überhaupt machen? Weil das kann alles auch ganz trivial sein, so wie Du das beschreibst, oder aber auch hoch komplex. Was Du machen kannst ist das Schwarz-Weiß BAS-Signal klemmen und digitalisieren (LM1881 holt Dir die Sync-Signale raus) und dann an den FPGA schicken. Der nimmt dann zum richtigen Zeitpunkt der Zeile 500-1000 Werte auf, und schickt die zusammen mit der Zeilennummer (und ggf. Bildnummer) per Gigabit Ethernet raus. Macht 14400 Pakete pro Sekunde, mit guten Gigabit Ethernet Karten im PC ist das kein Problem. Bei Farbe kann es sein, dass Du einen PAL Dekoder brauchst. Der kann primitiv einfach bis hoch komplex sein, je nach Anforderungen. Im einfachsten Falle machst Du per DDS einen PLL, der sich immer am Burstsignal nachsteuert (die zeitliche Position des Bursts schätzt Dir freundlicherweise sogar schon der LM1881). Damit kannst Du dann das QAM-Signal demodulieren. Wenn es besser sein soll, mittelst Du das mit der vorherigen Zeile, modulierst es wieder für beide Zeilen und ziehst es vom Helligkeitssignal ab. Ist Dir die Datenmenge zu groß, so kannst Du mal alte Artikel von der BBC durchlesen. Die haben da ihre Engineering Monographs und ähnliche Publikationen. In den 1960ger-1980ger Jahren hatten die immer mal wieder Artikel über einfache Bilddatenkompression. Ich glaube die konnten ein Farbsignal mit relativ primitiver Technik auf grob 35 MBit komprimieren. (und das ohne von PAL auf Komponenten zu gehen)
Framegrabbing per UDP über Microblaze geht nur, wenn der Frame selten kommt ;) Ein 66MHz Microblaze mit Linux schafft bei mir mit viel Glück so 3-4MB/s, und da hat die Netzwerkkarte (RTL8169) schon eine ganze Menge Arbeit abgenommen. Mag mit dem rohen Xilinxstack ohne OS und Spartan6 etwas schneller gehen, aber sicher nicht so, dass man auch nur PAL-Frames bei 25fps zuverlässig los wird. Wirklich gut läuft sowas nur ohne CPU. Das ist aber wirklich aufwendig (BTDT, knapp 90MB/s IPv6-UDP in Hardware und die CPU schaut zu...) und ohne gute VHDL-Kenntnisse und überhaupt allgemein Erfahrung im Design/Test der Komponenten in der angegebenen Zeit sicher nicht machbar. Wenn schon, solltest du das Ziel auf Subsystem einschränken und das dann vernünftig machen. Das ist besser als vollständig, aber nicht funktionierend...
Hi! Rein aus Neugierde: Gibt es keine fertigen Datagrabber, die so etwas können? Gruß Der
Danke für die guten Beiträge, die helfen mir schon mal weiter. Lesen tu ich in diesem Forum ab und zu aber diesmal habe ich zum ersten mal was geschrieben und bin überrascht, wie schnell und konstruktiv die Antorten kommen (das sieht im Xilinx Forum gaaanz anders aus...) @Fitzebutze Als FPGA habe ich einen Spartan 6 XC6SLX45 Wie ist das mit dem fertigen DDR Core auf dem Spartan 6 - ist das das DDR, das der BSB Wizard im Xilinx Platform Studio automatisch erzeugt? Ist der sofort einsetzbar und zugänglich über fertige Schnittstellen? Ein Mac Core mit gmii (was der PHY braucht) stellt XPS zur Verfügung - allerdings nicht lizenzfrei... Simulation klingt für mich recht schwierig - wieder Tools, in die ich mich einarbeiten muss. Ist das erforderlich oder geht das auch ohne @PittyJ Dass es nicht in Frage kommt, das System komplett selbst aufzubauen, hab ich mir auch schon gedacht. Alleine die MAC Ebene zu programmieren, das wäre schon eine eigene Bachelorarbeit. Das Entwicklungsboard ist auch schon gekauft und da, also gibt es dort keinen Spielraum. @Christian Berger Danke auch für deine ausführliche Antwort, allerdings geht sie in ein etwas andere Richtung, du schreibst von Analogsignalen, deshalb nochmal kurz etwas zur Eingangsseite: Der Videostream kommt bereits digital und parallelisiert als RGB Pixelstrom mit Synchronisationssignalen (vsync, hsync, de und pclk) an. @Georg A. Der Frame kommt häufig... 60fps. Allerdings kann bei dieser Datenrate auch jedes zweite Bild weggelassen werden. @der Es gibt meines Wissens noch keine, die dieses Eingangsformat (vor dem Deserializer) verarbeiten können (FTP Link III)
sorry, vertippt, das heißt FPD Link III, nicht FTP
Der MAC im Spartan 6 ist doch aber ein hard-IP, da sollte man eigentlich auch lizenzfreien Zugriff haben, jedenfalls wenn man ohne MicroBlaze oder sowas arbeitet. Die UDP Pakete kann man auch in Logik basteln, der µB wäre eh zu lahm. Edit: Sorry, ich hab das mit PCIe verwechselt. S6 hat doch keinen MAC eingebaut. Na dann wirds erst recht schwierig. Eventuell könntest du auf Glasfaser gehen, wenn du das SP605 Board haben solltest. Dann kannst du ja die Ethernet Frames direkt über die MGT Transceiver rauspusten.
D.S. schrieb: > Nun meine Frage - denkt ihr, dass dieses Thema überhaupt in den nächsten > 3-4 Monaten (für einen Newbie) zu schaffen ist Nur, wenn du einen sehr erfahrenen und hochmotivierten Betreuer hast und das Meiste deiner Freizeit investierst. Und: ein Viertel der Zeit wirst du für die Dokumentation der Arbeit brauchen... S.D. schrieb: > Simulation klingt für mich recht schwierig - wieder Tools, in die ich > mich einarbeiten muss. Ist das erforderlich oder geht das auch ohne Ohne Simulation geht es nur, wenn du zufällig alle zighundert Parameter, die du einstellen könntest, richtig einstellst. Rechne dir mal die Wahrscheinlichkeit aus...
Nur kurz: Es gibt seit Jahren einen Framegrabber, der sowas für CameraLink macht, nannte sich Pleora iPort. Gibt es offensichtlich auch immer noch in dieser Form. Der Gag an dem Teil war, dass es die Features des eingebauten Intel-MAC voll ausnutzt und auf PC-Seite einen optimierten Treiber nutzte, damit keine UDP-Pakete verloren gehn. Ist hier wohl aber eher zweitrangige Info.. S.D. schrieb: > Als FPGA habe ich einen Spartan 6 XC6SLX45 > Wie ist das mit dem fertigen DDR Core auf dem Spartan 6 - ist das das > DDR, das der BSB Wizard im Xilinx Platform Studio automatisch erzeugt? > Ist der sofort einsetzbar und zugänglich über fertige Schnittstellen? > Der ist relativ einsetzbar, ist ein harter Silizium-Kern. Also nur Konfiguration nötig, die ist aber u.U. schon knifflig genug. Mit einem Trenz Gigabee lief das bei mir aber auf Anhieb. > Ein Mac Core mit gmii (was der PHY braucht) stellt XPS zur Verfügung - > allerdings nicht lizenzfrei... > Da gibt es was bei OpenCores.. > Simulation klingt für mich recht schwierig - wieder Tools, in die ich > mich einarbeiten muss. Ist das erforderlich oder geht das auch ohne Absolut nicht ohne. Das Debugging kannst du ohne Simulation bei dieser Komplexität so gut wie vergessen, oder es kostet dich weitere 7 Monate :-) Ich kann ansonsten GHDL sehr empfehlen, 'obwohl' kostenlos, ist es zur Simulation von komplexen Systemen sehr gut geeignet. Nur wenn du herstellerspezifische Blöcke verwendest, kann es Probleme geben. Mit dem OpenSource-Ansatz haben wir bei einem Projekt viel Zeit gespart und sind erst noch FPGA-unabhängig. Gruss
Ich kann kaum begreifen, was ich hier an Zeit-Schätzungen lese. Entweder lesen hier einige die Randbedinungen nicht richtig oder haben keine Erfahrung. Fassen wir mal zusammen: Der Autor möchte .... - Daten über UDP-Protokoll mit 1GB versenden - hat einen Spartan ohne CPU Kern und einen PHY ohne MAC - darf keinen MAC kaufen - möchte einen Microblaze einsetzen - hat keine Erfahrung mit Xilinx - hat keine Erfahrung mit Simulation - keine Erfahrung mit Microblaze Allein die Vorstellung, man könne mit einem Microblaze 1GB Bandbreite schaffen, ist schon mal komplett irrig. Aber sowas von komplett irrig. Da fehlt mal locker ein Faktor 5-10. Selbst mit einem Virtex und Power-PC ist das kein Kinderspiel. Ebenso daneben ist der Versuch, ohne jegliche Simulation einen kompletten UDP-Stack implementieren zu wollen und sei es auch nur ein mickriger. Dabei ist es eigentlich egal, ob man ihn selber vereinfacht nachbaut oder einen fetten MAC nimmt und abspeckt. Wahrscheinlich ist es auch egal, ob man ihn in Software oder FSMs baut: Ohne Simulation geht das definitiv überhaupt nicht. *Chancenlos!* Meine Rechung für einen Studenten sieht so aus: Vorarbeiten: 1 Woche Lastenheft mit Projektleiter klären und Zeitplan machen 1 Monat ISE kennenlernen und Simulieren lernen 1 Monat Xlinx Probleme lernen und zu einem Compilat kommen 1 Monat high speed Designs und Constraints lernen Dann: 1 Monat SPEC schreiben, dass man weiss, was man arbeiten wird 1 Monat PHY kennenlernen und ansteuern lernen 1 Monat Simulieren und Testen, bis der PHY ein einziges Paket ausspuckt 1 Monat UDP ausbauen, dass das Protokoll stabil läuft 1 Monat State Machines bauen, die den Ablauf steuern Alternativ einfach den Xilinx MAC nehmen und sich 1 Monat in den einarbeiten, 1 Monat Xilinx Probleme lösen. Dann: 1 Monat timing optimieren, dass man die 1GB Bandbreite schafft 1 Monat Inbetriebnahme und Fehlersuche 1 Monat Bilddaten einlesen, Timing implementieren und verpacken 1 Monat Design umkrempeln, weil die Spartan-6 Krücke limitiert ist Dann muss da irgendeine Steuerung drauf. Der Rechner muss ja den Grabber irgendwie anwerfen und parametrieren. Also das Ganze nochmal in die andere Richtung mit Lesen vom PHY. 1 Monat Leseprotokoll und Aufweiten der FSM. 1 Monat Inbetriebnahme und Fehlersuche des Gesamtsystems 2 Monate dokumentieren, was man gemacht hat Ich sehe hier allein schon >1 Jahr, abzüglich eventueller Vorkenntnisse. Ich rechne das Ganze noch *+20%* weil "*Anfänger* ohne Betreuung". ************************************************************************ ** Wenn Du sowas noch nicht gemacht hast, sitzt Du da in *1,5* Jahren noch dran. ************************************************************************ ** Ich lasse mich aber gern eines Besseren belehren, dass Du es in einem Jahr am Laufen hast.:-) Mal ernsthaft: Deine einzige Chance ist, eine existente Lösung zu nehmen und zu modifizieren. Je mehr Fertiges Du irgendwo auftreiben kasst, desto besser. ABER: Nur einfach Fertigteile zusammenzustecken, wird Dich nicht weiterbringen, weil es ein oberflächliches Wissen ist, dass ohne Wert bleiben wird. Das ist für Studenten komplett das Falsche. Wenn Du wirklich so wenig Ahnung hast, musst Du die Basics lernen und das dauert länger, als 3 Monate = 12 Wochen = 60 Tage. Allein die Bruttozeit bei der Synthese eines TRiCore-MAC sind 30min+ je Lauf und Du wirst deren 50 brauchen, bis das geht. Das allein sind schon 3 komplette Tage Netto. Wahrscheinlich hat er die Freeware von ISE und das langsame Schmalspur ISIM und es ist deshalb ein S6 45. ************************************** Leute, Leute, so langsam kapiere ich, warum unsere lieben Projektleiter ständig die Entwicklungszeiten unterschätzen: Meine lieben Kollegen Entwicklungsingenieure geben vollkommen irrational kurze Zeiten weiter :-) Wir alle wissen doch, welche Probleme da auftreten und wie schwierig das für einen Anfänger ist!
Tach nochmal, also ganz so schwarz wie Markus sehe ich es nicht, aber würde ihm dennoch beipflichten. Hoffentlich ist auch dem 'Auftraggeber' klar, dass ein solches Projekt als Produkt (mit entsprechender Qualität) min. ein Jahr Entwicklung kostet. Es gibt immer mal wieder ein paar echt gute Hacker, die in wenigen Wochen gut funktionierenden Code schreiben und mit der richtigen Betreuung und einem kleinen Kickstart in Form eines Basis-Systems an dem sich alles gut debuggen lässt, durchaus in 3 Monaten ihre anspruchvollen Pläne auch fertigkriegen (bei einem durchschnittlichen 14-Stunden-Labortag). Muss der TO selber wissen, ob er einer von der Sorte ist :-) Mit dem Microblaze den Durchsatz zu schaffen, sehe ich nicht so problematisch. Stichwort DMA...die CPU macht dann nur noch den Verwalter und kickt die DMA-Ströme zyklisch an bzw. inkrementiert Ringbufer-Pointer. Mit einer CPU a la "*a++ = *b++" Daten herumschieben sollte man auf einem FPGA sowieso nicht tun. Aber wie gesagt: Das System sollte schon stehen, und der Betreuer muss sich damit auskennen. Wenn letzterer beim Auftraggeber nicht zu finden ist oder wenn, dann keine Zeit hat: no go. Das frustriert dann nur alle Teilnehmer. Da muss man auch die Firmen in die Verantwortung/Pflicht nehmen.
Microblaze?? Niemals. Wir haben in einer Diplomarbeit mal mit dem PowerPC auf dem Virtex 4 einen GbE UDP Stack implementiert. Das hat etwa ein halbes Jahr in Anspruch genommen (keine Zeile VHDL vom Diplomanden, nur EDK) und er musste den Stack selber schreiben, weil der beknackte LwIP viel viel zu lahm war. Der PPC hat dann mit 450MHZ Taktfrequenz, DMA über MCMP, riesigen Puffern und Checksum Offloading in Hardware gerade so 110MB/s an den PC schaufeln können. Da war noch keinerlei Interaktion mit der eigentlichen Hardware im Spiel. Ging auch nicht, weil der Virtex nahezu komplett ausgelastet war. Mit einem MB schaffst du vielleicht mit viel optimieren 100MBit. Bei der Ausgangslage würde ich auch auf etwa 1 Jahr Arbeit tippen, wenn man schnell lernt und sich durch den Xilinx Krempel durchbeißt. In einer Abschlussarbeit in dem Umfang nicht machbar. Brich das ab und mach was anderes. Ganz ernst gemeint. Du wirst damit niemals in der Zeit fertig. Wieso hast du nicht vorher mal gefragt?
> Und auch in meinem Umfeld kennt sich keiner so richtig aus...
Das ist das K.O. Kriterium schlechthin. Gib die Arbeit ab, oder sorge
dafür, dass du "nur" eine Teilaufgabe lösen oder "nur" ein
realisierbares Konzept ausarbeiten musst.
Auch auf das Risiko hin, daß der folgende Hinweis kontraprodultiv ist, da er in eine falsche Richtung führt: Ein Beispiel für die Erzeugung von UDP-Frames per FPGA, allerdings in Verilog und (!) nur für 10 MBit, findet man hier: http://www.fpga4fun.com/10BASE-T0.html
Mit der Zeitschätzung habt ihr bestimmt recht. Das klingt sehr aufwendig. Aber auch eine Arbeit, die das gesteckte Ziel nicht erreicht, kann sehr gut sein, indem man eben erstmal das Gesamtkonzept ausarbeitet und je nach Zeit noch Teilprobleme exemplarisch löst und dann auf Probleme hinweist und eine realistische Zeitschätzung ausarbeitet. Auch ein Fehlversuch kann sehr lehrreich sein.
> indem man eben erstmal das Gesamtkonzept ausarbeitet Das bedarf aber Vorwissen, d.h. sowas ähnliches muss man schonmal gemacht haben. Ohne Kenntnisse in VHDL (insb. einer Menge verbockter FPGA-Designs aka "Design-Erfahrung") wird das nix. Schau doch nur mal, was hier an unzähligen "Mein Code tut nicht das, was er soll"-Postings auftaucht und am Ende wars immer nur ein harmloses, unscheinbares und gaaaanz langsames Signal irgendwo. Nur halt asynchron... Das Framegrabberbeispiel strotzt nur so vor unterschiedlichen Clock-Domains. Wie soll man da vernünftige (effiziente, verständliche, zukunftssichere) Schnittstellen ausarbeiten, wenn man noch nie persönlich in die Sch... gegriffen, tagelang Fehler gesucht und damit ganz tief verinnerlicht hat, was in dem Bereich do's und don'ts sind. Und die Fehler tauchen noch nicht mal in der Simulation auf... > Auch ein Fehlversuch kann sehr lehrreich sein. Aber nur, wenn die Chance besteht, den einen Fehler zu finden. Ansonsten ist es maximal frustrierend, wenn man irgendwann zwischen VHDL-Macken, FPGA-Macken, Tool-Macken, IP-Core-Macken und der eigenen (falschen...) Vorstellung aufgerieben wird. BTW: Ich hab sowas in meiner DA durch. VHDL (im Jahre '95 hatte da KEINER meiner Betreuer eine Ahnung, ein DAler vorher ist schon grandios gescheitert, war dann so eine hättekönntewennte-Arbeit), Xilinx+Synopsys (Dreck meets Müll, der Design-Compiler war bei der Synthese im wesentlichen damit beschäftigt, Stack-Traces für den Crashreport auszugeben), zwei komplexe und brandneue ASICs (u.a. PCI-Bridge von PLX) mit spassigen Bugs, ein rudimentäres Pflichtenheft (aka "soll vier Räder haben und fahren") und völlig unterdimensionierte Workstations. Ich hatte nur das Glück, vorher schon mit Schematic Entry und Xilinx privat garbeitet zu haben und zu wissen, wie man lötet&fädelt. Zwei Monate Verlängerung (=>8 statt 6) waren auch noch nötig. Dann gings so lala und ich war mit den Nerven fertig.
Christian R. schrieb: > Microblaze?? Niemals. Wir haben in einer Diplomarbeit mal mit dem > PowerPC auf dem Virtex 4 einen GbE UDP Stack implementiert. Das hat etwa > ein halbes Jahr in Anspruch genommen Hier haben sie gerade ein Optikprojekt zur Implementierung von Bilddaten im HD-Bereich über GigE. Da sind 3 Leute dran ud 3 Monate geplant und das sind Experten. Ich kann ungefähr abschätzen, wie aufwändig das wird, da ich selber schon X over IP betrieben habe. Je nach Anspruch kann das einige Wochen oder auch Monate dauern, das so zu implementieren, dass es das tut, was man möchte. Wenn man mitgeringer Bandbreite auskommt ist das recht einfach, behaupte ich mal. Aber an die Grenze vom Gigabit Ethernet ranzukommen, ist schon ein Gehaue! In einem FPGA möchte ich das nicht machen. >110MB Das ist ja nicht schlecht, denke ich, zumal der PC am Ende kaum mehr wegschaffen wird. Jedenfalls unter Windows nicht.
> >110MB > Das ist ja nicht schlecht, denke ich, zumal der PC am Ende kaum mehr > wegschaffen wird. Jedenfalls unter Windows nicht. Zumindest Senden in dem Speedbereich geht auch mit den billigen Realtek-GBit-Chips recht gut. Die haben netterweise 2 Sendequeues, keine Ahnung, wofür das mal gedacht war. Die eine Queue kann ganz normal ohne SW-Änderung vom OS bedient werden, die zweite kann man per FPGA mit synthetischen Deskriptoren versorgen.
Georg A. schrieb: > per FPGA mit > > synthetischen Deskriptoren versorgen. Was ist das und wozu sind die gedacht?
60fps wissen wir jetzt. Es fehlen noch die Angaben über die Datenmenge eines Frames. Also wieviel Pixel und mit wieviel Bit Auflösung. Davon hängt es ab ob du mit dem internen FPGA Speicher überhaupt auskommst. oder hab ich das überlesen ...
>60fps wissen wir jetzt.
Weisst du das? Woher?
Quellseitig vielleicht? Aber darstellungsseitig?
S.D. schrieb: > Der Frame kommt häufig... 60fps. Allerdings kann bei dieser Datenrate > auch jedes zweite Bild weggelassen werden. Daher wissen wir das. Ausgabeseitig min. 30 fps schreibt er. Ändert aber nichts dran, dass das unmöglich von einem derart unerfahrenen Diplomanden in dieser Zeit zu erledigen ist.
> > Ändert aber nichts dran, dass das unmöglich von einem derart > unerfahrenen Diplomanden in dieser Zeit zu erledigen ist. Keine Frage. Aber es lesen ja auch noch andere mit ... nicht so eng sehen;) Es würd mich trotzdem noch die Pixeltaktrate und die Mgeabytes pro Frame interessieren.
Ich hab nochmal durchgelesen und so verstanden. Das geht darum Displays (auf Pixelfehler ?) zu überprüfen. Das wäre direkt mit dem FPGA geschätzt einfacher und es müsste nur gut/schlecht an den PC übertragen werden.
> > synthetischen Deskriptoren versorgen. > Was ist das und wozu sind die gedacht? Die Realteks (und eigentlich alle modernen IO-Chips ala USB&Co) arbeiten mit Varianten des Chained DMA. D.h. sie lesen aus dem Speicher eine Struktur (Deskriptor) aus, die Art des Transfer und vorallem die Quell/Zieladresse der Daten im Speicehr beinhaltet. Die Deskriptoren sind dann entweder in einem Array hintereinander oder als verkettete Liste aufgebaut. Wenn man als PCI(e) Gerät selbst Speicher implementiert, kann man die Deskriptoren natürlich auch "on-the-fly" erzeugen und damit den IO-Chips recht einfach Transfers entlocken.
Ich habe vor kurzen ein FPGA Board gefunden, da ist ein Spartan 6 drauf (günstig) und ein Cypress FX3 (USB 3.0) Somit überträgst Du die Daten nicht per UDP sondern über USB 3.0. Ein DDR3 Speicher ist auch schon drauf und es wird auch mit einem Demoprogramm in VHDL ausgeliefert. Demnach ist man fast schon fertig :-) Es sei denn es muss unbedingt über UDP gemacht werden. Ich kann morgen mal den Link posten
Ich habe den Link schon gefunden. Dies ist total geil. Damit sollte in 3 Monaten auf jedenfall etwas Möglich sein. http://www.enclustra.com/en/products/quick-start-kits/mars-pm3-usb3-kit/
Georg A. schrieb: >> > synthetischen Deskriptoren versorgen. >> Was ist das und wozu sind die gedacht? > Die Realteks (und eigentlich alle Danke!
Das board ist sicher nicht übel, wenn es um geringe Distanzen geht. Daten aber quer durch die Halle zu schicken, geht oft nur über vorhandene Ethernet-Einrichtungen. Trotzdem: 360 MBytes/sec sind schon Spitze!
USB 3 geht auch prima über Glasfaser, aber dann "nur" 100m weit.
Bilder sind maximal so ca. 1400x600 60fps 24bit RGB Board ist schon gekauft, da gibt es keinen Spielraum (Board von Trenz mit Spartan 6) Open Source ist leider auch recht wichtig, dafür darf das System aber so einfach wie möglich sein. Die Daten müssen leider über Ethernet raus, das ist das vorgegebene Ziel. Die Daten sollen RAW (quasi als Bytearray) an den PC und nicht auf dem FPGA ausgewertet werden. Da ich schon mal weiß, dass ich eh nicht fertig werde - besteht irgendwie auf "einfache" Weise die Möglichkeit im Rahmen einer Machbarkeitsstudie irgendwie ein Bild in Form von Paketen auf den PC zu bekommen? Würde auch reichen, wenn erstmal 1 Bild pro Sekunde geschickt wird, also was wäre die einfachste Möglichkeit, das System in minimaler Form aufzubauen ohne Rückkonfigurierbarkeit usw.? Da wäre ich über Hinweise sehr dankbar.
http://www.visiononline.org/vision-standards-details.cfm Diverse Hersteller verkaufen auch GigE Vision cores.
Ich bin mir ziemlich sicher, dass ich vor einigen Monaten am Bahnhof eine Zeitschrift in der Hand hatte, in der beschrieben wurde wie man mit einem Mikrocontroller (ohne Ethernet) und ein paar Gattern/Schieberegistern ein transmit-only 10BaseT Ethernet Gerät baut.
hi, mein Einstieg in mein GBIT - Ethernetmodul, war 10MBIT-Sender von fpga4fun.com. Ist in verilog und ich persönlich finde verilog auch anfängerfreundlicher, aber das kann man auch schnell in vhdl übersetzen wenns sein muss. außerdem erklärt er (autor) die grundlagen ganz gut. Wenn du da 1-2 wochen dran sitzt, solltest du dein erstes udp-paket versenden können und mit wireshark sehen können auch als anfänger. und vllt noch ein tipp wovon du deinen prof überzeugen solltest, schafft euch ne chipscope-lizenz an. für den ganzen fachbereich reicht eine kostet 500 € etwa und wird das debbuggen um faktor 1000 oder mehr vereinfachen. das prog is auch ziemlich einfach zu bedienen 1-2 tage einarbeitung. achso noch was bei den datein für das spartan sp601 eval board ist schon ne billige art von Gbit EMAC dabei (als source und bitfile) oder eher eine art gmiicontroller mit preamble-, streamerzeugung und crc32 berechnung. die kann man auf der website von xilinx runterladen, das war mein 2ter schritt. aber ich würde nicht versuchen die evalboard datein zu analysieren bevor du nicht das fpga4fun projekt verstanden hast und zusätzlich dich in die gmii-schnittstelle eingelesen hast (sollte so 2-3 tage dauern). viel glück
Daniel schrieb: > 10BaseT Ethernet das ist aber noch ein bissl was anderes: bei dem tempo kommen noch keine fpga themen hoch wie timing, io, das geht dann in der tat mit einem controller
D.S. schrieb: > Bilder sind maximal so ca. 1400x600 > 60fps > 24bit RGB > Das sind dann bei 30fps 75,6 MByte/sec, wenn ich richtig gerechnet habe. Wenn du das Xilinx SP605 Board hast, da ist scheinbar ein Demo dabei und hier: http://wiki.treck.com/Xilinx_Test_Results.html gibts auch Messwerte für die Übertragungs Geschwindigkeiten. Theoretisch lässt sich vielleicht der VideoDma logic core irgendwie in die Ethernet Demo reinfummeln. Aber keine Ahnung wie groß der Aufwand ist und ob es funktioniert.
> Bilder sind maximal so ca. 1400x600 > 60fps > 24bit RGB Aeh.. 840kPixel ... 60 mal sind 50M Pixel wandeln .. zu 3 byte pro pixel waeren dann ... 150M Byte/s. Heftig. Und wohin sollen die ?
Hallo zusammen (hab mir jetzt endlich mal einen Login zugelegt), ich bin jetzt gerade dabei das Konzept ein wenig umzukrempeln. Mein Plan geht jetzt eher so in Richtung "praktische Machbarkeitsstudie". D.h. ich will es irgendwie schaffen das Bild in der vorgegebenen Zeit (3 bis 3,5 Monate) in Form von Paketen auf dem PC anzeigen zu lassen. Das bedeutet, dass das System nicht ausgereift sein muss, sondern so einfach wie möglich implementiert werden soll. Das Ethernet soll erstmal nur in eine Richtung gehen (Senderichtung), UDP/IP kann gerne feste Adressen haben (gerne auch vorgefertigter Code), als Geschwindigkeit reicht es erstmal, wenn nur 1-2 Bilder pro Sekunde ankommen, der Rest der Bilddaten kann (erstmal) verworfen werden. Hauptsache der Datenstrom kommt erstmal zustande. Wichtig ist noch, dass die Daten in einem externen RAM zwischengespeichert werden. Mein Plan sieht deshalb vorerst so aus, dass ich alles ohne Prozessorsystem in der ISE mache. Freie IP Cores oder Programmbeispiele sollen die Arbeit erleichtern. Den Eingang würde ich über den Xilinx vid_in_to_axi4s Core lösen (habe ich bereits eingebunden), dann sollen die Daten über den AXI4Stream in das externe RAM (mit einem IP Core, der aus dem AXI4 Stream ein AXI4MM macht und vllt. ein weiterer Core, der direkt auf den Speicher zugreift). Dann würde ich eine Instanz selbst schreiben, die den Datenstrom nach dem Infrastruktur IP wieder entgegen nimmt, in einzelne Bilder teilt und dann an die nächste Stelle weitergibt (das ist dann die Sendeeinheit). - Ist das in dieser Form sinnvoll, um die ganze Sache überhaupt erstmal irgendwie umsetzen zu können? - Wie ist das mit den AXI4 IP Cores, die von Stream auf Memory Mapped umwandeln - welcher Core wäre für diese Aufgabe geeignet, ohne dass er von einem Prozessor gesteuert werden muss? (VDMA oder Virtual FIFO oder...? Wie ist das, wenn die Datenbreite (vom Dateneingang ja 24bit) nicht mit der des FIFO IP übereinstimmt? Ist das wichtig?) - Was hat es mit dem MIG Tool auf sich? - Kann dann den Datenstrom vom AXI4Stream dann auf einfache Weise wieder in Signale für den Ethernet Ausgang umwandeln? Danke schon mal für eure Antworten!
>Mit den Xilinx Entwicklungsumgebungen und VHDL habe ich so gut wie keine >Erfahrung das merkt man D. S. schrieb: > Mein Plan > geht jetzt eher so in Richtung "praktische Machbarkeitsstudie". etwas, was ich neuerding soft sehe - gerade bei Anfängern: Es wird nichts mehr gebaut, sondern das Bauen analysiert und die Vorgänge drum herum theoretisch untersucht - dies aber ausgerechnet von denen, die nicht praktisch gearbeitet haben und keinen Überblick besitzen und deshalb nur Informationen aus zweiter Hand sammeln. Daher ist die Studie für die Tonne. Früher haben diejenigen Systeme und Methoden analysiert, die selber 10 Jahre auf dem Buckel hatten. Heute analysieren die 25-jährigen die Welt ud beraten dann Industrie und Management. Gute Nacht! P.S Deine "Machbarkeitsstudie" ist ja schon fertig. Wurde vom Forum hier durchgeführt. Lies das hier: Beitrag "Re: Entwicklung Framegrabber - Aufwand & Umsetzbarkeit?" und die folgenden Beiträge. Du kannst es direkt in Deine Arbeit reinkopieren. (Quellenangabe nicht vergessen)
Hallo Mark, danke für deinen "hilfreichen" Eintrag, aber ich denke du hast vielleicht meinen letzten Beitrag nicht richtig gelesen oder verstanden. Ich hänge nun in dieser Arbeit drin und muss in der vorgegebenen Zeit zu einem Ergebnis kommen. Mein Ziel ist es dabei nicht die Industrie zu beraten sondern erstmal mein Studium fristgemäß abzuschließen. Wie man so ein System aufbauen müsste (mit MicroBlaze-System und AXI Ethernet Core usw.) habe inzwischen verstanden, genauso wie ich aber auch verstanden habe, dass es auf diese Weise in der vorgegebenen Zeit nicht machbar ist, besonders unter den gegebenen Vorraussetzungen. Es geht jetzt hier nicht um ein ausgereiftes System, wie es in Serie gehen würde, sondern darum, dass ich es auf einfache Weise in der Zeit hinbekomme, um eben das Ziel (Bild wird auf PC angezeigt) irgendwie erreiche. Dabei wären mir wirklich kluge Ratschläge ehrlich gesagt lieber. Über die Theorie weiß ich inzwischen genug, so eine Arbeit enthält aber eben auch einen praktischen Teil und den will ich nun zu Stande bekommen. Für den MIG Core habe ich passend zu meinem Board schon ein vorgefertigtes Projekt vom Hersteller, das ich denke ich so übernehmen könnte. Meine Hauptfrage für den Moment ist: Wie bekomme ich die Daten von dem AXI4 Stream in den Speicher, ohne dass der Core dafür von einem Prozessor gesteuert werden muss? (siehe meine Fragen in meinem letzten Beitrag)
an Mark: Vielleicht etwas zu harsch, deine Kritik an den Studierenden. Die Schuld würde ich eher den Bildungsinstitutionen geben. Die Ausbildung wird z.T. immer theorielastiger, während die meisten Studenten dank Bachelor/Master-Wahnsinn immer weniger Zeit haben, Dinge wirklich zu verstehen und detailliert praktisch zu erarbeiten. Aber die Diskussion wollen wir ja hier nicht anreissen. Zu den anderen Fragen: > - Ist das in dieser Form sinnvoll, um die ganze Sache überhaupt erstmal > irgendwie umsetzen zu können? Ich würde mal mit einem ganz simplen Streaming anfangen, ohne Core und ohne AXI-Gefuddel. > - Wie ist das mit den AXI4 IP Cores, die von Stream auf Memory Mapped > umwandeln - welcher Core wäre für diese Aufgabe geeignet, ohne dass er > von einem Prozessor gesteuert werden muss? (VDMA oder Virtual FIFO > oder...? Wie ist das, wenn die Datenbreite (vom Dateneingang ja 24bit) > nicht mit der des FIFO IP übereinstimmt? Ist das wichtig?) > - Was hat es mit dem MIG Tool auf sich? Damit generierst du das DDR2(3) memory interface. > - Kann dann den Datenstrom vom AXI4Stream dann auf einfache Weise wieder > in Signale für den Ethernet Ausgang umwandeln? Ansich schon, dafür gibts auch fertige IPs zur Anbindung eines PHY über RMII o.ä. Aber ohne Soft-Core würde ich keinen UDP-Stack anfangen. Und DMA brauchst du dafür auch. Hier mal 'meine' Einkaufsliste, die ich für eine USB-Lösung brauche: - Vorverarbeitungsmodul - Soft CPU (ZPU) - DMA-Controller, zweikanalig Bei dir käme dazu: - EMAC-Treiber (PHY) - UDP-Engine Im Prinzip ist der DMA nur dazu da, Header von der CPU aus abzuschicken. Alles andere geht bei mir ohne DDR RAM. Das geht im Prinzip mit UDP auch, schau mal, ob du DDR2 vermeiden kannst, das spart dir schon viel Aufwand. Wenn Du jede Zeile als einzelnes UDP-Paket raushaust, solltest Du da zum Ziel kommen. Grüsse!
D. S. schrieb: > Ich hänge nun in dieser Arbeit drin und muss in der vorgegebenen Zeit zu > > einem Ergebnis kommen. Da ist natürlich was dran. Allerdings waren meine Einwände schon ernst gemeint: Das Thema Machbarkeit wurde ja nun hinlänglich behandelt. Die Frage ist nun, was da jetzt noch für ein Lerneffekt bei rauskommt. Fitzebutze schrieb: > Die Schuld würde ich eher den Bildungsinstitutionen geben. Die > Ausbildung wird z.T. immer theorielastiger, während die meisten > Studenten dank Bachelor/Master-Wahnsinn immer weniger Zeit haben, Dinge > wirklich zu verstehen und detailliert praktisch zu erarbeiten. 100% d'accord. Mein Einwand war auch nicht allein in Richtung des Betroffenen gerichtet. Allerdings sehe ich auch hier zwei Themen: 1) Einerseits proklamieren die Hochschulen "praktische" Ausbildung, sind dann aber nicht gewillt und in der Lage, das zu leisten. Haben die dort Xilinx erklärt? Haben sie Simulieren erklärt? Wahrscheinlich nicht. Der Betreuer hat ja offenbar nicht mal einen Überblick. 2) Andererseits macht es keinen Sinn, Studenten konkretes Wissen zu vermitteln, dass nur ein Teil wird brauchen können. Der Sinn der Hichschule ist ein anderer: Grundlagen erklären! Ob man das als Theorie oder Praxis einstuft, bleibt der Interpreation überlassen. Ich für meinen Teil hätte erwartet, dass man dem Studenten erklärt, was Einsynchen ist, wie grundsätzliche Schaltungen arbeiten, wie man eine Simulation mit Testrahmen aufsetzt (dann kriegt er das für jeden beliebigen späteren Anwendungsfall hin, egal ob C oder Verilog). Dann würde eine Abschlussarbeit folgen, die diese gesamten Grundlagen auch abprüft: Messsystem auslegen, ADC dran, SFDR berücksichtigen, Filtern, Dezimieren, Aufbereiten, Speichern und das Ganze auf einem technisch einfachen Pfad. Das aber wird aber nicht gemacht. Stattdessen greift man zu einem Projekt, das viel zu gross angesetzt ist, viel Wissen nicht benötigt wird und münzt es dann noch um in eine theoretisches Analyseprojekt. Da kommen dann immer mehr "Theoretiker" raus mit dünnem Wissen, denen viele Zwischenschritte fehlen. In jedem Fall ist es komplett Banane, einen Studenten mit so einer Aufgabe zuzuknallen, die keinesfalls zu bewältigen ist, weder vom Umfang her noch von der Komplexität her. Wer hat sich das ausgedacht?? Eine "studie" zu dem Thema, wie man das machen könnte, ist etwas komplett anderes. Das hätte man ja von vorn herein so planen können, wobei ich inhaltlich infrage stelle, ob das sinnvoll ist, wenn ein Studi mit einer Abschlussarbeit glänzt, inder er ausgforscht hat, wie man etwas machen könnte. Das grenzt dann wieder an Unterforderung und riecht nach "Theoretiker" der zu realem Arbeiten nicht taugt. So könnten das die Firmen sehen. (und das tun sie!)
Das ist so als würde man von einem Fahrschüler verlangen, eine Studie über optimalen Fahrstil zur Reduzierung des Bezinverbrauchs anzufertigen ;-)
Dr. Schnaggels schrieb: > Das ist so als würde man von einem Fahrschüler verlangen, eine Studie > > über optimalen Fahrstil zur Reduzierung des Bezinverbrauchs anzufertigen und geplant war ja sogar, ein halbes Getriebe zu basteln. Ich würde ohnehin erstmal Lego empfehlen, um zu probieren was geht. Neuerdings gibt es ja sogar Lego für FPGAs: http://embdev.net/topic/266406#2775146
Ingenieur schrieb: > Neuerdings gibt es ja sogar Lego für FPGAs: > http://embdev.net/topic/266406#2775146 Naja, als Ingenieur sollte man eigentlich (selbst als Neuling) in der Lage sein, mit "Lego Technic" zu arbeiten, und nicht auf "Duplo" zurückgreifen müssen... (sorry, OT, werde meinen Schnabel halten)
Hallo zusammen, vielen Dank bis hierher für eure Antworten, Fazit für mich ist: Ich muss so weiter machen und werde versuchen das irgendwie zu schaffen, wenn auch in vereinfachter Form. Für weitere Fragen werde ich weiter(e) Beiträge erstellen, denn hier zu diskutieren, wie eine Abschlussarbeit auszusehen hätte, hilft mir im Moment nicht weiter. Jetzt muss ich da durch. Würde mich freuen, wenn ihr mir auch in Zukunft noch bei der ein oder anderen Frage weiterhelfen könnt. Vielen Dank für die vielen konstruktiven Rückmeldungen!
Mal im Ernst: Du kannst jederzeit Fragen stellen. Wir werden uns bemühen, Dich zu unterstützen. MfG, Dr. Schnaggels
Dr. Schnaggels schrieb: > Du kannst jederzeit Fragen stellen. Wir werden uns bemühen, Dich zu > > unterstützen. Das wird eine lange Danksagung auf dem Deckblatt.
>Das wird eine lange Danksagung auf dem Deckblatt.
Naja, Hauptsache Fußnoten sind dabei ;-)
Und, was ist nun draus geworden? Hast Du das Projekt umgesetzt?
Sicher hat ihn meine Einschätzung geschockt und er ist abgesprungen.
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.