Hallo und wer kann helfen. Ich beabsichtige eine Multiprozessorsteuerung aufzubauen, meist nutze ich C für meine Projekte und komme damit auch meist gut zurecht. Mit Interrupt-gesteuerten Routinen habe ich aber garkeine Erfahrungen. Für die Multiprozessorsteuerung benötige ich hier eine Routine welche einerseits Interruptgesteuert die RX empfängt, prüft ob die Daten für diesen Prozessor adressiert sind und wenn nicht diese über TX (ebenfalls Interruptgesteuert)an den nächsten Slave weiter gibt. Ich habe versucht aus den anderen Beiträgen schlau zu werden, leider ohne großen Erfolg. Gibt es eine "Standardt-Routine" für solch ein Problem, um die ich dann meinen eigenen Code drum rum schreiben kann? Vorteilhaft erscheint mir an dieser Stelle auch die Programmierung in Assembler um Platz und Zeit für die "Hauptanwendung" des Prozessors zu haben. Gruß Malcom PS: Ich habe ein Schema mal angehängt, um das Problem zu verdeutlichen
Angehängte Dateien:
Verwende einen RS-485 Bus und betreibe die ATmega im Multiprozessormodus. Auf Deinem Plan sehe ich einen ATM8 mit Display 480x200; ob der Prozessor dafür geeignet ist, würde ich zuvor gründlichst prüfen.
für die Textausgabe auf dem Display funktioniert die Sache schon prima und mehr will ich da auch garnicht darstellen. Aber ob der Platz noch für das RS 485 Prozedere reicht weis ich nicht. Das Programm habe ich hier aus dem Forum: Beitrag "Pollin Display Optrex F-51154NF-FW-AA" von Benedikt K. (benedikt). Es ist in Assembler geschrieben und unterstützt derzeit nur den RX im Interrupt-modus. Ob TX noch implementierbar ist weis ich leider auch nicht, weil der Platz wohl schon recht eng ist. Gruß Malcom
> weil der Platz wohl schon recht eng ist.
Dann nimm die ATmega doch alle mindestens eine Nummer größer z.B.
ATmega168. Und auch die Tiny2313 sind ein bißchen knapp für eine
Schrittmotoransteuerung. Wenn ich 1/8 Schritte mit Rampe erzeuge brauche
ich auf einem Mega8 rund 5k. Und ich werde mich hüten, in Assembler zu
programmieren, bloß um beim µC dann 10 Cent Kaufpreis zu sparen.
Klotzen, nicht kleckern :-)
Also, ich meine, abgesehen davon, dass die Hardware weitestgehend fertig aufgebaut ist... und...auch über UART (ohne Multiprozessor und ohne Interrupt) seine Funktion erfüllt, wollte ich hier eigendlich Tipps für die Programmierung des Interruptgesteuerten TX / RX bzw. für eine "Standardtprogrammierung" für Multiprozessorbetrieb. Schlagworte bringen mich da nicht weiter... Sollte sich dann bei einem guten Codevorschlag herrausstellen, dass der Prozessorspeicher nicht reicht, werde ich gern auf einen größeren Prozessor updaten. Gruß Malcom
Ich würde beim Konzept daran denken, ALLE Nachrichten IMMER gleich weiter zu geben. Auch diese, die für mich bestimmt sind. Dann kann der Absendende sein eigenes Telegramm noch mal überprüfen, weil es ja wieder bei ihm ankommt. Außerdem hast du dann die Möglichkeit, Telegramme an mehrere oder alle Teilnehmer im Ring zu schicken.
Willst du nur empfangen oder auch senden können? Müssen die Controller untereinander reden?
Fertigen Code gibts da vermutlich nicht so wirklich, die meisten Leute versuchen glaube ich größere Mengen (>2) an µCs zu vermeiden wo es geht... Und was für "Tips" willst du den?
>Schlagworte bringen mich da nicht weiter...
Man hilft ja immer gerne, eigendlicht.
Hallo und danke für die rege Beteiligung, Route_66 (Gast) hat die Proplematik gut wieder gegeben..... Der Master schickt Daten an einen Slave....dieser sendet dann die Antwort über den Ring wieder zum Master. Will heisen....Nachrichten die nicht für einen Slave bestimmt sind werden über TX sofort weiter gegeben.....Daten die für Ihn bestimmt sind werden Empfangen verarbeitet und eine "Empfangsbestätigung" zum Master geschickt. So ist es gedacht. Läubi .. (laeubi) schön wäre es schon, wenn Fehler oder Statusmeldungen vom Slave an den Master gegeben werden können, leider weis ich nicht in wie weit dies vom "Multiprozessorprotokoll" unterstützt wird. Eine Communikation der Slaves ist nicht vorgesehen. Chef ist der Master. abraxas (Gast) Ich habe in verschiedenen I-Net Beiträgen Codebeispiele gesehen, diese waren aber immer nur fragmentarisch. Aufgeschnappt habe ich daraus, dass einige Interruptaufrufe "fest" definiert sind. Leider habe ich keinen blasen Schimmer wie ich diese Codeschnipsel zu einem Ganzen zusammenfügen kann, da mir hierfür einfach die Erfahrungen fehlen. Sprich der Prozessor macht hier ein paar Sachen automatisch, wo ich einfach nicht weis, was wann in welchem Umfang passiert. Die meisten diesbezüglichen Beiträge lesen sich als wären sie für Leute geschrieben, die eh wissen wie es geht und nur noch paar einzelne Details bräuchten. abraxas schrieb weiter: "Und was für "Tips" willst du den?" Nun ich kann mir nicht vorstellen, dass sich der Code für den Einzelprozessor in meinem Beispiel nennenswert unterscheiden soll. Ein Byte wird vom Master gesendet für Slave 2, 3, 4 oder 5 die nicht Adressierten Slaves geben das Empfangene Byte immer gleich über TX weiter, der Adressierte schreibt es in den Speicher und sendet eine Quittung. Wie schreibe ich solchen Code für Interrupt gesteuerten RX/TX....oder gibt es vielleicht "vollständige Beispiele" die gut dokumentiert sind???? Gruß Malcom
Hallochen noch mal, vielen Dank noch mal für die bisherigen Beiträge....aber gibt es niemanden, der Erfahrungen mit Interruptprogrammierung hat und mir über die ersten "Stolpersteine" (in C) helfen könnte? Gruß Malcom
@ Dietmar G. (malcom) >Ich beabsichtige eine Multiprozessorsteuerung aufzubauen, meist nutze >ich C für meine Projekte und komme damit auch meist gut zurecht. Mit >Interrupt-gesteuerten Routinen habe ich aber garkeine Erfahrungen. >Für die Multiprozessorsteuerung benötige ich hier eine Routine welche >einerseits Interruptgesteuert die RX empfängt, prüft ob die Daten für >diesen Prozessor adressiert sind und wenn nicht diese über TX (ebenfalls >Interruptgesteuert)an den nächsten Slave weiter gibt. Auch was? Keine Erfahrung mit Interrupts aber eine Multiprozessorsteuerung bauen wollen? Du siehst mich schmunzeln. ;-) Mach dich erstmal schlau über das Thema Interrupt, versuch es dann in eigenen Projekten erfolgreich umzusetzen. Dann solltest du was über Multitasking lernen und ebenfalls selber umsetzen. >Vorteilhaft erscheint mir an dieser Stelle auch die Programmierung in >Assembler um Platz und Zeit für die "Hauptanwendung" des Prozessors zu >haben. Nööö, vollkommen unsinning. Lies die Artikel oben und denk drüber nach. Dann wirst du merken, das man dein Projekt höchstwahrscheinlich locker mit EINEM AVR durchziehen kann. Denn deine Multiprozessorsteuerung ist was für Leute, die EINEN Prozessor bestens im Griff haben. Und nix für Leute, die nicht mal über Interrupts Bescheid wissen. MfG Falk
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.