mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Verteilung von Aufgaben auf mehrere AVRs


Autor: Thomas Burkhart (escamoteur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

mein Projekt muss ingesamt 3 verschiende Aufgabenblöcke bewältigen:

1. Kommunikation über ein zigBee Modul, angebunden über UART
2. Kommunikation mit einem IPOD plus Steuerung eines kleinen Mischpultes 
Lautstärke der einzelnen Kanäle wird über ein serielles Protokoll 
angesteuert. Sowie einige Potis sollten ausgewertet werden
3. Kommunikation mit einem PC über RS232

Ich bin jetzt nicht sicher, ob ein einzelner MEGA32 dafür ausreicht, 
besonders wegen der vielen seriellen Ports, daher bin ich am Überlegen, 
ob ich den ganzen Soundteil nicht durch einen eigenen AVR regeln lasse, 
der lediglich Befehle vom Master AVR bekommt.

a) Was meint Ihr dazu?
b) Welches ist die beste Art zwei AVRs miteinaner kommunizieren zu 
lassen?

Grüße

Thomas

Autor: Jörg B. (manos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie arbeitet denn die Kommunikation zum IPOD? Der Mega644P hat 2 UARTS, 
ansonsten kann man immer noch Software-SIOs implementieren (bis zu einer 
gewissen Baudrate wahrscheinlich).

Autor: Thomas Burkhart (escamoteur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hatte ich vergessen, der IPOD ist auch RS232, aber dir Geschwindigkeit 
sollte kein Problem sein. Ich denke nur, dass mir langsam die Seriellen 
Ports auch mit Software UARTS ausgehen, besonders wenn man für das Noch 
mal min. 3 Ports brauche.

Der andere Grund zur Überlegung war, das dadurch das Gesamte System 
etwas übersichtlicher würde.

Gruß

Thomas

Autor: Analog (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
uart muxen -> hc4052

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas Burkhart wrote:
> Hatte ich vergessen, der IPOD ist auch RS232, aber dir Geschwindigkeit
> sollte kein Problem sein. Ich denke nur, dass mir langsam die Seriellen
> Ports auch mit Software UARTS ausgehen, besonders wenn man für das Noch
> mal min. 3 Ports brauche.

Du brauchst insgesamt 3 UART, richtig?
Das macht 6 Pins.
1 UART kriegst du in Hardware, die anderen beiden müsste man
in Software machen. Ist nicht unbedingt trivial aber auch wieder
nicht Raketentechnik. So eine Software UART ist im Grunde auch
nur ein Schieberegister, das bestimmte Timingvorgaben erfüllen
muss. Solange wir hier nicht über was weiss ich wieviele kBaud
reden, ist das kein grosses Problem.

>
> Der andere Grund zur Überlegung war, das dadurch das Gesamte System
> etwas übersichtlicher würde.

Das wird aber durch die Aufgabenverteilung auf mehrere µC
auch nicht übersichtlicher. Die komplette Aufgabenstellung
wird dadurch eher noch erschwert, weil du dann noch zusätzliche
Kommunikationswege im System hast.

Muss der Mega32 ausser der Weiterleitung von Kommandos noch
etwas machen? Irgendwelche Led, Motoren oder sonstige Hardware
ansteuern? Mit den 3 UART, vorausgesetzt wir reden nicht über
sehr, sehr hohe Baudraten, ist der Mega32 noch lange nicht
ausgelastet.

Autor: Thomas Burkhart (escamoteur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

wenn wir richtig Zählen, dann haben wir insgesamt 5UART, ich weiß nicht 
obs da eng wird. zusätzlich muss der MEGA32 natürlich noch ein 
Kontrollprogramm ausführen.

Gruß

Thomas

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hardware UART-ICs extern hinzufügen und über SPI/parallel oder sowas 
ansteuern?

Autor: Thomas Burkhart (escamoteur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ganz ehrlich, dann schon eher einen zweiten AVR.

Vielleicht ein wenig zur Erleuterung: Ich komme stark aus der 
Objektorientierten Softwareentwicklung und empfinde die Vorstellung ein 
einen AVR zu haben, bei dem mehr IQR Routinen für die UARTs gleichzeitig 
laufen als das Hauptprogramm etwas unheimlich.
Daher war die Vorstellung eines "MusicControllers" dem der Master nur 
Kommandos schicken muss recht attraktive, sozusagen die AVRs als Objecte 
die gegenseitig Methoden bei sich auffrufen. Die gesamtkomplexität würde 
eben auf zwei µC aufgeteilt und jeder dadruch übersichtlicher.

Gruß

Thomas

Autor: Spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Mal ne Frage: Wenn dir die USB-Schnittstellen an deinem Rechner nicht 
mehr reichen, kaufst du dir da einen zweiten PC, oder erweiterst du die 
Schnittstellen?

>Ich komme stark aus der
>Objektorientierten Softwareentwicklung und empfinde die Vorstellung ein
>einen AVR zu haben, bei dem mehr IQR Routinen für die UARTs gleichzeitig
>laufen als das Hauptprogramm etwas unheimlich.

Eigentlich sollte dir OOP unheimlich vorkommen.

Ich würde dir das gleiche wie Matthias vorschlagen,möglichst mit FIFO, 
oder du nimmst einen ATMega1280 oder ATMega2560. Die haben 4 
Hardware-UARTs und genug Speicher für OOP.

MfG Spess

Autor: Thomas Burkhart (escamoteur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn ich aber meine Idee mit zwei ARSs verfolgen möchte, auf welche Art 
verbindet man zwei AVRs am einfachsten? SPI, I²C, RS232?

Grüße

Thomas

Autor: scherzkecks (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
WLAN, sonst ist es dir zu einfach...

Autor: Thomas Burkhart (escamoteur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie Gut das Dein Username schon alles sagt ;-)

Autor: Peter Mahlknecht (pmahlknecht)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas Burkhart wrote:
> Wenn ich aber meine Idee mit zwei ARSs verfolgen möchte, auf welche Art
> verbindet man zwei AVRs am einfachsten? SPI, I²C, RS232?

Kommt auf die Anwendung an,
RS-232 ist für Point-to-Point Verbindungen gedacht, also verbindung 
zwischen zwei (gleichberechtigten) Geräten,
SPI ist ein Bus mit Master-Slave-Prinzip, selbiges gilt für I²C, wobei 
dieser Bus auch multimasterfähig ist. Soll es einer dieser beiden 
Datenbuse sein, sollte man noch beachten, dass bei SPI jeder 
Busteilnehmer eine eigene Select-Leitung vom Master benötigt, was bei 
I²C auf Grund der Softwareadressierung nicht nötig ist.

Grüße Peter

Autor: Oops (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt doch noch einen Mega mit 4 UARTs. Ginge der nicht vielleicht.

Gruss
Oops

Autor: Oops (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tschuldigung. Wurde schon vorgeschlagen.

Autor: Spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Wenn ich aber meine Idee mit zwei ARSs verfolgen möchte, auf welche Art..?

Evtl. auch parallel. Kostet zwar ein paar Leitungen, ist aber schnell 
und man muss sich nicht irgendwelchen Fremdprotokollen unterwerfen.

Trotzdem noch mal meine unmaßgebliche Meinung: OOP, falls du das 
vorhast, mag auf einem Controller noch angehen (frage mich aber bitte 
nicht, was ich davon halte, bin auf dem Gebiet notorischer 
Assemblerprogrammierer). Aber bei der Aufteilung auf 2 oder mehr 
Controller, wirst du das, was sonst dein Compiler für dich erledigt, 
alles von Hand machen müssen.

MfG Spess

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ich komme stark aus der
>Objektorientierten Softwareentwicklung und empfinde die Vorstellung ein
>einen AVR zu haben, bei dem mehr IQR Routinen für die UARTs gleichzeitig
>laufen als das Hauptprogramm etwas unheimlich.

Solang das mit dem Timing hinhauen würde, was solls? Ich persönlich 
finde es immer am schönsten, wenn der uC in main hauptsächlich in einem 
low-power Modus schläft und der Rest bei Bedarf von Interrupts erledigt 
wird. Das kann man bei den msp430 oft so machen, weiß nicht was die AVRs 
in Sachen low-power können. Ist hier wohl aber auch nicht so wichtig :)

Autor: Thomas Burkhart (escamoteur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>
> Trotzdem noch mal meine unmaßgebliche Meinung: OOP, falls du das
> vorhast, mag auf einem Controller noch angehen (frage mich aber bitte
> nicht, was ich davon halte, bin auf dem Gebiet notorischer
> Assemblerprogrammierer). Aber bei der Aufteilung auf 2 oder mehr
> Controller, wirst du das, was sonst dein Compiler für dich erledigt,
> alles von Hand machen müssen.


Der Hinweis auf OOP war auch mehr als Analogie gdeacht, dass ich eine 
gekapselte Einheit (Object) habe, dass über eine definierte 
Schnittstelle bestimmte Dienste zur Verfügung stellt ohne dass ich als 
Client irgendetwas über die internen Abläufe in diesem Objekt wissen 
muss.

Und eben dies hätte ich ja mit einem zweiten AVR, der auf definiete 
Befehle vom Master definierte Aufgaben abarbeitet.

P.S.: Hatte auch nicht vor einen µC in OO zu programmieren, sehe hier 
auch keine Notwendigkeit aber C muss es schon sein, habe Assembler 
leider nie richtig programmieren gelernt, kann Assembler so leidlich 
lesen :-(

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Spess53 verwechselt da etwas.
Er denkt, daß OOP mit einer Sprache zusammenhängt und weiß nicht, daß 
das ein Konzept bzw. Programmierparadigma ist und somit von der Sprache 
unabhängig.

Ein halbwegs intelligenter Assemblerprogrammierer macht auch nix 
anderes.

Autor: Thomas Burkhart (escamoteur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Kommt auf die Anwendung an,
> RS-232 ist für Point-to-Point Verbindungen gedacht, also verbindung
> zwischen zwei (gleichberechtigten) Geräten,
> SPI ist ein Bus mit Master-Slave-Prinzip, selbiges gilt für I²C, wobei
> dieser Bus auch multimasterfähig ist. Soll es einer dieser beiden
> Datenbuse sein, sollte man noch beachten, dass bei SPI jeder
> Busteilnehmer eine eigene Select-Leitung vom Master benötigt, was bei
> I²C auf Grund der Softwareadressierung nicht nötig ist.


Bei RS232 muss ich mich natürlich komplett um ein eigenes Protokoll 
kümmern. I²C hat ja schon ein Device/Kommando Struktur, ich weiß aber 
nicht, wie sehr dies beim AVR automatisiert ist.

Von SPI habe ich wenig Ahnung und so wie es müsste ich ja auch erst ein 
Kommando Protokoll implemetieren.

So gesehen wäre I²C wohl das geeignetste oder?

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Dirk (Gast)

>Spess53 verwechselt da etwas.
>Er denkt, daß OOP mit einer Sprache zusammenhängt und weiß nicht, daß
>das ein Konzept bzw. Programmierparadigma ist und somit von der Sprache
>unabhängig.

Nicht ganz. C++ & Co haben von Haus aus umfangreiche Unterstützung für 
OOP. In ASM muss man das alles mühsam per Hand machen.

>Ein halbwegs intelligenter Assemblerprogrammierer macht auch nix
>anderes.

Ein halbwegs intelligenter Assemblerprogrammierer programmiert OOP in 
C++ ;-)

MfG
Falk

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Thomas Burkhart (escamoteur)

>kümmern. I²C hat ja schon ein Device/Kommando Struktur, ich weiß aber
>nicht, wie sehr dies beim AVR automatisiert ist.

Nur auf unterster Byteebene.

>Von SPI habe ich wenig Ahnung und so wie es müsste ich ja auch erst ein
>Kommando Protokoll implemetieren.

Ist nicht mehr und nicht weniger Aufwand als I2C.

>So gesehen wäre I²C wohl das geeignetste oder?

Nö, ist nur eine von vielen Möglichkeiten.

MFG
Falk

P.S. Das bisschen was du da machen willst macht EIN AVR im Schlaf. Die 
Herausforderung ist "nur" die verschiedenen Aufgaben quasi parallel zu 
erledigen. Das geht mit Interrupts und State Machines. Da mit C++ 
anzufangen ist Overkill. C ist gut und ausreichend, zumal du ja was 
lernen willst.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sehe ich das jetzt richtig, dass der Threadopener unbedingt mehrere AVRs 
aufwändig und langsam über einen I2C Bus vernetzen will, weil im nicht 
gefällt, dass mehrere aktivierte Interrupts "auf einmal" zuschlagen 
können? Bzw. weil er sich mehr OOP fühlt, wenn er die Aufgaben auf jeden 
AVR verteilt, der dann zu 99% nichts zu tun hat?

Mich wundert ein wenig dass hier noch keiner bemerkt hat was für ein 
Quatsch das überhaupt ist.

Nimm doch einen AVR mit 4 Hardware UARTs, wo du eventuell die am 
kritischsten (vom Timing her) Sachen anschließt (Wo also am meisten 
gesendet/empfangen wird). Und die Schnittstelle zum PC bspw. machst du 
einfach mit einer Hardware-UART.

Denn wie Falk schon sagt, reicht für sowas ein AVR absolut aus. Manche 
tendieren dazu den kleinen zu unterschätzen ;) Aber wenn man sich mal 
anschaut, dass man sogar einen WebServer mit moderater Durchsatzrate auf 
so einem kleinen Käfer eingebaut kriegt, dann sollte man das nochmal 
überdenken ;)

Autor: Thomas Burkhart (escamoteur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, auch wenn der Kollege von eben das ganze für Quatsch hält, hate ich 
es für eine vom Design her sinnvolle Lösung. Wie gesagt OOP verseucht 
steht man halt auf dezentrale intelligente Komponenten.

Ich denke ich werde es mal mit dem TWI Interface von Manni
[Beitrag "AVR TWI Master und Slave Funtionen in C"]

Versuchen

Vielen Dank auf jeden Fall hab wieder ne Menge gelernt.

Thomas Burkhart

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.