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
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. :)
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.
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
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?
