Hallo, ich möchte ein Display (800 x 480) an ein Xilinx Spartan 3-FPGA anschließen. Da dies leider ziemliches Neuland für mich ist, wäre es super, wenn Ihr mir helfen könntet: 1) wie schließe ich ein Display hardware-mäßig an ein FPGA an ? 2) welche Steuer-, Synchronisations- und Datensignale benötige ich (RGB Schnittstelle)? 3) wie relaisiere ich die Ansteuerung im FPGA mittels VHDL ? 4) wie sieht das notwendige timing für das Display aus ? 5) Wo kann ich weitere Infos im Netz finden ? Vielen Dank für die Hilfe....
Na da wirst du einiges an arbeit haben. also zu 1.) Das kannst du am besten dem Datenblatt entnehmen. Ich denke mal du hast eine VGA Schnittstelle? Dann stehen im Datenblatt bestimmt auch die Werte für Back porch, front porch etc. Am besten schaust du mal in diesem Userguide vom Spartan3 Starter Kit (ab Seite 21) zu 2.) siehe zu 1 :-) zu 3 ) Tja da ist es ganz wichtig was du machen willst. Möchtest du texte ausgeben oder einzelne Pixel setzen??? Da stexkt einiges hinter. Es gibt aber glaub ich ne VGA ansteuerung in Verilog bei www.opencores.org zu 4.) siehe zu 1.) zu 5.) Also wie schon gesagt einfach mal bei opencores.org. Ansonsten hat www.fpga4fun.com hat ein Ponggame auf denen Seite erläutert. Ist zwar auch Verilog, aber evtl helfen dir ja dort die Erklärungen. Viel erfolg, wenn du noch fragen hast, frag !!! Axel MEineke
also es sollen in erster Linie Grafiken auf dem Display ausgeben werden, die vorher in ein RAM geladen wurden. Das ganze soll über eine RGB-Schnittstelle laufen. Ein Lösung ?
http://www.opencores.org/projects.cgi/web/vga_lcd/overview Das wär was in Verilog. Sowas suchst du doch oder??? Du kannst ja die anderen Module in VHDL programmieren, wenn du noch was extra haben willst. Damit kommt das WebPack zurecht.
Im Prinzip suche ich so etwas. Die Auflösung muß MINDESTENS 800 x 480 betragen (am besten noch frei skalierbar). Allerdings bräuchte ich eine Lösung in VHDL. Danke...
Hmmm... ich denke mal ne komplettlösung frei Haus wird schwer werden. Was spricht gegen die Verilog-Lösung??? du kannst duch auch mit vhdl die module ansprechen. Das ding ist glaube ich sehr gut dokumentiert, so das du nur die schnitstellenparameter ermitteln must. Ansonsten ist das schätzchen von Opencores einfach als Black Box anzusehen. Oder warum möchtest du das ganze in VHDL haben ???
Du kannst es doch sicher per hand umcoden. Ich habe auchmal einen smalltalk sourcecode in C umwandeln müssen, obwohl ich kein smalltalk kann. Für jemand der halbwegs eine ahnung davon hat was er da tut ist das absolut kein problem.
Das Umcoden von Virtex in VHDL ist zwar net so schwer, aber das Verilog-Projekt für die VGA_schnittstelle auf opencores.org ist schon ziemlich umfangreich. Also ich würde dir vorschlagen (TPSK) dich erstmal in den aufbau eines Videosignals einzulesen. Dannach würde ich einfach mal ein paar Testbilder generieren. (z.B. Graukeile die sind einfach mit dem dekrementieren von 255 auf 0 Graustufen zu erzeugen). So kannst du sehen ob deine ansteuerung stimmt. Du willst nur feste Grafiken darstellen die in deinem Speicher liegen oder? Du benötigst keine Zeichensätze? Na dann bist du an deisem Punkt schon fast am Ende. Wie du den Speicher händeln kannst, bin ich auch etwas überfragt. So grosse Datenmengen muste ich bis jetzt noch nicht bewältigen. Aber wenn du die Addressierung der Speicheraddressen verstanden und realisiert hast, ist es vom Graukeil zum fertigen Bild kein grosser aufwand mehr. Ich habe selber mal ein On Screen Display programmiert. Das geht ja in etwa in die Richtung. Wenn du also bei der realisierung mal hängen bleibst, frag einfach. So schwer ist das mit dem RGB-Signal nicht. Wie weit bist du denn bei deiner Realisierung? Für welche Hardware hast du dich entschieden?
Hallo Axel, Du scheinst ja etwas Erfahrung mit der Sache zu haben. Also baue ich mal schwer auf dich. Im Moment bin ich dabei, mich in den Aufbau von Videosignalen zu beschäftigen ....Uff !!! Zurück zu meinen Problem: also ich möchte Grafiken aus einem RAM auf einem Display darstellen. Vielleicht kannst du mir dazu noch ein paar Sachen erklären. Soviel ich weiß, benötige ich ja neben meinem RGB-Signalen, V- und H-Synch noch irgendwelche Koordinaten, wo und wie die einzelnen Pixel meiner Grafik im Speicher liegen (bitte korrigiert mich, wenn ich falsch liege...). Außerdem muß man noch die Spalten und Zeilen des Displays ansteuern. Kannst du mir erklären, wie das funktioniert (speziell die Koordinatensache und die Spalten/Zeilensteuerung) und wie man das realsiert ? Noch ein paar fragen: - Wieviel Verbindungen zum Display benötige ich (3 für RGB, 2 für Synch und 2 für X/Y ????) - Wie sieht die RGB-Schnittstelle zum Display aus ? - wie baue so einfach die Testbilder mit den Graukeilen auf ???? Einfach durch eine autarke VHDL-Realsierung der Sync-Signale und irgendwelcher RGB-Signale ??? - wie sehen genau die RGB-Signale aus - wie sieht das Timing für ein Display aus (X/Y, dazu RGB-Signale und zwischendurch irgendwelche Sync-Signale) Sorry, dass ich noch soviel Fragen habe (blutiger Anfänger in diesem Bereich). Aber ich finde irgendwie keine richtigen Antworten im Netz darüber (Links ???). Mit meiner Realisierung habe ich noch nicht angefangen - ich kenne nur das Soll-Ziel (Grins). Im Moment beginne ich mit der Vorbereitung darauf. Bevor ich aber damit anfange, will/muss ich aber erstmal noch einen Berg voll Fragen beseitigen. Danke und Gruß
Also erstmal zu den einfachen dingen... - Wieviel Verbindungen zum Display benötige ich (3 für RGB, 2 für Synch und 2 für X/Y ????) Du brauchst HSync VSync R, G, B. - Wie sieht die RGB-Schnittstelle zum Display aus ? An den Ausgängen für RGB musst du jeweils, wenn mich nicht alles Täuscht, nen 270 Ohm Widerstand packen. - wie sieht das Timing für ein Display aus (X/Y, dazu RGB-Signale und zwischendurch irgendwelche Sync-Signale) WICHTIG ist das du alles in FSM realisierst (Statemachine). So kannst du gleich die Position des Bildpunktes ermitteln. Hsync und Vsync sind so auch am besten umzusetzen. - wie sehen genau die RGB-Signale aus Das RGB Signal kannst du am besten mit 8bit je Farbe realisieren. Ich weiss ja nicht wie viele Farben dein Bild hat. Die position musst du versuchen geschickt mit dem Speuicher zu verknüpften. Ich habe es mit dem Blockram realisiert. Aber du brauchst ja mehr Speicher oder? Also bei deinem SRam kann ich dir leider nicht all zu sehr behilflich sein... noch nicht. Also ich habe viel Text ausgegeben und habe den Blockram von der breite so dimensiooniert, wie ein Zeichen breit ist... in meinem Fall 16 bit. War das zu verwirrent geschrieben? Wenn ja frag noch mal. Also keine Angst, ich kann dein Leiden nachempfinden. Wenn du nicht mehr weiterkommst müssen wir sonst mal das Telefon konsultieren. Das ist sonst doch etwas viel zu tippen. Ich glaube teilweise ist das auch sau schwer zu verstehen was ich hier tippe :-(. naja die E-Mail steht ja oben drin. Good Luck Axel
Hi schau mal hier rein http://www.tkk.fi/Misc/Electronics/faq/vga2rgb/calc.html Wähle mal VGA 640x480 aus, dann hast du folgende Werte: Pixelclock = 25.17 MHz, der VGA Code sollte also mit 25 Mhz getaktet werden. Bei jedem Takt muß also der HCounter -> Horizontal Counter um +1 inkrementiert werden. Gehe zu Punkt 3. und drücke Button Calculate. Gehe zu Punkt 4. dort siehst du das der HCounter bis 800 laufen muß, danach wird VCounter -> Vertical Counter +1 inkrementiert bis er bei 524 zurückgesetzt wird und ein Bild fertig ist. Die Werte 800x524 sind also die absoluten Counter Werte um ein 640x480 VGA Bild mit 60.04 Hz Bildwiederholrate zu erzeugen. So nun zerlegen wir die 800x524 in die einzelnen Bereiche, sprich Bild + Back Porch + Sync Pulse + Front Porch. Egal ob Horizontal oder Vertikal das Timing enthält immer 4 Abschnitte. Normalerweise zuerst das Front Porch == Schwarzer Rand Links am Bild, dann Bilddaten selber, also 640 Horizontal Pixel und 480 Vertikale Zeilen, dann Back Porch == schwarzer Rand Rechts und als vierten Teil der Synchronizations Puls. Ich handhabe es aber so das wir die 4 Abschnitte im VHDL anders gruppieren. 1.) Bild 2.) Back Porch 3.) Sync Pulse 4.) Front Porch Das hat den Vorteil das die Counter -> HCounter und VCounter bei 0 beginnend sofort das Bild darstellen, ergo solange HCounter < 640 ist werden Pixel dargestellt, so lange VCounter < 480 ist werden Bildzeilen dargestellt. So die Werte für Front/Back Porch und Sync Pulse findest du auf der obigen WEB Seite. Vereinfacht sieht es also so aus: 1.) mit einem Takt von 25.17 MHz inkrementiere HCounter 2.) solange HCounter < 640 gebe an R,G,B die Pixel aus, setze HSync auf 1 3.) solange HCounter >= 640 und HCounter < 640 + Back Porch, gebe schwarze Pixel aus, setze HSync aus 1 4.) solange HCounter >= 640 + Back Porch und HCounter < 640 + Back Porch + Sync Pulse, gebe schwarze Pixel aus und setze HSync auf 0 5.) solange HCounter < 800 ist gebe schwarze Pixel aus, setze HSync auf 1 6.) wenn HConter >= 800 dann setzen HCounter = 0; 7.) bei Flanke HSync von 1 auf 0 inkrementiere VCounter 8.) solange VCounter < 480 gebe Pixel aus und setze VSync = 1 9.) solange VCounter >= 480 und VCounter < 480 + Back Porch gebe schwarze Pixel aus und setze VSync = 1 10.) solange VCounter >= 480 + Back Porch und VCounter < 480 + Back Porch + VSync Pulse gebe schwarze Pixel aus und setze VSync = 0 11.) solange VCounter < 524 gebe schwarze Pixel aus und setze VSync = 1 12.) wenn VCounter >= 524 setze VCounter = 0. Also hast du minimal zwei Processe. Eine der mit Clock = 25 MHz getaktet wird und immer HCounter inkrementiert bis er 799 ist. Und einen zweiten der durch HSync getaktet wird und immer VCounter inkrementiert bis er bei 524 überläuft. Solange HCounter < 640 und VCounter < 480 ist gibst du die RGB Werte der Pixel aus. Dazu nimmst du einen Addresscounter der jedesmal um RGB Bits inkrementiert wird. An der Speicheraddresse dieses Addresscounters stehen im SRAM deine Bilddaten, linear und sequentiell mit 640 Pixel zu 480 Zeilen. So bald HCounter >= 640 oder VCounter >= 480 ist gibts du grundsätzlich Schwarze Pixel aus und der Addressconter wird NICHT inkrementiert. Alternativ kannst du natürlich auch VCounter || HCounter als Addresszeiger benutzen, wenn du zb. mit 512 oder 1024 Pixeln pro Zeile arbeitest. Solange HCounter >= 640 + HBack Porch und HCounter < 640 + HBack Porch + HSync Pulse ist wird HSync auf 0 gesetzt, oder eben in invertierter Ansteuerung von 0 auf 1 gesetzt. Das hängt vom Monitor ab. Das gleiche Schema gilt für VCounter, VBack Porch, VSync Pulse. Ist also relativ einfach die ganze Sache, problematischer ist der gemeinsamme Zugriff auf den Display SRAM. Gruß Hagen
Hallo Axel, erstmal Danke für deine Hilfe. Also nochmal zurück zu deinen Antworten. Die Realisierung mit der Statemachine habe ich schon ein paar mal gelesen. Kannst du mir das etwas genauer erklären ? Mir sagt, dass überhaupt nichts. Hast du oder jmd. ein Beispiel dafür, wie soetwas auszusehen hat (evtl. deine Blockram-Realisierung)? Gibt es auch noch andere Realisierungsmöglichkeiten, wie ich eine Grafik auf einem Display anzeigen kann (besonders die x/y-Position, Sync etc.)? Im Moment beschaffe ich mir einige Grundlagen über Bildsignale etc. Dabei werden sich bestimmt noch einge Fragen ergeben. Evtl. würde ich auch auf dein Angebot, dich einfach mal anzurufen, zurückkommen. Also dann viele Grüße TPSK
Noch eine weitere Frage: Wie lade bei einem FPGA eine Grafik in ein RAM ? Wie spreche ich das RAM anschl. wieder an ? Kennt ihr irgendwelche Links, VHDL-Modelle, Literatur mit Realisierungen etc. Danke....
Und meine Recherche geht weiter... Um eine Grafik auf dem Display auszugeben, bräuchte ich doch im prinzip so ein Gebilde wie in der angehängten Grafik, oder ? Hat irgendeiner eine Idee, wie man das ganze mittel VHDL realisiert ? Die X/Y-Signale steuern doch die Pixel der Grafik im Speicher. Wie muss ich mir das vorstellen ? Also ich lese Pixel für Pixel aus dem Speicher. Jedes Pixel besteht aus 3 RGB-Werten, die ich dann unter korrekten Synch Pixel für Pixel über meine RGB-Leitungen an das Display schicke. Stimmts ? Bitte korrigiert mich....
So und nun noch mal zur State Machine.. .Wo liegt a dein Problem??? Grundsätzlich im aufbau einer FSM oder an dem genauen Aufbau??? Ich habe irgendwo noch ne Statemachine die ich mal für ein 5 MegaPixel disblay erstellt habe. Hier schmeisst er dir auch gleich die x und y Koordinate aus. Würde dir das was weiterhelfen? Dann muss ich mal schauen ob ich das irgendwo finde. Ansonsten mus ich noch mal überlegen ob ich das erneut erstellen kann. Mit deinem Speicherproblem kann ich dir leider nicht viel weiter helfen. Da hast du aber ja im anderen Thread gute und kompetente leute an der Hand.
Also das Problem ist grundsätzlich die State Machine. Ich habe keine Ahnung, wie so etwas funktioniert bzw. aufgebaut ist. Es wäre echt super, wenn du mir dein Beispiel mal schicken könntest (hoffe, du findest es noch...). Das wäre klasse. Also die X/Y-Position beschreiben die Koordinaten jedes Pixels meiner Grafik. Wie "liegt" die Grafik im Speicher (erstes Pixel oben links hat Koordinate 0,0 und belegt die ersten 24 Bits, also je 8 Bit für RGB ??? Dann das 2. pixel usw.) Wie bekomme ich eine Grafik in den Speicher, also wie speichere ich eine Grafik (welches Format)? Kannst du mir da helfen. Danke für deine Unterstützung. Gruß
Hallo TPSK also ich würde deinen Display-Inhalt im RGB-Format in drei SRAMs von je 512kByte abspeichern - quasi für jeden Farbkanal ein SRAM. Da dein Display 800x480 Pixel hat, brauchst du davon sogar nur 384kByte. Die SRAMS schließt du dann allesamt an den gleichen Adressbus. Damit wird gewährleistet, dass du für jedes Pixel auch den richtigen RGB-Wert. Die drei Datenbusse zu je 8Bit schließt du dann an deine A/D Wandler für die VGA-Ausgabe an. Falls du willst, kann ich dir da mal 'n Layout schicken wie wir das hier schon seit 'nem Jahr benutzen. VHDL-Code kann ich dir allerdings aus wettberbs- und lizenztechnischen Gründen nicht geben. Ein TFT-Display haben wir jedenfalls mit diesem Board auch schon angesteuert. Hoffe ich konnte dir weiterhelfen ...
@ Michael... Oh die ansteuerung würde mich auch interessieren. Momentan bin ich in sachen SRam ansteuerung noch nen Noob. Kannst dzu das Layout hier im Forum posten?
@Michael... auf jedenfall bin ich an dem Layout interessiert (die Lösung klingt interessant). Wäre super, wenn du es mir schicken könntest oder hier posten könntest. Gruß TPSK
@ Axel & TSPK ist das Layout für unser XCV100E-Board. Hoffe man kann noch was drauf erkennen. Ist nämlich ein A3-Blatt was ich nur abfotografieren kann wegen mangelnder scan-hardware ;) Was euch evtl. besonders interessiert ist alles was an Pin 3-66 hängt. Die VGA-Treiber sind allerdings nicht mit auf diesem Schematic. Diese befinden sich auf einer anderen Platine, die über die 40poligen Steckverbinder "Huckepack" auf die Mutterplatine gesteckt wird. Die Speicherdaten haben wir entsprechend im FPGA "durchgeschliffen" ... naja werde aus dem Schaltplan schlau wer kann und muss :-P Ich stehe euch aber gerne fuer Fragen diesbezüglich zur Verfügung
Donnerschlag... gute auflösung .-) Da kann man ganz gut ranzoomen. Wenn ich mal Zeit habe werd ich mirdas mal zu gemüte führen. Danke dir.
N'abend habe nochmal in unser Archiv geschaut und das hier gefunden (siehe Anhang). Du hattest doch gefragt wie man ein VGA-Display an den FPGA anschließt. Hier hast du den 3x8-bit DAC für die 3 Farbkanäle. Du kannst an die 15Pin SubD Buchse dann jedes TFT, jeden CRT oder ähnliche Geräte mit SUBD-Eingang anschliessen. Hoffe das hilft dir bei "Wie anschließen?" weiter ...
Erst mal vieln Dank für eure Unterstützung (war/ist große Hilfe für mein Projekt). Besonderen Dank an Axel M. ;-) Jetzt aber genug des Dankes und der Grüße und zurück zu meinem Problem. OK, das Prinzip zur Erzeugung der Synch-Signale etc. habe ich jetzt soweit verstanden. Allerdings habe ich noch einige kleine Fragen: 1) Wie berechne ich die Werte für - HCounter - VCounter - Back Porch + Sync Pulse + Front Porch etc. für bestimmte Display-Auflösungen ? -> Formel ? 2) Ich benötige zusätzlich X/Y-Positionen, die die jedes Pixels meiner Grafik im Speicher beschreiben. - Wie "liegt" die Grafik im Speicher (erstes Pixel oben links hat Koordinate 0,0 und belegt die ersten 24 Bits, also je 8 Bit für RGB ??? Dann das 2. pixel usw.) - Welchen Speicher benutzt man am besten und warum (DDR-SDRAM, SRAM, etc.)? - Wie bekomme ich eine Grafik in den Speicher, also wie speichere ich eine Grafik und lade sie in einen Speicher ? Ist mir noch unklar. - Irgendwelche Beispiele zur Realisierungen in VHDL ? Vielen Dank
>>Wie berechne ich die Werte für .... http://www.tkk.fi/Misc/Electronics/faq/vga2rgb/calc.html http://xtiming.sourceforge.net/cgi-bin/xtiming.pl sollte ausreichend sein. Gruß Hagen
Ja, die Seiten sind schon echt prima, aber ich bin an Formeln zur Berechnung der Werte interessiert. siehe: Fragen 1) und 2) Gruß...Danke !!!
Hi... schau dir mal den VHDL Code, den ich dir geschickt habe an. Da wird automatisch auch immer der x und y Wert ausgegeben. >- Wie "liegt" die Grafik im Speicher (erstes Pixel oben links >hat Koordinate 0,0 und belegt die ersten 24 Bits, also je 8 Bit für >RGB >??? Dann das 2. pixel usw.) Genau so ist es. Du solltest jeden Pixelwert einzeln abspeichern. So wie du es selbst beschrieben hast, ist es schon meinmer meinung nach die beste Lösung. (siehe BMP Bilder ohne Header) Zum Thema Berechnungsformeln muss ich auch grad passen. Schau mal nach VGa spezifikation oder der gleichen im Internet. Evtl hilf dir das weiter.
@TPSK >- Wie "liegt" die Grafik im Speicher (erstes Pixel oben links >hat Koordinate 0,0 und belegt die ersten 24 Bits, also je 8 Bit für RGB >??? Dann das 2. pixel usw.) > >- Welchen Speicher benutzt man am besten und warum (DDR-SDRAM, SRAM, >etc.)? siehe mein Beitrag gleicher fred weiter oben http://www.mikrocontroller.net/forum/read-9-184389.html#187983 um nocheinmal auszuholen/zusammenzufassen: Also du wirst kaum einen Speicher mit 24bit Organisation finden. Daher empfehle ich dir entweder zwei asynchrone SRAMs zu je 16bit (wovon im ersten zwei und im zweiten nur ein Farbkanal zu je 8bit abgelegt ist) oder drei asynch. SRAMs zu je 8bit ... halt fuer jeden Farbkanal einen. >- Wie bekomme ich eine Grafik in den Speicher, also wie speichere ich >eine Grafik und lade sie in einen Speicher ? Ist mir noch unklar. Wie bekomme ich die Milch ins Glas? Nee, Scherz ;). Deine Bildinformation musst du dir entweder von extern (z.B. einem Flash oder RS232) holen, oder du generierst dir halt selbst ein Bildchen (weiß jetzt nicht so genau was du machen musst/willst). Für das WIE speichern solltest du dir mal ein Datenblatt von einen SRAM durchlesen. Da sind die Schreib- und Lesezyklen eigentlich gut dokumentiert. SD-RAM/DDR-RAM und generell alle synchronen RAMS würde ich dir als Anfänger nicht empfehlen, da du alleine hier Wochen ins Land gehen lassen kannst, um die Timings und Ansteuerung in einem FPGA zu implentieren. gruß Michael
Hey schaut mal bitte in diesen Forum-Beitrag: http://www.mikrocontroller.net/forum/read-1-193289.html#new Ich habe da noch ein paar Fragen... Gruß
Mein Tip an dich: erklaer mal Leuten hier (evtl. in einem separaten fred) was genau du vorhast und was fuer Hardware dir zur Verfuegung steht. Habe jetzt in deinem anderen thread zur Display-Ansteuerung gerade gelesen, dass du eigentlich ein digitales Display verwendest. Da kannst du naemlich schon mal die Haelfte meine Postings hier in den Skat druecken, weil die nicht wirklich zur Problemloesung beitragen, da ich dachte, dass du ein stinknormales VGA-Display mit RGB-Eingang hast. Und ich kann mich leider nur Rufus anschließen: Nutze mehr die Dokumentationen/Datenblaetter. Dadurch verringern sich deine Fragen alleine um die Haelfte ... Gruss PS: bring mal hier ein wenig mehr Durchblick[TM] in die Kiste Du hast jetzt hier schon 4 oder 5 freds aufgemacht, die sich alle irgendwie ums gleiche Thema drehen. aber ich steig da langsam nicht mehr durch
Hi... na da muss ich mich dem Michael anschliessen. Ich verleir so langsam auch den durchblick. Das hätte man doch super bei den beiden threads belassen können. UIch denke es fehlen noch viele Basics. Zum beispiel würdest du die Probleme mit dem Coden bestimmt selber lösen können, wenn du dir mal die FSM reinziehen würdest. Dann brauchst du auch keine Codeschnippsel. Ach ja und aus eigener Erfahrung kann ich nur sagen, das die Displays gerade in TFT Bereich immer mindestens die Daten für Hsync VSync, oder wie es auch immer genannt werden, zu finden sind. Wär doch schlimm wenn da keine Infos zur Verfügung stünden. Was dich jetzt aber nicht von fragen abhalten soll... :-). Oder ist die beschreibung deines Auftraggebers so schwammig? Sowas kenne ich ja leider auch. Aber da hilft nur penetrantes Nachfragen...
OK, Ihr habt wahrscheinlich recht. Ich werde mich jetzt erstmal mit den Basics beschäftigen...(Datenblätter durchforsten, timings studieren etc.) Und trotzdem muß ich sagen, dass alle Eure Beiträge mir (als blutiger Anfänger im Ansteuern von Displays) schon für das Verständnis enorm weitergeholfen haben...VIELEN DANK dafür. Bevor ich jetzt die nächsten Fragen stelle (ganz abgeschreckt habt ihr mich noch nicht ;-), werde ich mich noch etwas intensiver mit dem Thema beschäftigen. Wahrscheinlich kann ich dann auch meine Fragen präzisieren und minimieren. Ich weiß ja auch, dass Ihr recht habt, aber manchmal sieht man halt nur einen großen Berg vor sich und weiß gar nicht, wo man anfangen soll (...zu fragen). Dennoch bin ich immer offen für weitere Beiträge zu meinen bereits gestellten Fragen. Also dann Gruß
Bitte 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.