Bei einem SoC sind ja üblicherweise möglichst viele der Komponenten zusammen mit der CPU in einem Chip integriert. Auf welche hauptsächlichen Nachteile würde man eigentlich stossen, wenn man auf so eine Integration verzichtet und stattdessen alle Komponenten von aussen an die CPU anbindet, also einfach mehrere Chips einsetzt? Z.B. Entwickeln eines Kleincomputers mit den üblichen Hauptkomponenten wie CPU (ARM), RAM, SD/MMC, Ethernet, HDMI-Output, SATA, USB, Audio-Output, Mic-Input, ... Also bewährte Standardlösungen von der Stange einfach zusammenstöpseln. Soll ein Otto-Normal-Kleinrechner werden mit Linux-OS, also nicht Realtimefähig oder so. Wäre so eine Lösung am Markt dennoch konkurrenzfähig, oder was wären die Hauptnachteile? Etwas höherer Stromverbrauch?
:
Verschoben durch Moderator
Mutluit M. schrieb: > Wäre so eine Lösung am Markt dennoch konkurrenzfähig nein, ansonsten denke ich du trollst, bei allen "merkwürdigen" Beiträgen. Was fällt dir ein als Nachteil deiner Einzelchiplösung? Mir fällt zuerst ein die größere Menge Plastik um die vielen Chips zu umkleiden, der Platz der auf der Leiterplatte gebraucht wird.
Joachim B. schrieb: > Mutluit M. schrieb: >> Wäre so eine Lösung am Markt dennoch konkurrenzfähig > > nein, Hast du auch eine nachvollziehbare Begründung dafür? > ansonsten denke ich du trollst, bei allen "merkwürdigen" Beiträgen. Trollen liegt mir fern. Oder stört dich evtl. mein nicht-gerade-deutsch-klingender-Username vielleicht? > Was fällt dir ein als Nachteil deiner Einzelchiplösung? Etwas höherer Stromverbrauch habe ich doch schon genannt. Es muss nicht ein Winzling-Rechner werden, darf ruhig eine normale Tabletgrösse erreichen. > Mir fällt zuerst ein die größere Menge Plastik um die vielen Chips zu > umkleiden, der Platz der auf der Leiterplatte gebraucht wird. Na, ich weiss nicht ob das für den Enduser so wichtig wäre, s.a. oben. Ich glaube nicht dass mehr Chips zwangsläufig zu merklich mehr Stromverbrauch und Hitzeentwicklung führen würden. Es geht hauptsächlich um die Funktionalität und Leistung des Geräts.
:
Bearbeitet durch User
Ich finde die Idee eines System-On-a-Chip, nur nicht auf einem Chip, gut. Nennen wir es doch einfach....Mikrorechner.
Walter T. schrieb: > Ich finde die Idee eines System-On-a-Chip, nur nicht auf einem Chip, > gut. Nennen wir es doch einfach....Mikrorechner. Ich hatte vor kurzem ein Gespräch mit einem Produktmanager einer Firma die IP-Cores verkauft. Der schätzte für die Entwicklung eines Rechners wie den Raspberry Pi (also eine SoC-Lösung) eine Hausnummer zwischen 5 und 10 Mio EUR... Da kann unsereiner nicht mithalten, aber ich denke so teuer muss es nicht werden wenn man etwas unkonventionell an die Sache rangeht.
Mutluit M. schrieb: > .B. Entwickeln eines Kleincomputers mit den üblichen Hauptkomponenten > wie CPU (ARM), RAM, SD/MMC, Ethernet, HDMI-Output, SATA, USB, > Audio-Output, Mic-Input, ... > Also bewährte Standardlösungen von der Stange einfach zusammenstöpseln. > Soll ein Otto-Normal-Kleinrechner werden mit Linux-OS, also nicht > Realtimefähig oder so. Du willst den PC neu erfinden und fragst, ob der Erfolg haben könnte? Weiß nicht, was wurde denn aus dem original PC-Konzept?
Nachteile: die Platine wird größer -> kostet mehr es müssen mehr Bauteile bestückt werden -> kostet mehr es sind mehr Lötverbindungen -> höhere Fehlerrate, mehr Ausschuss -> kostet mehr Leitungen sind länger/haben größere Kapazitäten -> müssen langsamer getaktet werden -> schlechtere Leistung Leitungen sind länger/haben größere Kapazitäten -> mehr Stromverbrauch. Mehr Stromverbrauch heißt vielleicht auch teurere Stromversorgung, mehr Aufwand beim Kühlen oder Leistungsreduktion/geringere Taktzahl. Und wenn du dir deinen PC aus vielen Standardkomponenten zusammenstöpseln willst kommen noch der Montageaufwand und mögliche Montagefehler dazu. Viele Fertigkomponenten (=bestückte, getestete Platinen) zusammen sind auch viel aufwändiger als eine einzelne -> teurer Steckverbindungen sind übrigens auch relativ fehleranfällig -> mehr Ausschuss oder mehr Spaß beim Suchen von Fehlern -> kostet mehr Das war nur was mir auf die schnelle eingefallen ist. So, und jetzt kommen wir zu den Vorteilen: hmmm. Da fällt mir irgendwie nichts ein außer "bastlerfreundlich"
Paul schrieb: > Mutluit M. schrieb: >> .B. Entwickeln eines Kleincomputers mit den üblichen Hauptkomponenten >> wie CPU (ARM), RAM, SD/MMC, Ethernet, HDMI-Output, SATA, USB, >> Audio-Output, Mic-Input, ... >> Also bewährte Standardlösungen von der Stange einfach zusammenstöpseln. >> Soll ein Otto-Normal-Kleinrechner werden mit Linux-OS, also nicht >> Realtimefähig oder so. > > Du willst den PC neu erfinden und fragst, ob der Erfolg haben könnte? > Weiß nicht, was wurde denn aus dem original PC-Konzept? Nein, das hier soll mehr eine Konkurrenz zu Raspi & Co werden, ist aber von den Abmessungen her zwangsläufig etwas grösser da man kein SoC einsetzt. Andererseits denke ich ist man mit dieser Lösung flexibler und das Gerät kann Leistungsmässig mehr bieten.
:
Bearbeitet durch User
Mutluit M. schrieb: > Wäre so eine Lösung am Markt dennoch konkurrenzfähig, oder was wären die > Hauptnachteile? > Etwas höherer Stromverbrauch? Das auch, aber das steht erstmal ganz hinten an. 1. Geschwindigkeit Alle Komponenten müssten irgendwie auf den Hauptspeicher zugreifen. Dazu braucht man einen externen Adress-Daten-Bus, wie ihn z.B. ein 68030 oder ein i386 hatte. Verglichen mit heutigen Lösungen wäre der exterm langsam. Das Problem kommt, wenn Du mit der Geschwindigkeit soweit hochgehst, dass Du mit der kleinsten vorkommenden Wellenlänge in die Größenordnung des Schaltungsaufbaus kommst. Du musst also mit den Schaltungen immer kleiner werden, um die Geschwindigkeit heutiger Systeme zu erreichen. Systeme mit Einzelkomponenten waren zuletzt in den 90'ern aktuell. Heutzutage sind die schnellen Verbindungen zwischen Bausteinen Punkt-zu-Punkt-Verbindungen, und zwar Wellenleiter. Da kommst Du mit der Gleichstromdenkweise nicht mehr weiter, da musst Du in Feldern denken. Und so wie Du fragst kannst Du das nicht. Auch für den Hauptspeicher gilt dies. Das Layout einer DDRn-RAM Abbindung an einen Prozessor ist nicht trivial und außerhalb Deiner Reichweite. Auch da hast Du es im Prinzip mit Punkt-zu-Punkt Verbindungen zu tun. Die Aufteilung von RAM-Zugriffe auf verschiedene Bausteine wie früher in den 80'er Jahren ist bei heutigen SPeicherbausteinen nicht mehr möglich. 2. Verfügbarkeit Wegen 1. gibt es vieles gar nicht mehr als Einzel-IC zu kaufen. 3. Preis Der wird nur bei Massenware so niedrig sein, dass er für Consumerware akzeptabel ist. Exotische Lösungen haben auf dem Massenmarkt keinerlei Chance. fchk
Alles gute Einwände, danke soweit! Aber ich denke, ich habe eine Lösung welches die meisten der genannten Nachteile wettmacht. Mehr dazu bald, muss jetzt erstmal dringend einkaufen gehen... :-)
Frank K. schrieb: > Das Problem kommt, wenn Du mit der Geschwindigkeit soweit > hochgehst, dass Du mit der kleinsten vorkommenden Wellenlänge in die > Größenordnung des Schaltungsaufbaus kommst. > > Heutzutage sind die schnellen Verbindungen zwischen Bausteinen > Punkt-zu-Punkt-Verbindungen, und zwar Wellenleiter. Da kommst Du mit der > Gleichstromdenkweise nicht mehr weiter, da musst Du in Feldern denken. Das Thema finde ich jetzt interessant. Was versteht man unter einem Wellenleiter? Ich bin Nichtelektroniker. Ist das so etwas wie, dass man mehrere Signale als Wellen auf ein Signal aufmoduliert und dieses dann über eine Leitung schickt?
Mutluit M. schrieb: > Nein, das hier soll mehr eine Konkurrenz zu Raspi & Co werden, ist aber > von den Abmessungen her zwangsläufig etwas grösser da man kein SoC > einsetzt. > Andererseits denke ich ist man mit dieser Lösung flexibler und das Gerät > kann Leistungsmässig mehr bieten. Größer und leistungsfähiger als ein Pi, Komponenten zum Stecken, was unterscheidet das System dann von einem kleinen PC? Nur, daß Du als CPU einen ARM haben willst? Auch das gibt es im Industriebereich schon.
Mutluit M. schrieb: > Alles gute Einwände, danke soweit! Du könntest versuchen so zu bauen, wie man früher in den 80ern Computer gebaut hat. Dann sollte das machbar sein. Es gibt sogar Leute, die sich aus 74x Logikgattern einen eigenen Computer gebaut haben: https://www.youtube.com/watch?v=0jRgpTp8pR8 http://www.homebrewcpu.com/ Der Preis dafür sind aber hohe Kosten, viel Aufwand und vor allem musst du mit der Taktfrequenz ziemlich weit runter. So 4 MHz im Chip und für die Leitungen noch weniger könnte gehen. Konkurrenzfähig wirst du damit nie, gegen den Raspberry Pi schon einmal gar nicht. Das kann also nur ein Hobbyprojekt sein oder eben ein Geekprojekt wie der Gitatron TTL Computer: https://www.youtube.com/watch?v=6vbI-r5aXJI Wenn du einen schnelleren Computer bauen willst, dann probiere es mit FPGAs. Damit wäre es noch am realistischsten und preislich noch im Rahmen. Ansonsten, wenn es richtig schnell werden soll, dann kommst du um eine eigene SoC Fertigung nicht herum. Tja und da dürften die meisten schon aus finanziellen Gründen frühzeitig aussteigen.
Nano schrieb: > http://www.homebrewcpu.com/ PS: Den Magic 1 kannst du übrigens nachbauen, das nötige Wissen findest du auf obiger Webseite. Dann sparst du dir zumindest in diesem Bereich einen Haufen Arbeitsaufwand.
Nano schrieb: > Du könntest versuchen so zu bauen, wie man früher in den 80ern Computer > gebaut hat. Mit HDMI? Ich lach mich tot....
Also, das Ding muss (natürlich) leistungsmässig besser abschneiden als die Konkurrenz (Raspi, Banana, Orange, und evtl. auch die mit Rockchip-SoCs). In meinem nächsten Beitrag will ich darlegen, wie man das mit so einer Lösung dennoch erreichen kann (muss erstmal meine Gedanken aufs Blatt bringen...)
Mutluit M. schrieb: > In meinem nächsten Beitrag will ich darlegen, wie man das mit so einer > Lösung dennoch erreichen kann Das wird viele interessieren ...
Paul schrieb: > Mutluit M. schrieb: >> In meinem nächsten Beitrag will ich darlegen, wie man das mit so einer >> Lösung dennoch erreichen kann > > Das wird viele interessieren ... Ich sach mal, unser Mutluit ist voller heißer Luft, und spätestens in 2 Tagen kommt er mit dem nächsten Thema daher. Projektvorschläge: - 100GSPS-32Bit-Oszilloskop (mit Arduino) - Laser-Abstandsmessung, 1000m, Auflösung 3nm Ansonsten: Gitbs eigentlich schon neues zum 64Bit-ADC? Ich würde ja gleich Nägel mit Köpfen machen, und einen 256Bit-ADC verwenden. Sind ja nur 4mal soviele Bits und so. Nie wieder Auflösungsprobleme (weil jedem Elektron im ganzen Universum viele LSB zugeordnet sind :-)
Nano schrieb: > Frank K. schrieb: >> Das Problem kommt, wenn Du mit der Geschwindigkeit soweit >> hochgehst, dass Du mit der kleinsten vorkommenden Wellenlänge in die >> Größenordnung des Schaltungsaufbaus kommst. >> >> Heutzutage sind die schnellen Verbindungen zwischen Bausteinen >> Punkt-zu-Punkt-Verbindungen, und zwar Wellenleiter. Da kommst Du mit der >> Gleichstromdenkweise nicht mehr weiter, da musst Du in Feldern denken. > > Das Thema finde ich jetzt interessant. > Was versteht man unter einem Wellenleiter? Ich bin Nichtelektroniker. > Ist das so etwas wie, dass man mehrere Signale als Wellen auf ein Signal > aufmoduliert und dieses dann über eine Leitung schickt? Nein, das ist hier nicht gemeint. Ich versuch es mal einfach zu erklären. Stell Dir vor, Du hast eine Doppelader, also zwei voneinander isolierte Drähte, die parallel von A nach B laufen. Am Ende hast Du ein Licht, am Anfang eine Spannungsquelle mit Schalter. Schalter ein - Licht an. Schalter aus - Licht aus. Das ist die klassische Vorstellung: Schalter ein, es fließt ein Strom, das Licht leuchtet sofort. Der Strom durch die Drähte ist überall gleich, und wenn man den Gleichstromwiderstand des Kupfers vernachlässigt, ist die Spannung innerhalb eines Drahtes auch überall gleich. Diese Vorstellung versteht jedes Kind, und in der Praxis stimmt diese Vorstellung mit der Realität bis zu einer bestimmten Schaltgeschwindigkeit ganz gut überein. Wenn die Signalgeschwindigkeit noch höher wird, dann ändern sich das Verhalten. Die Ausbreitungsgeschwindigkeit wird plötzlich wichtig. Strom und Spannung innerhalb eines Drahtes (wir vernachlässigen immer noch den (ohmschen) Gleichstromwiderstand des Drahtes) sind dann auf einmal nicht mehr über die gesamte Länge gleich, und die Energie des Signals befindet sich nicht mehr im Kupfer, sondern im Raum zwischen den beiden Drähten, d.h. im elektromagnetischen Feld, das durch das Signal erzeugt wird. Wenn man diese Grenze erreicht, wird plötzlich das Leiterplattenmaterial und der gemetrische Aufbau der Leiterplatte (Schichtdicken) wichtig, und die Layoutregeln ändern sich. Das, was vorher einfach eine ideale Verbindung war, wird jetzt ein Gebilde, das durch eine Kette von Induktivitäten und Kapazitäten rechnerisch erfasst werden kann. Ich hoffe, die Idee dahinter ist etwas klarer geworden. fchk
Ich denke nicht dass er trollt, dafür waren die Aussagen zum SATA-Projekt zu fundiert. Eher einfach etwas sehr optimistisch (und zu wenig informiert), aber auch so kommt man manchmal zu guten Ideen. Außer dass man vielleicht nicht gleich den ersten Gedanken veröffentlichen muss. Beweisen könnte er das ganz einfach, die SATA-Patches veröffentlichen.
Mutluit M. schrieb: > Trollen liegt mir fern. > Oder stört dich evtl. mein nicht-gerade-deutsch-klingender-Username > vielleicht? nein alle deine Beiträge jemand schrieb: > Ich sach mal, unser Mutluit ist voller heißer Luft, und spätestens in 2 > Tagen kommt er mit dem nächsten Thema daher. > > Projektvorschläge: > - 100GSPS-32Bit-Oszilloskop (mit Arduino) > - Laser-Abstandsmessung, 1000m, Auflösung 3nm das war mein Gedankengang durch seine bisherigen Beiträge, wie soll man da nicht an Troll denken?
ich schrieb: > Ich denke nicht dass er trollt, dafür waren die Aussagen zum > SATA-Projekt zu fundiert. Eher einfach etwas sehr optimistisch (und zu > wenig informiert), aber auch so kommt man manchmal zu guten Ideen. Außer > dass man vielleicht nicht gleich den ersten Gedanken veröffentlichen > muss. > Beweisen könnte er das ganz einfach, die SATA-Patches veröffentlichen. Erst heute ist das SATA-Spezial-Kabel für den besagten Banana Pi M1 gekommen. Das müsste bis zum Wochenende jetzt klappen. Wie heisst es doch so schön: Gut Ding will Weile haben :-)
Hier also auf die Schnelle meine Vorstellung der Idee einer neuen Rechner-Architektur: Ein schneller Bus welches mit dem höchsten CPU-Takt arbeitet An diesem Bus hängen nur wenige Komponenten, als da wären: CPU, MemoryManager & RAM, und ein I/O-Hub. Der I/O-Hub ist quasi das Herz des Systems. Es sollte lieber nicht fest verdrahtet werden, sondern wie eine auswechselbare Komponente sein. Dieser ist wie gesagt an den Bus angeschlossen, auf der anderen Seite hat es viele Anschlüsse wo alle anderen Komponenten angeschlossen werden können (und nur da). Wie beim SATA-Protokoll können alle angeschlossenen Komponenten über den I/O-Hub angesprochen werden. Und die Komponenten selbst gehen auch nur über den I/O-Hub. D.h. I/O ist zentralisiert. Daher sollte die Bandbreite des Buses so gross wie möglich sein. Die am I/O-Hub hängenden Komponenten haben keinen Zugriff auf RAM und CPU des Systems. D.h. jede Komponente muss seine eigene Mini-CPU und sein eigenes RAM selbt mitbringen (zufern nötig) (ok, macht die Sache etwas teuerer, aber man schaue sich z.B. eine HDD oder SSD mal an: diese haben ja auch ihre eigene Mini-CPU und ihren eigenen RAM und haben kein Zugriff auf das System-RAM). Der I/O-Hub soll mit allen Client-Geschwindigkeiten umgehen können (auto-detect), so dass man beliebig schnelle/langsame Komponenten, auch gemischte Geschwindigkeiten, daran anschliessen kann. So wäre es auch möglich dass man die Komponenten nicht nur über ihre Standardgeschwindigkeiten anschliessen kann, sondern über einen eigenen Interconnect-Protokoll zum I/O-Hub eine viel schnellere Anbindung realisieren kann. Und: man kann so das System beliebig erweitern, und auch uraltäste Geräte und Protokolle könnten an den I/O-Hub angeschlossen werden. Nötig ist nur ein Adapter das auf der anderen Seite ans I/O-Hub angesteckt wird. Es können auch mehrere I/O-Hubs kaskadiert betrieben werden (dadurch mehr Anschlüsse), ganz wie beim USB-Hub. Und: das BIOS des Systems kann man im I/O-Hub unterbringen, so dass beim Booten sofort alle angeschlossenen Geräte ansprechbar sind, z.B. booten von SD/MMC/SATA/USB etc. (alle hängen ja am I/O-Hub) Da der I/O-Hub ein eigenständige Komponente darstellen soll, ist somit möglich dass das System mehrere BIOS'se haben kann :-), je nachdem welcher I/O-Hub direkt am Bus angeschlossen ist (= Root-I/O-Hub). Und: die Bus-Geschwindigkeit solcher Rechner darf verschieden sein, es ist für Datenaustausch unerheblich. Ist bei "normalen" Rechnern ja auch so der Fall. Das stellt somit eine neue Rechner-Architektur dar, mit starker Modularisierung und somit starker Vereinfachung.
Ich fände das interessant wenn man dadurch bessere Peripherie auf das Board bekommen würde. Also z.B. einen guten Audio Codec, HDMI mit ausreichend "Krawumm" für lange Kabel, WLAN mit MiMo & Antennenbuchse, SATA mit DMA zum GBit Ethernet. Eben solche Dinge, die jetzt bei den kleinen Rechnern aufgrund der SoC Integration immer etwas vernachlässigt werden (müssen?).
Also eine handelsübliche CPU mit PCIe, an denn per Bridge alles angehangen wird...
Andre schrieb: > Ich fände das interessant wenn man dadurch bessere Peripherie auf das > Board bekommen würde. Also z.B. einen guten Audio Codec, HDMI mit > ausreichend "Krawumm" für lange Kabel, WLAN mit MiMo & Antennenbuchse, > SATA mit DMA zum GBit Ethernet. > Eben solche Dinge, die jetzt bei den kleinen Rechnern aufgrund der SoC > Integration immer etwas vernachlässigt werden (müssen?). Ja, das geht: du kannst beliebige Geräte in beliebiger Anzahl anschliessen, ist alles Modular und austauschbar (über einen Stecker am I/O-Hub angeschlossen).
:
Bearbeitet durch User
mukel schrieb: > Also eine handelsübliche CPU mit PCIe, an denn per Bridge alles > angehangen wird... Ja, kann stimmen. Kannte solche PCI-Bridges noch nicht; werde mich gleich mal schlau machen. Nachtrag: ahso, du meinst Northbridge und Southbridge beim x86. Nein, es gibt grosse Unterschiede.
:
Bearbeitet durch User
Äh nein. Man nehme einen handesüblichen SOC mit möglichst vielen PCIe Lanes. An diese Lanes können dann Peripherie Bausteine wie Sata, USB, Ethernet usw. angeschlossen werden. Wie in vielen Boards gang und gäbe. Für klassische On-Chip-Interconnects wie AMBA gibts halt keine dedizierten Bausteine. Um in das Thema reinzukommen, schau dir doch mal die ZynqMP Bausteine von Xilinx an.
mukel schrieb: > Äh nein. > > Man nehme einen handesüblichen SOC mit möglichst vielen PCIe Lanes. An > diese Lanes können dann Peripherie Bausteine wie Sata, USB, Ethernet > usw. angeschlossen werden. Wie in vielen Boards gang und gäbe. Ja, das ist anschaulich. Stimmt, ist eine ähnliche Lösung. > Für klassische On-Chip-Interconnects wie AMBA gibts halt keine > dedizierten Bausteine. Um in das Thema reinzukommen, schau dir doch mal > die ZynqMP Bausteine von Xilinx an. Ja, danke für den Hineweis, werde ich machen.
Mutluit M. schrieb: > Ja, das geht: du kannst beliebige Geräte in beliebiger Anzahl > anschliessen, ist alles Modular und austauschbar (über einen Stecker am > I/O-Hub angeschlossen). Ein GHz-Bus, wo man an einem Hub alles austauschen kann? Sorry, aber jetzt wird es wirklich lächerlich. Die übliche Peripherie hat spezialisierte Busse: - I2S für Audio - RGMII für Ethernet - DDR3 für RAM - HDMI oder DSI für Display - CSI für Kamera Sogar für EMMC gibts einen eigenen Bus. Es gibt keinen HDMI-Controller für RGMII. Oder eine DDR3-Audio-Bridge. All diese Busse hat ein normaler Prozessor auch. Kein geistig gesunder Mensch tut Audio an PCI-X. Wie bescheuert ist das bitte, selbste wenn es irgenwie möglich ist?!? Sowieso: Ich halte das Projekt für einen Privatmann für unrealistisch. An meiner leetzten CPU (i.MX6 Quadcore) bin ich allein an der Schaltung 12 Wochen gesessen. Vollzeit. Der Layouter nochmal 6 (für das 10-Lagen Board). Der Linux-Spezialist brauchte nochmal 4 Wochen, bis alle Treiber liefen. Da war zum Beispiel ein Bug im Treiber für den PHY, den hätte ich in 100 Jahren nicht gefunden. Oder die Sache mit dem U-Boot und der DDR3-Kalibrierung, die ich nie so richtig verstanden habe. Selbst die Leiterplatte hat 3 Wochen Lieferzeit, und der Produzent (eine große Firma) erhebliche Vorarbeiten für die SMD-Bestückung zu leisten. Und selbst die haben das für "herausfordernd" gehalten. Sowas macht man nicht "mal so", und schon gar nicht in Kicad oder Eagle. Und Zuhause bestücken tut man das sowieso nicht. Das braucht Planung, und ist in großen Teilen sehr langweilige Fleißarbeit. KEIN Audiocodec oder GBIT-PHY hat ein spannendes Datenblatt, soviel kann ich dir schon einmal verraten ;-) Selbst die Stromversorgung ist eine Herausforderung. Mit Enthusiasmus und übersteigertem Selbstbewusstsein kombiniert mit viel Halbwissen wird man schnell aufgeben.
Ahja, mich ärgert immer wieder dass die CPUs (bzw. SoCs) auf den besagten Boards immer festverdrahtet sind, ebenso RAM. Ich möchte das Mainboard mit mehreren Sockets realisieren, - so dass RAM ausgetauscht, und auch erweitert werden kann, - und auch die CPU sollte austauschbar sein für kompatible CPUs Und auch an Multi-Sockets für mehrere CPUs habe ich gedacht...
jemand schrieb: > Mutluit M. schrieb: >> Ja, das geht: du kannst beliebige Geräte in beliebiger Anzahl >> anschliessen, ist alles Modular und austauschbar (über einen Stecker am >> I/O-Hub angeschlossen). > > Ein GHz-Bus, wo man an einem Hub alles austauschen kann? Hah! Jetzt kommt meine Geheimwaffe zum Ensatz :-) Aus den 1GHz kann man sich einen HiSpeed-Bus mit Faktor 2x bis ca. 16x basteln mit entsprechendem/bezahlbarem ADC/DAC und Modulationsverfahren... D.h. bei jedem Takt würden dann soviele bit übertragen werden, was die Bandbreite entsprechend um den Faktor erhöht. Das ist natürlich für den I/O-Hub angedacht... Ich denke dieser Bus kann alle bedienen, einschl. externe Grafikkarte --> s.a. eGPU via Thunderbird / USB-C...
:
Bearbeitet durch User
Mutluit M. schrieb: > Ich denke dieser Bus kann alle bedienen, einschl. externe Grafikkarte > --> s.a. eGPU via Thunderbird / USB-C... Man liest nur die erste Zeile des Beitrags, dann übernimmt die vom Kokain induzierte Euphorie, oder wie soll man das verstehen? USB-C ist kein Bus, und technisch genau das gleiche wie normales USB. Thunderbird ist kein Bus. Das sind ALLES nur punkt-zu-punkt Verbindungen. Lies dich ein. Schau dir Referenzdesigns an. Denk das durch, und erst dann poste wieder. com i.MX6 Rex gibts sämtliche Unterlagen zum Download. https://www.imx6rex.com/open-rex/ Langsam glaube ich auch an die Trolltheorie, um ehrlich zu sein...
Mutluit M. schrieb: > Aus den 1GHz kann man sich einen HiSpeed-Bus mit Faktor 2x bis ca. 16x > basteln Und du glaubst, das du diese Platine ganz alleine Designen kannst? Mit Leiterbahnen wo 16GHz rueber gehen sollen? Hast du dir mal gedanken ueber EMV gemacht? Such dir erstmal ein Prueflabor die das Testen und lass dir einen Kostenvoranschlag geben.
jemand schrieb: > > com i.MX6 Rex gibts sämtliche Unterlagen zum Download. > https://www.imx6rex.com/open-rex/ Nicht schlecht, aber auch stolze Preise ab $129 aufwärts je nach Modell. Eine Frage dazu: wie gut ist eigentlich deren SATA-Anbindung? Ich meine insb. wie hoch bei dem Board die Schreibgeschwindigkeit auf eine SSD via SATA ist. Kann man schnell testen wie folgt:
1 | mount /dev/sda1 /mnt |
2 | mkdir /mnt/test |
3 | dd if=/dev/zero of=/mnt/test/test.tmp bs=4k count=512k conv=sync |
Thx
Kaj schrieb: > Mutluit M. schrieb: >> Aus den 1GHz kann man sich einen HiSpeed-Bus mit Faktor 2x bis ca. 16x >> basteln > Und du glaubst, das du diese Platine ganz alleine Designen kannst? Mit > Leiterbahnen wo 16GHz rueber gehen sollen? Hast du dir mal gedanken > ueber EMV gemacht? Such dir erstmal ein Prueflabor die das Testen und > lass dir einen Kostenvoranschlag geben. Es ist noch nicht entschieden, welche ADC und DAC hierfür zum Einsatz kommen könnten. Ja, 16x ist schon sehr ambitioniert und wahrscheinlich auch zu teuer. In der Praxis wird es wohl nur ein 4x oder 8x werden.
Mutluit M. schrieb: > Nicht schlecht, aber auch stolze Preise ab $129 aufwärts je nach Modell. Und du glaubst, du bekommst das billiger hin? Allein die Bauteile kosten mehr, wenn du sie kaufst. Erheblich mehr. Schon beim Prozessor bist du mit 50€ dabei (je nach Derivat). Mit RAM dann bei 70€ oder mehr. Dann die restliche Peripherie, und DU bist bei 250€, weil du nicht deren Einkaufskonditionen hast. Falls du die Bauteile bekommst, was ich für fraglich halte. Die SATA-Schnittstelle ist im i.MX6 integriert. Wenn du suchst, findest du bestimmt Benchmarks. Wenn du den Schaltplan angesehen hättest, wüsstest du das. Hast du aber nicht. Ich würde von einem 1GHz Quadcore in der Hinsicht nicht zuviel erwarten. Nochmal: Ein i.MX6 Design (außer möglicherweise Ultra Light) ist für Hobbyisten-Einzekämpfer völlig undenkbar. Das gilt für alle Applikationsprozessoren dieser Kategorie. Ich kenne auch kein Beispiel, was das angeht ;-) Ein Open-Source-Design mit mehreren Leuten ist denkbar, ich halte aber auch das für schwierig. Blabla und Enthusiasmus helfen da nicht, da brauchts Beinarbeit, Durchhaltevermögen und Bereitschaft zum lesen von sehr großen, sehr komplexen Dokumenten. Was du bisher nicht gezeigt hast. Es gibt günstigere App-Prozessoren als den i.MX6 (und schnellere), aber der i.MX6 ist nun einmal einer der am besten dokumentierten.
In diesem Zusammenhang finde ich SSD-Modelle genannt Openchannel-SSDs ohne eingebauten SATA-Controller (sind dadurch auch billiger) interessant, da man die SSD mit einem eigenen Controller welches in Software realisert ist (d.h. NVMe-Treiber) betreiben kann, und somit Geschwindigkeiten jenseits der SATA-Specification erreichen kann: https://www.heise.de/newsticker/meldung/Dumme-SSDs-fuer-grosse-Datenmengen-4132807.html
:
Bearbeitet durch User
jemand schrieb: > Mutluit M. schrieb: >> Nicht schlecht, aber auch stolze Preise ab $129 aufwärts je nach Modell. > > Die SATA-Schnittstelle ist im i.MX6 integriert. Wenn du suchst, findest > du bestimmt Benchmarks. Wenn du den Schaltplan angesehen hättest, > wüsstest du das. Hast du aber nicht. > > Ich würde von einem 1GHz Quadcore in der Hinsicht nicht zuviel erwarten. Wieso eigentlich nicht? Es geht doch nur um SATA-II (300 MB/s). Das sollte doch machbar sein mit 1 GHz, und es handelt sich in deinem Fall sogar um Quadcore... Also, wenn ich so ein Board über den grünen Klee hochloben würde, wie du es hier tust, dann wüsste ich aber ganz genau bescheid über seine Performance-Zahlen. Kannst doch mal auf die schnelle testen. Sind bestimmt viele interessiert zu erfahren wie der auf dem Gebiet abschneidet.
:
Bearbeitet durch User
Mutluit M. schrieb: > Wieso eigentlich nicht? Es geht doch nur um SATA-II (300 MB/s). Das > sollte doch machbar sein mit 1 GHz, und es handelt sich in deinem Fall > sogar um Quadcore... > Also, wenn ich so ein Board über den grünen Klee hochloben würde, wie du > es hier tust, dann wüsste ich aber ganz genau bescheid über seine > Performance-Zahlen. Kannst doch mal auf die schnelle testen. Sind > bestimmt viele interessiert zu erfahren wie der auf dem Gebiet > abschneidet. Du bist mal ein seltsamer Vogel. Ich habe das Board nicht gelobt, und schon gar nicht über den Klee. Das liegt daran, dass ich es nicht habe. Ich habe es lediglich deshalb angeführt, weil es ein gutes Beispiel ist. Aus einem einzigen Grund - die Dokumentation (inklusive) ist frei und ohne Anmeldung verfügbar. Was nicht selbstverständlich ist. In der Hoffnung, es wäre als Literatur hilfreich. Es war verschwendete Tipparbeit... Was sonst noch zu sagen wäre: Du kannst ja gerne mal versuchen, die 300MB/s mit einem i.MX6 abzuhandeln. Wer schon mit solchen Systemen gearbeitet hat, weiß, dass theoretische und praktisch erreichbare Performance nicht identisch sind.
jemand schrieb: > Nano schrieb: >> Du könntest versuchen so zu bauen, wie man früher in den 80ern Computer >> gebaut hat. > > Mit HDMI? > Ich lach mich tot.... Habe ich irgendwo HDMI erwähnt? Ich sagte so wie früher, da gehört HDMI gewiss nicht dazu.
Frank K. schrieb: > ... (gekürzt) > > > Wenn man diese Grenze erreicht, wird plötzlich das Leiterplattenmaterial > und der gemetrische Aufbau der Leiterplatte (Schichtdicken) wichtig, und > die Layoutregeln ändern sich. Das, was vorher einfach eine ideale > Verbindung war, wird jetzt ein Gebilde, das durch eine Kette von > Induktivitäten und Kapazitäten rechnerisch erfasst werden kann. > > Ich hoffe, die Idee dahinter ist etwas klarer geworden. > > fchk Vielen Dank. Jetzt kann ich mir etwas darunter vorstellen.
Mutluit M. schrieb: > Hier also auf die Schnelle meine Vorstellung der Idee einer neuen > Rechner-Architektur: > > Ein schneller Bus welches mit dem höchsten CPU-Takt arbeitet Hier ist der Fehler, das erkenne ich sogar als Nicht Elektroniker. Ich wünsche dir jedenfalls viel Spaß, Bussignale mit einer Geschwindigkeit von > 4 GHZ auf Kupferleitungen zu übertragen. So mal als Tipp, es hat seinen Grund, warum der Takt auf dem PCI oder AGP Bus im Gegensatz dem CPU Takt begrenzt war. Du brauchst schon eine serielle Punkt zu Punkt Verbindung um da mehr zu erreichen. Aber auch hier gilt, nur mal zum Vergleich. Die Datenübertragungsrate beträgt bei USB 3.1 10 Gbit/s. Die Datenübertragsungsrate zwischen der CPU und dem DDR4 PC4-2400 RAM beträgt dagegen 19,2 GByte/s. Dual- und Quadchannel geht wahrscheinlich noch schneller. Man beachte, dass das eine in Bit, das andere in Byte angegeben ist.
Nano schrieb: > Mutluit M. schrieb: >> Hier also auf die Schnelle meine Vorstellung der Idee einer neuen >> Rechner-Architektur: >> >> Ein schneller Bus welches mit dem höchsten CPU-Takt arbeitet > > Hier ist der Fehler, das erkenne ich sogar als Nicht Elektroniker. > > Ich wünsche dir jedenfalls viel Spaß, Bussignale mit einer > Geschwindigkeit von > 4 GHZ auf Kupferleitungen zu übertragen. Also, ich hatte vor einigen Wochen recherchiert und es hiess Kupferkabel haben Kapazität noch bis ins Terahertz-Bereich. Da ist die Rede von "1 Tbps at 100-meter lengths" beim DSL: https://www.assia-inc.com/terabit-dlls-wireless-terahertz-band/ Und: https://en.wikipedia.org/wiki/Terabit_Ethernet So wie ich es verstehe, ist pro Kupferkabel-Adernpaar 100Gb/s bereits realisiert worden, d.h. beim Ethernet mit seinen 4 Lanes bedeutet das 400 Gb/s. Wo würdest du denn das praktische Limit ansetzen für so ein Projekt?
:
Bearbeitet durch User
Mutluit M. schrieb: > Der I/O-Hub Herzlichen Glückwunsch, du hast gerade USB neu erfunden. Netter Trollversuch trotzdem.
Mutluit M. schrieb: > Wäre so eine Lösung am Markt dennoch konkurrenzfähig da fällt mir doch das Wort Beratervertrag ein. Machen wir und dann schaunmermal.
Mutluit M. schrieb: > Terahertz Terabit != Terahertz Leg dir bitte mal Grundlagen in Kommunikationstechnik und elektromagnetischen Feldern+Wellen zu, bevor du weiter von Dingen faselst, die du nicht verstehst. Mutluit M. schrieb: > https://en.wikipedia.org/wiki/Terabit_Ethernet Da geht's um Glasfaser.
● J-A V. schrieb: > Mutluit M. schrieb: >> Wäre so eine Lösung am Markt dennoch konkurrenzfähig > > da fällt mir doch das Wort Beratervertrag ein. > > Machen wir und dann schaunmermal. Das würde ich um viel Geld nicht machen wollen. Ich durfte schon mit solchen Leuten arbeiten. Das wird nichts. Bevor A zuende gedacht ist, ist er schon bei Z, und alles ist gaaaaaaanz einfach. Am Ende kommt nichts heraus.
ich wollte damit auch nur ausdrücken, dass man nicht damit rechnen sollte, ein Forum kostenlos als Think-Tank für sein Gewerbe nutzen zu können. Gut, wer drauf anspringt... schön blöd sach ich nur.
:
Bearbeitet durch User
● J-A V. schrieb: > ich wollte damit auch nur ausdrücken, > dass man nicht damit rechnen sollte, > ein Forum kostenlos als Think-Tank > für sein Gewerbe nutzen zu können. > > Gut, wer drauf anspringt... schön blöd sach ich nur. Du glaubst er wird je irgenwann mit seinem Geblubber Geld verdienen? Ich nicht...
jemand schrieb: > Du glaubst er wird je irgenwann mit seinem Geblubber Geld verdienen? Mit der Sammlung von Features, die irgendwann mal jemand im Labor hinbekommen hat und die an der Grenze des technisch machbaren liegen, privat irgendwas lauffähiges basteln zu können, das auch nur annähernd läuft, wird schon nicht klappen. Solche Ideen hatte man früher in der Runde nach dem fünften Bier und die sind am nächsten Morgen ganz schnell verdrängt worden (sofern man sich noch dran erinnert hat).
Elektrotechnik schrieb: > Mutluit M. schrieb: >> Terahertz > > Terabit != Terahertz Das ist schon klar. > Leg dir bitte mal Grundlagen in Kommunikationstechnik und > elektromagnetischen Feldern+Wellen zu, bevor du weiter von Dingen > faselst, die du nicht verstehst. Ach Die-Alles-Besserwisser-Fraktion; Bremser, Neider, Schlechtmacher wird es immer geben. Liegt leider in der Natur des Menschen... :-( > Mutluit M. schrieb: >> https://en.wikipedia.org/wiki/Terabit_Ethernet > > Da geht's um Glasfaser. Zu deiner Information: Copper im Englischen steht für Kupfer im Deutschen...
:
Bearbeitet durch User
Michael X. schrieb: > Er kann seine tollen Ideen in einen FPGA gießen. Hab ich mir auch schon überlegt, aber können FPGA-Chips mit den hohen Geschwindigkeiten von CPUs von der Stange mithalten? Welche FPGA-Firma würdest du empfehlen?
ABX schrieb: > Mutluit M. schrieb: >> Der I/O-Hub > > Herzlichen Glückwunsch, du hast gerade USB neu erfunden. Könnte man oberflächlich vlt. meinen, aber meine Idee geht weit darüber hinaus: Hohe Geschwindkeiten, starke Modularität, Erweiterbarkeit (keine Limits bzgl. Anzahl Komponenten), starke Vereinfachung, schnelle Entwicklungszyklen weil alles standardisiert und vereinfacht. Und Müllvermeidung durch Langlebigkeit und Wiederverwendbarkeit der Komponenten, ...
:
Bearbeitet durch User
Mutluit M. schrieb: > Michael X. schrieb: >> Er kann seine tollen Ideen in einen FPGA gießen. > > Hab ich mir auch schon überlegt, aber können FPGA-Chips mit den hohen > Geschwindigkeiten von CPUs von der Stange mithalten? > Welche FPGA-Firma würdest du empfehlen? Wikipedia sagt uns: Standard-FPGA: Lattice, Altera (Intel), Xilinx. Vielleicht noch: Achronix Das damit keine GBIT-Busse realisierbar sind, ist auch klar. Das hat zwei sehr gute Gründe: - Lichtgeschwindigkeit - Kausalität Alle "Busse" (wie USB, PCI-X) sind größtenteils asynchrone Punkt zu Punkt Verbindungen, oder sehr, sehr spezialisiert. Wie Speicherbusse - was aber nur bei der Übertragungsgeschwindigkeit GHz schafft, nicht bei Zugriffzeiten (Grund: Lichtgeschwindigkeit und Kausalität...). Bin gespannt, wie unser Euphoriker das Lichtgeschwindigkeitsproblem lösen will. Subraumtransmitter? Kausalitätskorrigierer? Zeitportale?
jemand schrieb: > Bin gespannt, wie unser Euphoriker das Lichtgeschwindigkeitsproblem > lösen will. Subraumtransmitter? Kausalitätskorrigierer? Zeitportale? Flux-Kompensator!
jemand schrieb: > > Bin gespannt, wie unser Euphoriker das Lichtgeschwindigkeitsproblem > lösen will. Erklär doch mal inwiefern das bei den heute und in überschaubarer Zukunft hier auf der Erde gängigen Geschwindkeiten bereits relevant ist bzw. sein wird. Es ist die Rede von Kupferleitungen, nicht LWL.
:
Bearbeitet durch User
Mutluit M. schrieb: > jemand schrieb: >> >> Bin gespannt, wie unser Euphoriker das Lichtgeschwindigkeitsproblem >> lösen will. > > Erklär doch mal inwiefern das bei den heute und in überschaubarer > Zukunft hier auf der Erde gängigen Geschwindkeiten bereits relevant ist > bzw. sein wird. > Es ist die Rede von Kupferleitungen, nicht LWL. Umso schlimmer. Die schaffen nur 0,6C (so ungefähr).
Ahja, das habe ich noch nicht erwähnt, ist aber auch wichtig (Advanced Features): der Admin kann QoS vielfältig programmieren: auf Client-Basis (User) als auch auf Device-Basis kann die Bandbreitennutzung festgelegt werden.
Mutluit M. schrieb: > Es ist die Rede von Kupferleitungen, nicht LWL. [ ] du weißt wie sich elektromagnetische Felder ausbreiten.
Mutluit M. schrieb: > QoS WTF ist QoS? Bisher kein einziges Mal erwähnt. Mal eben ausgedachte für deinen super-modularen PC?
Erik schrieb: > Mutluit M. schrieb: >> QoS > > WTF ist QoS? Bisher kein einziges Mal erwähnt. > Mal eben ausgedachte für deinen super-modularen PC? Oh oh. Das lässt tief blicken bei dir... :-)
Erik schrieb: > Mutluit M. schrieb: >> Es ist die Rede von Kupferleitungen, nicht LWL. > > [ ] du weißt wie sich elektromagnetische Felder ausbreiten. Ja, und?
Mutluit M. schrieb: > Erklär doch mal inwiefern das bei den heute und in überschaubarer > Zukunft hier auf der Erde gängigen Geschwindkeiten bereits relevant ist > bzw. sein wird. Hmm. Dir ist klar, dass es bei GHz keine zwei Chips auf dem Board geben kann, die synchron laufen? Weil elektromagnetische Wellen eine begrenzte Ausbreitungsgeschwindigkeit haben. (=Lichtgeschwindigkeit). Nimm einen Bus. Chip A will bei Chip B eine Register lesen. Also läuft die Elektromagnetische Welle von Chip A zu Chip B, die Antwort als Welle zurück. Das geht nicht in z.B. 0,5ns (2GHz-Bus) über mehrere cm, weil die Welle zu langsam ist. Also begrenzt die Lichtgeschwindigkeit, wie hoch der Takt auf einem synchronen Bus sein kann. Und bei GHZ sind wir bei <10cm. Es gibt noch weitere Probleme. Eines davon ist, dass ein Chip nicht unendlich schnell antworten kann. Jetzt kannst du auf die Antwort warten. Schon ist Essig mit GHz. Oder man macht das Asynchron. Das machen SATA, USB und Konsorten.
jemand schrieb: > Mutluit M. schrieb: >> jemand schrieb: >>> >>> Bin gespannt, wie unser Euphoriker das Lichtgeschwindigkeitsproblem >>> lösen will. >> >> Erklär doch mal inwiefern das bei den heute und in überschaubarer >> Zukunft hier auf der Erde gängigen Geschwindkeiten bereits relevant ist >> bzw. sein wird. >> Es ist die Rede von Kupferleitungen, nicht LWL. > > Umso schlimmer. Die schaffen nur 0,6C (so ungefähr). Kein Problem für Otto-Normal. Du kannst ja LWL nehmen wenn's dir nicht ausreicht... :-)
:
Bearbeitet durch User
Oder die Bandbreite variabel verteilen, dann kann man die GraKa aufs RAM ausbremsen und der Computer erfüllt seinen Zweck. HW Module haben meist externe Echtzeit Anforderungen, die man alle gleichzeitig erfüllen muss. Mutluit M. schrieb: > der Admin kann QoS vielfältig programmieren deshalb ist es gut, dass es Schieberegler dafür gibt!
jemand schrieb: > > Dir ist klar, dass es bei GHz keine zwei Chips auf dem Board geben kann, > die synchron laufen? Weil elektromagnetische Wellen eine begrenzte > Ausbreitungsgeschwindigkeit haben. (=Lichtgeschwindigkeit). ... Ja, sehr interressant und informativ. Danke. Muss ich erstmal verdauen...
Wie wäre es wenn du mal anfängst, den Standard zu schreiben denn du umsetzten willst am besten als eine Refernzimplemtation auf einem FPGA. Dafür bieten sich FPGAs SOCs an, z.B. Xilinx Zynq Ultrascale. 4x Cortex-A53 verbunden mit aussreichenden FPGA Blöcken sollten für das Projekt doch erstmal reichen. Und du kannst vom FPGA mit eigenen Modulen per DMA auf den Speicher und per On-Chip-Connect mit der CPUs und der GPU reden.
mukel schrieb: > Wie wäre es wenn du mal anfängst, den Standard zu schreiben denn du > umsetzten willst am besten als eine Refernzimplemtation auf einem FPGA. > > Dafür bieten sich FPGAs SOCs an, z.B. Xilinx Zynq Ultrascale. 4x > Cortex-A53 verbunden mit aussreichenden FPGA Blöcken sollten für das > Projekt doch erstmal reichen. Und du kannst vom FPGA mit eigenen Modulen > per DMA auf den Speicher und per On-Chip-Connect mit der CPUs und der > GPU reden. Ja, das ist in der Tat sehr interessant. Jedoch würde ich es gerne sehen wenn man die GPU auslagern könnte und über den I/O-Hub anschliessen könnte, wie bei den heutzutage schon gängigen eGPUs, die man ja meistens an Laptops über USB-C/Thunderbird anschliesst.
Mutluit M. schrieb: > Jedoch würde ich es gerne sehen wenn man die GPU auslagern könnte und > über den I/O-Hub anschliessen könnte, wie bei den heutzutage schon > gängigen eGPUs, die man ja meistens an Laptops über USB-C/Thunderbird > anschliesst. Ich frag mich schon die ganze Zeit wie du irgendwelche Hardware über einen Email-Client anschließen willst...
Was hindert die daran einen GPU Baustein als - IP in den FPGA zu packen - Per PCIe an den FPGA zu packen - Per GTH/GTR an den FPGA zu packen - Dir ein beliebgies Protokoll inkl. Transceiver zu überlegen und an den FPGA zu packen? -> Dein Root IO Hub, kannst du dann als IP Core aufbauen! Er könnte im Betrieb geändert werden, je nach Anforderungen.
X2 schrieb: > Ich frag mich schon die ganze Zeit wie du irgendwelche Hardware über > einen Email-Client anschließen willst.. Wenn er dann mal "Thunderbolt" googlet und feststellt, dass das u.a nur PCIe und DisplayPort ist, was er oben schon verworfen hat, stellt sich vllt. ein Lerneffekt ein
mukel schrieb: > Was hindert die daran einen GPU Baustein als > - IP in den FPGA zu packen > - Per PCIe an den FPGA zu packen > - Per GTH/GTR an den FPGA zu packen > - Dir ein beliebgies Protokoll inkl. Transceiver zu überlegen und an den > FPGA zu packen? > > -> Dein Root IO Hub, kannst du dann als IP Core aufbauen! Er könnte im > Betrieb geändert werden, je nach Anforderungen. Ja, danke für die Anregungen. Hier konnte ich weitere Details finden: https://www.xilinx.com/products/technology/high-speed-serial.html https://en.wikipedia.org/wiki/Multi-gigabit_transceiver Ich habe bis jetzt von ADC/DAC geschrieben, aber in der Fachwelt wird sowas im Zusammenhang mit Datentransfers wohl als MGT/GTx und SerDes bezeichnet.
Mutluit M. schrieb: > ... Ich würde zu gern wissen, was wir hier vor uns haben. Einen Troll? Oder doch nicht? Mich erinnert er an dieses Video: https://www.youtube.com/watch?v=BKorP55Aqvg Er repräsentiert alle Rollen gleichzeitig, bis auf den Experten. Irre...
Mutluit M. schrieb: > Könnte man oberflächlich vlt. meinen, aber meine Idee geht weit darüber > hinaus: > Hohe Geschwindkeiten, starke Modularität, Erweiterbarkeit (keine Limits > bzgl. Anzahl Komponenten), starke Vereinfachung, schnelle > Entwicklungszyklen weil alles standardisiert und vereinfacht. Und > Müllvermeidung durch Langlebigkeit und Wiederverwendbarkeit der > Komponenten, ... Also USB.
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.