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
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).
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
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.
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
Hardware UART-ICs extern hinzufügen und über SPI/parallel oder sowas ansteuern?
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
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
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
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
Es gibt doch noch einen Mega mit 4 UARTs. Ginge der nicht vielleicht. Gruss Oops
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
>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 :)
> > 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 :-(
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.
> 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?
@ 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
@ 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.
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 ;)
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
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.