PIC "Shared" Speicher

Gast #4385498
Hallo,
ich habe einen Haupt PIC (PIC16F887) der einen Schrittmotor ansteuert.
Zur Überprüfung ob ein befohlener Schritt auch gemacht wurde habe ich 
einen zweiten PIC (PIC16F887) der sich um die Signale des Schrittmotor 
Encoders kümmert und nach jedem gemessenen Schritt eine Leitung zum 
Haupt PIC auf High oder Low setzt (LOW = Drehrichtung Links, HIGH = 
Drehrichtung Rechts) und auf einer zweiten Leitung einen kurzen Puls 
gibt.
Beim Puls auf der zweiten Leitung wird ein Interrupt ausgelöst der einen 
2 Byte Wert erhöht oder Verkleinert abhängig davon was die erste Leitung 
signalisiert.
So weis der Haupt PIC, nachdem er sich einmal kalibriert hat immer genau 
auf welcher Position sich der Schrittmotor bzw. der dadurch bewegte 
Schlitten befindet.

Jetzt meine eigentliche Frage, gibt es eine bessere Methode ohne das der 
Haupt PIC sich mit Interrupts oder sonstwie im Hauptprogramm mit dem 
Encoder auseinander setzten muss, sodass dem Haupt Pic einfach nur noch 
die 2 Bytes als Daten zur Verfügung stehen?
Also z.B. habe ich mal gesehen, dass ein paar PIC18ner DMA unterstützen.
Ich habe aber mich nicht weiter in DMA eingearbeitet weswegen ich nicht 
weiß, ob das überhaupt infrage kommt klang jedoch zunächst ganz 
vielversprechend.
Oder gibt es externe ICs die als Speicher Erweiterung dienen und auf die 
2 PICs gleichzeitig zugreifen können?
Gast
Einfach 2 Ports parallel verbinden, Outputs vom Encoder-PIC an Inputs 
vom Treiber-PIC. Je nach nötiger Auflösung reichen wohl auch 10 oder 12 
Pins.

Einziger Wermutstropfen: Zur Synchronisation braucht man noch einen 
"valid"-Pin. Wenn der "nicht valid" anzeigt, muss der Treiber-PIC ein 
zweites Mal lesen.
Gast
eagle user schrieb:
> Einfach 2 Ports parallel verbinden, Outputs vom Encoder-PIC an
> Inputs
> vom Treiber-PIC. Je nach nötiger Auflösung reichen wohl auch 10 oder 12
> Pins.
>
> Einziger Wermutstropfen: Zur Synchronisation braucht man noch einen
> "valid"-Pin. Wenn der "nicht valid" anzeigt, muss der Treiber-PIC ein
> zweites Mal lesen.

Wie meinst du das genau, 2 Ports parallel verbinden, was habe ich davon?
Wie bekomme ich jetzt die 2 Byte vom Encoder Pic auf den Haupt Pic und 
wie kann der Haupt Pic die 2 Bytes Löschen zur Kalibrierung?
Gast
Für so wenig zu übertragende Werte ist es denke ich okay wie du es 
aktuell machst. Bei wesentlich größeren Mengen könnte zum Beispiel ein 
Dual Port SRAM interessant sein.
Gast
Osccon schrieb:

> Wie bekomme ich jetzt die 2 Byte vom Encoder Pic auf den Haupt Pic
Der Encoder Pic schreibt die aktuelle Position in seinen Output Port. 
Der Haupt Pic liest seinen Input Port und hat damit direkt die Position.

> wie kann der Haupt Pic die 2 Bytes Löschen zur Kalibrierung?
Garnicht, das muss der Encoder Pic machen. Naja, ich betrachte das von 
ganz "oben", da ist es so nur logisch.
Gast
Dann müsste ich aber ja 16 Leitungen verlegen, das sind schon etwas zu 
viel, vor allem da ich zwei Schrittmotoren also 2 Encoder ansteuern 
muss, dann wäre ich ja schon 32 Leitungen... :)
Gast
Lass doch den Encoder PIC alles machen:
Bei Flankenwechsel ein INT auslösen, 2 Byte hoch oder runterzählen.

Beide Pics über SPI (4 Pins) verbinden.

Der Haupt PIC kann dann, wann immer er will, über SPI die aktuellen 
Daten pollen.
Osccon schrieb:
> Jetzt meine eigentliche Frage, gibt es eine bessere Methode ohne das der
> Haupt PIC sich mit Interrupts oder sonstwie im Hauptprogramm mit dem
> Encoder auseinander setzten muss, sodass dem Haupt Pic einfach nur noch
> die 2 Bytes als Daten zur Verfügung stehen?

Sorry, aber warum fängst du das nicht mit einem PIC ab? Es muss ja kein 
16er sein. Der Umstieg auf die PIC18 ist relativ easy, damit hast du 
bessere Hardware, fast identische Befehle (falls dir ASM liegt) und 
wesentlich höhere Taktfrequenz. Vielleicht erklärst du erst mal, warum 
da das mit zwei µC machst. Gibt es dafür einen Grund?

Osccon schrieb:
> Ich habe aber mich nicht weiter in DMA eingearbeitet weswegen ich nicht
> weiß, ob das überhaupt infrage kommt klang jedoch zunächst ganz
> vielversprechend.

Das ist wie mit Atombomben auf Spatzen geschossen. Das gewünschte 
Ergebnis erreichst du vielleicht, doch die Kollateralschäden sind 
massiv. Wenn sich zwei µC unterhalten müssen, macht man das seriell, 
z.B. über den UART oder SPI. Dafür hast du jeweils Hardwaremodule, 
schreibst die Daten in den Puffer und los gehts. Kommt vom anderen µC 
was rein, löst das HW-Modul einen Interrupt aus und du kannst die Daten 
verarbeiten. Die oben beschriebene parallele Übertragung über zwei Ports 
kann man zwar machen, es geht seriell aber einfacher. Zumal man sich da 
I/O-Pins spart.
Gast
> ohne das der Haupt PIC sich mit Interrupts ... auseinander setzten muss

Wieso willst du auf Interrupts verzichten? Diese Mikrocontroller sind 
genau dafür konstruiert, mehrere Aufgaben in Interrupts quasi 
gleichzeitig zu machen.

Für den Einstieg ist eine Hauptschleife mit Warteschleifen sicherlich 
ideal. Nur stößt du da ziemlich schnell an Grenzen.

Wenn du so etwas ein paar mal gemacht hast, wirst du deine Programme 
sowieso ganz anders anlegen. Die Hauptschleife bereitet nur die Arbeit 
für die Interruptroutinen vor.

Antwort schreiben

Eine eigene Frage? Dieser Thread ist über 10 Jahre alt. Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.

Neuen Thread starten

Eine Lösung, Ergänzung oder Rückmeldung zu diesem Thread? Dann antworte hier.

Formatierung
  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] – Link zu einem Artikel
  • Verweis auf einen anderen Beitrag: Rechtsklick auf dessen Beitrags-ID (#8078628), „Adresse kopieren“, in den Text einfügen

Mehr zur Formatierung

Längeren Sourcecode als Anhang, nicht in den Text. JPG nur für Fotos und Scans; Zeichnungen und Screenshots als PNG oder GIF. Siehe Bildformate.

Schon registriert? Anmelden

Wird nicht angezeigt. Wir schicken dir einen Link; sobald du damit bestätigst, erscheint dein Beitrag.

Mit dem Abschicken legst du einen kostenlosen Account an und erkennst die Nutzungsbedingungen und die Datenschutzerklärung an.