Handshake zwischen zwei Microcontrollern

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.

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?