Hallo liebe MCU-Gurus,
ich studiere Informatik und schreib gerade meine Bachelor-Arbeit zum
Thema: "KI in verteilten Systemen".
Ich entwickle einen Dronen-Schwarm der von einer KI gesteuert wird, die
dezentral durch die Gesammtheit des Schwarms realisiert wird
-- wie eine Art "Schwarm-Intelligenz". Name: Skynet :D
Im Großen und Ganzen läuft eig. alles ganz Gut. -- zumendest wenn man
die Kolataralschäden ignoriert (Fensterscheiben, Drohnen die Selbstmord
begehen usw. ).
Aber zur Sache. Weshalb ich hier bin:
Ich bin auf der suche nach einer guten LCD/LED Display+Controller
Kombination bei der die einz. Pixel "Matrixähnlich" ansteuern kann
(Auflösung grob so um die 50x100).
Und zu dem ein anständiges Framework existiert, das die Display
steuerung "so weit wie hald möglich" vereinfacht.
Und ich mich nich endlos mit Bit-OPs, Bit-Modulationen
,Signallaufzeiten, usw. rumschlagen muss.
Das macht mich echt fertig ^^
Respekt für den der das drauf hat.
Am schönsten wäre sowas in der Art wie:
// PseudoCode:
//(MC über Ports mit LCD-Modul/Controller verbunden):
import ValhallaTec.LcdController;
// innerhalb irgendeiner Objekt-Methode
LcdController controller = new LcdController("LcdModulXYZ");
controller.Initialize();
controller.ActivatePixel(15,59);
MethodeFubar();
controller.DeActivatePixel(15,59);
// Ende!!! xD
OK, so leicht wird's wohl bestimmt nich werden xD, aber so grob in die
Richting evt. ? -- Für verwöhnte Hochsprachen-Entwickler eben ;)
Ich mein da muss es doch irgendwas geben, ich bin doch bestimmt nich der
einzige den das in den Wahnsinn treibt -- Nich mehr lange und ich beiß
in den Tisch.
Mein Problem is, mir läuft so langsam die Zeit davon, ich hab die
Thematik gewaltig unterschätzt und viel zu wenig Zeit dafür eingeplant.
Wenn ich nich bald was finde muss ich mir n'Plan B ausdenken.
Ich könnt eure Hilfe wirklich gebrauchen :)
Danke Kevin.
Du benötigst ein intelligentes Display wie z.B. von ELECTRONIC ASSEMBLY https://www.lcd-module.de/produkte/ediptft.html oder https://4dsystems.com.au/ oder https://nextion.tech/ oder https://www.ftdichip.com/EVE.htm usw...
:
Bearbeitet durch User
Laß den Informatik-Bachelor sausen und bewirb dich für den RTL-Bachelor. Die intellektuellen Anforderungen entsprechen dort deinem Level und der Softwarewelt entsteht kein Verlust. Win/Win.
> Kombination bei der die einz. Pixel "Matrixähnlich" ansteuern kann > (Auflösung grob so um die 50x100). > Und zu dem ein anständiges Framework existiert, das die Display Das ist weitestgehend quatsch. :-) Displays mit 128x64 werden ueblicherweise mit SPI oder I2C angesteuert. DA muss man nichts gross frameworken. Wenn du unbedingt willst kannst du dies hier nutzen: https://github.com/lvgl/lvgl Aber bei so einem kleinen Display ist man gerade an der Grenze wo das anfaengt sinnvoll zu werden. Olaf
Du suchst ein Graphikfähiges terminal, kein stupides Display. Schau dir mal die STM Discovery boards an Beitrag "stm32 display" https://www.mikrocontroller.net/articles/STM32F4-Discovery https://www.mikrocontroller.net/attachment/431734/UserManual_STM32H747_DISCO.pdf
Das ist kein Hexenwerk, ein SetPixel ist die primitivste aller Zeichenprimitiven und das können alle Grafiklibs. Die einfachen TFT mit den integrierten Controllern brauchen eine Init Sequenz und dann schickt man Kommandos um zB die Schreibposition zu setzen und schiebt dann die Pixeldaten in den Controller. Da reichen die billigen Kombinationen aus Mega256 + Aufsteckdisplay oder auch verschiedene Cortex-M 32 Bitter. Bekannte Libs sind ug8 oder AdafruitGFX. Auch die schon genannte lvgl ist super, die setzt aber auch auf setPixel Funktionen auf.
> Das ist kein Hexenwerk, ein SetPixel ist die primitivste aller > Zeichenprimitiven und das können alle Grafiklibs. Nicht ganz. Ein Framework nimmt dir ja schon etwas arbeit ab was die Grafikelemente angeht. Sobald man also komplexere Dinge macht kann das schon nett sein. Aber man muss sich da halt auch erstmal reinarbeiten und bei kleinen Anwendungen wie man sie auf einem 128x64er Display verwirklicht wird sich der Aufwand meist nicht lohnen. Haengt ein bisschen davon ab was man damit macht. > Auch die schon genannte lvgl ist super, die setzt aber auch > auf setPixel Funktionen auf. Jein. Die schreibt, jedenfalls wenn du es fuer dein Display so implementiert, schon blockweise in den Speicher. Allerdings wird man das auch so machen wenn man selber ein Display anspricht. Ich z.B hab immer einen Buffer fuer 128x64pixel im Ram, setze da einzelne Pixel und eine Interruptroutine im Hintergrund prueft ob sich etwas in einem 32Byte-Block geaendert hat und uebergibt denn dann ans Display. Damit wird dann in der Regel beim setzen von 8Pixel nur einmal auf das Display zugegriffen und printf Aufrufe in der Anwendung sind sehr schnell, koennen also ueberrall im Source gemacht werden. Oh..und auch bei lvgl muss man die Lowlevelsachen natuerlich erstmal selber implementieren. .-) Ausserdem braucht lvgl einiges an Resourcen. Das sollte der Microcontroller mindestens 10k Ram haben. Olaf
WoW, danke für die goße Ressonanz :) -- Nach nur 4h, Hammer ^^ Das hilft mir weiter. Jetzt hab endlich mal n'paar gute Anhaltspunkte nach denen ich suchen kann. Und'n ganzen Haufen Links zum durchwühlen :D Die Fragen kommen dann wenn ich das Alles durch hab ^^ Auf jeden Fall, schon mal 2^10 x Danke :) Ihr seid Mega, keep Rockin. ======================================================================== There are only 10 types of people in this world. Those who understand binary and those who don't. ? ========================================================================
Jupiter Q. schrieb: > There are only 10 types of people in this world. > Those who understand binary and those who don't. I really love my Apple computer, but my girlfriend has the best software!
Olaf schrieb: > Nicht ganz. doch, ganz und gar. Zeichenprimitive sind Punkt, Linien, Rechteck, Kreis. Und evtl. noch Zeichenausgabe und Bitmap darstellen. Und alle können mit einem setPixel() realisiert werden. Alle Zeichenprimitive sind ein bisschen Mathematik die die Pixel zwischen Punkten berechnet und dann per setPixel() set. Controllerabhängig kann man evtl. noch optimieren, das beherrschen u8glib und AdafruitGFX auch. Olaf schrieb: > Ich z.B hab immer > einen Buffer fuer 128x64pixel im Ram, setze da einzelne Pixel und eine > Interruptroutine im Hintergrund prueft ob sich etwas in einem > 32Byte-Block geaendert unnötig, dann hast du die Doku zu lvgl bzw. der Treiberimplementierung nicht gelesen oder nicht verstanden. Die Optimierung macht lvgl nämlich selber schon. Die Zeichenfunktionen rendern auf eine virtuelle Tapete die sogar grösser sein kann als der Darstellungsbereich auf deinem Display. lvgl erkennt dann welche Bereiche geändert wurden und ruft für diese die low level Darstellung auf. Das ist im einfachen Fall das Setzen der Pixel für einen rechteckigen Bereich mit setPixel. Weil viele Controller wie ILI und Co. rechteckige Zeichenbereiche mit autoinkrekment unterstützen, kann man die Ausgabe optimieren indem man einmalig den Ausgabebreich setzt und dann in einer Schleife die Pixel für X,Y rausfeuert. Oder als Optimierung alternativ GPU / DMA benutzt wenn es die Hardware hergibt. Es muss ein Framebuffer (einfach oder doppelt) angelegt werden, der muss aber nur min. 10 Zeilen hoch sein. Da ist lvgl sehr clever was das Display aktualisieren angeht. Und lvgl kann kann auch transparente Bitmaps malen. Damit könnte man die Dronen auch als kleine Symbole über das Display fliegen lassen.
Johannes S. schrieb: > Damit könnte man die > Dronen auch als kleine Symbole über das Display fliegen lassen. Auf 128 Pixeln Breite, ja das macht Spass. Bitte mehr solche Vorschläge.
128 Pixel kam nicht vom TO. Der wollte nur 50 x 100 :) Es gibt aber auch bezahlbare Displays mit mehr Pixeln.
JupiterQ schrieb: > Am schönsten wäre sowas in der Art wie: > > // PseudoCode: > //(MC über Ports mit LCD-Modul/Controller verbunden): > import ValhallaTec.LcdController; > // innerhalb irgendeiner Objekt-Methode > LcdController controller = new LcdController("LcdModulXYZ"); > controller.Initialize(); > controller.ActivatePixel(15,59); Jaja, Schwarm-Intelligenz im Drohnenschwarm als Bachelor-Arbeit ... und dann sowas hier wie "ActivatePixel(x,y)". Was hast du in den vergangenen Semestern denn bloß gemacht? Ich geb dir mal nen Abriss in dürren Worten: Also, als allerunterste Stufe braucht man für ein GUI die Lowlevel-Hardware-Treiber, die das Display physisch in Gang setzen - und das sind keine Objekte, die man per new(Tsowieso) kreiert, sondern es sind Hardware-treiber!!!. Das sollte dir klar sein. Da obendrauf werkelt ein GDI, also eine Schicht, die Kringel malen kann, also Linien, Kreise, Flächen, Schrift - und das in verschiedenen Farben/Graustufen und verschiedenen Fonts. Sowas ist auch KEIN Objekt! Da obendrauf sollte dann ein Menüsystem sitzen - und dort kommt dann die objektorientierte Programmierung und ereignisgesteuerte Programmierung dazu. Die Objekte sind die grafischen Elemente, also die diversen Kringel, die sich auf der Bildfläche tummeln sollen. Aber da das Ganze ja in einem µC stattfinden soll und nicht im PC, sollte das Menüsystem im Flash angeordnet sein, so daß man dafür nicht noch extra den ganzen Kram im RAM aufbauen muß. Was Objekte sind, was Methoden von Objekten sind und was Properties von Objekten sind, solltest du selber wissen. Und wie man bei Objekten, bei denen nicht nur die jeweiligen VMT im Flash liegen sondern das ganze Objekt, die den Properties zugrundeliegenden internen Variablen realisiert, das solltest du dir selber ausdenken können. Sowas kann man zu Fuß auch in C machen. Ich hatte vor Jahren eben dieses in der Lernbetty demonstriert. Wenn du also derartiges noch garnicht beherrschst, dann lies dir dort an, wie man sowas machen kann. Von dem, was du im Eröffnungspost geschrieben hast, habe ich jedoch den Eindruck erhalten, daß du noch nicht reif für den Informatik-Bachelor bist. W.S.
> die Ausgabe optimieren indem man einmalig den Ausgabebreich setzt und > dann in einer Schleife die Pixel für X,Y rausfeuert. Oder als Bei den einfachen Display uebergibst du aber immer ein Byte mit 8Pixel. Da ist es schon sinnvoll wenigsten diese 8Pixel am Stueck zu setzen. > 128 Pixel kam nicht vom TO. Der wollte nur 50 x 100 :) Ich hab das mal grosszuegig aufgerundet weil diese Anfaenger ja garnicht wissen mit welchen Zahlensystemen Hardwareentwickler denken. :-) Mittlerweile sind die Display aber so preiswert geworden das ich auch eher empfehlen wuerde etwas mit 240x128 oder 320x240 zu nehmen. Aber dann darauf achten dieses Display immer noch mit spi angesprochen werden kann. Olaf
inglischman schrieb: > Auf 128 Pixeln Breite, ja das macht Spass. Olaf schrieb: > ich hab das mal grosszuegig aufgerundet soso, noch so Chameleon das die Forenuser mit wechselnden Namen verarscht. Olaf schrieb: > Bei den einfachen Display uebergibst du aber immer ein Byte mit 8Pixel. und weil die Displaycontroller Autoinkrement können muss man nicht jede Adresse vor der Pixelausgabe wieder neu setzen, das war gemeint.
W.S. schrieb: > Jaja, Schwarm-Intelligenz im Drohnenschwarm als Bachelor-Arbeit ... und > dann sowas hier wie "ActivatePixel(x,y)". Was hast du in den vergangenen > Semestern denn bloß gemacht? Wieder völlig am Thema vorbei. Wieweit soll die Fertigungstiefe bei der Bachelorarbeit gehen? Chips selber designen und fertigen? Und deine Lernbettys haben dafür auch alle K.I. und sind schwarmfähig? Auch der Rest der Antwort ist purer Anachronismus. Grafiktreiber können sehr gut als Objekt modelliert werden und die Mittel von C++ (Mehrfachvererbung) unterstützen das wie in den genannten Beispielen. Der 'Treiber' bzw. das Displayobjekt setzt sich aus Schnittstellenklasse und Klasse für Zeichenfunktionen zusammen. Damit lässt sich beides unabhängig voneinander implementieren und die gleichen Zeichenfunktionen können mit SPI, Parallel oder µC spezifischem wie FSMC arbeiten. Der Vorteil schon auf diesem Level mit Objekten zu arbeiten ist, das es mehrere Instanzen von Displays geben kann. Fest vernagelte Treiber sind einfach nur Mist. Und von Menusystemen war hier nie die Rede in der Anforderung.
Johannes S. schrieb: > soso, noch so Chameleon das die Forenuser mit wechselnden Namen > verarscht. Nö, ich != Olaf. Das wird jeder Moderator bestätigen können.
Olaf schrieb: > Aber dann darauf achten dieses Display immer noch mit spi angesprochen > werden kann. Warum? Wenn man genügend Portpins frei hat so ist der 16-Bit Parallelbus durchaus vertretbar. Dann kann man alle 16 RGB-Bits mit nur einem Clock raushauen. Das geht deutlich schneller als SPI.
Was lernt man im Studiengang Informatik überhaupt? Mit logischen Denken kann man sich doch das ein/ausschalte einzelner Pixel herleiten. Auch die Wahl der Displayauflösung ist doch nicht auf denken in Binärzahlen zurück zu führen. Aber ich erkenne das der TO wenigstens den Begriff Schwarmwissen versteht, denn etwas anderes will er hier nicht anzapfen - wann sind wir an dem Punkt wo die Bachelorarbeit als Multiple Choice-Test geschrieben wird?
Johannes S. schrieb: > Auch der Rest der Antwort ist purer Anachronismus. Grafiktreiber können > sehr gut als Objekt modelliert werden und die Mittel von C++ > (Mehrfachvererbung) unterstützen das wie in den genannten Beispielen. Witzbold. Wer soll denn da was vererben - bei Hardware? Und hier geht es wohl nicht um's Modellieren, sondern um's reale Machen. Ist ein ziemlicher Unterschied. Und die Lernbetty konnte zwar nicht schwärmen, aber sie konnte Grafik und Sound (jedenfalls soweit, wie die HW reicht). Aber wenn du so gut drauf bist mit dem Modellieren von Displays und der dazu passenden Software auf einem µC und in allen Schichten, dann zeig doch mal, was du tatsächlich kannst mit einem geposteten Projekt hier in diesem Forum. W.S.
Nimm das Nokia Display ;) Das kann sogar ein Arduino prima ansteuern.
Der Unwissende schrieb: > wann sind wir an dem Punkt wo die Bachelorarbeit als Multiple > Choice-Test geschrieben wird? Ich denke mal, der Herr v.Guttenberg hat uns schon vor Jahren den aktuellen Weg aufgezeigt. Aber das soll hier nicht das Thema sein. Es war zu meiner Studienzeit so und wird vermutlichst auch heute noch so sein, daß die akademische Hierarchie so angelegt ist, daß wohl fast jede Arbeit immer nur eine Zuarbeit für die nächst höhere Liga und ein Sub-Themen-Geber für die darunter liegende Liga ist. Deshalb sind Bachelor-Arbeiten nicht so aufzufassen, daß dabei jedesmal etwas wie e=m*c^2 herauskommt. Kurzum: Es ist normal, daß bei Bachelor- und Master-Arbeiten eben etwas kleinere Brötchen gebacken werden. Eben Teilbereiche. Das ist völlig normal. Nun soll der TO eine Arbeit zu "KI in verteilten Systemen" schreiben, was (soweit zu erkennen) trotz des sehr hochgestochenen Titels darauf hinausläuft, ein paar echte ferngesteuerte Drohnen durch einen "Leit"-Mikrocontroller steuern zu lassen, so daß sie irgendwo hinfliegen, ohne sich gegenseitig anzurempeln. Und für diesen Steuer-µC sucht er nun die Komponenten, die er für's Display braucht. Kann man ja verstehen, ist auch nur Mittel zum Zweck, weil sein Thema das gegenseitige Nichtanrempeln sein dürfte. Aber er hat von den Software-Schichten, die zwischen den Kringeln, die er auf der Glotze sehen will und der Glotze selbst liegen, noch keinen Überblick, weswegen er auf den gezeigten hanebüchenen Ansatz kam. Da ist noch ne Menge Arbeit drin, wenn er das alles selber entwickeln will. Aber dazu braucht er erstmal ein Konzept und ein Aufteilen in einzelne abarbeitbare Teile. W.S.
> Dann kann man alle 16 RGB-Bits mit nur einem Clock > raushauen. Das geht deutlich schneller als SPI. Das ist voll cool wenn man Videos darstellen will. Wenn man aber nur etwas Text und eine Messkurve darstellen will ist das viel zuviel Aufwand, EMV, kabel zum Display, einfach kacke. Erst recht fuer einen Anfaenger der nur Informatiker ist. .-) Olaf
W.S. schrieb: > dann zeig > doch mal, was du tatsächlich kannst mit einem geposteten Projekt hier in > diesem Forum. Code in diesem Forum zu posten (bis auf kurze snippets) ist auch Anachronismus, dafür gibt es github & Co. Test mit AdafruitGFX und Portierung auf Mbed für ein STM32F407VE Chinaboard oder LPC1347: https://github.com/JojoS62/mbed-os-example- blinky_STM32F407VE/tree/master/lib/Adafruit_TFTLCD_16bit_STM32-master/sr c Für den LPC mit dem anderen Display wird die Zeile
1 | Adafruit_TFTLCD_16bit_STM32 tft(NC); |
ausgetauscht, alles andere bleibt. das zeigt sowas an: https://www.youtube.com/watch?v=cM-VeylqiPc Unter mbed2 hatte ich die Lib auch schon benutzt: https://os.mbed.com/users/JojoS/code/Adafruit_GFX/ für das Display UC1601S, das dir vielleicht bekannt vorkommt. Nur bei mir funktioniert das mit 128x32. Auch die bekannten OLED funktionieren mit Adafruit, hier mit einem LPC824. Der hat genug Speicher für einen Framebuffer. https://www.youtube.com/watch?v=2aIS2tJxsAA lvgl Treiber für einige STM32 Boards sind noch hier: https://github.com/JojoS62/Test-lvgl/tree/master/libs/Display/lvglDriver noch für lvgl v6, da gibt es mittlerweile auch eine v7 die ich noch nicht angesehen habe. Es funktioniert auch auf dem F407 rasend schnell ohne DMA, damit könnte die CPU nochmal entlastet werden. Für F746 oder F469 habe ich die DMA aus dem BSP für diese Boards benutzt. Kann man rauswerfen und direkt in die nötigen Klassen einbauen, aber bei 1-2 MByte Flash sind solche Optimierungen zweitranging. Und im Netz gibt es reichlich Beispiele für einfache Anwendungen für AdafruitGFX oder u8glib. In den Repos sind auch Beispiele drin die genauso arbeiten wie der TO sich das vorstellt. Der gemeine Arduino User (und das dürften viele tausend oder gar zigtausend sein) weiss sicher nicht was da alles hintersteckt, aber die Anwendung ist sehr simpel und mit ein paar Zeilen Code hat man Punkte gesetzt oder einfache Objekte gezeichnet.
Warum hat hier noch keiner Nextion in die Runde gerufen?
Mitleser schrieb: > Warum hat hier noch keiner Nextion in die Runde gerufen? Wurde gleich in der ersten Antwort genannt. :-)
Aaaah, Brille ist fleckig, bin mal putzen. Philipp S. schrieb: > Wurde gleich in der ersten Antwort genannt. :-)
Ein Nextion ist schon sehr unterfordert mit einem simplen 'setPixel(color)'. Dazu der Overhead den ganzen Befehl erstmal in einen String zu verpacken und im Display zu dekodieren und auszuführen. Oder gibt es auch einen Binärmode für die Ansteuerung? Wenn das Update der Pixel langsam ist und es nicht zuviele sind, dann geht das sicher. Vor allem wenn der Skynet Master ein PC ist kann er einfach per USB angeschlossen werden. Aber über diesen Part hatte der TO ja nichts geschrieben. Und so Drohnen bewegen sich ja im 3D Raum, da ist die Pixelmap doch nur wenig aussagekräftig?
W.S. schrieb: > Was hast du in den vergangenen > Semestern denn bloß gemacht? Offensichtlich hat er mehr C/C++ gelernt als du in deinem bisherigen Leben ;) W.S. schrieb: > Witzbold. Wer soll denn da was vererben - bei Hardware? Mal wieder nichts gecheckt? Es gibt zB ein Interface für Pixelausgabe und das kann verschieden implementiert werden: FSMC, Parabus, HUB75 oder vllt sogar kranke sachen wie Artnet (Ethernet). Wer Treiber für ARM schreibt wie "UART1", "UART2", etc sollte bei sonem Thema einfach mal leise sein. (Son ARM µC/SoC kann ziemliche viele UARTs haben) Wir wissen, dass du nichts kannst, das musst du nicht immer aufs Neue bestätigen!
Mw E. schrieb: > Wir wissen, dass du nichts kannst, das musst du nicht immer aufs Neue > bestätigen! Na vielleicht solltet ihr euch auch mal auf ein Bier zusammensetzen, die Fehde ist doch wohl schon alt genug... Und Informatiker sind auch Leute die Datenbankgedöns, Warenwirtschaftssysteme, ERP CRM und so ein Zeug programmieren. Die haben sicher auch keinen Spaß an Bitschieberei und Compileroptionen einstellen, und trotzdem sind das keine schlechten Menschen. Und wer Software schreiben kann um sowas zu koordinieren der muss für ein popeliges Display wohl auch erstmal umdenken: https://www.youtube.com/watch?v=ggs1XRrCnlE https://www.youtube.com/watch?v=7mISNNEARkA
Johannes S. schrieb: > Na vielleicht solltet ihr euch auch mal auf ein Bier zusammensetzen Lieber nich ;) Ich frag mich eher wo der arbeitet. Bei uns wär der nach ein paar solcher Behauptungen und dem Magic Number Code mit gotos hochkant rausgeflogen. Wenn bei dem selbst memcpy des Teufels ist o0? Zudem gibts ja von vielen hier Gegenwind. Johannes S. schrieb: > Und Informatiker sind auch Leute die Datenbankgedöns, > Warenwirtschaftssysteme, ERP CRM und so ein Zeug programmieren. Die > haben sicher auch keinen Spaß an Bitschieberei und Compileroptionen > einstellen, und trotzdem sind das keine schlechten Menschen. So siehts auch aus, aber das begreift er ja nicht. (Wie so vieles nicht) Die embedded Spezis sind dann "technische Informatiker". Vom Bitwackeln auf Fußpilzebene über Prozessorenbau bis hoch zu Betriebssystem(auf)bau ist da auch alles bei. Nicht zu vergessen sind die ganzen Etechnik Kurse.
Icke ®. schrieb: > Laß den Informatik-Bachelor sausen und bewirb dich für den RTL-Bachelor. > Die intellektuellen Anforderungen entsprechen dort deinem Level und der > Softwarewelt entsteht kein Verlust. Win/Win. Gibt es einen Grund, so beleidigend zu sein?
JupiterQ schrieb: > ich studiere Informatik und schreib gerade meine Bachelor-Arbeit zum > Thema: "KI in verteilten Systemen". > Ich entwickle einen Dronen-Schwarm der von einer KI gesteuert wird, die > dezentral durch die Gesammtheit des Schwarms realisiert wird > -- wie eine Art "Schwarm-Intelligenz". Name: Skynet :D JupiterQ schrieb: > Und zu dem ein anständiges Framework existiert, das die Display > steuerung "so weit wie hald möglich" vereinfacht. > Und ich mich nich endlos mit Bit-OPs, Bit-Modulationen > ,Signallaufzeiten, usw. rumschlagen muss. > Das macht mich echt fertig ^^ > > Respekt für den der das drauf hat. Finde den Widerspruch!
inglischman schrieb: > I really love my Apple computer, > but my girlfriend has the best software! got
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.