Hallo Forum, die aktuellen ATtiny13 gibt es ja schon ab 60 Cent (War zumindest das billigste was ich gesehen habe), da kam mir die Idee, viele dieser Controller über einen gemeinsamen Bus zu verbinden und Cluster Computing zu betreiben. Ich habe schon die ATMega-Reihe sehr rechenintensive Dinge abarbeiten lasse, wie diesen Algorithmus(Ich glaube er heisst Sieb des Erastothenes oder so) und ein einzelener Controller hat an einer größeren Startzahl schon mal gut 30 sec. gearbeitet. Meine Frage an euch Experten: Wenn man noch größere Primzahlen ausrechnen will, hilft es viele kleine Controller die Arbeit machen zu lassen? Bei den Preisen würde es mich schon mal jucken, mein privates Cluster zusammenzuschustern ;) Was haltet ihr von dem Vorschlag? Hans
@ Benutzer (Gast)
>Was haltet ihr von dem Vorschlag?
Nichts. Viel zu wenig Rechenpower auf einem Fleck. Sowas macht man mit
Hochleistungs-FPGAs, und auch dort muss man zusehen, dass man nicht
zuviel Resourcen für die Kommunikation und Datenaustausch zwischen den
parallelen Recheneinheiten verbraucht.
Hallo, versuche mal den Energieverbrauch auf Attiny umzurechnen: http://code.google.com/p/primesieve/ Zitat: Intel Core i7-920 , 4 x (2.66GHz, 32K L1 Data Cache) Max TDP 130 W Primzahlen bis 10^12: 37,607,912,018 in 127.65 s Das sind 8 Milliarden Zahlen pro Sekunde Ist wohl nicht möglich, denn man muss mit Primzahlen bis 1^6 sieben, da fehlt es an Speicher. Zum sieben braucht es einfach viel Speicher.
Benutzer schrieb: > Was haltet ihr von dem Vorschlag? Es gibt spezielle CPUs für so etwas, sog. "Number Cruncher". Ein 8Bit-Microcontroller ist nicht gerade ein Number Cruncher ;)
Falk Brunner schrieb: > Nichts. Viel zu wenig Rechenpower auf einem Fleck. Sowas macht man mit > Hochleistungs-FPGAs, und auch dort muss man zusehen, dass man nicht > zuviel Resourcen für die Kommunikation und Datenaustausch zwischen den > parallelen Recheneinheiten verbraucht. Im Bezug auf professionellen Einsatz hast du ganz sicher Recht. Aber wenn es drum geht, ein Experiment zusammenzustellen, mit dem man das Aufteilen einer Aufgabe auf verschiedene Prozessoren und damit die Grundlagen von Cluster-Rechnern lernen und selber erfahren kann, finde ich die Idee gar nicht so schlecht.
Warum nehmt Ihr da nicht besser eine moderne Grafikkarte mit der entsprechenden GPU? Ich spanne doch auch nicht 10000 Ameisen vor einen Schlitten um damit Ziehhunde zu ersetzen. Paßt einfach nicht.
hallo hans, es ist eine gute idee sowas in kleinen massstab aufzubauen und daraus zu lernen wie man so was aufbaut. Ich habe ueber deine idee nach gedacht, es ist machbar. Viel Spass
Probier es und poste deine Ergebnisse! Das ist sicherlich eine lehrreiche und interessante Erfahrung!
nobody schrieb: > hallo hans, > > es ist eine gute idee sowas in kleinen massstab aufzubauen und daraus zu > lernen wie man so was aufbaut. Ich habe ueber deine idee nach gedacht, > es ist machbar. > Das es nicht machbar ist, hat ja auch keiner gesagt. Nur ist es mit Tinys eher sinnlos. (Die Hardware-Probleme bei massiv parallelen Strukturen liegen im übrigen nicht in den Prozessoren sondern in den Kommunikationsmechanismen. Was helfen dir 10 Prozessoren mehr, wenn die die meiste Zeit Däumchen drehen müssen bis sie endlich ihre Ergebnisse auf dem Bus weitergeben können)
Karl Heinz Buchegger schrieb: > Nur ist es mit Tinys eher sinnlos. Da wäre wieder die Sinn-Frage. :-) Wenn der Sinn einfach das Lernen ist, dann reicht das schon als Sinn. > (Die Hardware-Probleme bei massiv parallelen Strukturen liegen im > übrigen nicht in den Prozessoren sondern in den > Kommunikationsmechanismen. Was helfen dir 10 Prozessoren mehr, wenn die > die meiste Zeit Däumchen drehen müssen bis sie endlich ihre Ergebnisse > auf dem Bus weitergeben können) Völlig richtig. Und wenn genau diese Erkenntnis das Ergebnis eines solchen Experiments ist, dann hat man nicht nur "gelernt", sondern wirklich mit eigenen Händen "erfahren". Das ist etwas sehr Wertvolles, finde ich! Übrigens... So pauschal würde ich die Aussage mit den Kommunikationsproblemen auch nicht stehen lassen. Falls es sich um einen wirklich rechenintensiven Algorithmus handelt, wird es keinen Engpass bei der Kommunikation geben. Zumal die Tinys sowieso eine Weile brauchen, bis sie mit einer Berechnung fertig sind. ;-)
XMOS XS1-G4 ca. 18€/Stück 32 Bit µC mit 4 Kernen mit jeweils 8 parallelen Threads pro Kern und 400MHz Taktfrequenz (1600Mips) kostet auch nicht mehr als 32 ATTiny und kann sehr viel mehr... Edith sagt, einer der Gründer von XMOS war David May, Chefentwickler bei Inmos, dem Hersteller der Transputer...
hahhaha köstlich dieses Forum :-) Fragt einer nach Problemen an Schaltungen an der NEtzspanung heißt es lass die Finger davon ist gefährlich.. Fragt einer wie er eine LED eine 9V Batterie anklemmt heißt es such bei google fragt einer wie er tinys parallel arbeiten lassen kann heißt es vergiss es sinnlos nimm xyz HAHHAHA GEIL GEIl GEIL, die Motivation vieler hier ist echt vorn Arsch. Ich hoffe ihr werdet nie Kinder haben Und an den Thratstarter... Würde dieses Projekt auch gerne verfolgen einfach weil es interessant umzusetzen ist..
Bronco schrieb: > Da gab's doch mal diese "Transputer"... So ähnlich könnte man das auch machen: Einen ATmega2560, der über seine 4 UARTs mit den Nachbarn verbunden ist. Mit dem ATTiny13 ist das illusorisch, der hat weder die nötigen 4 UARTs, noch genügende Anzahl an Pins dafür. Peter
Naja, das Hauptproblem liegt in der Software. Da Du auf den Mikrocontrollern praktisch nichts speichern kannst, musst Du dafür sorgen, dass die Arbeitsleistung richtig verteilt wird und kein Controller auf den anderen warten muss. Wenn Du die Controller beispielsweise ringförmig per SPI verbindest und der SPI auf maximaler Geschwindigkeit läuft, kannst du beispielsweise Deine Programme in 18 Taktzyklen lange Segmente unterteilen, an deren Anfang und Ende immer ein Byte empfangen oder gesendet wird. Das muss sich einmal synchronisieren. Ab dann sollte es, wenn Du alle Controller mit dem selben Takt betreibst, synchron laufen. Nicht trivial, lohnt sich wahrscheinlich nicht, ist aber sicher eine geile Übung im Compilerbau. :)
Christian Berger schrieb: > Naja, das Hauptproblem liegt in der Software. Dafür gibts doch Occam...
1 | Wesentlich an dem Konzept des Transputers waren seine Cluster-Fähigkeiten |
2 | und die darauf basierenden Versuche der Parallelisierung der Rechenprozesse. |
3 | Dafür wurde die neue Programmiersprache Occam entwickelt. |
http://de.wikipedia.org/wiki/Occam Jetz muss nur noch einer einen Crosscompiler schreiben...
Den ATtiny13 würde ich auch als etwas zu "tiny" für die Aufgabe sehen. Du musst die Aufgabe sicher in so kleine Happen aufteilen und verteilen das das die zusätzliche Rechenleistung aufhebt. Ist natürlich nur meine Meinung :) Wenn es etwas grösser sein darf: http://glip.fr/ Da kann man schon mal etwas sehen.
Ich hab mal einen Mini-Cluster aus 3 MSP430 gebaut (weil damals ein MSP430 max. 60k Flash hatte und die Anforderungen während des Projektfortschritts permanent gewachsen sind). Mit Datenaustausch über ein FRAM an einem gemeinsamen I2C-Bus. War interessant zu machen, die Bus-Arbitierung, Zugriffsverwaltung usw. Das ging recht gut, weil jeder MSP430 seinen eigenen Aufgabenbereich hatte, aber es war doch nur eine Krücke, die man korrekterweise mit einem größen µC hätte lösen sollen...
Naja, man kann schon herausbekommen wieviel Prozent 4 Tinys schneller sind als ein einziger. Bei dem Sieb-Problem (und den meisten anderen ;) ) wird aber der viel zu kleine SRAM ein Problem sein. Das mag zwar akademisch interessant sein, aber am Ende kommt nur etwas extrem kompliziertes heraus was nur unter extremen SW Aufwand einen spürbaren Vorteil gegenüber einem einzelnem Tiny hat. Ich würde das Experiment eher mit ein paar STM32 machen, die gibt es zum Preis eines ATMEGA (<5.00€) und die Dinger bieten schon alleine ein vielfaches an Rechenpower und Speicher. Und man hat hat bei den meisten Typen min. 2 UARTS die man im MBit-Bereich betreiben kann wenn alle STM32 aus dem selben Takt betrieben werden. Ein weiterer Vorteil ist, das man immer etwas Rechenzeit (Rechenzeit, nicht Wartezeit!) zur Synchronisierung benötigt. Da dürften die Tinys schon locker 10% der Performance nur zur Verteilung der Tasks benötigen. Ein STM32 macht das schon eher mal nebenbei.
Kim Schmidt schrieb: > fragt einer wie er tinys parallel arbeiten lassen kann heißt es vergiss > es sinnlos nimm xyz > HAHHAHA > GEIL GEIl GEIL, die Motivation vieler hier ist echt vorn Arsch. > Ich hoffe ihr werdet nie Kinder haben Der springende Punkt ist der Tiny, nicht dass es sinnlos ist mehrere (viele) µC parallel rechnen zu lassen. Wenn dein Sprössling kommt und der Meinung ist, die Familie sollte doch eine Fahrradtour durch Norwegen machen, dann wirst du ihm auch sagen, dass das mit seinem Kinderrad (das mit den Stützrädern dran, dessen Schutzblech ausser klappern nur noch klappert, mit dem er sich auf 300 Meter Fahrstrecke zu Tode strampelt) nicht sehr sinnvoll ist. Mit einem ordentlichen Rad hingegen ist es einen Versuch wert. Und da macht man nicht gleich Norwegen, sondern erst mal eine Tour rund um den Baggersee. Der Tiny 13 hat ganz einfach so enge Beschränkungen, dass du mehr gegen diese Beschränkungen ankämpfst, als das du dich um das eigentliche Problem kümmern kannst. Da spielt es auch keine Rolle, ob der jetzt 60 Cent kostet oder nicht.
dann könnte man ja über nen Atmega reden das ist doch absolut ok.. Aber dann auf Intel oder komplett andere Systeme ist halt etwas unglücklick
Mit PICs hat das schon einer gemacht: http://cogsci.mcmaster.ca/~peter/piccluster.html mein Favorit wäre aber stm32 wie im Projekt oben.
Ich habe mal ein System gesehen mit Pic cluster, über 200 Stück eines Scenix IC (100Mhz/Mips Version eines Pics) mittels 30pin SIMM Modulen zusammengeschalten für Radar/Echo sowie Neuronale Netze gesehen. Das waren aber noch Zeiten, wo die PC Prozessoren unter 100Mhz waren. Für neuronale Netze habe ich sowas mal probiert.
Chris schrieb: > (100Mhz/Mips Version eines Pics) 100MHz waren mal versprochen, gehalten haben sie aber nur 50/75MHz. Inzwischen sind die lange den Bach runter. Wie kann man aber auch nen PIC12-Kern für Neuentwicklungen nehmen. Das mußte einfach schief gehen. Hardwarestack, RAM-Banking, kein Call in jede 2.Page, ich dachte, ich bin im falschen Film. Die etwa gleich alten 100MHz Silabs 8051 sind dagegen real und verfügbar. Peter
Karl Heinz Buchegger schrieb: > Wenn dein Sprössling kommt und der Meinung ist, die Familie sollte doch > eine Fahrradtour durch Norwegen machen, dann wirst du ihm auch sagen, > dass das mit seinem Kinderrad (das mit den Stützrädern dran, dessen > Schutzblech ausser klappern nur noch klappert, mit dem er sich auf 300 > Meter Fahrstrecke zu Tode strampelt) nicht sehr sinnvoll ist. Mit einem > ordentlichen Rad hingegen ist es einen Versuch wert. Du wirst aber zugeben, dass der Coolness-Faktor mit dem Kinderrad — oder erst recht mit einem Dreirad — ein Vielfaches größer wäre, auch wenn die benötigte Zeit wahrscheinlich ebenfalls ein Vielfaches sein wird ;-) Wenn du in der Zeitung zwei Artikelüberschriften siehst: "Bradley Wiggins (aktueller Tour-de-France-Sieger) fährt auf seinem Carbonrenner in 5 Tagen 1000 km durch Norwegen" und "4-Jähriger fährt auf seinem Dreirad in 100 Tagen 1000 km durch Norwegen" Welchen der beiden Artikel würdest du zuerst lesen? (Kinners, das war nur ein Beispiel, bitte nicht tatsächlich machen) Ich würde mir halt irgendeine Demoandwendung aussuchen, wo Speicher und Kommunikation nicht so die große Rolle spielen. Dass ein ATtiny weniger Rechenleistung/Euro hat als ein PC-Prozessor, und dass es durch die Parallelisierung noch weniger werden, sollte dabei natürlich klar sein. "Sinnvolle" Multiprozessorsysteme lassen sich nur aus Prozessoren zusam- mensetzen, die schon als Einzelprozessoren viel Rechenleistung/Euro haben. Da kommen fast nur PC-Prozessoren (aber nicht die allerneuesten) in Frage. Womit wir wieder beim oft diskutierten Thema wären: Muss Basteln immer monetär sinnvoll sein, oder ist schon ein Erkenntnisgewinn (und zwar ein selbst erfahrener, nicht ein nachgelesener) ein erstrebenswertes Ziel? Letzterer ist bei einem System aus 64 Attiny-Controllern (am besten mit per Steckbrücken konfigurierbarer Topologie) sicher höher als bei einem wesentlichen schnelleren und universeller einsetzbaren Quad-Core-PC.
Peter Dannegger schrieb: > Chris schrieb: >> (100Mhz/Mips Version eines Pics) > > 100MHz waren mal versprochen, gehalten haben sie aber nur 50/75MHz. > Nein, von Scenix waren die Real, aber seit Scenix von Ubicom sowie Ubicom von Cisco/Dell aufgekauft wurde, wurde der Vertrieb sowei Packaging an Parallax exclusiv vergeben und da wurden diverse Packages abgekündigt, wie auch die 100Mhz Version, aus Preis sowie Ausschussgründen. Wer will schon die 50Mhz Version wenn es die 75/100Mhz auch gibt und wenn sie die letzteren Preislich hochschrauben damit die 50Mhz Version Absatz findet, dann sind sie zu teuer. > Inzwischen sind die lange den Bach runter. > Wie kann man aber auch nen PIC12-Kern für Neuentwicklungen nehmen. Das > mußte einfach schief gehen. Dies war aber auch ca 1997/98 , andere Zeiten. > > Die etwa gleich alten 100MHz Silabs 8051 sind dagegen real und > verfügbar. Ich glaube, die waren erst 2000-2003 verfügbar und da auch nur 25mips glaube ich. Pic haben einige Vorteile bei Multiprozessorapplikationen weil es möglich ist sie Taktsynchron laufen zu lassen. Dies eröffnet diverse Möglichkeiten und schon massiv Resourcen. Bei neuronalen Netzen werden sie noch massiv eingesetzt, entwder direkt oder auch als pic12 in ein FPGA gegossen.
Karl Heinz Buchegger schrieb: > Wenn dein Sprössling kommt und der Meinung ist, die Familie sollte doch > > eine Fahrradtour durch Norwegen machen, dann wirst du ihm auch sagen, > > dass das mit seinem Kinderrad (das mit den Stützrädern dran, dessen > > Schutzblech ausser klappern nur noch klappert, mit dem er sich auf 300 > > Meter Fahrstrecke zu Tode strampelt) nicht sehr sinnvoll ist. Mit einem > > ordentlichen Rad hingegen ist es einen Versuch wert. Und da macht man > > nicht gleich Norwegen, sondern erst mal eine Tour rund um den Baggersee. Für so etwas gibts das FollowMe-Tandem...
Verteiltes Prozessing solte man nur machen koennen, wenn man das Programm auch aus dem RAM laufen lassen kann. Der Transputer konnte ueber die Links booten, und Software laden. Sowas muesste man mit PIC und AVR erst mal machen. Ein bootloader ins Flash dauert viel zu lange, denk ich. Obwohl, man koennte alle gleichzeitig programmieren.
Ich habe mir hier gerade einen kompletten Computer aus AVRs gebaut, der sich vom Prinzip her wunderbar als Basis für einen AVR-Cluster eignen könnte. Bei mir arbeiten derzeit 5 AVRs parallel, davon teilen sich drei(bzw. vier möglich) einen gemeinsamen Ext.RAM. Die Anbindung liegt bei 2MB/s je Prozessor und Code wird über Interpreter ausgeführt. Entsprechend angepasst ließen sich auf so einem System locker bspw. drei parallele 6809-Kerne mit je 2MHz plus einmal Netzwerk mit bspw. 10-Mbit Ethernet realisieren, also mehr als das sechsfache eines C64 plus Netzwerk mit DMA. Ich würde mal behaupten, dass es viele andere 8-bitter gibt, die für sowas besser geeignet sind, als der AVR. Aber grundsätzlich möglich ist es schon mit vielen AVRs (grob geschätzt ca. 250-400) bspw. die Rechenleistung einer Cray-1 zu erreichen.
> ... und Code wird über Interpreter ausgeführt...
und wie gross ist die tatsaechliche Geschwindigkeit, zB in Additionen/
Multiplikationen pro sekunde ?
LOL Schon süß was für Ideen so kommen und wie dann argumentiert wird. Stellt sich halt die Frage was erreicht werden soll. Zehn tiny13 wären 6,- Teurönchen, da allerdings kein Onewire o.ä. vorhanden ist könnte man versucht sein den Debugwire zur Kommunikation zu "mißbrauchen". Das wäre eine schöne Praktikumsaufgabe wie allerdings schon mehrfach erwähnt bringt es insgesamt nicht viel, denn die 1K Flash sind wahrscheinlich mit dem Programm zur Kommunikation schon voll ... Für konkreten Cluster-Einsatz empfehle ich eher sowas http://www.linux-ha.org/wiki/Main_Page Bei pollin mal schaun was an Upgradeboards so gerade vorrätig ist und die dann übereinander stapeln und via Gigabit-Switch zusammenstoppeln, der Rest ist in der Anleitung gut beschrieben. Viel Spaß mit der eigenen "Cloud" grins Achja und es macht im µC Bereich i.d.R. keinen Sinn mehrere kleine µCs zusammen zu schließen wenn es größere µCs gibt die die Anforderungen erfüllen.
Schlau-Meier schrieb: > Warum nehmt Ihr da nicht besser eine moderne Grafikkarte mit der > entsprechenden GPU? Weil das Ganze dann nichts mehr mit Mikrocontrollern zu tun hätte vielleicht?!
Amir Troglodim schrieb: > und wie gross ist die tatsaechliche Geschwindigkeit, zB in Additionen/ > Multiplikationen pro sekunde ? Je 1 MIPS bei 6809-Code (add, mul), MUL entspricht damit einem 11MHz-6809 :-) Wobei hier die Speicheranbindung einige Wartezyklen bedingt(bei MUL 25%), der Code selbst ist schneller. Mit einer auf paralleles Rechnen optimierten Software ließe sich sicher noch mehr herausholen, besonders, wenn man einen anderen Weg als einen Opcode-Interpreter nimmt. Hier ist halt beim AVR so eines der Probleme, Code im RAM geht nur über einen Interpreter, der schnell mal seine 12 Takte oder mehr je Opcode u.a. für die Sprünge benötigt. Bspw. Die Repeat-Opcodes vom Z80 laufen bei mir mit 21MHz(bei Repeat) verglichen mit einem 4MHz-Z80, weil ich das Opcode-Lesen eingespart habe, ein einfaches ADD ist gerade mal gleich schnell wie ein 4MHz-Z80.
>Je 1 MIPS bei 6809-Code (add, mul), MUL entspricht damit einem
11MHz-6809 :-)
eher eine bis zwei Groessenordnungen weniger. Denn die Hauptarbeit ist
der Interpreter, nicht die Ausfuehrung.
Nehmen wir man an, die Zeile
Mul Reg1,Reg2
liesse sich auf den OpCode runter compilieren, und der Interpreter
schaut den OpCode in einer Tabelle nach. Dann wird auf eine Routine
verweigt, die den ersten und zweiten parameter als Binaer nimmt, die
Operation durchfuehrt und weiter in der routine zum OpCode das Resultat
abspeichert. Wir haetten dann eigentlich keinen Interpreter, sondern
einen Emulator.
Wenn man gut ist..
16bit pointer fuer den Code zugriff im RAM, statisch allozierte
Register,
16bit pointer fuer RAM variablen, eine 8bit grosse OpCode Tabelle, ...
25 befehle pro ASM OpCode Zeile
Andere Schaetzungen?
Amir Troglodim schrieb: > Andere Schaetzungen? Sorry, ging vielleicht aus meinem Text nicht hervor, aber ich habe realen Code beschrieben, keine Schätzungen. 'Mein' mul auf dem AVR-6809 benötigt exakt 1µs, dafür müsste man das Original auf 11MHz takten damit der das auch schafft.
Ich habe mir in letzter Zeit sehr viele Gedanken zu diesem Thema gemacht. Hier in der Diskussion werden einige Fakten gar nicht beleuchtet. Es gibt verschiedene Architekturen von parallelen Systemen. Mit dem AVR wäre ein nachrichtengekoppeltes System am besten. Die Rechenleistung kann man dann genau bekommen, wenn der Bus nicht zu stark belastet wird. Zum Beispiel beim Sieb des Erathostenes berechnet jeder µC einen Abschnitt und sendet seine Ergebnisse an den Master zurück. Der erste zwischen 1 und 10000, der zweite 10001 bis 20000, usw. Der Master verteilt die Aufgaben. Klar der Tiny ist da zu klein wegen seinem Speicher, aber ein Mega8515 mit exterenem SRAM kann das unfd kostet auch nicht die Welt. Das andere µC das alleine erledigen können ist klar. Vielleicht auch schneller. Aber das war ja auch nicht die Frage und ist dem Threadstarter sicher auch klar. Die Frage war: Ist es möglich? Antwort: Ja, mit ein paar änderungen (Tiny auf Mega mit RAM). Ich finde das ein tolles Projekt und bin auf Ergebnisse gespannt! Grüße, Jens
>Ich finde das ein tolles Projekt und bin auf Ergebnisse gespannt!
Welches Projekt? Wer arbeitet daran? DU?
Ist sicher die Frage auf welcher Ebene man sich damit beschäftigen will, mit einfachen uCs ist fast noch sinnvoller als mit irgendwas komplexerem, da man sich da mit den richtig tiefliegenden Problemen auseinandersetzt. Wenn ich mir hingegen die RaspberryPi-Jünger angucke die dann 10 RaspberryPis zu einem "Cluster" via Ethernet verschalten wollen um verteilte Programmierung zu üben... Denkbar schlechte Plattform und wenn man eh unter Linux arbeitet kann man auch einfach mit VirtualBox 10 VMs aufsetzen auf nem normalen PC und in denen üben, ist man noch flexibler was simulierte Netztopologien etc angeht. Bei den AVRs kann man hingegen schön nachvollziehen was auf den Ebenen ganz unten passieren muss damit sowas funzt, weil es keine Libraries oder Betriebssystemfunktionen gibt die einem irgendwas abnehmen.
Mir scheint es sinnvoller zu sein etwas zu bauen, das auch etwas Dampf hat und eine Chance hat gegen einen Quadcore i7, zumindest mit einer endlichen Anzahl Einheiten. zB einen 32bitter, mit 100-200MHz und Memory Interface. In den Memory bereich schnallt man den kleinsten FPGA, der SERDES kann. zB einen ECP3-17 im 256 BGA, der kostet 31$ und hat 4 Serdes Kanale mit je 3Git. Damit koennte man einen aufgebohten Transputer bauen.
Was ist eigentlich daraus geworden? Interessanter Ansatz für das Lernen im Bereich verteiltes Rechnen. Würde das mal neubeleben und den ESP8266 mit 160 MHZ betreiben, das RF offline stellen, sagen wir mal 32 stck auf einer Steckplatine, entspricht dann wohl 5 GHz für 32x 2,40 EUR = 76 EUR bei Modulen, und wenn man sich die Module einspart, und gleich ein PCB macht, dann denke ich kommt man auf knappe 50 EUR hin. Immerhin war der TO mit 8 Bit und 0,60 EUR eingestiegen, jetzt sind wir mit dem SoC bei 32 bit und auch noch unter 1 eur je SoC. Welche RAM Bausteine nimmt man da am Besten?
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.