Hallo, in einem Schulprojekt habe ich die Aufgabe Lenkung und Gas/Bremse für ein Fahrzeug zu entwickeln. Habe nun einen alten Joystick genommen und mittels AD-Wandler eines Atmega die Potistellungen in x- und y-Werte von -8 bis 8 umgerechnet. Meine Idee: PortX nehmen und die Werte folgendermaßen an den Steuerungcontroller übergeben: Bit0: Rückwärts/ Vorwärts (0 - Rückwärts, 1 - Vorwärts) Bit1..3: Geschwindigkeit (0 - 8, s.o.) Bit4: Rechts/ Links (0 - Rechts, 1 - Links) Bit5..7: "Stärke" der Lenkung Parallele Übertragung deshalb, weil genügend Portpins vorhanden sind und es einfach einfach ist. Sieht da jemand Nachteile, gibts Verbesserungsvorschläge? Die Werte werden dann vom Steuerungscontroller in PWM-Werte umgerechnet und entsprechend H-Brücken angesteuert.
Nils Friess schrieb: > Parallele Übertragung deshalb, weil genügend Portpins vorhanden sind und > es einfach einfach ist. Ist es das? Wirklich? Dann muss der zweite Controller ständig alle Portpins überwachen, damit er mitbekommt, daß sich etwas geändert hat. Bei einer gezielteren Art der Kommunikation würde der erste Controller dem anderen mitteilen, was sich geändert hat, und so dieses ständige Überwachen durch den zweiten Controller entfallen. Wenn schon zwei Controller verwendet werden, wird das einen Grund haben, nämlich z.B. unzureichende Rechenleistung. Will man die durch das ständige Überwachen unnötig verballern?
Bist Du Dir sicher, dass sich alle Pins einer Gruppe immer GLEICHZEITIG ändern? Ich nicht. Das führt dann früher oder später zu Übertragungsfehlern. Du brauchst mindestens ein Taktsignal, mit dem Du dem anderen Controller sagst, dass ein neuer Wert anliegt. Wenn Du dann einen modernen AVR mit Pin Change Interrupts verwendest (also zB Mega 324 statt Mega 32), dann kann jeder Portpin einen Interrupt auslösen. Ansonsten muss das Taktsignal an einen der Interrupt-Pins des empfangenden AVRs gehen. Zudem würde ich mit Zweierkomplement-Zahlen arbeiten statt Vorzeichen/Richtung+Wert.
Erstmal danke für die Anmerkungen. Also wir haben uns das eher so vorgestellt, dass nicht nach eine Änderung geschaut wird, sondern einfach regelmäßig die Portpins abgefragt werden (in bspw. 100ms Intervallen). Zwei Controller werden nicht mangels Rechenleistung verwendet, sondern einfach als Übungsaufgabe in der Schule, die langweilen sich zwar beide zu Tode, aber ist eben so. SPI wäre natürlich auch eine Möglichkeit, ist einfach zu realisieren und wird von fast allen Controllern sogar in Hardware unterstützt. Ich denke wir versuchen das mal mit der parallelen Übertragung und schauen was dabei raus kommt. Da das ganze nicht in Serie gehen soll und einfach nur zur Übung dienen soll ist es letztendlich egal wie - Hauptsache es funktioniert ..
Erinnert mich an den alten Druckerport: http://computer.howstuffworks.com/parallel-port1.htm Zumindest das Strobe-Signal würde ich auch einbauen. Ansonsten kannst du nicht sicher sein ob beim Einlesen die Bits wirklich richtig stehen.
Hi, ich würde es, auch (oder gerade weil es zum lernen gedacht ist), per SPI, oder UART machen. Das wäre einfach viel Praxisnaher als es so zu scannen. Zudem habt ihr so den Vorteil, das der der Steuer-Controller so direkt per Interrupt informiert wird (sobald neue Daten vorhanden sind), und nicht erst etwas sporadisch abfragen muss. Bei UART hättet ihr zusätzlich den Vorteil, die Controller einfacher vom PC aus testen zu können, falls er nicht das tut, was ihr erwartet, habt ihr gleich eine Möglichkeit Fehler ausgeben zu lassen.
Rufus Τ. Firefly schrieb: > Ist es das? Wirklich? Dann muss der zweite Controller ständig alle > Portpins überwachen, damit er mitbekommt, daß sich etwas geändert hat. Es gibt noch etwas anderes als den Atmega8. Nämlich Controller mit Pin-Change-Interrupt. Aber trotzdem ist die serielle der parallelen Übertragung überlegen. mfg.
Thomas Eckmann schrieb: > Rufus Τ. Firefly schrieb: >> Ist es das? Wirklich? Dann muss der zweite Controller ständig alle >> Portpins überwachen, damit er mitbekommt, daß sich etwas geändert hat. > > Es gibt noch etwas anderes als den Atmega8. Nämlich Controller mit > Pin-Change-Interrupt. Aber trotzdem ist die serielle der parallelen > Übertragung überlegen. > > mfg. Es wird nur blöderweise ein 8051 als Steuerungscontroller verwendet (nein, das lässt sich nicht ändern). Wir werden jetzt mal die parallele Übertragung testen, evtl. mit weiterem Steuerbit (Port zum auslesen bereit). Klappt das nicht richtig oder ist am Ende noch genug Zeit werden wir wohl auf SPI umsteigen (was der 8051 aber nicht in Hardware unterstützt ergo keine Interrupts).
:
Bearbeitet durch User
Warum dann nicht UART ? Das hat der 8051 doch eingebaut und es ist einfach zu debuggen, was gerade bei so einer Übungsaufgabe sicher nicht verkehrt ist.
Hi Wenn er doch parallel kommunizieren will, dann lasst ihn doch. Der richtige Hinweis dazu: Daten sind bereit-Signal. Ihr müsst niemandem Äpfel andrehen wollen, der Bananen möchte... Irgendwann wird er sich schon um die serielle Übertragung einen Kopf machen. Gruß oldmax
Nils Friess schrieb: > Wir werden jetzt mal die parallele Übertragung testen, evtl. mit > weiterem Steuerbit (Port zum auslesen bereit). Du brauchst zwei Handshake Signale, nicht eines, sonst wird das nichts. Der Sender muss mitteilen können (Strobe) dass seine Daten bereit sind, der Empfänger muss bestätigen (ACK) dass er Daten empfangen hat, damit der Sender weiss dass er ein neues Datum senden kann.
Also wir haben heute die parallele Übertragung getestet - funktioniert einwandfrei und da die Werte andauernd gepollt werden ist es auch nicht schlimm, falls mal Unsinn gelesen wird. Wir versuchen dennoch das ganze per UART zu lösen (ist ja kein großer Mehraufwand, das Byte das an dem Port lag wird jetzt einfach über die serielle geschickt), da Steuerung und Bedieneinheit doch weiter auseinander liegen als gedacht (Verkabelung gering halten).
Mitlesa schrieb: > [...] der Empfänger muss bestätigen (ACK) dass er Daten > empfangen hat, damit der Sender weiss dass er ein neues Datum > senden kann. Nein, muss er nicht. Der Empfänger darf halt nur dann lessen, wenn das Strobe-Signal gesetzt ist und der Sender muss garantieren, dass das Signal nach Wegnehmen des Strobes noch solange Anliegt, wie der Empfänger zum lessen benötigt. Der Sender muss also - Daten anlagen - Strobe setzen - warten - Strobe wegnehmen - warten TD
tastendrücker schrieb: > Der Sender muss also Das geht leider nur dann sicher, wenn der Sender garaniert langsamer sendet als der Empfänger empfangen kann, sonst gibt es einen Overrun. Aber du bist dir ja gaaaanz sicher dass das nicht passiert, gelle? Weil du ja durch die Leitung zum Empfänger "sehen" kannst.
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.