Hallo zusammen, ich finde im Netz nichts eindeutiges, darum möchte ich hier nochmal vorsichtig eine wahrscheinlich dämliche Frage stellen: Ich möchte ca 40 Atmega328 (Follower) per I2C mit einem ESP8266 (Leader) reden und rechnen lassen. Da sie außer der I2C Kommunikation "nur" rechnen sollen möchte ich die optimale Performance rausholen und dachte an Overclocking. (Mir ist völlig klar, das der ESP um weiten schneller rechnet!) In meiner Laienmäßigen Vorstellung bestimmt die Quarzfrequenz auch mit die Rechengeschwindigkeit. Braucht jetzt jeder Chip einen eigenen Quarz, oder kann ich die Taktleitung eines Quarzes über alle Chips spannen? (Die sollen auf einer Platine gleich nebeneinander sein). Es ist ein Spaßprojekt bei dem ich wohl das eine oder andere dazulerne. Hier könnte ich aber einen Stups in die richtige Richtung brauchen und bin für jeden Tipp dankbar. Ich vermute das ich aus Unkenntnis eine Menge übersehe was Kompatibilität oder so angeht oder? Gruß Rene´
Rene M. schrieb: > Braucht jetzt jeder Chip einen eigenen Quarz, oder kann ich die > Taktleitung eines Quarzes über alle Chips spannen? (Die sollen auf einer > Platine gleich nebeneinander sein). DAS wird unter Umständen nicht funktionieren, da die kapazitive Belastung der Leiterbahnen zu groß werden kann. Du KÖNNTEST eine zentrale Taktquelle mit einem Quarzoszillator und ggf. einem Buffer (oder mehreren, je nach Länge der Leitung) machen.
Mit dem Übertakten kommst du aber höchstens auf 20 Mhz. Das ist in Zeiten wo man 240 MHz haben kann ziemlich sinnlos. Die wirklich interessanten Aspekte dieses Projektes kannst du auch ohne Übertakten mit den internen R/C Oszillatoren testen.
Vielleicht Gruppen bilden und mit Fuse CKOUT / Pin CLKO arbeiten. Programmiert wird dann (automatisiert) vom ESP per I2C-Bootloader? Stefan ⛄ F. schrieb: > Mit dem Übertakten kommst du aber höchstens auf 20 Mhz ? Ohne Übertakten ...
S. Landolt schrieb: > Vielleicht Gruppen bilden und mit Fuse CKOUT / Pin CLKO arbeiten. > Programmiert wird dann (automatisiert) vom ESP per I2C-Bootloader? > > Stefan ⛄ F. schrieb: >> Mit dem Übertakten kommst du aber höchstens auf 20 Mhz > ? > Ohne Übertakten ... Vielleicht doch nur MIT Übertakten? Im Datasheet steht MAX 16MHz...
Rene M. schrieb: > Braucht jetzt jeder Chip einen eigenen Quarz, oder kann ich die > Taktleitung eines Quarzes über alle Chips spannen? (Die sollen auf einer > Platine gleich nebeneinander sein). Du brauchst sowas: https://www.reichelt.de/quarzoszillator-16-00-mhz-oszi-16-000000-p13686.html?&trstct=pol_14&nbc=1 Der gibt einen 16 MHz Takt aus, und den kannst Du dann weiter verteilen. Deine AVRs musst Du dann auf "External Clock" (0000) stellen. fchk
> Im Datasheet steht MAX 16MHz...
Wo? Bei mir steht u.a. gleich auf der ersten Seite: '̶ Up to 20 MIPS
Throughput at 20MHz'
Rene M. schrieb: > In meiner Laienmäßigen Vorstellung bestimmt die Quarzfrequenz auch mit > die Rechengeschwindigkeit. > Braucht jetzt jeder Chip einen eigenen Quarz, oder kann ich die > Taktleitung eines Quarzes über alle Chips spannen? Die brauchst EINEN Taktgeber, d.h. einen Quarz, der mit der Oszillatorschaltung eines deiner ATmega betrieben wird. Die anderen konfigurierst du auf externen Takt und speist sie über XTAL1 (external Clock Signal) vom Ausgang (XTAL2) des ersten. 39 Eingänge damit direkt zu speisen, könnte wegen der kapazitiven Belastung eventuell etwas knapp werden. Du solltest vielleicht ein paar Treiber vorsehen, so dass sich die Last aufteilt.
Wolfgang schrieb: > Du solltest vielleicht ein paar > Treiber vorsehen, so dass sich die Last aufteilt. Oder die CKOUT-Fuse benutzen.
Rene M. schrieb: > In meiner Laienmäßigen Vorstellung bestimmt die Quarzfrequenz auch mit > die Rechengeschwindigkeit. Wenn der Quarztakt als Systemtakt benutzt wird ist das i.d.R. so... > Braucht jetzt jeder Chip einen eigenen Quarz, oder kann ich die > Taktleitung eines Quarzes über alle Chips spannen? (Die sollen auf einer > Platine gleich nebeneinander sein). Theoretisch könnte man natürlich alle "Follower" mit demselben Takt betreiben. Es muß nur bei den Mega328 "external clock" als Taktquelle gewählt werden und dort muß halt jeweils der Mastertakt in hinreichender Qualität erscheinen. Das ist aber auch schon bei den maximal 20Mhz, die ein Mega328 als externen Takt abkann, ein nicht zu unterschätzendes Problem. Es ist im Gegenteil eine ziemliche Herausforderung, ein derartiges Layout funktionsfähig hinzubekommen. Ich würde mir das nicht zutrauen. Was nicht heißen muss, dass es unmöglich wäre. Ist nur nicht mein Job, sowas zu realisieren. Mag sein, dass es begnadete Layouter gibt, die sogar solchen Schwachsinn hinbekommen könnten... Aber es gibt einen Ausweg: Jeder Mega328 kann seinerseits seinen (regenerierten) Systemtakt wieder ausgeben. Damit würde es für mich beherrschbar werden, vielleicht auch für dich. Man kann damit nämlich einen Baum für die Taktdistribution aufbauen. D.h.: der Mastertakt wird zunächst nur an z.B. vier Megas geführt. Die versorgen über ihren CLKOUT jeweils wieder vier weitere Megas mit demselben (regenerierten, aber leicht verzögerten) Takt. Usw, usf. Bei 40 Konsumenten sind also in der dritten Ebene alle versorgt. Das ist immer noch eine Herausforderung, aber eine Machbare. Sinnvoll? Eher nicht...
S. Landolt schrieb: >> Im Datasheet steht MAX 16MHz... > > Wo? Bei mir steht u.a. gleich auf der ersten Seite: '̶ Up to 20 MIPS > Throughput at 20MHz' Hat jemand dein Datenblatt übertaktet? Im Anhang das aktuelle...
Ist das wirklich das aktuelle Datenblatt? - Mein Gott, Microchip!
Den Chip gibt es in zwei Variablen. Automotive bis 16 MHz Normal bis 20 MHz Mit 25 MHz bei 5V laufen die normalen schon nicht mehr, das hatte ich mal ausprobiert.
Stefan ⛄ F. schrieb: > Den Chip gibt es in zwei Variablen. > > Automotive bis 16 MHz > Normal bis 20 MHz > > Mit 25 MHz bei 5V laufen die normalen schon nicht mehr, das hatte ich > mal ausprobiert. Ich hab auch gerade gesehen, es gibt unterschiedliche Datenblätter. Das ist eigentlich ein no-go. Also sorry an S.Landolt, hab mich eines besseren belehren lassen ;-)
Fury schrieb: > Hat jemand dein Datenblatt übertaktet? > Im Anhang das aktuelle... Gibt es durchaus: Microchip Technology ATMEGA328P-PU Embedded-Mikrocontroller PDIP-28, 20 MHz
an Fury: Dacht' ich doch - im aktuellen (eben heruntergeladenen) steht im Kopf "MICROCHIP" (nicht "Atmel") und anschließend die 20 MHz.
Rene M. schrieb: > Da sie außer der I2C Kommunikation "nur" rechnen sollen möchte ich die > optimale Performance rausholen und dachte an Overclocking Klingt wie völliger Unsinn, leistungsschwache uC schneller als laut Datenblatt möglich zu betreiben, an statt einfach einen schnelleren uC zu verweden. Teensy ? Rene M. schrieb: > Braucht jetzt jeder Chip einen eigenen Quarz, oder kann ich die > Taktleitung eines Quarzes über alle Chips spannen? Man kann den ersten uC mit einem Quartz bestücken und von dem zum nächsten das Taktsignal über einen (22pF bis 47pF) Kondensator zu Takteingang und von dessen Taktausgang wieder über einen Kondensator zum nächsten, bis zum letzten leiten. Jeder Oszillator an dem kein Quartz hängt bekommt 1 MegOhm zwischen X1 und X2.
Moin, Ja, kann man alles machen. 41 I2C-Bus Teilnehmer, alle irgendwie an einem Quarz und nur rechnen... Ich kann mir auch Loecher in's Knie bohren und Milch reingiessen. Die Frage ist halt immer: Wie lange macht so ein Spassprojekt wirklich Spass? SCNR, WK
Beitrag #6679983 wurde von einem Moderator gelöscht.
Rene M. schrieb: > ca 40 Lastfaktor der Taktquelle? Andererseits würde ich mir auch über gleichzeitige Stromspitzen im Netzteil Gedanken machen wenn Zuverlässigkeit gefragt ist.
oszi40 schrieb: > Andererseits würde ich mir auch über > gleichzeitige Stromspitzen im Netzteil Gedanken machen wenn > Zuverlässigkeit gefragt ist. Ach was, die 40 Atmegas koennen sich sicher auch den einen 100nF Abblockkondensator (der mit je ca. 20cm langen Schnuersenkeln irgendwo angebunden wird) teilen, wenn sie sich eh' schon den Quarz teilen muessen... SCNR, WK
oszi40 schrieb: > Andererseits würde ich mir auch über gleichzeitige Stromspitzen im > Netzteil Gedanken machen wenn Zuverlässigkeit gefragt ist. Schon einzelne µCs bekommen Abblockkondensatoren direkt an den Versorgungspins, damit die Umschaltspitzen gar nicht erst auf die Versorgungsleitung und zum Netzteil gelangen. Und die Leitungsinduktivität tut ein Übriges. 40 * 0 = 0 Sonst sollte man noch mal über seine Abblock-Cs nachdenken.
Beitrag #6680003 wurde von einem Moderator gelöscht.
Eselwarnung schrieb im Beitrag #6679983: > Stefan ⛄ F. schrieb: >> Mit 25 MHz bei 5V laufen die normalen schon nicht mehr, das hatte ich >> mal ausprobiert. > > Meiner war dann mit 26 MHz wohl anormal. Bleib doch mal ruhig, wenn du > nichts zu sagen hast. Tja Ausreißer gibt es immer, was vielleicht generell erwähnenswert ist: Die AVRs lassen sich häufig etwas höher takten, es kann aber sein, das ab einem Takt Peripheriekomponenten ausfallen oder der AVR in manchen Temperaturbereichen nicht mehr zuverlässig arbeitet. Es kann daher sein, das alle ATMega328 mit 24MHz noch „arbeiten“, aber zum Beispiel der ADC sich nicht wie in der Spezifikation verhält und dieses Fehlverhalten kann auch nur vereinzelte Chips betreffen, während die gesamte restliche Charge diese Anomalie nicht hat. Daher legt der Hersteller eben seine Bedingungen fest und sichert gewisse Eigenschaften zu, solange die Bedingungen erfüllt sind.
Bin dafür, zuerst mal die zwei Probleme zu trennen! Wie hoch übertakte ich...wie versorge ich 40 Controller mit Arbeitstakt. Übertakten interessiert mich persönlich überhaupt nicht, aber es wird schon seinen Grund haben, 16 auf 20MHz zu bringen. Warum nicht lieber 80 Controller mit sicherem/langsamen Rechenbetrieb? Bleibt also der Takt, der vernünftigerweise mit einem Quarzoszillator erzeugt wird, dem ein satter Puffer/Treiber nachgeschaltet ist. So ist es kaum ein Problem, die Controller auf einer höchstens im Europaformat designeten Leiterplatte mit Takt, Spannung und den I2C-Busleitungen zu verbinden. Und schon kann der Leader rechnen lassen! Neben der Frage, was er denn nun rechnen läßt, interessierte mich mehr die Frage, wie das Ganze denn dann aussieht, wenn es fertig ist :-) Gruß Rainer
Wer mit solchem 1990er-Jahre Hype von Overclocking anfängt, wird wohl ewig 25 Jahre hinter dem aktuellen Kenntnisstand bleiben und auf ewig Anfängerfragen stellen müssen. Schnellere µCs (> 100 MHz) sind überall billig zu bekommen. Wenn es DIL sein muss, gibt's die auch auf Break-Out-Boards im bequemen Raster. Ansonsten macht klügere Programmierung jeden µC deutlich schneller, als einige 10% Overclocking mit unsicherem Ergebnis...
Rene M. schrieb: > öchte ich die optimale Performance rausholen und dachte an Overclocking. Nimm einen (in Zahlen 1) µC, der die 40-fache Rechenleistung hat. Kein Mensch will im Ernst 40 µC, die so dicht beieinander sitzen, dass man sogar 39 Quarze (die je 20Cent kosten) einsparen könnte, irgendwas miteinander reden lassen. Davon träumen nur Anfänger. Profis wissen, dass so ein System in der Praxis kaum beherrschbar ist. Denn das ist wie ein Saal, in dem 40 Leute sitzen und alle plappern munter miteinander. Was soll dabei herauskommen? Flöhe hüten ist einfacher... > Braucht jetzt jeder Chip einen eigenen Quarz, oder kann ich die > Taktleitung eines Quarzes über alle Chips spannen? Du meinst wohl die Takttleitung eines Quarzoszillators. Denn ein Quarz hat keine "Taktleitung". Aber natürlich kann man mit passendem Layout einen Oszillator an mehrere Abnehmer anschließen. Im Idealfall bekommt jede der 40 am Oszillator abgehenden Taktleitungen einen eigenen Widerstand zur Sereienterminierung. Oder du kannst die µC so platzieren, dass du nur 10 terminierte Leitungen brauchst und jeweils 4 Oszillatoreigänge mit kurzen Stubs anfährst. > Es ist ein Spaßprojekt bei dem ich wohl das eine oder andere dazulerne. Das ist auf jeden Fall sicher. Viel Erfolg. BTW: in der Praxis nennt sich das, was du da letztlich bekommen wirst, das bei unüberlegt angegangenen Multiprozessorsystemen übliche Problem mit dem Semaphorenhandling bzw. mit Deadlocks. Sieh dir mal sowas an: https://www.numa.uni-linz.ac.at/Staff/haase/parvor/node23.html
Knut schrieb: > Ansonsten macht klügere Programmierung jeden µC deutlich schneller, > als einige 10% Overclocking mit unsicherem Ergebnis... Das ist auch meine Erfahrung, Nachdenken ergibt die größte Beschleunigung. Für private Projekte benutze ich die AVRs mit 1..8MHz. Dann habe ich Reserve, wenn es doch mal eng werden sollte. In der Firma muß ich alles auf Kante nähen, d.h. 16MHz. Da es damit manchmal EMV-Probleme und Quarzausfälle gab, benutze ich nur noch einen Quarzoszillator. Beim AVR kann Übertakten den LPM-Befehl stören, d.h. man liest manchmal falsche Daten. Viel Spaß dabei, solche Fehler zu debuggen.
René F. schrieb: > Es kann daher sein, > das alle ATMega328 mit 24MHz noch „arbeiten“, aber zum Beispiel der ADC > sich nicht wie in der Spezifikation verhält und dieses Fehlverhalten > kann auch nur vereinzelte Chips betreffen, während die gesamte restliche > Charge diese Anomalie nicht hat. Es fehlt nur noch der Hinweis, dass die Versicherung nicht zahlt, wenn beim Übertakten das Haus abbrennt! Lasst den TO doch sein "Spaßprojekt" machen. Nur sollte er die ATmega sockeln, damit er sie nach Beendigung seiner Spielereien noch sinnvoll einsetzen kann. 40 x einen Controller einzusetzen kann sinnvoll sein, wenn man 40 x USARTs braucht, die autark agieren müssen, und zum Beispiel ganz, ganz viel IO. Wenn's um's reine Rechnen geht, da sind die ATmega rausgeschmissenes Geld. Ein Cortex-M7 mit mehreren 100 MHz läßt die 8-Bittern total alt aussehen, egal wieviel Stück man zusammenlötet. Peter D. schrieb: > Beim AVR kann Übertakten den LPM-Befehl stören, d.h. man liest manchmal > falsche Daten. Woher willst du das denn wissen? Traust dich ja garnicht an Übertaktung heran ;-)
Eselwarnung schrieb: > Woher willst du das denn wissen? Traust dich ja garnicht an Übertaktung > heran ;-) Irgend jemand hatte das mal untersucht und das mit dem LPM festgestellt. Warum sollte ich völlig grundlos und nutzlos einen AVR übertakten? Ich überlaste ja auch keine Transistoren, sondern setze den passenden Typ ein.
Peter D. schrieb: > Irgend jemand hatte das mal untersucht und das mit dem LPM festgestellt. Bei Vcc = 4 V und 26 MHz hatte ich keine Probleme mit LPM. Wer hat nun Recht? Komme ich nun ins Gefängnis? > Warum sollte ich völlig grundlos und nutzlos einen AVR übertakten? Der TO möchte es probieren. Es gibt keinen Grund, ihn nicht seine Erfahrungen machen zu lassen oder es ihm zu verbieten.
Eselwarnung schrieb: > Komme ich nun ins Gefängnis? Ja, weil Du um Kaisers Bart redest. Die genauen Randbedingungen für die LPM-Fehler erinnere ich nicht mehr. Das ist mir auch herzlich schnuppe. Eselwarnung schrieb: > Es gibt keinen Grund, ihn nicht seine > Erfahrungen machen zu lassen oder es ihm zu verbieten. Ich habe nichts verboten. Wie kommst Du denn darauf? Es scheint aber überwiegend Konsens zu bestehen, daß sowas sinnlos ist.
Rene M. schrieb: > Ich möchte ca 40 Atmega328 (Follower) per I2C mit einem ESP8266 (Leader) > reden und rechnen lassen. Ahhh, ein politisch korrekter Elektroniker! Sehr löblich! Die häßlichen Worte "Slave" und "Master" haben MILLIONEN I2C-Teilnehmende über JAHRZEHNTE diskriminiert! Zum Glück benutzt er nicht die deutsche Übersetzung von "Leader" . . .
Eselwarnung schrieb: > 40 x einen Controller einzusetzen kann sinnvoll sein, wenn man 40 x > USARTs braucht, die autark agieren müssen, und zum Beispiel ganz, ganz > viel IO. Wenn's um's reine Rechnen geht, da sind die ATmega > rausgeschmissenes Geld. Kommt wohl tatsächlich von einem Esel denn im 1. Beitrag steht: Rene M. schrieb: > Da sie außer der I2C Kommunikation "nur" rechnen sollen möchte ich die > optimale Performance rausholen und dachte an Overclocking. Eselwarnung schrieb: > Bei Vcc = 4 V und 26 MHz hatte ich keine Probleme mit LPM. Wer hat nun > Recht? Komme ich nun ins Gefängnis? Aha, weil du einmal ohne nach links und rechts zu schauen über die Straße gegangen bist und nicht überfahren wurdest, empfiehst du das jetzt auch anderen. Eselwarnung schrieb: > Der TO möchte es probieren. Es gibt keinen Grund, ihn nicht seine > Erfahrungen machen zu lassen oder es ihm zu verbieten. Keiner "verbietet". Du scheinst gern anderen das Wort im Mund herumzudrehen. Und du lässt anscheinend gern andere ins Messer laufen. "Anfänger" und 40 µCs die miteinander kommunizieren und rechnen sollen ist der Garant dafür, das das Projekt in einem Fiasko endet. Die Gründe wurden alle schon genannt: Synchronisation, Dead Locks, Hardware Probleme bei der Verteilung des Takts. Und du ermutigst den TO auch noch als zusätzliches Problem Overclocking zu machen.
Stefan ⛄ F. schrieb: > Den Chip gibt es in zwei Variablen. > > Automotive bis 16 MHz > Normal bis 20 MHz > > Mit 25 MHz bei 5V laufen die normalen schon nicht mehr, das hatte ich > mal ausprobiert. Die betreibe ich jenseits der 32MHz mit externem Oszillator. Über Monate.
Uwe D. schrieb: > Die betreibe ich jenseits der 32MHz mit externem Oszillator. Über > Monate. Und was hast Du davon? Nimm doch einen 100MHz C8051, der rennt Deinem 32MHz AVR aber sowas von davon. https://www.silabs.com/mcu/8-bit/c8051f12x-f13x
Uwe D. schrieb: > Die betreibe ich jenseits der 32MHz mit externem Oszillator. Über > Monate. Na du traust dich ja was! Bist du völlig wahnsinnig? Nach dem, was hier so geschrieben wurde, bist du eine ernsthafte Gefahr für diese Forumsgemeinde. Sofortige Sperre, Hausverbot, Klappse! Kaum vorstellbar, wenn das der TO auch noch als Vorbild nehmen sollte. :----)
So dauert das aber ne Weile bis zum ersten geschürften Bitcoin.
Hallo nochmal, ich war schon ein bisschen traurig, das ich keine Benachrichtigung bekam obwohl ich den Thread beobachte. Und als dann eben eine kam, POFF! Jede Menge Unterstützung. Toll! Vielen Dank! Da einige Fragen dabei waren versuche ich zu Antworten und das was ich glaube verstanden zu haben fasse ich mal zusammen. Dann noch eine Handlungsempfehlung aus euren Beiträgen destillieren und es kann losgehen. Das es Quarze und Quarzoscillatoren gibt wusste ich noch garnicht. Habe gleich mal ein paar Seiten dazu gelesen. In Verbindung mit euren Warnungen das man bei übertakteten AVRs Fehlerquellen hinzufügt, um die Bauteilliste klein zu halten und das Ding erstmal in Version 1 einfach ans laufen zu bekommen habe ich mich entschlossen es doch zunächst mit dem inneren Quarz zu versuchen und erst später ans optimieren zu gehen. Das ich mit Absicht schwache AVRs nehme und die versuche zu übertakten hat mit dem Zweck dieser Bastelei zu tun. 1. möchte ich was dazulernen was AVRs angeht 2. möchte ich was dazulernen was c Programmierung mit direktem technischen Bezug angeht 3. Ist mir Platinendesign völlig neu und letztlich: Am Ende soll ein optisch ansprechender solarbetriebener cryptominer in meinem Wohnzimmer auf der Fensterbank stehen. Jetzt werden wohl alle lachen :-) Es sei euch gegönnt. Vor ein paar Monaten bin ich auf den crypto Duco bz. Duinocoin aufmerksam geworden. Eine Blockchain zum lernen. Speziell für AVR/MCUs. Durch ein gerechtes rewardingsystem werden schwache Maschinen höher honoriert. Ein einzelner Arduino generiert mehr rewards als ein quadcore PC. Ich dachte mir AVRs sind ja auch nicht direkt Stromhungrig, also wenn das ganze mal funktioniert, erweitere ich es später mal um den Solarbetrieb. Aber das ist ferne Zukunft. Zurück zu den Quarzoszillatoren. Meine Laienidee mit dem höhere-frequenz = mehr performance habt ihr ja vom Grundsatz bestätigt. Den Signalerzeugenden bzw deligierenden Aufbau nach Baum-hierachie habe ich mir notiert. Das klingt clever und problemmindernd :-) 20Mhz im vergleich zu den internen 8Mhz _könnte_ einen reward beeinflussenden Unterschied machen. Ich werde das ende der Woche mal mit einem einzelnen AVR testen. Vermutlich kann man dabei noch einen goldenen Schnitt finden welcher AVR und welcher Speed "sinnvoll" ist. 40 Atmega328 kosten ja auch und ich nehme an "eine Tüte" einfacherer AVRs die I2C sprechen sind günstiger (und brauchen weniger Saft). Am Ende wird alles aus Kompromissen bestehen, wie es ja immer so ist. Ich freue mich sehr darauf einiges auszuprobieren und dazuzu lernen. Ziel ist nicht elektrotechnik zu studieren. Ich danke allen Beitragenden für die nützlichen Impulse und Informationen! Gruß Rene´
Jetzt bin ich sprachlos - so viel jugendlicher Optimismus ist beneidenswert. Gruß aus dem Schwarzwald
PS: [Seymour Cray and Co.] had come to build what are generally acknowledged to be the fastest computers in the world, the quintessential number-crunchers. Cray was a legend in computers, and in the movie Cray said that he liked to hire inexperienced engineers right out of school, because they do not usually know what’s supposed to be impossible. West liked that idea. ... weil sie in der Regel noch nicht wüßten, was unmöglich sei - 'unmöglich' nach Meinung der Anderen ... Tracy Kidder: The Soul of a New Machine
S. Landolt schrieb: > ... weil sie in der Regel noch nicht wüßten, was unmöglich sei - > 'unmöglich' nach Meinung der Anderen ... Nur hat hier noch niemand etwas von "unmöglich" gesagt. Alles ist so irgendwie machbar. Was nichts daran ändert dass die Idee Schwachsinnig ist. Das hätte auch Cray so gesehen.
Rene M. schrieb: > Am Ende soll ein optisch ansprechender solarbetriebener > cryptominer in meinem Wohnzimmer auf der Fensterbank stehen. Tja da war ich wohl mal wieder auf den richtigen Pfad. Bin ich zwar gewohnt, aber trotzdem. Nur dieser Aufwand für einen wertlosen Coin ist halt extrem sinnlos.
Cyblord -. schrieb: > Tja da war ich wohl mal wieder auf den richtigen Pfad. Bin ich zwar > gewohnt, aber trotzdem. APPLAUS APPLAUS
Moin, Cyblord -. schrieb: > Nur dieser Aufwand für einen wertlosen Coin ist halt extrem sinnlos. Der Weg ist das Ziel - aeh' der Sinn. Gruss WK
Rainer V. schrieb: > Bleibt also der Takt, der > vernünftigerweise mit einem Quarzoszillator erzeugt wird, dem ein satter > Puffer/Treiber nachgeschaltet ist. Du brauchst dafür kaum noch Treiber. 1.Mikrocontroller mit Quarz, mit Fuse stimmst du PB0 als CLKO ein, von dem kannst du ein paar weitere Mikrocontroller mit Takt auf XTAL1 versorgen, die von ihren CLKO jeder seine Gruppe von weiteren Mikrocontrollern mit Takt versorgt. ATMega gibt ja bis 20 mA pro Pin aus, d.h. selber ein guter Treiber. Zwar kostet das immer PB0, so kostet das dir je einen Port pro führende oder verteilende Mikrocontroller, z.B. ICP1 hast du dann nicht mehr... Dafür aber bekommst du bei jedem weiteren Mikrocontroller PB7 frei, der zwar keine besondere Funktionen wie ICP usw. hat, da für CLK nur PB6/XTAL1 gebraucht wird. Überlege aber, daß wenn jeder beliebige Mikrocontroller programmiert wird, sollte führende Mikrocontroller ihn auch während dieser Zeit mit Takt versorgen. Auch wenn der führende Mikrocontroller ausfällt, werden alle anderen stehen bleiben. Ob sicht das alles lohnt?
Wie ist es eigentlich beim Avr, ist dieser auch wie Pic cyclensynchron wenn man mehrere uC aus derselben Taktquelle speist? Habe noch eine Platine hier mit umschaltbar osz 20/24/32 MHz und 121 uC. In 1x master und 15x slaves mit je 7x huckepack dil + Bierdosenblech für die Kühlung und Schrumpfschlauch zur Kontaktierung der Pins.
Chris schrieb: > Wie ist es eigentlich beim Avr, ist dieser auch wie Pic cyclensynchron > wenn man mehrere uC aus derselben Taktquelle speist? Davon gehe ich mal aus, sofern wir die Modelle mit PLL außen vor lassen.
Bei Pic stimmt dies nur für ältere da bei neueren der power on timer an den internen wdt gekoppelt ist und damit ist diese Funktionalität nicht mehr fofhanden.
Peter D. schrieb: > Uwe D. schrieb: >> Die betreibe ich jenseits der 32MHz mit externem Oszillator. Über >> Monate. > > Und was hast Du davon? > Nimm doch einen 100MHz C8051, der rennt Deinem 32MHz AVR aber sowas von > davon. > https://www.silabs.com/mcu/8-bit/c8051f12x-f13x Das ist mir schon klar was Du mir nahebringen möchtest. Es war für mich der einfachste Weg, bestehende Platinen mit geringem Aufwand zu pimpen und ein zeitkritisches Thema zu lösen. Und selbst die halbgare Anbindung des Taktes über eine fliegende Winzig-Platine führt im Sommer nicht zum aufhängen des Sensors.
Rene M. schrieb: > Am Ende soll ein optisch ansprechender solarbetriebener > cryptominer in meinem Wohnzimmer auf der Fensterbank stehen. Der Bitcoinkurs liegt bei knapp 50.000 Euro. Du kannst also (vereinfacht gesagt) nur erfolgreich sein, wenn Du a) Dein Investment in diese Region schraubst b) Klüger bist als alle anderen und ein effizientere Berechnung schaffst c) Glück hast (Lotto-Effekt). Das heißt nicht, dass eine Collage aus 40 Mikrocontrollern "falsch" ist, aber Du kannst Dich unbesorgt den Aspekten Kunst und Tüftelei widmen. Z1-Nachbau, Weltzeituhr, Visualisierung Klimawandel, Gezeitenrechner... Eine Frage, die ich mir gestellt habe bei dem Thread: Wie kann ich am billigsten Rechenpower zuhause (d.h. ohne Cloud) erzeugen, Strom und Kauf gerechnet? Beim Mining sind es wohl GPUs, aber im allgemeinen Fall? Wahrscheinlich durch Cluster aus billiger PC-Hardware mit i5 oder Ryzen, vermute ich. Oder gibt es im Embedded Bereich Module, mit denen das besser geht?
Uwe D. schrieb: > Es war für mich > der einfachste Weg, bestehende Platinen mit geringem Aufwand zu pimpen > und ein zeitkritisches Thema zu lösen. Ich habe bisher zeitkritische Aufgaben allein durch Codeumstellung lösen können. Meine AVRs sind weit unter 100% CPU-Last und idlen die meiste Zeit. Wir können das Thema also schließen. Es wurde ja schon alles gesagt.
Peter D. schrieb: > Es wurde ja schon alles gesagt. Wobei... Rene M. schrieb: > und letztlich: Am Ende soll ein optisch ansprechender solarbetriebener > cryptominer in meinem Wohnzimmer auf der Fensterbank stehen. Nett. Du wirst wegen der dafür nötigen Solarzelle aber nicht mehr zum Fenster raussehen können. Denn 40 Stück mit 20MHz getaktete mega328 brauchen mit je 10mA schon gehörig Strom. Mit einer 10x10cm² Zelle wirst du da nicht viel stemmen. Ein Tipp aus der Praxis: mach einen Klimatest im Backofen, denn wenn deine 40 Stück übertaktete mega328 auf der Fensterbank dank solarer Versorgung in der Sommersonnenhitze neben dem Kaktus stehen, könnte die Stabilität und Zuverlässigkeit doch arg leiden. > Meine Laienidee mit dem höhere-frequenz = mehr performance habt ihr ja > vom Grundsatz bestätigt. Aber es wurde vordringlich eben auch bestätigt, dass man die Angaben der Herstellers aus dem Datenblatt einhalten muss, wenn man ein zuverlässiges System aufbauen will. Rene M. schrieb: > 20Mhz im vergleich zu den internen 8Mhz könnte einen reward > beeinflussenden Unterschied machen. Ich liebe den Konjunktiv: Wenn der Hund nicht geschissen hätte, hätte er den Hasen gekriegt. Fazit: entweder machst du das Ganze nur als Spielerei, dann ist dir das Ergebnis schlicht EGAL, so lange es optisch hübsch aussieht. Oder du machst es, um tatsächlich einen Bitcoin zu finden, dann solltst du dir selber aber zugeben, dass du mit deiner Laienhardware gegen richtige Rechenboliden anstinken willst. Oder kurz: deine Art zu "schürfen" ist, wie wenn du mit dem Kindergartenplastikschäufelchen bei dir im Vorgarten nach Gold gräbst. Viel Glück.
:
Bearbeitet durch Moderator
War beim Bitcoin Mining nicht auch das problem, dass viele Teilnemer die gleichen Codes generieren und nur der schnellste gewinnt? Die anderen müssen den Code verwerfen und nochmal neu anfangen. So habe ich das zumindest verstanden. Die Chance, mit ein paar AVR irgendwann im Leben auch nur einen einzigen gültigen Bitcoin zu generieren geht damit gegen Null.
Stefan ⛄ F. schrieb: > So habe ich das zumindest verstanden. Die Chance, mit ein paar AVR > irgendwann im Leben auch nur einen einzigen gültigen Bitcoin zu > generieren geht damit gegen Null. Irgendwelche Retro-Fans haben sogar einen Bitcoin Miner für den C64 geschrieben! https://www.golem.de/news/8-bit-mining-bitcoin-schuerfen-auf-dem-c64-2104-156010.html
Rene M. schrieb: > Vor ein paar Monaten bin ich auf den crypto Duco bz. Duinocoin > aufmerksam geworden. Eine Blockchain zum lernen. Speziell für AVR/MCUs. > Durch ein gerechtes rewardingsystem werden schwache Maschinen höher > honoriert. Ein einzelner Arduino generiert mehr rewards als ein quadcore > PC. Es geht hier doch überhaupt nicht um Bitcoins ihr Schlaumeier. Ich gebe zu, das Konzept klingt auf den ersten Blick nach Quatsch. Aber andererseits ist es wohl Hobby, also lasst ihn doch basteln. Amateurfunk z. B. ist in Zeiten des globalen mobilen Internets auch nur noch ein Hobby für Leute mit nem großem Spleen, das scheint hier aber allgemein akzeptiert zu sein.
Ztrewq schrieb: > Eine Blockchain zum lernen. Speziell für AVR/MCUs Was für ein Quatsch. Dazu braucht man doch keine Mikrocontroller! Das ist so, als ob ich mir einen Unimog mit Bagger kaufen würde, um damit in den Urlaub zu fahren.
Ztrewq schrieb: > Es geht hier doch überhaupt nicht um Bitcoins ihr Schlaumeier. Wirklich? Rene M. schrieb: > Am Ende soll ein optisch ansprechender solarbetriebener > cryptominer in meinem Wohnzimmer auf der Fensterbank stehen.
Stefan ⛄ F. schrieb: > Das ist so, als ob ich mir einen Unimog mit Bagger kaufen würde, um > damit in den Urlaub zu fahren. Ich würde den Vergleich eher andersrum ziehen. Wenn du mit einem Spielzeugbagger einen Tagebau ausheben willst. :-)
Stefan ⛄ F. schrieb: > Ztrewq schrieb: >> Es geht hier doch überhaupt nicht um Bitcoins ihr Schlaumeier. > > Wirklich? > > Rene M. schrieb: >> Am Ende soll ein optisch ansprechender solarbetriebener >> cryptominer in meinem Wohnzimmer auf der Fensterbank stehen. Ja wirklich. Es geht um einen anderen Coin. > Duco bz. Duinocoin
Rene M. schrieb: > Ich möchte ca 40 Atmega328 (Follower) per I2C mit einem ESP8266 (Leader) > reden und rechnen lassen. Das ist doch eigentlich eine schöne Trollfrage... > Es ist ein Spaßprojekt bei dem ich wohl das eine oder andere dazulerne. > Hier könnte ich aber einen Stups in die richtige Richtung brauchen und > bin für jeden Tipp dankbar. Mein Tipp: Klein anfangen. Erstmal einen ESP und einen AVR, dann steigern auf zwei AVR.
Upps hier gehts ja noch weiter ;-) ok noch ein paar Sätze zum Abrunden: Danke an Lothar!: >Du wirst wegen der dafür nötigen Solarzelle aber nicht mehr zum Fenster >raussehen können. Denn 40 Stück mit 20MHz getaktete mega328 brauchen mit >je 10mA schon gehörig Strom. Mit einer 10x10cm² Zelle wirst du da nicht >viel stemmen. Dein Hinweis finde ich ziemlich cool, denn er macht Hoffnung das es klappen wird. In meiner (nicht ganz vollständigen) Rechnung überschlage ich 0,033W/Atmega328 * 40 + 0,33W für den ESP8266 Leader. Wär schön wenn er bei Tageslicht rechnet (per NTP,Astro-API Sonnenauf/Untergang abgragen und entsprechend in den deepsleep gehen, die AVR per Transistor abschalten). Ich habe hier diese 25x25cm Dinger aus China rumliegen. Die sollen 5watt machen. Wenn die in der Realität 2W schaffen würde ich einfach 4 Nebeneinander auf die Fensterbank legen, in Kauf nehmend dass die Ernte wegen dem falschen Winkel nicht optimal ist. Habe mir dazu das geniale Video von "dem schweizer mit dem Akzent" angesehen, was Solarbetrieb von AVR/MCU in Reinform komplett erklärt (Mega-empfehlenswert!) 1. Vid: https://www.youtube.com/watch?v=WdP4nVQX-j0 2. Vid: https://www.youtube.com/watch?v=ttyKZnVzic4&t=2s An FalkB und Stefan F: Natürlich ist mit AVR & MCU bei Bitcoin nichts zu gewinnen. Hier geht es um einen ganz anderen crypto, bei dem das anders ist. Nebenbei erwähnt auch, dass es durchaus cryptos gibt, die mit der CPU sehr einträglich sind und keine GPU benötigen (siehe Monero). Details zur Leistung hier: https://monerobenchmarks.info/ An Gast Felix: "Rechenpower zuhause" ist eine sehr diffuse Frage. Es kommt dann drauf an wie du die Power nutzen willst/kannst. Meist braucht es spezielen Code für spezielle Maschinen. Bei Ebay bekommst du momentan regelmäßig für 50€ Intel Coprozessorkarten mit 60 Cores. Damit der Code die Karten nutzen kann sind aber Klimmzüge nötig. Ich habe letztes Jahr just 4Fun mal 8 mini-itx i7/i5 Boards übereinander montiert und ein paar Experimente mit Monero-mining und Cluster computing mit Mosix gemacht (geile Tech!). Hab mal ein Foto angehängt. Aber auch da musst du den code speziell für Cluster programmieren. Eine Zeitlang war ich schwanger mit der Idee mein Biostar BC250 BTC+ Board mit älteren Grakas zu befüllen und mit einem großen Solarpanel von den Vosswinkeln (oder wie die heißen, das sind niederländische Zollauktionen, bei denen du 250W Panele für 15€ bekommst.) zu betreiben und aufs Dach zulegen. Dankend an Gast (bzl. "klein Anfangen") Klein Anfangen ist immer richtig und wichtig! SO hab ich es gemacht. Jetzt unterhalten sich ein ESP8266 Leader und ein Arduino Uno empfängt Befehle (Strings). Dabei ist mir eine Fehlerrate von etwa 7% ein Dorn im Auge. Ist derzeit mit einfachen 15cm Käbelchen(^=Antennen) als I2C ohne zusätzliche Treiber direkt verbunden. Dem Problem will ich heute mit Fehlererkenung begegnen. Hab mal was zu CRC32, MD5, Sha und Co gelesen. Weil die Hashes >32Byte sind (I2C-Grenze) muss ich mir aber was einfallen lassen wie das in Häppchen gesittet übertragen werden soll..... Und nochmal an die mit I2C Erfahrung eine Frage: Ich will ja "nur" 40 ICs verbinden und das auch noch gleich nebeneinander. Datenblätter und Info-Webseite habe ich mir durchgelesen. Verstehe ich das richtig, das ich vom ersten bis zum letzten immer Serienwiderstände + Kondensator dazwischenfummeln muss? So. Schluß mit schreiben, sonst komm ich nicht mehr zum Basteln ;-) Gruß Rene´
Rene M. schrieb: > Und nochmal an die mit I2C Erfahrung eine Frage: > Ich will ja "nur" 40 ICs verbinden und das auch noch gleich > nebeneinander. > Datenblätter und Info-Webseite habe ich mir durchgelesen. > Verstehe ich das richtig, das ich vom ersten bis zum letzten immer > Serienwiderstände + Kondensator dazwischenfummeln muss? In und an den I2C-Bus gehören laut Spec gar keine Serienwiderstände oder gar Kondensatoren. Sowas brauchen nur Frickler. Dank maximaler Datenrate mit 400kBit/s bleibt dann für jeden einzelnen Knoten bestenfalls <<10kBit/s an Bandbreite.
:
Bearbeitet durch Moderator
Moin, Lothar M. schrieb: > Sowas brauchen nur Frickler. Oder Leute, die's interessiert, welcher der 40 Teilnehmer jetzt grad keinen Bock hat, den Bus wieder loszulassen. Aber ein I2C Bus mit 40 Teilnehmern ist ja eh' nur was fuer Vollprofis. Am besten dann noch Multimaster und Anschluss ueber Freileitungen - weil ja der Kumpel von 'nem Bekannten von 'nem Arbeitskollegen einen kennt, bei dem das so funktioniert. :-D Gruss WK
Lothar M. schrieb: > In und an den I2C-Bus gehören laut Spec gar keine Serienwiderstände oder > gar Kondensatoren. Sowas brauchen nur Frickler. Das stimmt wenn der Bus, wie vorgesehen, auf einer Platine stattfindet. Aber es ist ebenfalls keine gute Praxis, GPIOS direkt mit der Aussenwelt zu verbinden. Also wann immer die Platine verlassen wird, sollte entsprechende Schutzbeschaltung vorhanden sein. Ein Serienwiderstand ist das Minimum. Dazu wäre auch noch eine TVS Diode zu empfehlen. Gerade bei langen Freileitungen fängt man sich schnell was ein. Womit wir beim Thema sind: I2C ist hier die falsche Wahl.
:
Bearbeitet durch User
Cyblord -. schrieb: > Womit wir beim Thema sind: I2C ist hier die falsche Wahl. Oh, hast du vielleicht eine gangbare Alternative vorzuschlagen? Die gesuchten Merkmale sind ja nur 2 i/o Leitungen, 40 clients. Bei der Recherche sind mir der SMbus begegnet, aber ich fand keine Arduinotauglichen Beispiele dazu.
Moin, SMBus ist so ziemlich das Selbe wie I2C. Zumindest von der Hardware her koennte es sein, dass ein lustiger Kreis aus allen Beteiligten, wo jeweils ein UART Ausgang auf den UART Eingang eines Nachbarn geht, funktionieren koennte. Braucht auch nur einen I und einen O pro Teilnehmer. Da muss wenigstens ein Ausgang immer nur eine Leitung und nur einen Eingang treiben, die Richtung ist klar und es kann mit Push/Pull Ausgaengen und damit definierten Impedanzen auf der Leitung gearbeitet werden. Braucht aber noch ein Protokoll in Software, was irgendwie Adressen verteilt/beruecksichtigt und Nachrichten fuer andere Devices weiterleitet, etc. pp. Wird wahrscheinlich auch nicht gerade raketenschnell sein. Aber normalerweise wuerde man fuer 40 Teilnehmer eher sowas wie Ethernet nehmen... Gruss WK
Dergute W. schrieb: > Aber normalerweise wuerde man fuer 40 Teilnehmer eher sowas wie Ethernet > nehmen.. Aber nicht für 40x Krümelkram ala AVR. Am Ende ist der Master, ähhh, Leader, mehr mit I2C-Datenverkehr beschäftig als mit allem Anderen. Naja, wenn's scheeee macht https://youtu.be/dPM3wPhaMvE ;-)
Cyblord -. schrieb: > Also wann immer die Platine verlassen wird, sollte > entsprechende Schutzbeschaltung vorhanden sein. An diesen Stellen wird der Bus allerdings in der Regel zu einer Point-To-Point Verbindung degradiert.
Duinocoin? Echt jetzt? Bin ich wohl zu alt für. ;)
Axel R. schrieb: > Duinocoin? Echt jetzt? Das ist der neue Stern am Finanz-Himmel. Werde auch du Reich mit deinem Arduino und einem einfachen Download. Schon bald kannst du dir ein Stück Zucker leisten, oder eine Prise Salz.
Dergute W. schrieb: > Zumindest von der Hardware her koennte es sein, dass ein lustiger Kreis > aus allen Beteiligten, wo jeweils ein UART Ausgang auf den UART Eingang > eines Nachbarn geht, funktionieren koennte. Braucht auch nur einen I und > einen O pro Teilnehmer. Simpel, hat aber auch den Nachteil, das der Kreis immer geschlossen sein muss. Ganz zu schweigen von der Software, die keine Daten verschlucken darf, egal was da komme. Wenn es robust sein soll, würde man hier RS-485 nehmen und eine handvoll Inputs um die individuelle Knotenadresse nicht fest im Code haben zu müssen...
Rene M. schrieb: > Oh, hast du vielleicht eine gangbare Alternative vorzuschlagen? Hab ich weiter oben schon. UART / RS232 braucht auch nur 2 Leitungen. Das ganze auch als Bus aufgebaut werden mit OD Teilnehmern. Sogar als Halbduplex über eine einzige Datenleitung. Natürlich wäre RS481 oder RS485 noch besser. Man kann sich hier auch mal LIN anschauen. Und natürlich CAN. Man muss das Rad nicht neu erfinden. Man muss klar sagen: Ein Bussystem für 40 Teilnehmer kann eben nicht beliebig trival gestaltet sein. Das liegt in der Natur der Sache. Es gibt also eben nicht die extrem simple Lösung die gleichzeitig zuverlässig ist. Ein wenig mehr Aufwand sollte hier ins Auge gefasst werden.
:
Bearbeitet durch User
Stefan ⛄ F. schrieb: > An diesen Stellen wird der Bus allerdings in der Regel zu einer > Point-To-Point Verbindung degradiert. Schon mal Ethernet oder einen beliebigen Feldbus angeschaut? Da wird nichts degradiert und trotzdem hat jeder Teilnehmer meist viel Schutzbeschaltung. Schon wieder deine Weisheiten aus dem Kinderzimmer. Keine Ahnung von echter Technik in einem prof. Umfeld.
:
Bearbeitet durch User
Cyblord -. schrieb: > Schon wieder Ja "schon wieder". Aus dem Zusammenhang gerissen kann man das so werten wie du es gemacht hast. Fühlst du dich jetzt besser?
Vielen Dank @Cyblord! Habe mich gleich drauf gestürzt und ein bisschen was zu deinen Vorschlägen gelesen. * RS485: 32 Teilnehmer, mit Tranceiverbausteinen 256. Naja ich möchte 40 Nodes haben (das ist im Kolka rewardsystem der goldene Schnitt) und zusätzliche Bauteile soweit irgendmöglich vermeiden. * Zu RS481 haben ich überhaupt keine Infos gefunden. Hier und da ein Baustein, aber nichts über das Protokoll. * Den CAN Bus hatte ich so verstanden das er schon Toll ist wegen zuverlässiger Kommunikation über "weite" Strecken. Aber eben auch einiges an Bauteilen braucht. (*)Siehe Nebensatz unten * Die Fehlererkennung des LIN Busses ist sehr interessant. Insbesondere der Bitweise rückvergleich. Was Wikipedia aber mit "maximal 64 Botschaften" meint erschließt sich mir nicht. Für den Augenblick habe ich mir folgendes überlegt: Es gibt eine winzge md5 Library für Arduino. Zudem habe ich mich geirrt was die Nachrichtenlänge angeht, sie muss nicht 2048 Byte sein, sondern "nur" 128. Also dachte ich mir das Wire Protokoll, das eine definiertes Transmissionslimit von 32 Bytes hat zu patchen. Ich sende dann meine (bis zu) 128 Zeichen Nachricht, ergänzt um den 16 Byte langen md5 hash. Auf Empfängerseite kann ich mit wenig load prüfen ob die transmission korrekt war. Allerdings hab ich wohl noch einen Bug drinn. Denn mit der Erhöhung des Buffers auf 144 werden trotzdem nur 32 übertragen. -> hmmm... !? Zeile 29: #define BUFFER_LENGTH 32 https://github.com/arduino/ArduinoCore-avr/blob/master/libraries/Wire/src/Wire.h @derguteweka: Den SMBUS hatte ich im Blick, weil er Adresskollision erkennt und beheben kann (können soll). Anfangs dachte ich das es möglich ist die UniqueID des Atmega328p in eine Adresse zu transformieren. Dann hätte ich auf jeden Chip den gleichen code hochladen können. Was die Nummer mit dem "Token Ring" ähnlichem RS232 angeht: Die Idee hatte was! Leider denke ich aber, dass das Protokoll was ich dazu schreiben müsste (insbesondere die Fehlerkorektur) wirklich umfangreich wäre. Auch hätte jeder Chip mit der Kommunikation der anderen "zu leiden"(rechnen). Wenn ich das missverstanden habe, bitte ich das zu entschuldigen. Grundsätzlich ist das aber die Art von Freigeist, die ich mir hier gewünscht habe ;-) (*) Nochmal an die Zwischenrufe wegen des DuinoCois: Manche lesen Zeitungen, andere schreiben Dedichte. Manche spielen/klicken Facebookspiele, andere schreiben Spiele wie Pong für eine Türsprechanlage. Zitat der Duino Carta:
1 | Preface
|
2 | Duino-Coin has no intention of becoming the best, biggest or most modern crypto. Duino-Coin has no intention of rediscovering privacy either. Duino-Coin does not use complicated systems, algorithms or solutions. And it won't. Because if someone is looking for a cryptocurrency with such requirements, with thousands of different crypto coins in the world they will find it in a few minutes. |
3 | |
4 | However, Duino-Coin is distinguished by its instant transactions, the ability to acquire coins in various ways on a large number of platforms, of global availability, cost-effectiveness, openness, simplicity, ease of exchange and a friendly, growing community of avid miners who also want to contribute to our project. |
5 | |
6 | Duino-Coin is meant to be a platform that allows people to learn something and at the same time earn some money (thanks to already existing exchange services). |
Ich habe eben Lust was zu löten und was zu programmieren. Das darf auch etwas abseits des Standards sein. Ich bin nicht Wegen cryptos hier, sondern weil ich ein paar technisch elektrische Fragen habe. z.B. warum verdammt kann ich den Buffer nicht von 32 auf 144 anheben? ;-) Nichts für ungut! Gruß Rene´
Rene M. schrieb: > Naja ich möchte 40 Nodes haben (das ist im Kolka rewardsystem der > goldene Schnitt) Das aktuelle Web Wallet https://wallet.duinocoin.com/ hat einen Earnings Calculator: 1 Arduino 7,68 D/day, 10 Arduinos 53,19 D/day, 40 Arduinos 62,52 D/day.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.