ZitierenDann doch lieber USART, SPI oder I2C.
Da musst du dich einfach um weniger kümmern. Außerdem lassen sich damit auch sehr hohe Geschwindigkeiten erreichen.
Was genau hast du denn vor?
Hallo allerseits!
Ich bereite ein Projekt vor, bei dem 2 ATmegas miteinander über 4 Leitungen kommunizieren sollen. 2 davon sind Datenleitungen. Über die 1. Datenleitung sendet der 1. ATmega und über die 2. der andere. Die beiden anderen Leitungen sind "OK-Bit" Leitungen.
Das Protokoll soll nun so funktionieren:
Möchte ATmega A Daten senden legt er eine 1 oder eine 0 auf die seine Datenleitung und verändert sein OK-Bit. ATmega B erkennt die Veränderung des OK-Bits und und speichert die 1 oder die 0 die an der Datenleitung anliegt ab, gleich danach verändert ATmega B sein OK-Bit zur Bestätigug. So erkennt ATmega A, dass ATmega B wieder bereit ist um weitere Daten zu empfangen. Also legt ATmega A das nächste Datenbit auf die seine Datenleitung und verändert sein OK-Bit. ATmega B erkennt nun wieder die Veränderung des OK-Bits und speichert das Datenbit ab und verändert sein eigenes OK-Bit als Bestätigung für den Empfang. Dann geht es wieder von vorne los.
Das ganze hat den Sinn, dass Daten sozusagen mit beinahe dem maximalen Takt übertragen werden und dass ein neues Bit aber auch immer erst gesendet wird wenn der Empfänger (in diesem Fall ATmega B) bereit ist ein neues Bit zu empfangen.
Meint ihr das könnte so funktionieren oder ist es doch besser einen vordefinierten Takt zu verwenden?
Dann doch lieber USART, SPI oder I2C.
Da musst du dich einfach um weniger kümmern. Außerdem lassen sich damit auch sehr hohe Geschwindigkeiten erreichen.
Was genau hast du denn vor?
Was hindert dich daran, eines der eingebauten Kommunikationsmodule (USART, SPI, TWI) zu verwenden? Im Gegensatz zu deiner Softwarelösung kann man da nebenher sogar noch andere Aktivitäten durchführen.
mfG
Markus
Es soll ein Roboter werden, bei dem sich mehrere Microcontroller die Aufgaben teilen. Ein ATmega ist für die Sensoren zuständig, ein anderer kümmert sich um die Motoren und noch einer ist für das Display und die Bedientasten verantwortlich. Alle diese uC sollen Daten zu einem zentralen ATmega senden und empfangen können. Der "Zentralatmega" entscheidet dann was geschehen soll, nachdem ein Sensor ausgelöst wurde.
Vom I2C und vom SPI habe ich schon gehört.
Das klingt sehr überzeugend und nachdem es mit I2C wohl wirklich viel einfacher ist werde ich jetzt es natürlich auch verwenden.Im Gegensatz zu deiner Softwarelösung kann man da nebenher sogar noch andere Aktivitäten durchführen.
Wenn der zentrale ATmega die Funktion des Masters übernimmt, dann ist der "Sensoratmega" ein Slave. Und der kannn dann doch nur senden, wenn er vom Master gefragt wird, oder?
Da der Master ja nicht weiß wann ein Sensor augelöst wird, müsst er den "Sensoratmega" doch ständig abfragen, oder gibt es auch hier eine bessere Möglichkeit?
Natürlich kann der andere Controller auch von sich aus etwas senden.Und der kannn dann doch nur senden, wenn er vom Master gefragt wird, oder?
Nennt sich dann Multi-Master. Da muss man dann aber aufpassen und sich was einfallen lassen, wenn 2 Teilnehmer gleichzeitig senden wollen.
Alternative wäre noch CAN, aber für den Bereich evtl. Overkill.
Bei CAN gibts dann halt keinen Master mehr, sondern jeder Sendet einfach drauf los und holt sich das vom Bus, was ihn interessiert.
#ifndef MfG
#define MfG
Könnte man das Multi-Master-System mit einer zusätzlichen Leitung realisieren, die der zentrale Masteratmega immer auf high zieht bevor er etwas sendet und nach dem senden wieder auf low legt? So weiß der Sensoratmega immer wann er senden darf.Da muss man dann aber aufpassen und sich was einfallen lassen, wenn 2 Teilnehmer gleichzeitig senden wollen.
Ist kein Problem. Muss man halt dann selbst einbauen.
Was ähnliches gibts aber für den normalen Master-Slave-Betrieb auch. Hier hat der Slave eine Leitung, an der er zupft, wenn er was neues hat. Der Master fragt ihn dann ab.
Ist z.B. beim RNKeyLCD so; hat man eine Taste gedrückt, wird die Leitung auf Low gezogen. Sobald der Master die Taste abgefragt hat, wird die Leitung wieder losgelassen.
#ifndef MfG
#define MfG
Das ist überhaupt die beste Lösung!Was ähnliches gibts aber für den normalen Master-Slave-Betrieb auch. Hier hat der Slave eine Leitung, an der er zupft, wenn er was neues hat. Der Master fragt ihn dann ab.
Auf jeden Fall vielen Dank!
Und ich werde jetzt einfach ein bisschen experimentieren.
Berechtigungen
Lesezeichen