Hallo, ich habe hier einen Mega32, der über eine 1-Draht Verbindung an einen Mega8 eine Ziffer zwischen 0 bis 9 senden soll. Eine Rückantwort des Mega8 ist nicht erforderlich. In BASCOM würde ich das ja mit Printbin usw. erledigen. Wie stelle ich das aber in C an ? Danke Guido
warum nicht einfach Seriell senden? Ist denn bei beidem µC die UArt noch frei?
Man könnte den TxD des einen Atmega32 mit dem RxD des anderen verbinden, 1 Draht wenn keine Rückantwort nötig, und das entsprechende Print von C verwenden. Über kurze Entfernungen tut es der 5V-Pegel, sonst einen RS-Baustein dazwischen schalten. Sind die beiden Atmegas am gleichen Platz reicht vermutlich sogar der interne Oszillator für die serielle Schnittstelle. (Nach meiner Erfahrung (und mit einer "Autobaud-Routine"))
Die Megas sitzen max. 10cm nebeneinander. Evtl. kann ich sie sogar stapeln. Bin ich zwingend an TxD / RxD gebunden , oder kann ich die Pins auch frei wählen ? Wie realisiere ist das in C ?
@ Anton (Gast) >Sind die beiden Atmegas am gleichen Platz reicht vermutlich sogar der >interne Oszillator für die serielle Schnittstelle. Nein, das tut er nicht! >(Nach meiner Erfahrung (und mit einer "Autobaud-Routine")) Das ist ein glücklicher Einzelfall. MFg Falk
@ Guido S. (Gast) >Die Megas sitzen max. 10cm nebeneinander. Evtl. kann ich sie sogar >stapeln. Bin ich zwingend an TxD / RxD gebunden , Ja. > oder kann ich die Pins auch frei wählen ? Nein, das geht nur mit einem Soft-UART, der ist aufwändiger. > Wie realisiere ist das in C ? Wozu überhaupt ZWEI AVRs? Wegen ein paar Zahlen anzeigen? Das macht EIN AVR nebenbei, und langweilt sich immer noch. MFG Falk
Falk Brunner schrieb: > Wozu überhaupt ZWEI AVRs? Wegen ein paar Zahlen anzeigen? Das macht EIN > > AVR nebenbei, und langweilt sich immer noch. woher weißt du dass er nur ein paar Zahlen anzeigen will?
Thomas B. schrieb: > Falk Brunner schrieb: >> Wozu überhaupt ZWEI AVRs? Wegen ein paar Zahlen anzeigen? Das macht EIN >> >> AVR nebenbei, und langweilt sich immer noch. > > woher weißt du dass er nur ein paar Zahlen anzeigen will? Standard-Erfahrung hier im Forum, die in 90% aller Fälle zutrifft: Keine UART Verbindung von A nach B programmieren können aber für jeden Scheiss einen eigenen Prozessor vorsehen, weil der Hauptprozessor ja mit dem lösen von quadratischen Gelichungen soooooo ausgelastet ist. Merke: Wenn man für das Erstellen einer Partyeinladung mit Word schon einen 3 GHz Prozessor braucht, dann muss zumindest jede einzelne Stelle einer 7-Segment Anzeige ihren eigenen 20Mhz-Prozessor bekommen. Kann natürlich sein, dass wir falsch liegen und es tatsächlich sinnvoll ist, beim konkreten Proejekt eine Aufteilung in mehrere Prozessoren vorzunehmen. Möglich ist es, aber nicht sehr wahrscheinlich. Wer tatsächlich so ein aufwändiges Projekt macht, weiß wie eine UART funktioniert.
Nochmal Hallo zusammen, vielen Dank für die sinnvollen Antworten. Ich bin mir allerdings nicht sicher, wie man sich hier im Forum den Status eines Moderatoren verdienen kann wenn die User Anfragen derart beantwortet werden. Was für'n "Scheiss" ich hier zusammen bauen möchte, sollte doch tatsächlich meine Sorge bleiben. Ob mein angestrebtes Objekt einen weiteren Controller rechtfertigt oder nicht, dürfte ebenfalls von untergeordnetem Intresse sein. Ich denke, dass ich meine Frage verständlich ausgedrückt habe. Und ich habe diese Frage gestellt, WEIL ich nicht weiss, wie eine UART in C programmieren kann. Also Herr Buchegger. um in Ihrem Sprachgebrauch zu bleiben, "Behalten Sie doch ihren Scheiss für sich"
Als Ergänzung zu den 90%: Die Ein-Draht-Verbindung setzt natürlich einen 2. (dicken) Draht voraus: die Masseverbindung zwischen beiden Prozessoren. Bernhard
> Und ich habe diese Frage gestellt, WEIL ich nicht weiss, wie eine > UART in C programmieren kann. Dann hast du aber die Suchfunktion hier im Forum nicht bemüht. Karl Heinz schreibt diese Pauschalierung nicht, weil ihm gerade nach Pauschalierungen ist. Sondern weil das Problem jeden Tag in irgenwelchen abwandlungen immer wieder auftaucht. Sieh dir das doch mal an: http://www.mikrocontroller.net/search?query=%2Bavr+%2Brs232+%2Bcode&forums[]=1&forums[]=2&max_age=-&sort_by_date=0
Und weil die alle nicht faehig waren, die Suchfunktion zu benutzen. Gast
M803 schrieb: > Und weil die alle nicht faehig waren, die Suchfunktion zu benutzen. Offenbar: denn für die Frage "wie mache ich mit einem AVR eine serielle Verbindung?" hätte prinzipiell 1 Antwort gereicht. Das ändert sich ja nicht jeden Tag... > Und weil die alle nicht faehig waren, die Suchfunktion zu benutzen. Oder: weil sie meinten, sie hätten das ultimative und alleinige Problem, eine RS232 Verbindung aufbauen zu müssen.
Ich hätte jetzt gesagt, dass man, um 0..9 zu senden keinen UART o.Ä. braucht. Pin des einen an Pin des anderen. B lauscht jetzt immer meinetwegen 255 ms lang, ob da was kommt. A sendet 0..9 mit 1..10 Impulsen mit 5 ms Länge und 5 ms Pause. Nach der Übertragung 100 ms Pause und Wiederholung. Dann nocheinmal eine Wiederholung nach 30 ms. B muss jede ms den Pin abfragen. Wenn Jetzt zwei mal das gleiche Ergebnis angekommen ist, ist die Übertragung erfplgreich gewesen. Ganz primitiv. Takte egal.
Lothar Miller schrieb: >> Und ich habe diese Frage gestellt, WEIL ich nicht weiss, wie eine >> UART in C programmieren kann. > Dann hast du aber die Suchfunktion hier im Forum nicht bemüht. Karl > Heinz schreibt diese Pauschalierung nicht, weil ihm gerade nach > Pauschalierungen ist. Richtig. >Sondern weil das Problem jeden Tag in irgenwelchen > abwandlungen immer wieder auftaucht. > Sieh dir das doch mal an: > http://www.mikrocontroller.net/search?query=%2Bavr+%2Brs232+%2Bcode&forums[]=1&forums[]=2&max_age=-&sort_by_date=0 Und dann gibt es auch noch das AVR-GCC-Tutorial Trotzdem bleib ich bei meiner Meinung: Wer nicht weiß wie er 2 Prozessoren per UART miteinander verbindet, sollte sich zuallererst einmal fragen, ob er überhaupt wirklich 2 Prozessoren benötigt. Diejenigen, die tatsächlich 2 oder mehr Prozessoren für ihr Projekt brauchen, müssen nämlich nicht nach UART fragen. Wie gesagt: Das ist die Erfahrung, die sich hier im Forum im Lauf der Zeit angesammelt hat. Ganz nüchtern betrachtet.
@Testfall Ja genau . Soetwas in der Richtung schwebte mir vor. Dann wäre auch der PIN egal , oder ?
Vielleicht klebt der eine Mik ja auf Netzpotential und der andere nicht ... ist doch auch möglich. Ich hab' ja schon ne primitive, schnelle und einfach Lösung genannt. Ist nicht unbedingt schön, aber fix umgesetzt.
Pin ist vollkommen pappe. Musst hat nur den richtigen abfragen ;-)
Achte drauf, dass du nicht zu 255 passende Pausen zwischen den Übertragungen wählst, dabei aber noch genug Luft hast, dass das Ende der ersten Übertragung sicher erkannt wir. Sonst kommt nur Mist an. Ich würde sagen, das Verhältnis von Sendezeit, Sendepause und Wiederholungspause sollte so ungefähr 1:3:10 sein. Allerdings jeweils so lange Zeiten wählen, dass die mindestens zwei Abtastzyklen (bei "B") entsprchen, damit du immer sicher ein "an" oder "aus" hast. So. Mittagspause zu Ende. Viel Erfolg.
@Testfall Und falls ich nun einmal nach so einer routine suche: welchen technischen Begriff muss ich dafür in die Suchfunktin eintippen ? Das ist doch eine serielle Übertragung, oder ? In BASCOM ist das - wie in meinem ersten Post gesagt - ja recht einfach gehalten . COM definieren und senden.
> welchen technischen Begriff muss ich dafür in die Suchfunktin eintippen
Das ist eine Pulspaketübertragung (weil da immer ein Päcken Pulse
übertragen wird). Aber wozu denn so ein Gewürge (du mußt den Pin pollen,
Flanken erkennen, Timeouts auswerten...) wenn du doch eine RS232 übrig
hast?
Ein Tipp: beschreib einfach, WAS du machen willst, nicht WIE du es
machen willst. Denn sonst kommst du letztlich nie zu mehr Wissen. Denn
du machst ja immer das, was du schon kannst... :-/
Guido S. schrieb: > @Testfall > > Und falls ich nun einmal nach so einer routine suche: welchen > technischen Begriff muss ich dafür in die Suchfunktin eintippen ? Das > ist doch eine serielle Übertragung, oder ? Ja und nein. IMHO gibt es dafür keinen wirklichen Begriff. Das ist ein ziemliches Ad-hoc Verfahren. Am ehesten könnte man es noch als Puls-Count Übertragung bezeichnen, auch wenn es diesen Begriff so nicht gibt. > In BASCOM ist das - wie in > meinem ersten Post gesagt - ja recht einfach gehalten . COM definieren > und senden. Nur hilft dir das nicht viel, weil dein Empfäger in diesem Fall nun mal keine RS232 macht. Am ehesten könnte man, auch wenn sich das jetzt naiv anhört, noch damit vergleichen, wie man sich naiv Rauchzeichen der Indianer vorstellt: 5 Rauchwölkchen hintereinander bedeutet 5. 7 Rauchwölkchen eben 7. Das einzige Problem beim µC: man muss sicherstellen, dass man auch jeweils zum richtigen Zeitpunkt hinschaut, nicht ein Rauchwölkchen 2 mal zählt und die Pause zwischen den Gruppen richtig erkennt. So banal, wie dir Testfall das verkaufen will, ist das nämlich gar nicht.
Wenn ich du wäre und die Hardware UART Pins nicht mehr frei sind und, ganz wichtig, sich auch nicht freischaufeln lassen, würde ich in die Codesammlung gehen und nach Software UART suchen. Irgendwas vom PeDa findet sich da sicher. Meine erste Option wäre: Hardware UART Meine zweite Option wäre: Software UART Hradware UART hat den Charm, das man sich nach der Konfiguration um nichts mehr kümmern braucht. Trifft ein Zeichen ein, so wird ein Interrupt ausgelöst, der die Weiterverarbeitung in die Wege leitet. Je nach Pin, kann man Software-Lösungen auch über Interrupts in die Wege leiten, allerdings ist das Timing dann nicht mehr so simpel hinzubekommen. Vor allen Dingen dann nicht, wenn der Prozessor ohnehin schon bis zur Decke mit Arbeit voll ist.
Naja, man muss halt nachdenken, was passieren kann. Und man muss wissen, ob man nen Timer oder den UART übrig hat. Rauchwölkchen. Das ist gut. Ich persönlich bin ein Fan dieser Methode, weil man die mit ner LED prima nachvollziehen kann, wenn man den Tank etwas runterdreht. Und ja, ich weiß, alles andere ist störfester usw. aber manchmal ist das Rauchzeichenverfahren nützlich. Und manchmal geht's einfach schnell (bspw. mit nem unbekannten, uralten Optokoppler dessen Daten man nicht kennt und ihn nur braucht um mal eben Daten galvanisch getrennt zu übertragen). Guter alter Frickler-Stil eben. :-) Aber der werte Starter dieses Threads hat sich scheinbar eine fertige Lösung gewünscht ... dann uss er eben lernen, mit dem UART umzugehen.
Ich hätte das ganze mit einer PWM oder einer Impulslänge programmiert. Geht mit einer Leitung, man muss allerdings einen Timer initialisieren, damit man messen kann, wie lange der Impuls ist. Ich selbst würde bei 2 Prozessoren nicht die wertvolle UART verschwenden (bauche ich meistens für Debug-Zwecke oder zur Host-Kommunikation), sondern würde eine Eindrahtverbindung machen. Wie man einen Pin in C programmiert, sollte in jedem Sampel-Beginner-Programm drinn stehen, den Timer bekommt man auch noch hin. Der Sender muss seinen Port als Output, der Empfänger als Input konfigurieren. Ob man zwei Prozessoren benötigt, hängt von der Anwendung ab. Wir haben mal einen zweiten wegen der Redundanz spendieren müssen, um sicherheitsrelevante Aufgaben zu erledigen (war im Gesetz gefordert). Ob das Sinn macht oder nicht, haben wir hier nicht zu entscheiden. Nur wenn gefragt wird, ob es eine bessere Lösung gibt. Na dann, viel Spass beim Wälzen des Tutorials...
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.