Hallo zusammen. Ich würde gern ein Bluetoothmodul und ein Xbee Modul an einen AVR anschließen. Beide Module stellen nur UART der Außenwelt zur Verfügung. Bin ich jetzt gezwungen eine Hardware und eine Software UART zu nutzen, oder gibt es auch andere Möglichkeiten. Wenn ich eine S & H UART nutzen will, was sollte man besonders beachten bzw. wo könnten Probleme auftreten. Z.B. beide Module empfangen was?! LG Max
Hi, sehe ich das richtig, dass du dieselbe UART auf zwei Funkmodulen versenden möchtest? Oder möchtest du jeweils unterschiedliche Daten versenden?
Nene... Das ist getrennt. Also im Optimalfall wären 2 getrennte Uarts ne feine Sache. Sprich ich möchte über das Bluetooth Daten verschicken und empfangen und "parallel" dazu Daten verschicken und empfangen vom Xbee.
Max wrote: > Ich würde gern ein Bluetoothmodul und ein Xbee Modul an einen AVR > anschließen. Beide Module stellen nur UART der Außenwelt zur Verfügung. > Bin ich jetzt gezwungen eine Hardware und eine Software UART zu nutzen, > oder gibt es auch andere Möglichkeiten. Wenn ich eine S & H UART nutzen > will, was sollte man besonders beachten bzw. wo könnten Probleme > auftreten. Z.B. beide Module empfangen was?! Wenn beide UARTs über Interrupts laufen, sollte es keine Probleme geben. Auch Vollduplex für beide UARTs ist machbar, hängt nur von deinem Code ab.
Warum nimmst Du nicht einfach einen ATMega164 bzw. 324 bzw. 644? Der hätte nämlich 2 HW-UARTs. Evtl. ist der sogar weitgehend pinkompatibel?
Ah ok... joa hatte ich auch schon dran gedacht. Allerdings sind die ja doch schon recht groß für mein Projekt. Will versuchen ein möglichst kostensparendes Modul zu bauen. Nicht weil ich geizig bin, sondern weil ich es auf das nötigste beschränken will. Aber der ATMega164 ist schon ein feines Ding... :)
Bedenke: Durch die Verwendung eines SW-UARTs bürdest Du dir selbst (unnötige) Schmerzen und Einschränkungen bei der Produktentwicklung auf. Es ist möglich - keine Frage. Antun würde ich es mir indes nicht! Bei einer Kleinserie oder gar einem Einzelstück spielt der Mehrpreis keine Rolle, selbst bei einer Großserie würde kein vernünftiger Entwickler solche Unwägbaarkeiten (z.B. für Weiterentwicklungen der SW) eingehen.
Ok... da hast du wohl recht. Ich glaube, ich werde auch den oben genannten Atmega nehmen. Alles andere würde glaube ich auch mein Diplomthema sprengen. Ist schon arbeit genug mich in Zigbee einzulesen! ;-)
Harald wrote: > Bei einer Kleinserie oder gar einem Einzelstück spielt der Mehrpreis > keine Rolle, Einverstanden. > selbst bei einer Großserie würde kein vernünftiger > Entwickler solche Unwägbaarkeiten (z.B. für Weiterentwicklungen der SW) > eingehen. Oh doch. Ich weiß auch nicht, an welcher Stelle man da irgendwelche Unwägbarkeiten eingeht, da die benötigte Rechenleistung und die benötigte Hardware klar bestimmbar sind. Was spricht dagegen, wenn man einen Timer-Block und eventuell noch einen Interrupt fähigen Pin zur Verfügung hat? Die Anforderungen an den Controller müssen sowieso im Voraus klar sein. @Max: So schwer ist ein zweiter Software-UART nicht, zumal du in der Codesammlung sehr guten Code findest für AVR-Controller. Ich habe selber auch schon einen Hardware und einen Software-UART gleichzeitig bei einem ATmega8 in Betrieb gehabt, oder bei einem MSP430 einen Hardware-UART, einen Software-UART (jeweils vollduplex) und noch einen dritten halbduplex UART. Für eine Diplomarbeit ist es meines Erachtens jedoch egal, das würde an der Bewertung des Gesamtsystems nichts ändern (so zumindest meine Erfahrung).
Gut ich denke ich werde erstmal die Variante mit dem großen AVR machen. So bekomm ich wenigstens schon mal recht zügig was zu laufen und testen. Muss ja auch erstmal Erfahrung sammeln. Und je nachdem werde ich dann das ganze System verkleinern... Aber lieben Danke für die coole Hilfe! :-)
Also mir ist das recht, soll jeder so machen wie er meint. Meiner(!!!) Meinung(!!!) nach hat allein aus EMV-Gesichtspunkten die SW-UART nichs in größeren Serien verloren, der HW-UART ist hier der Vorzug zu geben. (Falls jemand nicht weiß, was EMV mit der UART zu tun hat, siehe Datenblatt: Asynchronous Data Recovery). Mit Unwägbarkeiten meine ich insbesondere Latenzen und Interrupt-Prioritätsverschiebungen aufgrund von ungeplanten Erweiterungen. Aber wie schon gesagt, es gibt halt unterschiedliche Ansprüche und Designziele.
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.