Hallo, ich benötige mal einen Denkanstoß :) ich habe zwei Mikrocontroller-Platinen, die beide mit unterschiedlichen Takten arbeiten (20MHz, kleiner PIC mit 8-Bit und 24 MHz, kleiner ATMEL 8-Bit). Platine 1 überwacht diverse Sensoren und ich möchte im Problemfall einen Fehler an Platine 2 - die Kommunikationsplatine - melden. Die Kommunikationsplatine lässt eine Meldung auf einem Bildschirm erscheinen und erwartet eine Freigabe vom Benutzer durch drücken einer Taste. Wenn die Taste gedrückt wurde, so soll Platine 2 dies der Platine 1 mit der Sensorik mitteilen. Ein einfaches HIGH im Optimalfall müsste auch hier wieder ausreichen. Das HIGH von Platine 1 geht dann im Optimalfall mit dem HIGH von Platine 1 wieder LOW. Also sozusagen ein Handshake. Meine Frage nun ist... inwiefern bereiten die beiden unterschiedlichen Takte in diesem Fall Probleme und wie könnte ich diese Probleme umgehen? Ich möchte KEIN UART, SPI oder Ähnliches verwenden und auch nicht aus beiden Platine eine basteln. Das muss doch auch anders gehen über die GPIOs z.B.? Die Zeit ist nicht so kritisch. Darf auch verhältnismäßig langsam sein. Gruß Dennis
Und wo ist das Problem? Einfach machen. Wenn Du den Sendertreiber auf weak stellst kann der Empfänger auf derselben Leitung den Empfang quittieren, dann brauchst Du nur eine Leitung. Keine Ahnung ob AVR das kann.
Dennis schrieb: > Meine Frage nun ist... inwiefern bereiten die beiden unterschiedlichen > Takte in diesem Fall Probleme und wie könnte ich diese Probleme umgehen? welche Probleme sollen denn dabei entstehen? Taster und Schalter haben gar keinen Takt und können auch an einen µC angeschlossen werden. > Ich möchte KEIN UART, SPI oder Ähnliches verwenden und auch nicht aus > beiden Platine eine basteln. das ist aber die ausbaufähigste Lösung die noch die wenigsten Leitungen braucht. > Das muss doch auch anders gehen über die > GPIOs z.B.? Die Zeit ist nicht so kritisch. Darf auch verhältnismäßig > langsam sein. dann mach es doch einfach, einfach einen IN mit einen OUT verbinden und schon kannst du eine 0 oder 1 übertragen.
Dennis schrieb: > Meine Frage nun ist... inwiefern bereiten die beiden unterschiedlichen > Takte in diesem Fall Probleme und wie könnte ich diese Probleme umgehen? Du wartest einfach auf das HIGH der Gegenseite (auf das Handshake) - da ist die unterschiedliche Geschwindigkeit egal.
Dennis schrieb: > inwiefern bereiten die beiden unterschiedlichen > Takte in diesem Fall Probleme und wie könnte ich diese Probleme umgehen? Keine. Alle IOs werden vom MC mit seinem Takt gelatcht. Selbst 2 gleich MCs am selben Takt sind nie synchron, da sie ja unterschiedliche Programme abarbeiten.
hast Du freie Verbindungen zwischen den Platinen? wendelsberg
Peter Dannegger schrieb: > Dennis schrieb: >> inwiefern bereiten die beiden unterschiedlichen >> Takte in diesem Fall Probleme und wie könnte ich diese Probleme umgehen? > > Keine. > Alle IOs werden vom MC mit seinem Takt gelatcht. > > Selbst 2 gleich MCs am selben Takt sind nie synchron, da sie ja > unterschiedliche Programme abarbeiten. Danke. Ich bin blutiger Anfänger was Mikrocontroller und deren Programmierung betrifft. Habe bisher nur brauchbare VHDL und FPGA Kenntnisse und ich hatte irgendwie ein taktflankengesteuertes Verhalten vor Augen. Und da könnte es ja durchaus passieren, dass es beim Handshake zu Problemen kommt wenn Signal 1 (Req) oder Signal 2 (Ack) des Handshakes zu lang / zu kurz ist. wendelsberg schrieb: > hast Du freie Verbindungen zwischen den Platinen? > > wendelsberg Ja, aber nur GPIO. Der kleine PIC hat auch kein UART / SPI in Hardware. Deswegen die einfache Idee mit dem Handshake.
Dennis schrieb: > Ja, aber nur GPIO. Der kleine PIC hat auch kein UART / SPI in Hardware. > Deswegen die einfache Idee mit dem Handshake. Na denn, das Druecken der Taste setzt einen Ausgang, der setzt ueber einen Draht einen Eingang, der wird am 2. uC eingelesen. wendelsberg
>Habe bisher nur brauchbare VHDL und FPGA Kenntnisse Ohne davon Ahnung davon zu haben, halte ich das für eine brauchbare Grundlage. >und ich hatte irgendwie ein taktflankengesteuertes Verhalten vor Augen. Auch das ist nicht die schlechteste Idee. >Und da könnte es ja durchaus passieren, dass es beim Handshake zu Problemen kommt wenn Signal 1 (Req) oder Signal 2 (Ack) des Handshakes zu lang / zu kurz ist. Das lässt sich doch durch ein fest definierte Timing/Ablauflogik erledigen. Etwas Raum für Unschärfen lassen.... >Darf auch verhältnismäßig langsam sein. Je langsamer, desto leichter/kleiner die Timing Probleme... >Ja, aber nur GPIO. Der kleine PIC hat auch kein UART / SPI in Hardware. Deswegen die einfache Idee mit dem Handshake. Warum für beide Seiten ein proprietäres Protokoll entwickeln? Mein Tipp: Die üblichen Schnittstellen und Protokolle sind erprobt, stabil und weit verbreitet. Der Atmel hat da schon einiges in Hardware gegossen und es gibt fertige Libs für den Rest. Für den Pic gibts da bestimmt auch reichlich. Verwendest du eine der üblichen Schnittstellen, hast du weniger Arbeit, und kannst die Geräte später leichter gegen andere austauschen. Beispiel: Setzt du auf UART, könntest du mit jedem beliebigen seriellen Monitor die Kommunikation beobachten. Die Geräte einzeln an der Konsole probefahren, bevor du sie zusammen klemmst. Alternativ kannst du natürlich eine eigenes Protokoll entwickeln ..... Aber dann frage ich mich irgendwie, warum du überhaupt hier fragen musst?
Ulrich F. schrieb: > Verwendest du eine der üblichen Schnittstellen, hast du weniger Arbeit, > und kannst die Geräte später leichter gegen andere austauschen. Das wäre ja zu einfach, den PIC mit einem Dreizeiler als SPI-Master und den AVR mit seinem eingebauten SPI oder USI als Slave zu betreiben mfg.
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.