hallo, kann ich zwei Arduino (X&Y) im gleichtakt arbeiten lassen indem ich von beiden deren XTAL1 von board X mit XTAL1 von board Y und XTAL2 von board X mit XTAL2 von board Y miteinander verbinde? also ohne deren 16MHz quarz auszubauen oder so. würden die dann immer noch mit 16MHz schwingen? ich möchte so wenig wie möglich and hard- und software anpassen müssen.
beta-tester schrieb: > kann ich zwei Arduino (X&Y) im gleichtakt arbeiten lassen indem ich von > beiden deren > > XTAL1 von board X mit XTAL1 von board Y und > XTAL2 von board X mit XTAL2 von board Y miteinander verbinde? Nein, du darfst nicht zwei Ausgänge miteinander verbinden. Du könntest allerdings beim zweiten die Fuses auf externen Clock stellen und dann den Taktausgang des ersten mit dem Takteingang des zweiten verbinden.
Dann sind die aber aufgrund verschiedener Startupzeiten des Oszillators, trotzdem nicht synchron. Oder irre ich mich da?
Einer schrieb: > Oder irre ich mich da? Nein, es wäre selbst für einen sehr guten Programmierer nur sehr aufwendig zu schaffen zwei Prozessoren synchron laufen zu lassen, die Software müsste komplett auf diesen Zweck ausgerichtet sein. Und der TO ist nicht einmal ein schlechter Programmierer, nach eigener Einschätzung (was zu loben ist, die meisten hier überschätzen ihre Fähigkeiten masslos). Georg
Georg schrieb: > die Software müsste komplett auf diesen Zweck ausgerichtet sein Die Hardware auch, man bräuchte zumindest irgend eine Sync-Leitung zwischen den beiden Bausteinen. Ansonsten wird es sich gar nicht vermeiden lassen, dass die Systeme selbst bei identischer Taktversorgung aufgrund irgendwelcher Unterschiede früher oder später auseinander laufen. Das können auch so unbeherrschbare Dinge sein wie: Bei Chip B lösen die Schmitt-Trigger Eingänge durch Fertigungsschwankungen 0,5V später aus, und weil das Eingangssignal langsam steigt, sind damit sämtliche Interrupts "zu spät".
beta-tester schrieb: > kann ich zwei Arduino (X&Y) im gleichtakt arbeiten lassen Bei solchen Fragen würde mich immer das eigentliche Problem interessieren, wenn schon die geplante Lösung dieses Problems so durch die Brust ins Auge geht... beta-tester schrieb: > ich möchte so wenig wie möglich and hard- und software anpassen müssen. Um das zu beurteilen müsste man Hard- und Software kennen. Aber wenn mich mein Chef mit Geld dazu zwingen würde, so ein Gebastel zu machen, dann würde ich 1 Stück 16MHz Oszillator nehmen, beide µC damit takten und über eine gemeinsame Resetleitung die beiden µC "gleichzeitig" loslaufen lassen. Naja, wenigstens ziemlich "gleichzeitig".
:
Bearbeitet durch Moderator
Ein Kollege hatte mal das Problem, bis zu 4 DDS AD9835 phasengleich zu starten, das ist nicht so einfach. Ich würde einen Quarz einseitig auslöten und so stilllegen. Den Ausgang des noch schwingenden Quarzoszillators kann man noch auf mindestens einen weiteren Arduino-Quarzeingang legen, bei 16 MHz machen 10 cm Verbindung noch keine Probleme. Mit einem gemeinsamen Resetpuls sollten beide nahezu synchron starten. >einen DualCore zu verwenden "statt des ELefanten können auch Erdbeeren genommen werden" (Loriots Kochrezepte)
Einer schrieb: > Dann sind die aber aufgrund verschiedener Startupzeiten des Oszillators, > trotzdem nicht synchron. Nicht nur das, auch Interrupts lassen sie allmählich immer weiter auseinander laufen.
100Ω W. schrieb: > Wäre es nicht sinnvoller einen DualCore zu verwenden, z.B. den RP2040? Ich denke das ändert nichts daran, dass die Kerne im Laufe der zeit immer weiter auseinander laufen.
Es müssten dann ja beide die selbe Software abarbeiten. Welchen Sinn hat das? Dann wäre z.B. der selbe Algofehler in beiden drin. Selbst ein Vergleich von Ergebnissen aus Sicherheitsaspekten bringt einen in dem Fall nicht viel weiter: welcher war den der, der keinen Fehler gemacht hat? Ich weiß dann nur, ja es ist etwas schief gegangen - gut, vielleicht reicht das ja.
Ja genau. Es ist sogar noch schwieriger: Mal angenommen der erste Mikrocontroller erkennt einen Tastendruck jetzt, und der andere erst einen Takt später. Welcher der beiden hat Recht? Beide! Solche race Condition können bei allen asynchronen Signalen auftreten, die nicht ebenfalls mit dem Takt synchronisiert wird. In der Praxis sind wohl fast alle Signale an Eingängen asynchron. Was ist mit analogen Spannungen, die ausgewertet werden? Je nach Spannungswert dauern Berechnungen unterschiedlich lange. Dass beide Mikrocontroller mit ihren ADC immer auf exakt den selben Wert kommen ist praktisch unmöglich.
Mein Gott, was für eine Hysterie schon wieder. Wir wissen gar nicht, warum der OP meint, die beiden Arduinos mit einem Takt laufen lassen zu müssen. Das heißt nicht zwingend, daß sie synchron ihre Programme ausführen. Wer schon länger hier mitliest weiß, daß 99% dieser Ideen Unfug sind. So vermutlich auch diese.
Falk B. schrieb: > was für eine Hysterie schon wieder Wo? Ich sehe keine Hysterie. Das die Idee wahrscheinlich Unfug ist haben andere bereits geschrieben und begründet.
Stefan ⛄ F. schrieb: > Wo? Ich sehe keine Hysterie So wie gewisse Kanzler keine gesellschaftliche Spaltung sehen . . . Die ganze Diskussion ist SINNLOS, denn es fehlen wesentliche Angaben des OP. Die Fragen dazu wurden gestellt, also sollte man auf die Antwort warten und nicht end- und sinnlos rumlabern.
@TO: du merkst, das ganze ist gar nicht so einfach, und wird auch außeinanderdriften. Mehr Sinn würde es m.E. machen, wenn man die Software synchronisiert. Was sollen die Arduinos den machen? Lässt sich nicht ggf. alles auf einen Arduino unterbringen? Wie synchron müssen die den wirklich laufen? Mein erster Gedanke zum synchronisieren der Software wäre, den Startzeitpunkt der Durchläufe der Loop-Schleife zu synchronisieren. Dazu würde ich versuchen, jeweils zwei Pins der Arduinos zu verbinden, also jeweils digitalOutput auf digitalInput, gerne auch über Kreuz, dann muss man die Software nicht anpassen. Im Setup wird der Ausgangspin auf Low gezogen. Zu Beginn des Loops wird der Ausgang auf High geschaltet und z.B. mit einer while-Schleife solange gewartet, bis der Eingang ebenso auf High geht. Wenn die while-Schleife verlassen wird, wird der Ausgang sofort wieder auf Low gesetzt. Ich habe das allerdings noch nie ausprobiert. Darum keine Ahnung wie das in der Praxis funktioniert, und welche Fallstricke es gibt. Wenn ich jetzt allerdings dein Problem tippen dürfte, würde ich sagen, dass du mit den zwei Arduinos irgendein LED-Gefoppel ansteuerst, und dir das mit der Zeit auseinander läuft. Da muss dann so eine exakte Synchronisierung gar nicht sein. Sehr wahrscheinlich langweilen sich die Arduinos auch die meiste Zeit und mit etwas Code-Anpassung wäre es möglich, alles mit einem Arduino anzusteuern.
Beitrag #6946192 wurde von einem Moderator gelöscht.
Beitrag #6946196 wurde von einem Moderator gelöscht.
verzeihung, dass ich den eigentlichen zweck nicht mit angegeben habe und damit eine unnötig hitzige diskusion angestoßen habe. es geht mir eigentlich darum zu verstehen warum auf dem Arduino UNO rev.3 bei dem projekt http://amiga.robsmithdev.co.uk/instructions/uno nicht die bordeigene serial-nach-USB lösung benutzt werden kann. der Arduino UNO rev.3 mit dem Atmel16U2 als serial-nach-USB und dem Atmel328P als haupt µC haben beide 16MHz. laut datenblatt sollte der Atmel16U2 ebenfalls in der lage sein 2.000.000bps zu unterstützen. da war meine vermutung, dass die beiden µC eventuell langsam leicht auseinander driften und dadurch probleme mit der datenübertragung entstehen. um zu sehen, ob sich das anders verhält, wenn beide µC mit der selben taktquelle arbeiten, hatte ich halt die frage wie man das am einfachsten bewerkstelligen könnte ohne viel herumlöten zu müssen oder irgend welche fuses zu ändern. aber das schein dann wohl ein echter bullshit-gedanke gewesen zu sein. also verzeihung nocheinmal.
Beitrag #6946218 wurde von einem Moderator gelöscht.
beta-tester schrieb: > es geht mir eigentlich darum zu verstehen warum auf dem Arduino UNO > rev.3 bei dem projekt http://amiga.robsmithdev.co.uk/instructions/uno > nicht die bordeigene serial-nach-USB lösung benutzt werden kann. Steht das nicht auf der Seite? "The onboard USB to Serial interface isn't able to keep up with the throughput of data this project requires. Also, to write disks, the Arduino needs access to the CTS pin on the RS232 interface to control the flow of data (This pin also isn't available either). This means we have to use a separate board as follows:" > der Arduino UNO rev.3 mit dem Atmel16U2 als serial-nach-USB und dem > Atmel328P als haupt µC haben beide 16MHz. laut datenblatt sollte der > Atmel16U2 ebenfalls in der lage sein 2.000.000bps zu unterstützen. Mag sein, aber dazu muss man ggf. die Software dort drin ändern. > da war meine vermutung, dass die beiden µC eventuell langsam leicht > auseinander driften und dadurch probleme mit der datenübertragung > entstehen. Nö. > um zu sehen, ob sich das anders verhält, wenn beide µC mit der selben > taktquelle arbeiten, hatte ich halt die frage wie man das am einfachsten > bewerkstelligen könnte ohne viel herumlöten zu müssen oder irgend welche > fuses zu ändern. Ganz schlechte Idee. Man sollte schon DIREKT fragen, und nicht dreimal um die Ecke denken! Siehe https://www.mikrocontroller.net/articles/Netiquette#Klare_Beschreibung_des_Problems
Beitrag #6946224 wurde von einem Moderator gelöscht.
Beitrag #6946228 wurde von einem Moderator gelöscht.
Beitrag #6946232 wurde von einem Moderator gelöscht.
Beitrag #6946240 wurde von einem Moderator gelöscht.
Angehängte Dateien:
-
SCRN0087.PNG
4,3 KB
Also zumindest schafft der Arduino UNO die 2Mbd, siehe Anhang. Die Handshakeleitungen sind allerdings nicht verfügbar und bei einem QFN-Gehäuse auch schlecht per Klingeldraht kontaktierbar.
beta-tester schrieb: > hallo, > kann ich zwei Arduino (X&Y) im gleichtakt arbeiten lassen indem ich von > beiden deren > XTAL1 von board X mit XTAL1 von board Y und > XTAL2 von board X mit XTAL2 von board Y miteinander verbinde? > also ohne deren 16MHz quarz auszubauen oder so. > würden die dann immer noch mit 16MHz schwingen? > ich möchte so wenig wie möglich and hard- und software anpassen müssen. Ja das geht. DC ist Gleich- und AC ist Anderstspannung. Einfach AC anschließen. Alternativ im C-Kot Synchro definieren: A = 0; B = 0; B != A
Falk B. schrieb: > Also zumindest schafft der Arduino UNO die 2Mbd war nicht die allgemeingültige Bedingung CLK 16x Baudrate was nur 1 MBd bedeutet? Tatsache bleibt das wUSB und sharkoon USBwebserver sicher nur 57k6 schaffen leider
Joachim B. schrieb: >> Also zumindest schafft der Arduino UNO die 2Mbd > > war nicht die allgemeingültige Bedingung CLK 16x Baudrate was nur 1 MBd > bedeutet? Es gibt den /8 Modus.
Falk B. schrieb: > Es gibt den /8 Modus. ich weiss ist aber contraproduktiv den Takt /8 zu teilen um 1M oder 2M Baudrate zu erreichen! rem der Takt muss 16x Baudrate minimum sein! https://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Der_UART Du musst (solltest) schon im Kontext bleiben, die 2Mbd kamen von dir Falk B. schrieb: > Also zumindest schafft der Arduino UNO die 2Mbd und widerspricht dem µC Wiki mit dem 16-fachen AVR Clock! Das würde ja AVR Clock von 32MHz bedeuten
:
Bearbeitet durch User
Joachim B. schrieb: > Falk B. schrieb: >> Es gibt den /8 Modus. > > ich weiss ist aber contraproduktiv den Takt /8 zu teilen um 1M oder 2M > Baudrate zu erreichen! Du hast mich nicht verstanden. Es gibt einen UART-Modus, wo dieser nur den 8fach höheren Takt braucht als die Datenrate, aka double speed mode. Gibt es für das SPI und auch UART. > rem der Takt muss 16x Baudrate minimum sein! > https://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Der_UART Nö. Dieser Artikel ist vielleicht richtig, aber unvollständig. Edit. Nö, es steht drin! U2X (Double the transmission speed) RTFM!
:
Bearbeitet durch User
Falk B. schrieb: > Du hast mich nicht verstanden. Es gibt einen UART-Modus, wo dieser nur > den 8fach höheren Takt braucht als die Datenrate, aka double speed mode. dann schreib das doch und nicht nur verkürzt /8 denn /8 hat mit Falk B. schrieb: > U2X (Double the transmission speed) ja wenig zu tun!
Joachim B. schrieb: > dann schreib das doch und nicht nur verkürzt /8 denn /8 hat mit > > Falk B. schrieb: >> U2X (Double the transmission speed) > > ja wenig zu tun! Wieso? Das hat doch außer dir jeder verstanden.
Dyson schrieb: > Wieso? Das hat doch außer dir jeder verstanden. Unfug, U2X hätte vollständig genügt und ist nicht /8 Fuse Arduino mit U2X und 16 MHz ist mit /8 schon SEHR um die Ecke gedacht! /8 da fällt einem sofort die /8 Fuse ein! Er hatte es wohl im Kopf aber nicht rausgelassen ;-)
:
Bearbeitet durch User
Joachim B. schrieb: > Fuse "Fuse" schreibst du jetzt aber in diesem Zusammenhang zum ersten Mal... Die SIO kann 8-faches oder 16-faches Oversampling. Bei 16MHz Takt und 2MBd geht natürlich mit nur 8-faches Oversampling mit "Vorteiler=1".
Lothar M. schrieb: > Joachim B. schrieb: >> Fuse > "Fuse" schreibst du jetzt aber in diesem Zusammenhang zum ersten Mal... ist immer das Erste was MIR bei /8 in den Kopf kommt, soweit um die ecke wie Falk denke ich halt nicht 16-fach oversampling mit UX2 ist irgendwie zwar auch :8 aber das X2 in UX2 lässt nicht gerade eine Division durch 8 erahnen
Chris schrieb: > Hast du zwei Pins frei? ja, da sind noch 3 pins (A3,A4,A5) frei zur verfügung. Falk B. schrieb: > Also zumindest schafft der Arduino UNO die 2Mbd, siehe Anhang. Die > Handshakeleitungen sind allerdings nicht verfügbar und bei einem > QFN-Gehäuse auch schlecht per Klingeldraht kontaktierbar. die CTS leitung soll angeblich nur zum schreiben der disketten benutzt werden, ich will aber nur lesen. laut chat/forum sollen die probleme mit 2Mbps beim Arduino UNO eigenen seriel<->USB nicht sofort auftreten sondern erst nach einigen 1000 bytes permanenter übertragung. Joachim B. schrieb: > Falk B. schrieb: >> Also zumindest schafft der Arduino UNO die 2Mbd > > war nicht die allgemeingültige Bedingung CLK 16x Baudrate was nur 1 MBd > bedeutet? laut datenblatt BAUD = fosc / (8 * (UBRRn + 1)), wenn U2Xn = 1 (Async. Double Speed) https://ww1.microchip.com/downloads/en/DeviceDoc/ATmega48A-PA-88A-PA-168A-PA-328-P-DS-DS40002061B.pdf#G3.1199934 2Mbps bei fosc = 16MHz, UBRRn = 0, U2Xn = 1 https://ww1.microchip.com/downloads/en/DeviceDoc/ATmega48A-PA-88A-PA-168A-PA-328-P-DS-DS40002061B.pdf#G3.3112384
ich habe gerade im chat erfahren dass nicht die 2Mbps der seriellen schnittstelle das problem sind, sondern der USB-stack des AT16U2 der bordeigenen serial-nach-USB lösung. ist die firmware des 16U2 serial-to-USB open source und könnte man dort noch mehr rausholen, wenn man denn ahnung davon hätte? gibt es schon irgendwo optimiertere firmware?
Falk B. schrieb: > Die > Handshakeleitungen sind allerdings nicht verfügbar und bei einem > QFN-Gehäuse auch schlecht per Klingeldraht kontaktierbar. Ganz so schlimm ist es nicht. 4 Pins sind herausgeführt! frei. Dazu wird allerdings die Software auf dem 16U2 modifiziert werden müssen, um da DSR raus zu bekommen.
beta-tester schrieb: > Joachim B. schrieb: >> Falk B. schrieb: >>> Also zumindest schafft der Arduino UNO die 2Mbd >> >> war nicht die allgemeingültige Bedingung CLK 16x Baudrate was nur 1 MBd >> bedeutet? > > laut datenblatt war doch schon längst geklärt, guten morgen! Du hast den Thread also nicht komplett gelesen oder nicht verstanden was ich meinte! wer mit /8 um die Ecke kommt aber U2X Register meint der drückt sich eben unklar aus oder hat um die Ecke gedacht! Frage 100 AVR Programmierer und frage nach /8 ich glaube über 90% denken an die div8 Fuse, wer UX2 meint kann das auch benennen!
:
Bearbeitet durch User
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.